消息传递部分(MTP)第二级用户适配层(M2UA)技术规范

I
No.7信令与IP 互通适配层技术规范 消息传递部分（MTP ）第二级用户
适配层（M2UA ）
Technical Specification of Adaption Layer of No.7 Signalling
Interworking with IP Message Transfer Part （MTP ）Level 2
User Adaption Layer
（报批稿）
中国移动通信企业标准 QB-╳╳-╳╳╳-╳╳╳╳ 中国移动通信集团公司 发布 ╳╳╳╳-╳╳-╳╳发布
╳╳╳╳-╳╳-╳╳实施
目次
前言 (IV)
1. 范围 (1)
2 规范性引用文件 (1)
3 术语和缩略语 (1)
3.1术语 (1)
3.2缩略语 (2)
4 概述 (2)
4.1M2UA的结构 (2)
4.1.1 使用M2UA协议时，信令网关与软交换（或MGC）的关系 (3)
4.1.2 ASP 故障倒换的概念 (3)
4.1.3 客户机/服务器模型 (4)
4.2M2UA适配层提供的业务 (4)
4.2.1 支持MTP-2/MTP-3间的接口 (4)
4.2.2 支持M2UA协议的端点（SG、MGC）与层管理之间的通信 (4)
4.2.3 支持对SG和MGC间偶联的管理 (4)
4.2.4 支持对AS和ASP的状态管理 (4)
4.3M2UA层提供的功能 (5)
4.3.1 映射功能 (5)
4.3.2 支持对SG和ASP之间SCTP偶联的管理 (5)
4.3.3. SG上对ASP的状态管理 (6)
4.3.4 对SCTP 的流管理 (6)
4.3.5 与NO.7信令网管理无缝的互通 (6)
4.3.6 流量控制/和拥塞控制 (6)
4.3.7 查询NO.7信令链路状态 (7)
4.4M2UA边界原语的定义 (7)
4.4.1 M2UA和MTP－3 之间的原语 (7)
4.4.2 M2UA和MTP－2 之间的原语 (7)
4.4.3 M2UA和SCTP之间的原语 (7)
4.4.4 M2UA 和层管理之间的原语 (7)
5 M2UA协议单元格式 (11)
5.1公共消息头 (11)
5.1.1 版本字段 (11)
5.1.2 备用字段 (11)
5.1.3 消息类别字段 (11)
5.1.4 消息类型字段 (12)
5.1.5 消息长度字段 (13)
5.1.6 可变长参数的格式 (14)
5.2M2UA消息头 (16)
5.3M2UA消息 (16)
5.3.1 MTP-2用户适配消息 (16)
5.3.2 应用服务器进程维护消息（ASPM） (22)
5.3.3 层管理（MGMT）消息 (28)
5.3.4 接口标识符管理消息（IIM）（暂不使用） (32)
6. M2UA协议程序 (37)
II
6.1支持M2UA用户层的程序 (37)
6.1.1 MTP-2/MTP-3边界上的程序 (37)
6.1.2 MAUP 消息的程序 (37)
6.2收到层管理的原语 (37)
6.2.1 收到对端M2UA的管理消息 (38)
6.3AS和ASP的状态维护 (39)
6.3.1 ASP 状态 (39)
6.3.2 AS 状态 (40)
6.3.3 M2UA对原语的管理程序 (41)
6.3.4 两个M2UA层之间的ASPM消息 (41)
6.4链路关键字管理程序（暂不使用） (47)
6.4.1 注册 (47)
6.4.2 注销 (48)
7 定时器取值 (48)
附录 A M2UA 程序示例 (49)
附录B SG侧M2UA 通知链路故障原因的程序（国内任选） (58)
III
前言
本标准是根据IETF信令传送部分（Sigtran）中NO.7信令消息传递部分（MTP）第二级用户适配层（M2UA）协议（RFC 3331）制定的，它规定了M2UA所使用的消息格式、编码和程序，并在本文件的附录中给出了应用M2UA协议时的一些流程示例。

M2UA协议主要用于IP网中传送No.7信令消息，特别适用于媒体网关（MGW）透传与MSC Server 之间的No.7信令消息，在这种情况下两种设备都需要具备M2UA功能。

本技术规范主要适用于完成NO.7信令与IP网互通的信令网关（SG）和具备信令网关功能的媒体网关（MGW）设备，以及IP网用于呼叫控制的软交换（Soft-Switch）交换机（MSC Server）等设备M2UA协议的开发和引进。

本标准的附录A是资料性的附录。

本标准由中国移动通信集团公司技术部提出并归口。

本标准由标准提出并归口部门负责解释。

本标准起草单位：中国移动通信集团公司研发中心。

本标准主要起草人：魏冰、杜倩
本标准解释单位：同提出单位。

IV
No.7信令与IP互通适配层技术规范消息传递部分（MTP）第二级用户适配层（M2UA）
1. 范围
本标准规定了NO.7信令消息传递部分第二级用户适配层（M2UA）协议的功能、消息参数、格式和程序。

本标准适用于采用M2UA协议作为信令传送适配协议软交换设备，以及信令网关功能（SGF）与媒体网关功能（MGF）采用同一物理实体的信令网关设备，此时的信令网关功能只完成信令链路终端的功能。

2 规范性引用文件
下列文件中的条款通过在本标准中引用而成为本标准的条款，凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而鼓励根据本部分达成协议的各方研究是否可以适用这些文件的最新版本。

凡是不注日期的引用文件，其最新版本适用于本标准。

YD/T 1194－2002 流控制传输协议（1.0）技术规范
GF010－9001 中国国内电话网No.7信号方式技术规范（暂行规定）
RFC 3331 消息传递部分（MTP）第二级用户适配层（M2UA）协议
3 术语和缩略语
3.1 术语
应用服务器（AS）：执行特定应用实例的逻辑实体。

软交换或MGC就可以被看做是一个应用服务器，它用来处理MTP第三层消息和终接于NO.7信令链路上的呼叫处理。

通常来讲，SG 通常把AS看做是一个或多个相关应用服务器进程（ASP）组成的有序队列（例如：首选、次选等）。

应用服务器进程（ASP）–应用服务器的处理实例。

如主用的或备份的MGC通常可以看做是应用服务器进程。

偶联：本标准中提到的偶联都是指SCTP 偶联，偶联可以用来在一个或多个接口上传递协议数据单元。

故障倒换、倒回－在当前使用的应用服务器进程故障或不可用的情况下，信令业务可以重新选路到替换服务器的其他ASP上的能力，当先前不可用的应用服务器进程（ASP）恢复
1
后，故障倒回能力可以把原来该ASP承担的业务量重新送到该ASP。

接口标识符：接口标识符用来识别在SG上的物理接口，它用来表示接收或发送的信令消息是从哪个接口上收到的或者是需要发送到的。

接口标识符参数可以是文本的，也可以是整数，该参数值的分配由网络运营者决定。

该参数值只在本地有效，该值的分配由SG和ASP之间协调。

层管理：层管理是SG或ASP中的节点功能，它用来处理M2UA层和本地管理实体之间输入和输出。

链路关键字：链路关键字是一个本地唯一（在SG和ASP之间）的值，用这个参数可以识别一个特定的信令数据链路和信令链路终端对之间的注册请求。

MTP－2：消息传递部分第二层，NO.7信令协议栈中的信令数据链路层。

MTP－3：消息传递部分第三层，NO.7信令协议栈中的网络层。

MTP－2用户：使用MTP二层提供的服务的协议（即MTP-3）。

信令数据链路：信令数据链路是指连接在两个信令链路终端的一组特定的通信功能。

流：本标准中提到的流是指SCTP流，它是从一个SCTP端点到另一相关SCTP端点建立的单向逻辑通路。

所有用户消息在流中按序传递，除非提交的是无序传递业务。

M2UA通路：是指使用M2UA协议的SG和ASP及其之间的SCTP偶联。

3.2 缩略语
AS 应用服务器
ASP 应用服务器进程
IP 因特网协议
M2UA MTP第二级用户适配层
MGC 媒体网关控制器
NIF节点互通功能
SCTP 流控制传输协议
SG 信令网关
SP NO.7信令点
4 概述
4.1 M2UA 的结构
本标准中定义的M2UA适配协议用于传送NO.7信令协议中的MTP-2 的用户消息，即MTP-3消息，目前MTP-3是七号信令MTP-2的唯一的用户，M2UA利用流控制传输协议来提供可靠的低层传送。

信令网关使用标准的七号信令链路接口与PSTN网相连，在七号信令接口上使用MTP协议2
3
来保证MTP-2消息可以可靠地向（从）信令点或信令转接点发送（接收）；同时SG 还提供与IP 网的互通功能，把MTP-2用户消息传送到对应的应用服务器进程。

4.1.1 使用M2UA 协议时，信令网关与软交换（或MGC ）的关系
信令网关可以通过标准的NO.7信令链路终端接收NO.7信令消息，并使用MTP 功能提供对MTP-2用户信令消息传递。

此时信令网关只完成信令链路终端（SLT ）的功能，向软交换（或MGC ）传送MTP-3消息。

使用M2UA 协议的信令网关提供的信令传送功能如下图所示：
注：信令点和信令网关之间的NO.7信令通路上可以包括STP 。

对于使用M2UA 作为适配协议的信令传送功能必须要使用流控制传输协议（SCTP ）作为低层的传送协议，SCTP 用以提供以下功能：
－ 明确的面向分组的递交；
－ 多个流中的用户消息的顺序递交，也可以提供对单个用户消息的按消息到达顺序进行递交；
－ 把多个用户消息复用到一个SCTP 分组中；
－ 在偶联的两端使用多归属机置，来增加网络层的可靠性；
－ 避免泛播和其他的攻击；
－ 根据通路MTU 的情况对用户数据进行分段；
在公共的传输层之下不需要提供另外的冗余性保证。

4.1.2 ASP 故障倒换的概念
为了提供更高的呼叫可用性和事务处理能力，M2UA 提供了故障倒换、倒回功能。

从NO.7信令网进入SG 的所有MTP-2用户消息，根据消息的接口标识符被分配到一个唯一的应用服务器。

SP SG MGC NO.7信令 IP MTP L2 L1 NO.7信令用户部分 MTP L3 IP MTP L3 SCTP M2UA MTP L2 L1 IP
SCTP M2UA （NIF ） 图1 SG 和MGC 中应用M2UA 协议的结构图 NO.7信令用户部分
M2UA协议支持支持n+k的冗余配置模型（包括：主备用、负荷分担），其中n是指处理业务所必需的最少的ASP数量，k则是可用来代替故障或不可用ASP的ASP数量。

4.1.3 客户机/服务器模型
SG和ASP都可以支持服务器和客户机的操作，如果在两个端点上使用了M2UA协议，则配置原则如下：即一端总是配置为服务器的客户机，另外一端则配置为服务器，通常的情况SG 被配置为服务器端，ASP被配置为客户端。

在这种情况下，应当由ASP来发起到SG的SCTP偶联建立，其中M2UA协议使用的SCTP的端口号为2904。

4.2 M2UA适配层提供的业务
由于IP网中的端点仍然保留了NO.7信令协议的MTP-3/MTP-2（MTP－2用户）间的接口，因此就要求M2UA协议层向MTP-3提供的业务应当与MTP-2向MTP-3提供的业务相同。

4.2.1 支持MTP-2/MTP-3间的接口
M2UA 必须要支持MTP-2/MTP-3间的接口，从而保证NO.7信令网络中和IP域中的MTP-2对等用户实体间的操作可以是无缝的。

M2UA协议也是利用与MTP-2类似的原语来支持MTP-2/MTP-3间的接口。

4.2.2 支持M2UA协议的端点（SG、MGC）与层管理之间的通信
为了方便与SG（MGC）层管理模块之间的通信，M2UA定义了M-ERROR原语来报告由于承载MTP-3协议时产生的错误：
M-ERROR原语用来指示收到的M2UA消息中出现了差错（例如，接口ID值未知或不存在）4.2.3 支持对SG和MGC间偶联的管理
SG的M2UA层应当维护所有配置的ASP的状态，以下原语由层管理使用，来管理SG和软交换（或MGC）之间的偶联。

M2UA层可以根据层管理的指示来建立或释放到对端M2UA 端点的SCTP的偶联。

M-SCTP_ESTABLISH原语用来请求、指示和证实到对端M2UA节点的SCTP的偶联建立。

M-SCTP_RELEASE原语用来请求、指示和证实到对端M2UA节点的SCTP的偶联释放。

M2UA层使用M-SCTP_STATUS原语向层管理通知当前SCTP偶联的状态。

4.2.4 支持对AS和ASP的状态管理
层管理可以向M2UA层通知AS/ASP的状态（例如：激活、故障等），通过在两个对等的M2UA层之间交换一些消息，来停止或恢复到本地M2UA用户的业务。

这一功能是通过以下原语实现的。

M-ASP_STATUS原语：该原语由层管理调用，向M2UA层请求应用服务器进程的状态，该原语也可用来指示ASP的状态。

M-ASP_MODIFY原语：该原语由层管理调用，修改ASP的状态，即：ASP侧的层管理可以使用该原语启动ASPM程序。

4
5
M-AS_STATUS 原语：该原语由层管理调用，向M2UA 层请求应用服务器的状态，这个原语也可用来指示AS 的状态。

4.3 M2UA 层提供的功能
4.3.1 映射功能
在M2UA 层必须要维护一张用于接口ID 与SG 物理接口之间映射的表，物理接口可以是E1电路/时隙等，同时M2UA 层还必须维护一张用于接口ID 与SCTP 偶联和相关流进行映射的表，从而完成物理接口到SCTP 流之间的映射关系。

只有当ASP 针对某个特定的接口标识符发送了ASP Active 消息后，SG 才可以把接口标识符映射成SCTP 的偶联和流。

由于ASP 的状态会发生变化，因此这种映射关系是可以动态变化的。

SG 必须要知道AS/ASP 的状态，并且在进行消息选路时参考AS/ASP 的当前状态。

SGSG
图2： SG 中NO.7信令链路、接口标识符、AS 和ASP 之间的关系
图2中给出了在SG 中的NO.7信令链路、接口标识符、AS 和ASP 之间的关系。

其中一个SG 可以支持多个AS ，一个AS 可以支持多个接口标识符。

一个接口标识符标识的是一条NO.7信令链路，M2UA 通路用于承载一个（或多个）NO.7信令链路的业务。

在通常的应用中，一条NO.7信令链路映射到M2UA 通路中的一个流，但一条NO.7信令链路上的消息不能映射到M2UA 通路的多个流中。

4.3.2 支持对SG 和ASP 之间SCTP 偶联的管理
为了管理SCTP 偶联以及SG 与MGC 之间的业务量，SG 的M2UA 层必须来维护所有已配置的ASP 的可用性状态，包括远端ASP 的激活或去激活状态。

所谓激活的ASP 就是当前可以接收SG 发的送业务量的ASP 。

M2UA 层可以根据本地层管理的指令，建立到对端M2UA 节点的SCTP 偶联，这个建立过程可以通过调用M-SCTP_ESTABLISH 原语来实现。

同样的，M2UA 层也可以使用M-SCTP_STA TUS 向本地层管理通知底层SCTP 的状态。

M2UA 可以利用这个原语向本地管理报告本地SCTP 偶联释放的原因，确定释放是由本地M2UA 发起的，还是由SCTP 发起的。

此外，M2UA 层还可以使用M-ASP STATUS 或 M-AS_STATUS 原语向本地管理报告ASP
NO.7信令链路NO.7信令链路 1 2
或AS的状态变化，
4.3.3. SG上对ASP的状态管理
SG的M2UA层必须要维护它支持的ASP的状态，ASP的状态变化可以是由于收到对等层间的消息（ASPM消息）造成的，也可以是由于收到本地SCTP偶联的指示造成的。

ASP的状态迁移程序可参见6.3.1节。

在SG，为了支持故障倒换、倒回程序，应用服务器列表中必须包括所有激活的和未激活的ASP。

当首选和备用的ASP都可用时，对端M2UA协议要求指定当前的哪个ASP是激活的。

一个逻辑AS的中的ASP排序情况始终在SG中进行跟踪刷新，用以反映当前激活的应用服务器进程。

同样的M2UA也需要向本地管理通知ASP或AS的状态变化，这个功能的实现需要使用M-ASP_STATUS或M-AS_STA TUS
4.3.4 对SCTP 的流管理
SCTP允许用户在偶联最初建立时规定可以使用的流的数量，从而保证M2UA可以正确地管理这些流，由于SCTP的流具有单向特性，因此M2UA并不知道对端M2UA层的流信息。

同时接口标识符应当在M2UA消息头中。

在M2UA中之所以推荐使用SCTP的流其主要原因是可以使传输和缓存的时延降到最小，从而可以全面改善信令实体单元间的性能和可靠性。

每个NO.7信令链路可以使用一个单独的SCTP流。

SCTP偶联中的流“0”不用来传送MTP-2用户适配层消息（MAUP），这是因为M2UA要求SCTP偶联中的流“0”只能用来传送ASP管理消息。

4.3.5 与NO.7信令网管理无缝的互通
如果当前激活的ASP从激活（ACTIVE）状态迁移出后，则SG的M2UA层应当向本地层管理传送关于M2UA的用户（MTP-3）不可用的指示。

SG的M2UA采取的动作应当与Q.703建议规定的MTP-2协议的动作一致。

4.3.6 流量控制/和拥塞控制
M2UA可以采用不同实施的方式，通知IP网络拥塞门限触发和消除（即：来自于SCTP 的指示）。

M2UA层对收到的这个拥塞指示的处理取决于不同的实施。

但是SG采取的动作应当与MTP规范规定的动作一致，并可以保证NO.7信令链路的流量控制功能可以正确的进行。

当SG的SCTP检测到拥塞时，应向M2UA发送拥塞指示。

当SG的M2UA在收到SCTP发送的拥塞指示时，M2UA向MTP2发送拥塞指示，信令网关在相应的NO.7信令链路上发送SIB （SIB的发送处理程序应符合Q.703建议中规定的程序）,以便通知对端的MTP2在收到SIB消息后减少或停止发送信令消息。

在SG侧，当M2UA收到SCTP上报的网络拥塞消除指示时，M2UA向MTP2发送拥塞消除指示，SG应停止在相关的NO7信令链路上发送SIB消息（其处理程序应符合Q.703建议中规定
6
的程序）。

4.3.7 查询NO.7信令链路状态
当从一个ASP故障倒换到另一个ASP后，可能需要ASP上的M2UA去查询当前No.7信令链路的状态，以保证其状态的一致性，SG的M2UA可以在查询请求的响应中包含当前NO.7信令链路的状态的信息（即：进入业务、退出服务、拥塞状态或LPO/RPO状态）。

4.4 M2UA边界原语的定义
4.4.1 M2UA和MTP－3 之间的原语
M2UA和MTP第三功能级之间使用如下原语，使用这些原语后，对于MTP-3来讲，M2UA 与MTP-2是相同的：
－DATA
－ESTABLISH
－RELEASE
－STATE
－DATA RETRIEV AL
－DATA RETRIEV AL COMPLETE
4.4.2 M2UA和MTP－2 之间的原语
M2UA和MTP－2 之间定义了如下原语，这部分原语主要是用于提供SG功能的M2UA端点上。

－DATA
－ESTABLISH
－RELEASE
－STATE
－DATA RETRIEV AL
－DATA RETRIEV AL COMPLETE
4.4.3 M2UA和SCTP之间的原语
M2UA和SCTP之间的原语可参见YD/T 1194－2002“流控制传输协议（1.0）”
4.4.4 M2UA 和层管理之间的原语
M2UA协议和M2UA端点的层管理定义了如下原语：
M-SCTP ESTABLISH request原语：
方向：LM -> M2UA
作用：LM请求ASP与SG建立SCTP偶联。

M-STCP ESTABLISH confirm原语：
方向：M2UA -> LM
作用：ASP向LM确认它已经与SG建立了SCTP。

M-SCTP ESTABLISH indication 原语：
方向：M2UA -> LM
作用：SG通知层管理ASP已经建立了SCTP偶联。

M-SCTP RELEASE request 原语：
方向：LM -> M2UA
作用：LM请求ASP释放与SG的SCTP偶联。

M-SCTP RELEASE confirm原语：
方向：M2UA -> LM
作用：ASP向层管理确认它已经释放了与SG的SCTP偶联。

M-SCTP RELEASE indication原语：
方向：M2UA -> LM
作用：SG通知层管理ASP已经释放了SCTP偶联。

M-SCTP_RESTART indication原语：
方向：M2UA -> LM
作用：M2UA 通知层管理收到了SCTP再启动指示。

M-SCTP STATUS request 原语：
方向：LM -> M2UA
作用：LM请求M2UA报告SCTP偶联的状态。

M-SCTP STATUS confirm 原语：
方向：M2UA -> LM
作用：M2UA 报告SCTP偶联的状态。

M-ASP STATUS request 原语：
方向：LM -> M2UA
作用：LM请求SG报告远端ASP的状态。

M-ASP STATUS confirm 原语：
方向：M2UA -> LM
作用：SG报告远端ASP的状态。

M-AS STATUS request 原语：
方向：LM -> M2UA
作用：LM 请求SG报告AS的状态。

M-AS_STATUS indication 原语：
方向：M2UA -> LM
作用：SG报告远端AS的状态。

M-NOTIFY indication 原语：
方向：M2UA -> LM
作用：ASP用来报告已经收到对端的NOTIFY消息。

M-ERROR indication 原语：
方向：M2UA -> LM
作用：ASP或SG用来报告已经收到对端的ERROR消息。

M-ASP_UP request 原语：
方向：LM -> M2UA
作用：LM请求ASP启动运行并向对端SG发送ASP UP 消息。

M-ASP_UP confirm 原语：
方向：M2UA -> LM
作用：ASP向层管理报告它已经从对端SG收到了ASP UP Acknowledgement消息。

M-ASP_DOWN request 原语：
方向：LM -> M2UA
作用：LM请求ASP停止运行并向对端SG发送ASP DOWN消息。

M-ASP_DOWN confirm原语：
方向：M2UA -> LM
作用：ASP向层管理报告它已经从对端SG收到了ASP DOWN Acknowledgement消息。

M-ASP_ACTIVE request 原语：
方向：LM -> M2UA
作用：LM请求ASP向对端SG发送ASP ACTIVE消息。

M-ASP_ACTIVE confirm 原语：
方向：M2UA -> LM
作用：ASP向层管理报告它已经从对端SG收到了ASP ACTIVE Acknowledgement消息。

M-ASP_INACTIVE request 原语：
方向：LM -> M2UA
作用：LM请求ASP向对端SGP发送ASP INACTIVE 消息
M-ASP_INACTIVE confirm 原语：
方向：M2UA -> LM
作用：ASP向层管理报告它已经从对端SG收到了ASP INACTIVE Acknowledgement消息。

M-LINK_KEY_REG Request 原语：
方向：LM -> M2UA
作用：LM请求ASP用REG REQ消息向SG注册链路关键字
M-LINK_KEY_REG Confirm 原语：
方向：M2UA -> LM
作用：ASP向层管理报告已经从SG成功的收到了REG RSP消息。

M-LINK_KEY_REG Indication 原语：
方向：M2UA -> LM
作用：SG 向层管理报告已经成功处理了一个来自ASP的REG RSP消息。

M-LINK_KEY_DEREG Request 原语：
方向：LM -> M2UA
作用：LM请求ASP通过向SG发送DEREG REQ消息注销一个已经注册的链路关键字。

M-LINK_KEY_DEREG Confirm 原语：
方向：M2UA -> LM
作用： ASP 向层管理报告它已经成功的从SG 收到了DEREG RSP 消息。

M-LINK_KEY_DEREG Indication 原语： 方向： M2UA -> LM
作用： SG 向层管理报告它已经成功的处理了一个从ASP 收到的DEREG REQ 消息。

5 M2UA 协议单元格式 5.1 公共消息头
MTP-2用户适配层协议消息中必须包括版本、消息类别、消息类型、消息长度和消息内容几个部分。

消息头部分对于所有信令协议适配层消息都是通用的。

5.1.1 版本字段
版本字段（Vers ）中包含了M2UA 适配层的版本。

目前所支持的版本编码为： 0000 0001 1.0版本协议 5.1.2 备用字段
备用字段的长度为8比特，在发送方应当设置为全0，在接收方应忽略该字段，即收到备用字段不为全0的消息时也应正确处理。

5.1.3 消息类别字段
该字段为8比特的无符号整数，表1中列出了公共消息头中消息类别字段的编码分配。

表1 消息类别编码表
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
版本 备用 消息类型
消息长度 图 3 公共消息头
消息类别
5.1.4 消息类型字段
表2－表6中给出了不同的M2UA消息类别下，该字段所使用的有效消息类型编码。

表2 MTP-2 用户适配（MAUP）消息
表3 M2UA ASP状态维护（ASPSM）消息类型
表4 M2UA ASP业务维护（ASPTM）消息类型
表5 M2UA管理（MGMT）消息类型
表6 M2UA接口标识符管理（MII）消息类型
5.1.5 消息长度字段
消息长度定义了整个M2UA消息的八位位组数，对于消息的最后一个参数，如果包含填
充字节，那么消息长度应把填充信息包含在内。

消息长度字段的取值应等于MTP-3消息长度、公共消息头长度和M2UA 消息头的长度之和 5.1.6 可变长参数的格式
M2UA 消息在公共消息头之后可以包含0个或几个可变长参数，所有包含在消息中的参数的格式都使用“参数标签－参数长度－参数取值”的形式进行描述，如下图所示：
图4：可变长参数的格式。

消息中的必备参数必须要放在任选参数前传送。

参数标签：，参数标签字段是一个16比特的无符号整数，其取值范围从0到65534，适配层使用的通用参数的标签取值范围从00－ff ，M2UA 专有参数的标签取值范围从300到3ff 。

M2UA 使用的通用参数标签（即：所有的用户适配层使用）定义在表7中。

表7： 通用参数标签
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
参数标签 参数取值
参数长度
表8 M2UA的专用参数
参数长度字段为16比特的无符号整数，该字段指示了参数的字节数，长度包括参数标签、参数长度和参数值字段，即当没有参数取值时，该字段的长度取值为4。

参数指示的长度不包括任何填充字节。

参数值的长度是可变的，它包含参数实际传送的信息。

参数的实际总长度（包括标签、参数长度和值字段）必须是四字节的整数倍。

如果参数长度不是四的整数倍，发送者应在结尾用0填充参数，填充的长度不包括在参数长度字段。

发送
者不能填充多于三个字节，接收方忽略填充字节（即：根据长度字段指示的长度处理参数）。

5.2 M2UA 消息头
除了公共消息头外， M2UA 消息还有特有消息头。

M2UA 特有消息头紧跟在公共消息头后，但只用在MAUP 消息中，
M2UA 特有消息头应包括接口标识符，接口标识符用来标识SG 接收和发送信令消息的物理接口。

接口标识符参数的格式可以是整数类型的，也可以是基于文本编码的，该参数的取值由网络运营者来分配，这个参数值仅在本地有效，由SG 和ASP 协商使用。

在国内应用时，要求使用整数类型编码方式的接口标识符，对基于文本格式编码方式的接口标识符的支持是任选的，目前暂不要求使用字符串类型的接口标识符。

基于整数格式编码的接口标识符参数的标签值为0x0001。

此时，参数的长度字段取值恒等于8。

基于文本格式编码的接口标识符参数的标签值为0x0003。

此时，接口标识符的编码应符合ANSI X3.4-1986的规定，基于文本的标识符的字符串最大取值为255个八位位组。

参数长度字段的取值等于标识符文本的字符串的长度加4个字节。

5.3 M2UA 消息
下节中定义了M2UA 消息和参数内容。

M2UA 消息使用公共消息头（图3）和M2UA 消息头（图5）。

5.3.1 MTP-2用户适配消息 5.3.1.1 DATA 消息
DATA 消息包括NO.7信令 MTP-2用户协议数据单元（PDU ）。

DATA 消息包括协议数据和关联ID 两个参数，其中协议数据为必备参数，关联ID 为任选参数。

1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
标签（0x0003）
（0x1）
接口ID （文本类型） 参数长度 图 6 M2UA 消息头（基于文本编码的接口标识符）
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
标签（0x0001）
（0x1）
接口ID （整数类型）
参数长度＝8 图 5 M2UA 消息头（基于整数编码的接口标识符）
DATA 消息的格式如下图所示：
协议数据字段包括MTP-2用户消息，消息的封装顺序应符合网络发送的顺序，从信令信息八位位组（SIO ）开始顺序排放，且协议数据的长度不应大于272个八位位组。

关联ID 参数可以唯一的标识封装在协议数据单元的MSU 是属于哪个AS 。

5.3.1.2 Data Acknowledge 消息
Data Acknowledge 消息必须包含从Data 消息中收到的关联ID ，用来表明对端M2UA 已经成功的处理了收到的Data 消息。

Data 消息中的关联ID 参数和Data Acknowledge 消息中的关联ID 参数提供一种机制，SG 可以利用这个关联ID ，从而使得发送的MSU 在得到对端NO.7信令链路的MTP-2的确认前，就可以对端M2UA 发送的消息进行证实，这样可以避免由于偶联故障或拥塞造成的消息丢失。

如果从对端M2UA 收到的DA TA 消息中，包含有关联ID 参数，则必须发送Data Acknowledge 消息。

否则可以不发送Data Acknowledge 消息。

在Data Acknowledge 消息中，关联ID 中必备参数。

Data Acknowledge 消息中关联ID 的格式如下图所示。

如果发送的Data Acknowledge 消息中没有包括关联ID 或发送的关联ID 不正确，则No.7信令链路最终将由于缺少对MSU 的MTP-2的证实导致链路故障。

5.3.1.3 Establish （Request ， Confirmation ）消息
Establish Request 消息用来建立一条NO.7信令链路或者是指示相关的通路已经建立，MGC 负责控制NO.7信令链路的状态。

当MGC 要使NO.7链路进入工作时，则发送Establish Request 消息。

注如果SG 已经建立的了NO.7信令链路，则在收到Establish Request 消息后SG 不需要采取任何动作，直接发送Establish Confirm 消息即可。

当MGC 发送了M2UA 的Establish Request 消息，MGC 可以启动一个定时器，在收到对端的Establish Confirm 消息后，该定时器停止。

如果定时器超时后还没有收到Establish Confirm 消息，
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 图7：DATA 消息参数格式
标签（0x0300） 协议数据
长度
标签（0x0013）
关联ID
长度＝8
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 图8：关联ID 参数的格式
标签（0x13） 关联ID
长度＝8。