Network Working Group K. Morneault, Ed.
Request for Comments: 4666 Cisco Systems
Obsoletes: 3332 J. Pastor-Balbas, Ed.
Category: Standards Track Ericsson
September 2006
Network Working Group K. Morneault, Ed.
Request for Comments: 4666 Cisco Systems
Obsoletes: 3332 J. Pastor-Balbas, Ed.
Category: Standards Track Ericsson
September 2006
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
信令系统7（SS7）消息传输第3部分（MTP3）-用户适配层（M3UA）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332.
本备忘录定义了一个协议，用于支持使用流控制传输协议的服务通过IP传输任何SS7 MTP3用户信令（例如ISUP和SCCP消息）。此外，还提供了协议元素，以实现SS7和IP域中MTP3用户对等点的无缝操作。该协议将在信令网关（SG）和媒体网关控制器（MGC）或IP驻留数据库之间使用，或在两个基于IP的应用程序之间使用。假设SG使用SS7消息传输部分（MTP）通过标准SS7接口接收SS7信令以提供传输。本文件淘汰RFC 3332。
Table of Contents
目录
1. Introduction ....................................................6
1.1. Scope ......................................................6
1.2. Terminology ................................................6
1.3. M3UA Overview ..............................................9
1.3.1. Protocol Architecture ...............................9
1.3.2. Services Provided by the M3UA Layer ................10
1.3.2.1. Support for the Transport of
MTP3-User Messages ........................10
1.3.2.2. Native Management Functions ...............11
1.3.2.3. Interworking with MTP3 Network
Management Functions ......................11
1.3.2.4. Support for the Management of SCTP
Associations between the ..................11
1.3.2.5. Support for the Management of
Connections to Multiple SGPs ..............12
1.4. Functional Areas ..........................................12
1.4.1. Signalling Point Code Representation ...............12
1.4.2. Routing Contexts and Routing Keys ..................14
1.4.2.1. Overview ..................................14
1.4.2.2. Routing Key Limitations ...................15
1.4.2.3. Managing Routing Contexts and
Routing Keys ..............................15
1.4.2.4. Message Distribution at the SGP ...........15
1.4.2.5. Message Distribution at the ASP ...........16
1.4.3. SS7 and M3UA Interworking ..........................16
1.4.3.1. Signalling Gateway SS7 Layers .............16
1.4.3.2. SS7 and M3UA Interworking at the SG .......17
1.4.3.3. Application Server ........................17
1.4.3.4. IPSP Considerations .......................18
1.4.4. Redundancy Models ..................................18
1.4.4.1. Application Server Redundancy .............18
1.4.5. Flow Control .......................................18
1.4.6. Congestion Management ..............................19
1.4.7. SCTP Stream Mapping ................................19
1.4.8. SCTP Client/Server Model ...........................19
1.5. Sample Configuration ......................................20
1.5.1. Example 1: ISUP Message Transport ..................20
1.5.2. Example 2: SCCP Transport between IPSPs ............21
1.5.3. Example 3: SGP Resident SCCP Layer, with
Remote ASP .........................................22
1.6. Definition of M3UA Boundaries .............................23
1.6.1. Definition of the Boundary between M3UA and
an MTP3-User .......................................23
1.6.2. Definition of the Boundary between M3UA and SCTP ...23
1.6.3. Definition of the Boundary between M3UA and
Layer Management ...................................24
1. Introduction ....................................................6
1.1. Scope ......................................................6
1.2. Terminology ................................................6
1.3. M3UA Overview ..............................................9
1.3.1. Protocol Architecture ...............................9
1.3.2. Services Provided by the M3UA Layer ................10
1.3.2.1. Support for the Transport of
MTP3-User Messages ........................10
1.3.2.2. Native Management Functions ...............11
1.3.2.3. Interworking with MTP3 Network
Management Functions ......................11
1.3.2.4. Support for the Management of SCTP
Associations between the ..................11
1.3.2.5. Support for the Management of
Connections to Multiple SGPs ..............12
1.4. Functional Areas ..........................................12
1.4.1. Signalling Point Code Representation ...............12
1.4.2. Routing Contexts and Routing Keys ..................14
1.4.2.1. Overview ..................................14
1.4.2.2. Routing Key Limitations ...................15
1.4.2.3. Managing Routing Contexts and
Routing Keys ..............................15
1.4.2.4. Message Distribution at the SGP ...........15
1.4.2.5. Message Distribution at the ASP ...........16
1.4.3. SS7 and M3UA Interworking ..........................16
1.4.3.1. Signalling Gateway SS7 Layers .............16
1.4.3.2. SS7 and M3UA Interworking at the SG .......17
1.4.3.3. Application Server ........................17
1.4.3.4. IPSP Considerations .......................18
1.4.4. Redundancy Models ..................................18
1.4.4.1. Application Server Redundancy .............18
1.4.5. Flow Control .......................................18
1.4.6. Congestion Management ..............................19
1.4.7. SCTP Stream Mapping ................................19
1.4.8. SCTP Client/Server Model ...........................19
1.5. Sample Configuration ......................................20
1.5.1. Example 1: ISUP Message Transport ..................20
1.5.2. Example 2: SCCP Transport between IPSPs ............21
1.5.3. Example 3: SGP Resident SCCP Layer, with
Remote ASP .........................................22
1.6. Definition of M3UA Boundaries .............................23
1.6.1. Definition of the Boundary between M3UA and
an MTP3-User .......................................23
1.6.2. Definition of the Boundary between M3UA and SCTP ...23
1.6.3. Definition of the Boundary between M3UA and
Layer Management ...................................24
2. Conventions ....................................................27
3. M3UA Protocol Elements .........................................28
3.1. Common Message Header .....................................28
3.1.1. M3UA Protocol Version: 8 bits (unsigned integer) ...28
3.1.2. Message Classes and Types ..........................28
3.1.3. Reserved: 8 Bits ...................................30
3.1.4. Message Length: 32-Bits (Unsigned Integer) .........30
3.2. Variable-Length Parameter Format ..........................30
3.3. Transfer Messages .........................................33
3.3.1. Payload Data Message (DATA) ........................33
3.4. SS7 Signalling Network Management (SSNM) Messages .........36
3.4.1. Destination Unavailable (DUNA) .....................36
3.4.2. Destination Available (DAVA) .......................39
3.4.3. Destination State Audit (DAUD) .....................40
3.4.4. Signalling Congestion (SCON) .......................40
3.4.5. Destination User Part Unavailable (DUPU) ...........43
3.4.6. Destination Restricted (DRST) ......................45
3.5. ASP State Maintenance (ASPSM) Messages ....................45
3.5.1. ASP Up .............................................45
3.5.2. ASP Up Acknowledgement (ASP Up Ack) ................46
3.5.3. ASP Down ...........................................47
3.5.4. ASP Down Acknowledgement (ASP Down Ack) ............48
3.5.5. Heartbeat (BEAT) ...................................48
3.5.6. Heartbeat Acknowledgement (BEAT Ack) ...............49
3.6. Routing Key Management (RKM) Messages [Optional] ..........49
3.6.1. Registration Request (REG REQ) .....................49
3.6.2. Registration Response (REG RSP) ....................54
3.6.3. Deregistration Request (DEREG REQ) .................56
3.6.4. Deregistration Response (DEREG RSP) ................57
3.7. ASP Traffic Maintenance (ASPTM) Messages ..................59
3.7.1. ASP Active .........................................59
3.7.2. ASP Active Acknowledgement (ASP Active Ack) ........60
3.7.3. ASP Inactive .......................................61
3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack) ....62
3.8. Management (MGMT) Messages ................................63
3.8.1. Error ..............................................63
3.8.2. Notify .............................................67
4. Procedures .....................................................70
4.1. Procedures to Support the M3UA-User .......................70
4.1.1. Receipt of Primitives from the M3UA-User ...........70
4.2. Receipt of Primitives from the Layer Management ...........71
4.2.1. Receipt of M3UA Peer Management Messages ...........72
4.3. AS and ASP/IPSP State Maintenance .........................73
4.3.1. ASP/IPSP States ....................................74
4.3.2. AS States ..........................................76
4.3.3. M3UA Management Procedures for Primitives ..........78
4.3.4. ASPM Procedures for Peer-to-Peer Messages ..........79
4.3.4.1. ASP Up Procedures .........................79
2. Conventions ....................................................27
3. M3UA Protocol Elements .........................................28
3.1. Common Message Header .....................................28
3.1.1. M3UA Protocol Version: 8 bits (unsigned integer) ...28
3.1.2. Message Classes and Types ..........................28
3.1.3. Reserved: 8 Bits ...................................30
3.1.4. Message Length: 32-Bits (Unsigned Integer) .........30
3.2. Variable-Length Parameter Format ..........................30
3.3. Transfer Messages .........................................33
3.3.1. Payload Data Message (DATA) ........................33
3.4. SS7 Signalling Network Management (SSNM) Messages .........36
3.4.1. Destination Unavailable (DUNA) .....................36
3.4.2. Destination Available (DAVA) .......................39
3.4.3. Destination State Audit (DAUD) .....................40
3.4.4. Signalling Congestion (SCON) .......................40
3.4.5. Destination User Part Unavailable (DUPU) ...........43
3.4.6. Destination Restricted (DRST) ......................45
3.5. ASP State Maintenance (ASPSM) Messages ....................45
3.5.1. ASP Up .............................................45
3.5.2. ASP Up Acknowledgement (ASP Up Ack) ................46
3.5.3. ASP Down ...........................................47
3.5.4. ASP Down Acknowledgement (ASP Down Ack) ............48
3.5.5. Heartbeat (BEAT) ...................................48
3.5.6. Heartbeat Acknowledgement (BEAT Ack) ...............49
3.6. Routing Key Management (RKM) Messages [Optional] ..........49
3.6.1. Registration Request (REG REQ) .....................49
3.6.2. Registration Response (REG RSP) ....................54
3.6.3. Deregistration Request (DEREG REQ) .................56
3.6.4. Deregistration Response (DEREG RSP) ................57
3.7. ASP Traffic Maintenance (ASPTM) Messages ..................59
3.7.1. ASP Active .........................................59
3.7.2. ASP Active Acknowledgement (ASP Active Ack) ........60
3.7.3. ASP Inactive .......................................61
3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack) ....62
3.8. Management (MGMT) Messages ................................63
3.8.1. Error ..............................................63
3.8.2. Notify .............................................67
4. Procedures .....................................................70
4.1. Procedures to Support the M3UA-User .......................70
4.1.1. Receipt of Primitives from the M3UA-User ...........70
4.2. Receipt of Primitives from the Layer Management ...........71
4.2.1. Receipt of M3UA Peer Management Messages ...........72
4.3. AS and ASP/IPSP State Maintenance .........................73
4.3.1. ASP/IPSP States ....................................74
4.3.2. AS States ..........................................76
4.3.3. M3UA Management Procedures for Primitives ..........78
4.3.4. ASPM Procedures for Peer-to-Peer Messages ..........79
4.3.4.1. ASP Up Procedures .........................79
4.3.4.2. ASP-Down Procedures .......................81
4.3.4.3. ASP Active Procedures .....................82
4.3.4.4. ASP Inactive Procedures ...................86
4.3.4.5. Notify Procedures .........................88
4.3.4.6. Heartbeat Procedures ......................89
4.4. Routing Key Management Procedures [Optional] ..............90
4.4.1. Registration .......................................90
4.4.2. Deregistration .....................................92
4.4.3. IPSP Considerations (REG/DEREG) ....................93
4.5. Procedures to Support the Availability or
Congestion Status of SS7 Destination ......................93
4.5.1. At an SGP ..........................................93
4.5.2. At an ASP ..........................................94
4.5.2.1. Single SG Configurations ..................94
4.5.2.2. Multiple SG Configurations ................94
4.5.3. ASP Auditing .......................................94
4.6. MTP3 Restart ..............................................96
4.7. NIF Not Available .........................................97
4.8. M3UA Version Control ......................................97
4.9. M3UA Termination ..........................................97
5. Examples of M3UA Procedures ....................................98
5.1. Establishment of Association and Traffic between
SGPs and ASPs .............................................98
5.1.1. Single ASP in an Application Server ("1+0"
sparing), No Registration ..........................98
5.1.1.1. Single ASP in an Application
Server ("1+0" Sparing), No Registration ...98
5.1.1.2. Single ASP in Application Server
("1+0" Sparing), Dynamic Registration .....99
5.1.1.3. Single ASP in Multiple
Application Servers (Each with "1+0"
Sparing), Dynamic Registration (Case 1
- Multiple Registration Requests) ........100
5.1.1.4. Single ASP in Multiple
Application Servers (each with "1+0"
sparing), Dynamic Registration (Case 2
- Single Registration Request) ...........101
5.1.2. Two ASPs in Application Server ("1+1" Sparing) ....102
5.1.3. Two ASPs in an Application Server ("1+1"
Sparing, Loadsharing Case) ........................103
5.1.4. Three ASPs in an Application Server ("n+k"
Sparing, Loadsharing Case) ........................104
5.2. ASP Traffic Failover Examples ............................105
5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ...105
5.2.2. 1+1 Sparing, Backup Override ......................105
5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP ..106
5.3. Normal Withdrawal of an ASP from an Application Server ...106
5.4. Auditing Examples ........................................107
4.3.4.2. ASP-Down Procedures .......................81
4.3.4.3. ASP Active Procedures .....................82
4.3.4.4. ASP Inactive Procedures ...................86
4.3.4.5. Notify Procedures .........................88
4.3.4.6. Heartbeat Procedures ......................89
4.4. Routing Key Management Procedures [Optional] ..............90
4.4.1. Registration .......................................90
4.4.2. Deregistration .....................................92
4.4.3. IPSP Considerations (REG/DEREG) ....................93
4.5. Procedures to Support the Availability or
Congestion Status of SS7 Destination ......................93
4.5.1. At an SGP ..........................................93
4.5.2. At an ASP ..........................................94
4.5.2.1. Single SG Configurations ..................94
4.5.2.2. Multiple SG Configurations ................94
4.5.3. ASP Auditing .......................................94
4.6. MTP3 Restart ..............................................96
4.7. NIF Not Available .........................................97
4.8. M3UA Version Control ......................................97
4.9. M3UA Termination ..........................................97
5. Examples of M3UA Procedures ....................................98
5.1. Establishment of Association and Traffic between
SGPs and ASPs .............................................98
5.1.1. Single ASP in an Application Server ("1+0"
sparing), No Registration ..........................98
5.1.1.1. Single ASP in an Application
Server ("1+0" Sparing), No Registration ...98
5.1.1.2. Single ASP in Application Server
("1+0" Sparing), Dynamic Registration .....99
5.1.1.3. Single ASP in Multiple
Application Servers (Each with "1+0"
Sparing), Dynamic Registration (Case 1
- Multiple Registration Requests) ........100
5.1.1.4. Single ASP in Multiple
Application Servers (each with "1+0"
sparing), Dynamic Registration (Case 2
- Single Registration Request) ...........101
5.1.2. Two ASPs in Application Server ("1+1" Sparing) ....102
5.1.3. Two ASPs in an Application Server ("1+1"
Sparing, Loadsharing Case) ........................103
5.1.4. Three ASPs in an Application Server ("n+k"
Sparing, Loadsharing Case) ........................104
5.2. ASP Traffic Failover Examples ............................105
5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ...105
5.2.2. 1+1 Sparing, Backup Override ......................105
5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP ..106
5.3. Normal Withdrawal of an ASP from an Application Server ...106
5.4. Auditing Examples ........................................107
5.4.1. SG State: Uncongested/Available ...................107
5.4.2. SG State: Congested (Congestion Level=2) /
Available .........................................107
5.4.3. SG State: Unknown/Available .......................107
5.4.4. SG State: Unavailable .............................108
5.5. M3UA/MTP3-User Boundary Examples .........................108
5.5.1. At an ASP .........................................108
5.5.1.1. Support for MTP-TRANSFER
Primitives at the ASP ....................108
5.5.2. At an SGP .........................................109
5.5.2.1. Support for MTP-TRANSFER Request
Primitive at the SGP .....................109
5.5.2.2. Support for MTP-TRANSFER
Indication Primitive at the SGP ..........110
5.5.2.3. Support for MTP-PAUSE,
MTP-RESUME, MTP-STATUS Indication
Primitives ...............................110
5.6. Examples for IPSP Communication ..........................112
5.6.1. Single Exchange ...................................112
5.6.2. Double Exchange ...................................113
6. Security Considerations .......................................113
7. IANA Considerations ...........................................114
7.1. SCTP Payload Protocol Identifier .........................114
7.2. M3UA Port Number .........................................114
7.3. M3UA Protocol Extensions .................................114
7.3.1. IETF-Defined Message Classes ......................115
7.3.2. IETF Defined Message Types ........................115
7.3.3. IETF-Defined Parameter Extension ..................115
8. Acknowledgements ..............................................115
9. Document Contributors .........................................116
10. References ...................................................116
10.1. Normative References ....................................116
10.2. Informative References ..................................117
Appendix A .......................................................119
A.1. Signalling Network Architecture .............................119
A.2. Redundancy Models ...........................................121
A.2.1. Application Server Redundancy ........................121
A.2.2. Signalling Gateway Redundancy ........................122
5.4.1. SG State: Uncongested/Available ...................107
5.4.2. SG State: Congested (Congestion Level=2) /
Available .........................................107
5.4.3. SG State: Unknown/Available .......................107
5.4.4. SG State: Unavailable .............................108
5.5. M3UA/MTP3-User Boundary Examples .........................108
5.5.1. At an ASP .........................................108
5.5.1.1. Support for MTP-TRANSFER
Primitives at the ASP ....................108
5.5.2. At an SGP .........................................109
5.5.2.1. Support for MTP-TRANSFER Request
Primitive at the SGP .....................109
5.5.2.2. Support for MTP-TRANSFER
Indication Primitive at the SGP ..........110
5.5.2.3. Support for MTP-PAUSE,
MTP-RESUME, MTP-STATUS Indication
Primitives ...............................110
5.6. Examples for IPSP Communication ..........................112
5.6.1. Single Exchange ...................................112
5.6.2. Double Exchange ...................................113
6. Security Considerations .......................................113
7. IANA Considerations ...........................................114
7.1. SCTP Payload Protocol Identifier .........................114
7.2. M3UA Port Number .........................................114
7.3. M3UA Protocol Extensions .................................114
7.3.1. IETF-Defined Message Classes ......................115
7.3.2. IETF Defined Message Types ........................115
7.3.3. IETF-Defined Parameter Extension ..................115
8. Acknowledgements ..............................................115
9. Document Contributors .........................................116
10. References ...................................................116
10.1. Normative References ....................................116
10.2. Informative References ..................................117
Appendix A .......................................................119
A.1. Signalling Network Architecture .............................119
A.2. Redundancy Models ...........................................121
A.2.1. Application Server Redundancy ........................121
A.2.2. Signalling Gateway Redundancy ........................122
This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol [18]. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database [12], or between two IP-based applications.
本备忘录定义了一个协议，用于支持使用流控制传输协议的服务通过IP传输任何SS7 MTP3用户信令（例如ISUP和SCCP消息）[18]。此外，还提供了协议元素，以实现SS7和IP域中MTP3用户对等点的无缝操作。该协议将在信令网关（SG）和媒体网关控制器（MGC）或IP驻留数据库[12]之间使用，或在两个基于IP的应用程序之间使用。
There is a need for Switched Circuit Network (SCN) signalling protocol delivery from an SS7 Signalling Gateway (SG) to a Media Gateway Controller (MGC) or IP-resident Database as described in the Framework Architecture for Signalling Transport [12]. The delivery mechanism should meet the following criteria:
需要将交换电路网络（SCN）信令协议从SS7信令网关（SG）传送到媒体网关控制器（MGC）或IP驻留数据库，如信令传输框架架构[12]中所述。交付机制应符合以下标准：
* Support for the transfer of all SS7 MTP3-User Part messages (e.g., ISUP [1,2,3], SCCP [4,5,6], TUP [13], etc.) * Support for the seamless operation of MTP3-User protocol peers * Support for the management of SCTP transport associations and traffic between an SG and one or more MGCs or IP-resident Databases * Support for MGC or IP-resident database process failover and load sharing * Support for the asynchronous reporting of status changes to management
* 支持传输所有SS7 MTP3用户部件消息（例如ISUP[1,2,3]、SCCP[4,5,6]、TUP[13]等）*支持MTP3用户协议对等方的无缝操作*支持管理SG与一个或多个MGC或IP驻留数据库之间的SCTP传输关联和流量*支持MGC或IP驻留数据库进程故障切换和负载共享*支持向管理层异步报告状态更改
In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP, and/or any other MTP3-User protocol messages, as well as certain MTP network management events, over SCTP transport associations to MTP3-User peers in MGCs or IP-resident databases.
简单地说，SG将终止SS7 MTP2和MTP3协议层[7,8,9]，并通过SCTP传输关联将ISUP、SCCP和/或任何其他MTP3用户协议消息以及某些MTP网络管理事件传递给MGC或IP驻留数据库中的MTP3用户对等方。
Application Server (AS) - A logical entity serving a specific Routing Key. An example of an Application Server is a virtual switch element handling all call processing for a signalling relation, identified by an SS7 DPC/OPC. Another example is a virtual database element, handling all HLR transactions for a particular SS7 SIO/DPC/OPC combination. The AS contains a set of one or more unique Application Server Processes, of which one or more is normally actively processing traffic. Note that there is a 1:1 relationship between an AS and a Routing Key.
应用服务器（AS）-为特定路由密钥提供服务的逻辑实体。应用服务器的一个示例是一个虚拟交换机元件，它处理信令关系的所有呼叫处理，由SS7 DPC/OPC标识。另一个示例是虚拟数据库元素，它处理特定SS7 SIO/DPC/OPC组合的所有HLR事务。AS包含一组一个或多个唯一的应用程序服务器进程，其中一个或多个进程通常正在积极处理流量。请注意，AS和路由密钥之间存在1:1的关系。
Application Server Process (ASP) - A process instance of an Application Server. An Application Server Process serves as an active or backup process of an Application Server (e.g., part of a distributed virtual switch or database). Examples of ASPs are processes (or process instances) of MGCs, IP SCPs, or IP HLRs. An ASP contains an SCTP endpoint and may be configured to process signalling traffic within more than one Application Server.
应用程序服务器进程（ASP）-应用程序服务器的进程实例。应用服务器进程用作应用服务器的活动或备份进程（例如，分布式虚拟交换机或数据库的一部分）。ASP的示例是MGC、IP SCP或IP HLR的进程（或进程实例）。ASP包含SCTP端点，可以配置为在多个应用服务器内处理信令通信。
Association - An association refers to an SCTP association. The association provides the transport for the delivery of MTP3-User protocol data units and M3UA adaptation layer peer messages.
关联-关联是指SCTP关联。该关联为MTP3用户协议数据单元和M3UA适配层对等消息的传递提供传输。
IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node.
IP服务器进程（IPSP）-基于IP的应用程序的进程实例。IPSP本质上与ASP相同，只是它以点对点的方式使用M3UA。从概念上讲，IPSP不使用信令网关节点的服务。
Failover - The capability to reroute signalling traffic as required to an alternate Application Server Process, or group of ASPs, within an Application Server in the event of failure or unavailability of a currently used Application Server Process. Failover also applies upon the return to service of a previously unavailable Application Server Process.
故障转移—在当前使用的应用程序服务器进程出现故障或不可用时，根据需要将信令流量重新路由到应用程序服务器内的备用应用程序服务器进程或一组ASP的能力。故障转移也适用于以前不可用的应用程序服务器进程恢复服务时。
Host - The computing platform that the process (SGP, ASP or IPSP) is running on.
主机-进程（SGP、ASP或IPSP）运行的计算平台。
Layer Management - Layer Management is a nodal function that handles the inputs and outputs between the M3UA layer and a local management entity.
层管理-层管理是处理M3UA层和本地管理实体之间的输入和输出的节点功能。
Linkset - A number of signalling links that directly interconnect two signalling points, which are used as a module.
链路集-直接互连两个用作模块的信令点的若干信令链路。
MTP - The Message Transfer Part of the SS7 protocol.
MTP—SS7协议的消息传输部分。
MTP3 - MTP Level 3, the signalling network layer of SS7.
MTP3-MTP级别3，SS7的信令网络层。
MTP3-User - Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP, TUP, etc.).
MTP3用户-通常使用SS7 MTP3服务的任何协议（例如，ISUP、SCCP、TUP等）。
Network Appearance - The Network Appearance is a M3UA local reference shared by SG and AS (typically an integer) that, together with an Signaling Point Code, uniquely identifies an SS7 node by indicating the specific SS7 network to which it belongs. It can be used to distinguish between signalling traffic associated with different networks being sent between the SG and the ASP over a common SCTP association. An example scenario is where an SG appears as an
网络外观-网络外观是SG和AS共享的M3UA本地参考（通常为整数），它与信令点代码一起，通过指示SS7节点所属的特定SS7网络来唯一标识SS7节点。它可用于区分与通过公共SCTP关联在SG和ASP之间发送的不同网络相关联的信令通信量。一个示例场景是SG显示为
element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks.
多个单独的国家SS7网络中的元素和相同的信令点代码值可以在不同的网络中重用。
Network Byte Order - Most significant byte first, a.k.a Big Endian. Routing Key - A Routing Key describes a set of SS7 parameters and parameter values that uniquely define the range of signalling traffic to be handled by a particular Application Server. Parameters within the Routing Key cannot extend across more than a single Signalling Point Management Cluster.
网络字节顺序-最高有效字节优先，也称为大端字节。路由密钥-路由密钥描述了一组SS7参数和参数值，它们唯一地定义了特定应用服务器要处理的信令通信量的范围。路由密钥中的参数不能跨多个信令点管理群集扩展。
Routing Context - A value that uniquely identifies a Routing Key. Routing Context values are configured either using a configuration management interface, or by using the routing key management procedures defined in this document.
路由上下文-唯一标识路由密钥的值。路由上下文值可以使用配置管理界面进行配置，也可以使用本文档中定义的路由密钥管理过程进行配置。
Signaling End Point (SEP) - A node in the SS7 network associated with an originating or terminating local exchange (switch) or a gateway exchange.
信令端点（SEP）-SS7网络中与发起或终止本地交换机（交换机）或网关交换机相关的节点。
Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an active, backup, load-sharing, or broadcast process of a Signalling Gateway.
信令网关进程（SGP）-信令网关的进程实例。它充当信令网关的活动、备份、负载共享或广播过程。
Signalling Gateway (SG) - An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network [12]. An SG appears to the SS7 network as an SS7 Signalling Point. An SG contains a set of one or more unique Signalling Gateway Processes, of which one or more is normally actively processing traffic. Where an SG contains more than one SGP, the SG is a logical entity, and the contained SGPs are assumed to be coordinated into a single management view to the SS7 network and to the supported Application Servers.
信令网关（SG）-SG是在IP网络边缘接收/发送SCN本机信令的信令代理[12]。SG在SS7网络中显示为SS7信令点。SG包含一组一个或多个唯一的信令网关进程，其中一个或多个进程通常在积极处理业务。如果一个SG包含多个SGP，则SG是一个逻辑实体，并且所包含的SGP被假定为协调到SS7网络和支持的应用服务器的单个管理视图中。
Signalling Process - A process instance that uses M3UA to communicate with other signalling processes. An ASP, an SGP, and an IPSP are all signalling processes.
信令进程-使用M3UA与其他信令进程通信的进程实例。ASP、SGP和IPSP都是信令过程。
Signalling Point Management Cluster (SPMC) - The complete set of Application Servers represented to the SS7 network under a single MTP entity (Signalling Point) in one specific Network Appearance. SPMCs are used to aggregate the availability, congestion, and user part status of an MTP entity (Signalling Point) that is distributed in the IP domain, for the purpose of supporting MTP3 management procedures towards the SS7 network. In some cases, the SG itself may also be a member of the SPMC. In this case, the SG availability/congestion/User_Part status should also be taken into account when considering any supporting MTP3 management actions.
信令点管理集群（SPMC）-在一个特定网络外观中，在单个MTP实体（信令点）下表示为SS7网络的一整套应用服务器。SPMC用于聚合分布在IP域中的MTP实体（信令点）的可用性、拥塞和用户部分状态，以支持针对SS7网络的MTP3管理过程。在某些情况下，SG本身也可能是SPMC的成员。在这种情况下，在考虑任何支持MTP3管理措施时，还应考虑SG可用性/拥塞/用户部件状态。
Signaling Transfer Point (STP) - A node in the SS7 network that provides network access and performs message routing, screening and transfer of signaling messages.
信令传输点（STP）-SS7网络中的一个节点，提供网络访问并执行消息路由、屏蔽和信令消息传输。
Stream - An SCTP stream; a unidirectional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the unordered delivery service.
流-SCTP流；从一个SCTP端点到另一个相关SCTP端点建立的单向逻辑通道，在该通道内，除提交给无序传递服务的用户消息外，所有用户消息都按顺序传递。
The framework architecture that has been defined for SCN signalling transport over IP [12] uses multiple components, including a common signalling transport protocol and an adaptation module to support the services expected by a particular SCN signalling protocol from its underlying protocol layer.
为IP上的SCN信令传输定义的框架架构[12]使用多个组件，包括通用信令传输协议和适配模块，以支持特定SCN信令协议从其底层协议层预期的服务。
Within the framework architecture, this document defines an MTP3-User adaptation module suitable for supporting the transfer of messages of any protocol layer that is identified to the MTP Level 3 as an MTP User. The list of these protocol layers includes but is not limited to ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part (SCCP) [4,5,6], and Telephone User Part (TUP) [13]. TCAP [14,15,16] or RANAP [16] messages are transferred transparently by the M3UA protocol as SCCP payload, as they are SCCP-User protocols.
在框架架构内，本文件定义了一个MTP3用户适配模块，该模块适用于支持任何协议层的消息传输，该协议层被识别为MTP级别3的MTP用户。这些协议层的列表包括但不限于ISDN用户部分（ISUP）[1,2,3]、信令连接控制部分（SCCP）[4,5,6]和电话用户部分（TUP）[13]。TCAP[14,15,16]或RANAP[16]消息通过M3UA协议作为SCCP有效载荷透明传输，因为它们是SCCP用户协议。
It is recommended that M3UA use the services of the Stream Control Transmission Protocol (SCTP) [18] as the underlying reliable common signalling transport protocol. This is to take advantage of various SCTP features, such as:
建议M3UA使用流控制传输协议（SCTP）[18]的服务作为底层可靠的通用信令传输协议。这是为了利用各种SCTP功能，例如：
- Explicit packet-oriented delivery (not stream-oriented) - Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages - Optional multiplexing of user messages into SCTP datagrams - Network-level fault tolerance through support of multi-homing at either or both ends of an association - Resistance to flooding and masquerade attacks - Data segmentation to conform to discovered path MTU size
- 显式面向数据包的交付（非面向流）-在多个流中按顺序交付用户消息，具有单个用户消息到达顺序交付选项-可选将用户消息多路复用到SCTP数据报中-通过支持关联任意端或两端的多宿主实现网络级容错-抵抗泛洪和伪装攻击-数据分段以符合发现的路径MTU大小
Under certain scenarios, such as back-to-back connections without redundancy requirements, the SCTP functions above might not be a requirement, and TCP MAY be used as the underlying common transport protocol.
在某些情况下，例如没有冗余要求的背靠背连接，上述SCTP功能可能不是要求，TCP可以用作底层公共传输协议。
The M3UA Layer at an ASP or IPSP provides the equivalent set of primitives at its upper layer to the MTP3-Users as provided by the MTP Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 services are offered remotely from an MTP3 Layer at an SGP, and not by a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that its local users are actually remote user parts over M3UA. In effect, the M3UA extends access to the MTP3 layer services to a remote IP-based application. The M3UA layer does not itself provide the MTP3 services. However, in the case where an ASP is connected to more than one SG, the M3UA layer at an ASP should maintain the status of configured SS7 destinations and route messages according to the availability and congestion status of the routes to these destinations via each SG.
ASP或IPSP的M3UA层在其上层向MTP3用户提供等效的原语集，如MTP级别3在SS7 SEP向其本地MTP3用户提供的原语集。这样，ASP或IPSP的ISUP和/或SCCP层不知道预期的MTP3服务是从SGP的MTP3层远程提供的，而不是通过本地MTP3层。SGP的MTP3层也可能不知道其本地用户实际上是M3UA上的远程用户部分。实际上，M3UA将对MTP3层服务的访问扩展到基于IP的远程应用程序。M3UA层本身不提供MTP3服务。然而，在ASP连接到多个SG的情况下，ASP处的M3UA层应保持已配置SS7目的地的状态，并根据通过每个SG到这些目的地的路由的可用性和拥塞状态来路由消息。
The M3UA layer may also be used for point-to-point signalling between two IP Server Processes (IPSPs). In this case, the M3UA layer provides the same set of primitives and services at its upper layer as the MTP3. However, in this case the expected MTP3 services are not offered remotely from an SGP. The MTP3 services are provided, but the procedures to support these services are a subset of the MTP3 procedures, due to the simplified point-to-point nature of the IPSP-to-IPSP relationship.
M3UA层还可用于两个IP服务器进程（IPSP）之间的点对点信令。在这种情况下，M3UA层在其上层提供与MTP3相同的原语和服务集。然而，在这种情况下，预期的MTP3服务不是从SGP远程提供的。提供了MTP3服务，但由于IPSP与IPSP关系的简化点对点性质，支持这些服务的程序是MTP3程序的一个子集。
The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association between an SGP and an ASP or between IPSPs.
M3UA层在SGP和ASP之间或IPSP之间建立的SCTP关联中提供MTP传输原语的传输。
At an ASP, in the case where a destination is reachable via multiple SGPs, the M3UA layer must also choose via which SGP the message is to be routed or support load balancing across the SGPs, thereby minimizing missequencing.
在ASP中，如果可以通过多个SGP到达目的地，则M3UA层还必须选择通过哪个SGP路由消息或支持跨SGP的负载平衡，从而最大限度地减少误序。
The M3UA layer does not impose a 272-octet signalling information field (SIF) length limit as specified by the SS7 MTP Level 2 protocol [7,8,9]. Larger information blocks can be accommodated directly by M3UA/SCTP, without the need for an upper layer segmentation/ re-assembly procedure as specified in recent SCCP or ISUP versions. However, in the context of an SG, the maximum 272-octet block size must be followed when interworking to a SS7 network that does not support the transfer of larger information blocks to the final destination. This avoids potential ISUP or SCCP fragmentation requirements at the SGPs. The provisioning and configuration of the SS7 network determines the restriction placed on the maximum block
M3UA层没有按照SS7 MTP 2级协议[7,8,9]的规定施加272八位字节信令信息字段（SIF）长度限制。M3UA/SCTP可以直接容纳更大的信息块，而不需要最新SCCP或ISUP版本中规定的上层分段/重新组装程序。然而，在SG的上下文中，当与不支持向最终目的地传输较大信息块的SS7网络互通时，必须遵循最大272个八位组块大小。这避免了SGP的潜在ISUP或SCCP分段要求。SS7网络的供应和配置决定了对最大数据块的限制
size. Some configurations (e.g., Broadband MTP [19,20,22]) may permit larger block sizes.
大小一些配置（例如，宽带MTP[19,20,22]）可能允许更大的块大小。
The M3UA layer provides the capability to indicate errors associated with received M3UA messages and to notify, as appropriate, local management and/or the peer M3UA.
M3UA层能够指示与接收到的M3UA消息相关的错误，并根据需要通知本地管理层和/或对等M3UA。
At the SGP, the M3UA layer provides interworking with MTP3 management functions to support seamless operation of the user SCN signalling applications in the SS7 and IP domains. This includes
在SGP，M3UA层提供与MTP3管理功能的互通，以支持SS7和IP域中用户SCN信令应用程序的无缝操作。这包括
- providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is not reachable;
- 向ASP上的MTP3用户提供SS7网络中的目的地不可到达的指示；
- providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is now reachable;
- 向ASP上的MTP3用户提供SS7网络中的目的地现在可到达的指示；
- providing an indication to MTP3-Users at an ASP that messages to a destination in the SS7 network are experiencing SS7 congestion;
- 向ASP上的MTP3用户提供向SS7网络中的目的地发送的消息正在经历SS7拥塞的指示；
- providing an indication to the M3UA layer at an ASP that the routes to a destination in the SS7 network are restricted; and
- 向ASP处的M3UA层提供指向SS7网络中目的地的路由受限的指示；和
- providing an indication to MTP3-Users at an ASP that a MTP3-User peer is unavailable.
- 向ASP上的MTP3用户提供MTP3用户对等点不可用的指示。
The M3UA layer at an ASP keeps the state of the routes to remote SS7 destinations and may initiate an audit of the availability and the restricted or the congested state of remote SS7 destinations. This information is requested from the M3UA layer at the SGP.
ASP处的M3UA层保持到远程SS7目的地的路由状态，并可启动对远程SS7目的地的可用性和受限或拥塞状态的审计。该信息是从SGP的M3UA层请求的。
The M3UA layer at an ASP may also indicate to the SG that the M3UA layer itself or the ASP or the ASP's Host is congested.
ASP处的M3UA层还可向SG指示M3UA层本身或ASP或ASP的主机拥塞。
1.3.2.4. Support for the Management of SCTP Associations between the SGP and ASPs
1.3.2.4. 支持SGP和ASP之间SCTP关联的管理
The M3UA layer at the SGP maintains the availability state of all configured remote ASPs, to manage the SCTP Associations and the traffic between the M3UA peers. Also, the active/inactive and congestion state of remote ASPs is maintained.
SGP的M3UA层维护所有配置的远程ASP的可用性状态，以管理SCTP关联和M3UA对等方之间的流量。此外，远程ASP的活动/非活动和拥塞状态也会保持不变。
The M3UA layer MAY be instructed by local management to establish an SCTP association to a peer M3UA node. This can be achieved using the
本地管理层可以指示M3UA层建立与对等M3UA节点的SCTP关联。这可以通过使用
M-SCTP_ESTABLISH primitives (see Section 1.6.3 for a description of management primitives) to request, indicate, and confirm the establishment of an SCTP association with a peer M3UA node. In order to avoid redundant SCTP associations between two M3UA peers, one side (client) SHOULD be designated to establish the SCTP association, or M3UA configuration information maintained to detect redundant associations (e.g., via knowledge of the expected local and remote SCTP endpoint addresses).
M-SCTP_建立原语（有关管理原语的说明，请参见第1.6.3节），以请求、指示和确认与对等M3UA节点建立SCTP关联。为了避免两个M3UA对等方之间的冗余SCTP关联，应指定一方（客户端）建立SCTP关联，或维护M3UA配置信息以检测冗余关联（例如，通过了解预期的本地和远程SCTP端点地址）。
Local management MAY request from the M3UA layer the status of the underlying SCTP associations using the M-SCTP_STATUS request and confirm primitives. Also, the M3UA MAY autonomously inform local management of the reason for the release of an SCTP association, determined either locally within the M3UA layer or by a primitive from the SCTP.
本地管理层可以使用M-SCTP_状态请求和确认原语从M3UA层请求底层SCTP关联的状态。此外，M3UA可以自主地将SCTP关联释放的原因通知本地管理层，由M3UA层内本地确定或由SCTP的原语确定。
Also, the M3UA layer MAY inform the local management of the change in status of an ASP or AS. This MAY be achieved using the M-ASP_STATUS request or M-AS_STATUS request primitives.
此外，M3UA层可以将ASP或AS的状态变化通知本地管理层。这可以通过使用M-ASP_状态请求或M-AS_状态请求原语来实现。
As shown in Figure 1, an ASP may be connected to multiple SGPs. In such a case, a particular SS7 destination may be reachable via more than one SGP and/or SG; i.e., via more than one route. As MTP3 users only maintain status on a destination and not on a route basis, the M3UA layer must maintain the status (availability, restriction, and/or congestion of route to destination) of the individual routes, derive the overall availability or congestion status of the destination from the status of the individual routes, and inform the MTP3 users of this derived status whenever it changes.
如图1所示，一个ASP可以连接到多个SGP。在这种情况下，特定的SS7目的地可经由多个SGP和/或SG到达；i、 例如，通过一条以上的路线。由于MTP3用户仅维护目的地的状态，而不是基于路由，因此M3UA层必须维护各个路由的状态（路由到目的地的可用性、限制和/或拥塞），从各个路由的状态推导出目的地的总体可用性或拥塞状态，并在MTP3状态发生变化时通知MTP3用户该派生状态。
For example, within an SS7 network, a Signalling Gateway might be charged with representing a set of nodes in the IP domain into the SS7 network for routing purposes. The SG itself, as a signalling point in the SS7 network, might also be addressable with an SS7 Point Code for MTP3 Management purposes. The SG Point Code might also be used for addressing any local MTP3-Users at the SG such as a local SCCP layer.
例如，在SS7网络中，信令网关可能负责将IP域中的一组节点表示到SS7网络中以进行路由。作为SS7网络中的信令点，出于MTP3管理目的，SG本身也可以使用SS7点代码进行寻址。SG点代码还可用于寻址SG处的任何本地MTP3用户，如本地SCCP层。
An SG may be logically partitioned to operate in multiple SS7 network appearances. In such a case, the SG could be addressable with a Point Code in each network appearance, and it represents a set of nodes in the IP domain into each SS7 network. Alias Point Codes [8] may also be used within an SG network appearance.
SG可以被逻辑分区以在多个SS7网络外观中操作。在这种情况下，SG可以在每个网络外观中使用点代码进行寻址，并且它表示每个SS7网络中IP域中的一组节点。别名点代码[8]也可在SG网络外观中使用。
Where an SG contains more than one SGP, the MTP3 routeset, SPMC, and remote AS/ASP states of each SGP SHOULD be coordinated across all the SGPs. Rerouting of traffic between the SGPs MAY also be supported.
如果一个SG包含多个SGP，则应在所有SGP之间协调每个SGP的MTP3路由集、SPMC和远程AS/ASP状态。还可以支持SGP之间的流量重新路由。
Application Servers can be represented under the same Point Code of the SG, under their own individual Point Codes, or grouped with other Application Servers for Point Code preservation purposes. A single Point Code may be used to represent the SG and all the Application Servers together, if desired.
应用服务器可以在SG的相同点代码下表示，也可以在其各自的点代码下表示，或者与其他应用服务器分组以保存点代码。如果需要，可以使用单点代码来表示SG和所有应用服务器。
If an ASP or group of ASPs is available to the SS7 network via more than one SG, each with its own Point Code, the ASP(s) will typically be represented by a Point Code that is separate from any SG Point Code. This allows, for example, these SGs to be viewed from the SS7 network as "STPs", each having an ongoing "route" to the same ASP(s). Under failure conditions where the ASP(s) become(s) unavailable from one of the SGs, this approach enables MTP3 route management messaging between the SG and SS7 network, allowing simple SS7 rerouting through an alternate SG without changing the Destination Point Code Address of SS7 traffic to the ASP(s).
如果一个ASP或一组ASP可通过多个SG供SS7网络使用，每个SG都有自己的点代码，则ASP通常由一个与任何SG点代码分开的点代码表示。例如，这允许从SS7网络将这些SGs视为“STP”，每个SGs都有一条到相同ASP的持续“路由”。在ASP从其中一个SG变得不可用的故障条件下，此方法启用SG和SS7网络之间的MTP3路由管理消息传递，允许通过备用SG进行简单的SS7重新路由，而无需将SS7通信量的目标点代码地址更改为ASP。
Where a particular AS can be reached via more than one SGP, the corresponding Routing Keys in the SGPs should be identical. (Note: It is possible for the SGP Routing Key configuration data to be temporarily out of sync during configuration updates).
如果可以通过多个SGP访问特定AS，则SGP中的相应路由密钥应相同。（注意：在配置更新期间，SGP路由密钥配置数据可能暂时不同步）。
+--------+
| |
+------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ----
| SEP +---+ +--------+ +---/ \
| or | |* | ASPs |
| STP +---+ +--------+ +---\ /
+-------+ | | | | ----
+------------+ SG 2 +--------------+
| "STP" |
+--------+
+--------+
| |
+------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ----
| SEP +---+ +--------+ +---/ \
| or | |* | ASPs |
| STP +---+ +--------+ +---\ /
+-------+ | | | | ----
+------------+ SG 2 +--------------+
| "STP" |
+--------+
Figure 1. Example with mated SGs
图1。匹配SGs的示例
* Note: SG-to-SG communication (i.e., "C-links") is recommended for carrier grade networks, using an MTP3 linkset or an
* 注：对于运营商级网络，建议使用MTP3链路集或
equivalent, to allow rerouting between the SGs in the event of route failures. Where SGPs are used, inter-SGP communication might be used. Inter-SGP protocol is outside of the scope of this document.
等效，允许在发生路由故障时在SGs之间重新路由。在使用SGP的情况下，可以使用SGP间通信。SGP间协议不在本文件范围内。
The following example shows a signalling gateway partitioned into two network appearances.
以下示例显示了划分为两个网络外观的信令网关。
SG
+-------+ +---------------+
| SEP +--------------| SS7 Ntwk.|M3UA| ----
+-------+ SS7 links | "A" | | / \
|__________| +-----------+ ASPs |
| | | \ /
+-------+ | SS7 Ntwk.| | ----
| SEP +--------------+ "B" | |
+-------+ +---------------+
SG
+-------+ +---------------+
| SEP +--------------| SS7 Ntwk.|M3UA| ----
+-------+ SS7 links | "A" | | / \
|__________| +-----------+ ASPs |
| | | \ /
+-------+ | SS7 Ntwk.| | ----
| SEP +--------------+ "B" | |
+-------+ +---------------+
Figure 2. Example with multiple network
图2。具有多个网络的示例
The distribution of SS7 messages between the SGP and the Application Servers is determined by the Routing Keys and their associated Routing Contexts. A Routing Key is essentially a set of SS7 parameters used to filter SS7 messages, whereas the Routing Context parameter is a 4-octet value (integer) that is associated to that Routing Key in a 1:1 relationship. The Routing Context therefore can be viewed as an index into a sending node's Message Distribution Table containing the Routing Key entries.
SS7消息在SGP和应用服务器之间的分布由路由密钥及其关联的路由上下文决定。路由密钥本质上是一组用于过滤SS7消息的SS7参数，而路由上下文参数是一个4个八位组的值（整数），该值以1:1的关系与该路由密钥关联。因此，可以将路由上下文视为发送节点的消息分发表（包含路由键条目）的索引。
Possible SS7 address/routing information that comprise a Routing Key entry includes, for example, the OPC, DPC, and SIO found in the MTP3 routing label. Some example Routing Keys are: the DPC alone, the DPC/OPC combination, or the DPC/OPC/SI combination. The particular information used to define an M3UA Routing Key is application and network dependent, and none of the above examples are mandated.
包括路由密钥条目的可能SS7地址/路由信息包括，例如，MTP3路由标签中的OPC、DPC和SIO。一些路由键示例有：DPC单独、DPC/OPC组合或DPC/OPC/SI组合。用于定义M3UA路由密钥的特定信息取决于应用程序和网络，以上示例均未强制要求。
An Application Server Process may be configured to process signalling traffic related to more than one Application Server, over a single SCTP Association. In ASP Active and ASP Inactive management messages, the signalling traffic to be started or stopped is discriminated by the Routing Context parameter. At an ASP, the Routing Context parameter uniquely identifies the range of signalling traffic associated with each Application Server that the ASP is configured to receive.
应用服务器进程可被配置为通过单个SCTP关联处理与多个应用服务器相关的信令业务。在ASP Active和ASP Inactive管理消息中，要启动或停止的信令通信量由路由上下文参数区分。在ASP上，Routing Context参数唯一地标识与ASP配置为接收的每个应用程序服务器相关联的信令通信量的范围。
Routing Keys SHOULD be unique in the sense that each received SS7 signalling message SHOULD have a full or partial match to a single routing result. An example of a partial match would be a default Routing Key that would be the result if there are no other Routing Keys to which the message belongs. It is not necessary for the parameter range values within a particular Routing Key to be contiguous.
路由密钥应该是唯一的，因为每个收到的SS7信令消息都应该与单个路由结果完全或部分匹配。部分匹配的一个示例是默认路由密钥，如果消息不属于其他路由密钥，则会产生该密钥。特定路由密钥中的参数范围值不必是连续的。
There are two ways to provision a Routing Key at an SGP. A Routing Key may be configured statically using an implementation dependent management interface, or dynamically using the M3UA Routing Key registration procedure.
在SGP中提供路由密钥有两种方法。路由密钥可以使用依赖于实现的管理接口静态配置，也可以使用M3UA路由密钥注册过程动态配置。
When using a management interface to configure Routing Keys, the message distribution function within the SGP is not limited to the set of parameters defined in this document. Other implementation-dependent distribution algorithms may be used.
使用管理界面配置路由密钥时，SGP中的消息分发功能不限于本文档中定义的参数集。可以使用其他依赖于实现的分布算法。
To direct messages received from the SS7 MTP3 network to the appropriate IP destination, the SGP must perform a message distribution function using information from the received MTP3-User message.
为了将从SS7 MTP3网络接收到的消息定向到适当的IP目的地，SGP必须使用来自接收到的MTP3用户消息的信息执行消息分发功能。
To support this message distribution, the SGP might, for example, maintain the equivalent of a network address translation table, mapping incoming SS7 message information to an Application Server for a particular application and range of traffic. This could be accomplished by comparing elements of the incoming SS7 message to currently defined Routing Keys in the SGP.
为了支持此消息分发，例如，SGP可以维护等效的网络地址转换表，将传入的SS7消息信息映射到特定应用程序和流量范围的应用服务器。这可以通过将传入SS7消息的元素与SGP中当前定义的路由密钥进行比较来实现。
These Routing Keys could in turn map directly to an Application Server that is enabled by one or more ASPs. These ASPs provide dynamic status information regarding their availability, traffic-handling capability and congestion to the SGP using various management messages defined in the M3UA protocol.
这些路由密钥又可以直接映射到由一个或多个ASP启用的应用程序服务器。这些ASP使用M3UA协议中定义的各种管理消息向SGP提供有关其可用性、流量处理能力和拥塞的动态状态信息。
The list of ASPs in an AS is assumed to be dynamic, taking into account the availability, traffic-handling capability, and congestion status of the individual ASPs in the list, as well as configuration changes and possible failover mechanisms.
假设AS中的ASP列表是动态的，考虑到列表中各个ASP的可用性、流量处理能力和拥塞状态，以及配置更改和可能的故障切换机制。
Normally, one or more ASPs are active (i.e., currently processing traffic) in the AS, but in certain failure and transition cases it is possible that there may be no active ASP available. Broadcast, loadsharing, and backup scenarios are supported.
通常，AS中有一个或多个ASP处于活动状态（即当前正在处理流量），但在某些故障和转换情况下，可能没有可用的活动ASP。支持广播、负载共享和备份方案。
When there is no matching Routing Key entry for an incoming SS7 message, a default treatment MAY be specified. Possible solutions are to provide a default Application Server at the SGP that directs all unallocated traffic to a (set of) default ASPs, or to drop the message and provide a notification to layer management. The treatment of unallocated traffic is implementation dependent.
当传入SS7消息没有匹配的路由密钥条目时，可以指定默认处理。可能的解决方案是在SGP上提供一个默认的应用服务器，将所有未分配的流量定向到（一组）默认的ASP，或者删除消息并向层管理提供通知。未分配流量的处理取决于实现。
The ASP must choose an SGP to direct a message to the SS7 network. This is accomplished by observing the Destination Point Code (and possibly other elements of the outgoing message, such as the SLS value). The ASP must also take into account whether the related Routing Context is active or not (see Section 4.3.4.3).
ASP必须选择SGP将消息定向到SS7网络。这是通过观察目的地代码（可能还有传出消息的其他元素，如SLS值）来实现的。ASP还必须考虑相关路由上下文是否处于活动状态（参见第4.3.4.3节）。
Implementation Note: Where more than one route (or SGP) is possible for routing to the SS7 network, the ASP could, for example, maintain a dynamic table of available SGP routes for the SS7 destinations, taking into account the SS7 destination availability/restricted/congestion status received from the SGP(s), the availability status of the individual SGPs, and configuration changes and failover mechanisms. There is, however, no M3UA messaging to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
实施说明：如果有多个路由（或SGP）可以路由到SS7网络，ASP可以（例如）维护SS7目的地可用SGP路由的动态表，同时考虑从SGP接收到的SS7目的地可用性/受限/拥塞状态，单个SGP的可用性状态、配置更改和故障切换机制。但是，没有用于管理SGP状态的M3UA消息（例如，SGP向上/向下/活动/非活动消息）。
Whenever an SCTP association to an SGP exists, the SGP is assumed to be ready for the purposes of responding to M3UA ASPSM messages (refer to Section 3).
只要存在与SGP的SCTP关联，就假定SGP已准备好响应M3UA ASPSM消息（参考第3节）。
In the case of SS7 and M3UA interworking, the M3UA adaptation layer is designed to provide an extension of the MTP3-defined user primitives.
在SS7和M3UA互通的情况下，M3UA适配层旨在提供MTP3定义的用户原语的扩展。
The SG is responsible for terminating MTP Level 3 of the SS7 protocol, and offering an IP-based extension to its users.
SG负责终止SS7协议的MTP级别3，并向其用户提供基于IP的扩展。
From an SS7 perspective, it is expected that the Signalling Gateway transmits and receives SS7 Message Signalling Units (MSUs) over a standard SS7 network interface, using the SS7 Message Transfer Part (MTP) [7,8,9].
从SS7的角度来看，预期信令网关使用SS7消息传输部分（MTP）通过标准SS7网络接口发送和接收SS7消息信令单元（MSU）[7,8,9]。
As a standard SS7 network interface, the use of MTP Level 2 signalling links is not the only possibility. ATM-based High Speed Links can also be used with the services of the Signalling ATM Adaptation Layer (SAAL) [19,20].
作为标准的SS7网络接口，使用MTP 2级信令链路不是唯一的可能性。基于ATM的高速链路也可与信令ATM适配层（SAAL）的服务一起使用[19,20]。
Note: It is also possible for IP-based interfaces to be present, using the services of the MTP2-User Adaptation Layer (M2UA) [24] or M2PA [25].
注：也可以使用MTP2用户适配层（M2UA）[24]或M2PA[25]的服务提供基于IP的接口。
These could be terminated at a Signalling Transfer Point (STP) or Signalling End Point (SEP). Using the services of MTP3, the SG could be capable of communicating with remote SS7 SEPs in a quasi-associated fashion, where STPs may be present in the SS7 path between the SEP and the SG.
这些可以在信令传输点（STP）或信令端点（SEP）处终止。使用MTP3的服务，SG能够以准关联方式与远程SS7 SEP通信，其中STP可能存在于SEP和SG之间的SS7路径中。
The SGP provides a functional interworking of transport functions between the SS7 network and the IP network by also supporting the M3UA adaptation layer. It allows the transfer of MTP3-User signalling messages to and from an IP-based Application Server Process where the peer MTP3-User protocol layer exists.
SGP通过支持M3UA适配层，提供SS7网络和IP网络之间传输功能的功能互通。它允许在存在对等MTP3用户协议层的基于IP的应用服务器进程之间传输MTP3用户信令消息。
For SS7 user part management, it is required that the MTP3-User protocols at ASPs receive indications of SS7 signalling point availability, SS7 network congestion, and remote User Part unavailability, as would be expected in an SS7 SEP node. To accomplish this, the MTP-PAUSE, MTP-RESUME, and MTP-STATUS indication primitives received at the MTP3 upper layer interface at the SG need to be propagated to the remote MTP3-User lower layer interface at the ASP.
对于SS7用户部件管理，要求ASPs的MTP3用户协议接收SS7信令点可用性、SS7网络拥塞和远程用户部件不可用性的指示，正如在SS7 SEP节点中预期的那样。为此，在SG的MTP3上层接口接收到的MTP-PAUSE、MTP-RESUME和MTP-STATUS指示原语需要传播到ASP的远程MTP3用户下层接口。
MTP3 management messages (such as TFPs or TFAs received from the SS7 network) MUST NOT be encapsulated as Data message Payload Data and sent either from SG to ASP or from ASP to SG. The SG MUST terminate these messages and generate M3UA messages, as appropriate.
MTP3管理消息（如从SS7网络接收的TFP或TFA）不得封装为数据消息有效负载数据，并从SG发送至ASP或从ASP发送至SG。SG必须终止这些消息并酌情生成M3UA消息。
A cluster of application servers is responsible for providing the overall support for one or more SS7 upper layers. From an SS7 standpoint, a Signalling Point Management Cluster (SPMC) provides complete support for the upper layer service for a given point code.
应用服务器集群负责为一个或多个SS7上层提供总体支持。从SS7的角度来看，信令点管理集群（SPMC）为给定点代码的上层服务提供完全支持。
As an example, an SPMC providing MGC capabilities could provide complete support for ISUP (and any other MTP3 user located at the point code of the SPMC) for a given point code.
例如，提供MGC功能的SPMC可以为ISUP（以及位于SPMC点代码处的任何其他MTP3用户）提供给定点代码的完整支持。
In the case where an ASP is connected to more than one SGP, the M3UA layer must maintain the status of configured SS7 destinations and route messages according to the availability/congestion/restricted status of the routes to these SS7 destinations.
在ASP连接到多个SGP的情况下，M3UA层必须根据到这些SS7目的地的路由的可用性/拥塞/受限状态保持已配置SS7目的地的状态和路由消息。
Since IPSPs use M3UA in a point-to-point fashion, there is no concept of routing of messages beyond the remote end. Therefore, SS7 and M3UA interworking is not necessary for this model.
由于IPSP以点对点的方式使用M3UA，因此没有将消息路由到远程端以外的概念。因此，该型号不需要SS7和M3UA互通。
All MTP3-User messages (e.g., ISUP, SCCP) that match a provisioned Routing Key at an SGP are mapped to an Application Server.
所有与SGP上配置的路由密钥匹配的MTP3用户消息（例如，ISUP、SCCP）都映射到应用服务器。
The Application Server is the set of all ASPs associated with a specific Routing Key. Each ASP in this set may be active, inactive, or unavailable. Active ASPs handle traffic; inactive ASPs might be used when active ASPs become unavailable.
应用服务器是与特定路由密钥关联的所有ASP的集合。此集中的每个ASP都可能处于活动、非活动或不可用状态。主动ASP处理流量；当活动的ASP不可用时，可能会使用非活动的ASP。
The failover model supports an "n+k" redundancy model, where "n" ASPs is the minimum number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP. Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be either active at the same time as "n" or kept inactive until needed due to a failed or unavailable ASP.
故障转移模型支持“n+k”冗余模型，其中“n”个ASP是处理流量所需的最小冗余ASP数量，“k”个ASP可用于接管发生故障或不可用的ASP。流量应在“n”ASP激活后发送。“k”ASP可能与“n”同时处于活动状态，也可能由于ASP失败或不可用而在需要之前一直处于非活动状态。
A "1+1" active/backup redundancy is a subset of this model. A simplex "1+0" model is also supported as a subset, with no ASP redundancy.
“1+1”主动/备份冗余是该模型的一个子集。单工“1+0”模型也支持作为子集，没有ASP冗余。
Local Management at an ASP may wish to stop traffic across an SCTP association to temporarily remove the association from service or to perform testing and maintenance activity. The function could optionally be used to control the start of traffic on to a newly available SCTP association.
ASP的本地管理层可能希望停止通过SCTP关联的通信，以临时将该关联从服务中删除，或执行测试和维护活动。该功能可选择性地用于控制新可用SCTP关联上的流量开始。
The M3UA layer is informed of local and IP network congestion by means of an implementation-dependent function (e.g., an implementation-dependent indication from the SCTP of IP network congestion).
M3UA层通过依赖于实现的功能（例如，来自IP网络拥塞的SCTP的依赖于实现的指示）通知本地和IP网络拥塞。
At an ASP or IPSP, the M3UA layer indicates IP network congestion to local MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3 procedures, to invoke appropriate upper-layer responses.
在ASP或IPSP中，M3UA层通过MTP-STATUS原语（根据当前MTP3程序）向本地MTP3用户指示IP网络拥塞，以调用适当的上层响应。
When an SG determines that the transport of SS7 messages to a Signalling Point Management Cluster (SPMC) is encountering IP network congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled management messages to originating SS7 nodes, per the congestion procedures of the relevant MTP3 standard. The triggering of SS7 MTP3 Management messages from an SG is an implementation-dependent function.
当SG确定到信令点管理集群（SPMC）的SS7消息的传输遇到IP网络拥塞时，SG可根据相关MTP3标准的拥塞过程触发SS7 MTP3向发起SS7节点传输受控管理消息。从SG触发SS7 MTP3管理消息是一项依赖于实现的功能。
The M3UA layer at an ASP or IPSP MAY indicate local congestion to an M3UA peer with an SCON message. When an SG receives a congestion message (SCON) from an ASP and the SG determines that an SPMC is now encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled management messages to concerned SS7 destinations according to congestion procedures of the relevant MTP3 standard.
ASP或IPSP上的M3UA层可能通过SCON消息向M3UA对等方指示本地拥塞。当SG从ASP接收到拥塞消息（SCON）并且SG确定SPMC现在遇到拥塞时，它可以根据相关MTP3标准的拥塞过程触发SS7 MTP3向相关SS7目的地传输受控管理消息。
The M3UA layer at both the SGP and ASP also supports the assignment of signalling traffic into streams within an SCTP association. Traffic that requires sequencing SHOULD be assigned to the same stream. To accomplish this, MTP3-User traffic may be assigned to individual streams based on, for example, the SLS value in the MTP3 Routing Label, subject of course to the maximum number of streams supported by the underlying SCTP association.
SGP和ASP的M3UA层还支持将信令流量分配到SCTP关联内的流中。需要排序的流量应分配给同一个流。为了实现这一点，可以基于例如MTP3路由标签中的SLS值，将MTP3用户业务分配给各个流，当然取决于基础SCTP关联支持的最大流数。
The following rules apply (see Section 3.1.2):
以下规则适用（见第3.1.2节）：
1. The DATA message MUST NOT be sent on stream 0. 2. The ASPSM, MGMT, RKM classes SHOULD be sent on stream 0 (other than BEAT, BEAT ACK and NTFY messages). 3. The SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be sent on any stream.
1. 数据消息不能在流0上发送。2.ASPSM、MGMT、RKM类应在流0上发送（BEAT、BEAT ACK和NTFY消息除外）。3.SSNM、ASPTM类和BEAT、BEAT ACK和NTFY消息可以在任何流上发送。
It is recommended that the SGP and ASP be able to support both client and server operation. The peer endpoints using M3UA SHOULD be
建议SGP和ASP能够同时支持客户端和服务器操作。使用M3UA的对等端点应该是
configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations. The default orientation would be for the SGP to take on the role of server while the ASP is the client. In this case, ASPs SHOULD initiate the SCTP association to the SGP.
配置为一个始终担任客户端角色，另一个始终担任服务器角色，以启动SCTP关联。默认方向是SGP承担服务器角色，而ASP是客户端。在这种情况下，ASP应启动与SGP的SCTP关联。
In the case of IPSP to IPSP communication, the peer endpoints using M3UA SHOULD be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations.
在IPSP到IPSP通信的情况下，应配置使用M3UA的对等端点，以便其中一个始终扮演客户端角色，另一个始终扮演服务器角色，以启动SCTP关联。
The SCTP and TCP Registered User Port Number Assignment for M3UA is 2905.
M3UA的SCTP和TCP注册用户端口号分配为2905。
******** SS7 ***************** IP ********
* SEP *---------* SGP *--------* ASP *
******** ***************** ********
******** SS7 ***************** IP ********
* SEP *---------* SGP *--------* ASP *
******** ***************** ********
+------+ +---------------+ +------+
| ISUP | | (NIF) | | ISUP |
+------+ +------+ +------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+-+------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+
|_______________| |______________|
+------+ +---------------+ +------+
| ISUP | | (NIF) | | ISUP |
+------+ +------+ +------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+-+------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+
|_______________| |______________|
SEP - SS7 Signalling End Point SCTP - Stream Control Transmission Protocol NIF - Nodal Interworking Function
SEP-SS7信令端点SCTP-流控制传输协议NIF-节点互通功能
In this example, the SGP provides an implementation-dependent nodal interworking function (NIF) that allows the MGC to exchange SS7 signalling messages with the SS7-based SEP. The NIF within the SGP serves as the interface within the SGP between the MTP3 and M3UA. This nodal interworking function has no visible peer protocol with either the MGC or SEP. It also provides network status information to one or both sides of the network.
在该示例中，SGP提供了一个依赖于实现的节点互通功能（NIF），该功能允许MGC与基于SS7的SEP交换SS7信令消息。SGP内的NIF用作SGP内MTP3和M3UA之间的接口。该节点互通功能与MGC或SEP都没有可见的对等协议。它还向网络的一侧或两侧提供网络状态信息。
For internal SGP modeling purposes, at the NIF level, SS7 signalling messages that are destined to the MGC are received as MTP-TRANSFER indication primitives from the MTP Level 3 upper layer interface,
出于内部SGP建模的目的，在NIF级别，目的地为MGC的SS7信令消息作为MTP-TRANSFER指示原语从MTP级别3上层接口接收，
translated to MTP-TRANSFER request primitives, and sent to the local M3UA-resident message distribution function for ongoing routing to the final IP destination. Messages received from the local M3UA network address translation and mapping function as MTP-TRANSFER indication primitives are sent to the MTP Level 3 upper-layer interface as MTP-TRANSFER request primitives for ongoing MTP Level 3 routing to an SS7 SEP. For the purposes of providing SS7 network status information, the NIF also delivers MTP-PAUSE, MTP-RESUME, and MTP-STATUS indication primitives received from the MTP Level 3 upper-layer interface to the local M3UA-resident management function. In addition, as an implementation and network option, restricted destinations are communicated from MTP network management to the local M3UA-resident management function.
转换为MTP-TRANSFER请求原语，并发送至本地M3UA常驻消息分发功能，以持续路由至最终IP目的地。从本地M3UA网络地址转换和映射功能接收的消息作为MTP传输指示原语发送至MTP 3级上层接口，作为MTP传输请求原语，用于将MTP 3级路由发送至SS7 SEP，以提供SS7网络状态信息，NIF还将从MTP 3级上层接口接收的MTP-PAUSE、MTP-RESUME和MTP-STATUS指示原语传递给本地M3UA常驻管理功能。此外，作为一种实现和网络选项，限制目的地从MTP网络管理传送到本地M3UA常驻管理功能。
******** IP ********
* IPSP * * IPSP *
******** ********
******** IP ********
* IPSP * * IPSP *
******** ********
+------+ +------+
|SCCP- | |SCCP- |
| User | | User |
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| M3UA | | M3UA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
|________________|
+------+ +------+
|SCCP- | |SCCP- |
| User | | User |
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| M3UA | | M3UA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
|________________|
This example shows an architecture where no Signalling Gateway is used. In this example, SCCP messages are exchanged directly between two IP-resident IPSPs with resident SCCP-User protocol instances, such as RANAP or TCAP. SS7 network interworking is not required; therefore, there is no MTP3 network management status information for the SCCP and SCCP-User protocols to consider. Any MTP-PAUSE, MTP-RESUME, or MTP-STATUS indications from the M3UA layer to the SCCP layer should consider the status of the SCTP Association and underlying IP network and any congestion information received from the remote site.
此示例显示了一种不使用信令网关的体系结构。在此示例中，SCCP消息直接在两个驻留在IP上的IPSP与驻留在IP上的SCCP用户协议实例（如RANAP或TCAP）之间交换。不需要SS7网络互通；因此，没有MTP3网络管理状态信息为SCCP和SCCP用户协议考虑。从M3UA层到SCCP层的任何MTP暂停、MTP恢复或MTP状态指示应考虑SCTP关联和底层IP网络的状态以及从远程站点接收的任何拥塞信息。
******** SS7 ***************** IP ********
* SEP *---------* *--------* *
* or * * SGP * * ASP *
* STP * * * * *
******** ***************** ********
******** SS7 ***************** IP ********
* SEP *---------* *--------* *
* or * * SGP * * ASP *
* STP * * * * *
******** ***************** ********
+------+ +---------------+ +------+
| SCCP-| | SCCP | | SCCP-|
| User | +---------------+ | User |
+------+ | _____ | +------+
| SCCP | | | | | | SCCP |
+------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+
|_______________| |______________|
+------+ +---------------+ +------+
| SCCP-| | SCCP | | SCCP-|
| User | +---------------+ | User |
+------+ | _____ | +------+
| SCCP | | | | | | SCCP |
+------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+
|_______________| |______________|
STP - SS7 Signalling Transfer Point
STP-SS7信令传输点
In this example, the SGP contains an instance of the SS7 SCCP protocol layer that may, for example, perform the SCCP Global Title Translation (GTT) function for messages logically addressed to the SG SCCP. If the result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN address of an SCCP peer located in the IP domain, the resulting MTP-TRANSFER request primitive is sent to the local M3UA-resident network address translation and mapping function for ongoing routing to the final IP destination.
在该示例中，SGP包含SS7 SCCP协议层的实例，该实例例如可以对逻辑上寻址到SG SCCP的消息执行SCCP全局标题转换（GTT）功能。如果SCCP消息的GTT结果产生位于IP域中的SCCP对等方的SS7 DPC或DPC/SSN地址，则生成的MTP-TRANSFER request原语将发送到本地M3UA常驻网络地址转换和映射功能，以便持续路由到最终IP目的地。
Similarly, the SCCP instance in an SGP can perform the SCCP GTT service for messages logically addressed to it from SCCP peers in the IP domain. In this case, MTP-TRANSFER indication primitives are sent from the local M3UA-resident network address translation and mapping function to the SCCP for GTT. If the result of the GTT yields the address of an SCCP peer in the SS7 network, then the resulting MTP-TRANSFER request primitive is given to the MTP3 for delivery to an SS7-resident node.
类似地，SGP中的SCCP实例可以对从IP域中的SCCP对等方逻辑寻址到它的消息执行SCCP GTT服务。在这种情况下，MTP传输指示原语从本地M3UA常驻网络地址转换和映射功能发送到GTT的SCCP。如果GTT的结果产生SS7网络中SCCP对等方的地址，则将产生的MTP-TRANSFER request原语提供给MTP3以交付给SS7驻留节点。
It is possible that the above SCCP GTT at the SGP could yield the address of an SCCP peer in the IP domain, and that the resulting MTP-TRANSFER request primitive would be sent back to the M3UA layer for delivery to an IP destination.
SGP上的上述SCCP GTT可能会产生IP域中SCCP对等方的地址，并且生成的MTP-TRANSFER request原语将被发送回M3UA层，以交付到IP目的地。
For internal SGP modeling purposes, this may be accomplished with the use of an implementation-dependent nodal interworking function within the SGP that effectively sits below the SCCP and routes MTP-TRANSFER request/indication messages to/from both the MTP3 and the M3UA layer, based on the SS7 DPC or DPC/SI address information. This nodal interworking function has no visible peer protocol with either the ASP or SEP.
出于内部SGP建模目的，这可以通过在SGP内使用依赖于实现的节点互通功能来实现，该功能有效地位于SCCP之下，并基于SS7 DPC或DPC/SI地址信息，将MTP传输请求/指示消息路由到MTP3和M3UA层，或从MTP3和M3UA层路由MTP传输请求/指示消息。此节点互通功能与ASP或SEP都没有可见的对等协议。
Note that the services and interface provided by the M3UA layer are the same as in Example 1 and that the functions taking place in the SCCP entity are transparent to the M3UA layer. The SCCP protocol functions are not reproduced in the M3UA protocol.
请注意，M3UA层提供的服务和接口与示例1中的相同，并且SCCP实体中发生的功能对M3UA层是透明的。SCCP协议功能不在M3UA协议中重现。
This section provides a definition of the boundaries of the M3UA protocol. They consist of SCTP, Layer Management, and the MTP3-User.
本节提供了M3UA协议边界的定义。它们由SCTP、层管理和MTP3用户组成。
+-----------+
| MTP3-User |
+-----------+
|
|
+-----------+ +------------+
| M3UA |-----| Layer Mgmt |
+-----------+ +------------+
|
|
+-----------+
| SCTP |
+-----------+
+-----------+
| MTP3-User |
+-----------+
|
|
+-----------+ +------------+
| M3UA |-----| Layer Mgmt |
+-----------+ +------------+
|
|
+-----------+
| SCTP |
+-----------+
From ITU Q.701 [7]:
来自ITU Q.701[7]：
MTP-TRANSFER request MTP-TRANSFER indication MTP-PAUSE indication MTP-RESUME indication MTP-STATUS indication
MTP-传输请求MTP-传输指示MTP-暂停指示MTP-恢复指示MTP-状态指示
An example of the upper-layer primitives provided by the SCTP are provided in Reference [18], Section 10.
参考文献[18]第10节提供了SCTP提供的上层原语示例。
M-SCTP_ESTABLISH request Direction: LM -> M3UA Purpose: LM requests that ASP establish an SCTP association with its peer.
M-SCTP_建立请求方向：LM->M3UA目的：LM请求ASP与其对等方建立SCTP关联。
M-SCTP_ESTABLISH confirm Direction: M3UA -> LM Purpose: ASP confirms to LM that it has established an SCTP association with its peer.
M-SCTP_建立确认方向：M3UA->LM目的：ASP向LM确认其已与其对等方建立SCTP关联。
M-SCTP_ESTABLISH indication Direction: M3UA -> LM Purpose: M3UA informs LM that a remote ASP has established an SCTP association.
M-SCTP_建立指示方向：M3UA->LM目的：M3UA通知LM远程ASP已建立SCTP关联。
M-SCTP_RELEASE request Direction: LM -> M3UA Purpose: LM requests that ASP release an SCTP association with its peer.
M-SCTP_释放请求方向：LM->M3UA目的：LM请求ASP释放与其对等方的SCTP关联。
M-SCTP_RELEASE confirm Direction: M3UA -> LM Purpose: ASP confirms to LM that it has released SCTP association with its peer.
M-SCTP_发布确认方向：M3UA->LM目的：ASP向LM确认其已发布与其对等方的SCTP关联。
M-SCTP_RELEASE indication Direction: M3UA -> LM Purpose: M3UA informs LM that a remote ASP has released an SCTP Association or that the SCTP association has failed.
M-SCTP_释放指示方向：M3UA->LM目的：M3UA通知LM远程ASP已释放SCTP关联或SCTP关联已失败。
M-SCTP_RESTART indication Direction: M3UA -> LM Purpose: M3UA informs LM that an SCTP restart indication has been received.
M-SCTP_重启指示方向：M3UA->LM目的：M3UA通知LM已收到SCTP重启指示。
M-SCTP_STATUS request Direction: LM -> M3UA Purpose: LM requests that M3UA report the status of an SCTP association.
M-SCTP_状态请求方向：LM->M3UA目的：LM请求M3UA报告SCTP关联的状态。
M-SCTP_STATUS confirm Direction: M3UA -> LM Purpose: M3UA responds with the status of an SCTP association.
M-SCTP_状态确认方向：M3UA->LM目的：M3UA响应SCTP关联状态。
M-SCTP STATUS indication Direction: M3UA -> LM Purpose: M3UA reports the status of an SCTP association.
M-SCTP状态指示方向：M3UA->LM目的：M3UA报告SCTP关联的状态。
M-ASP_STATUS request Direction: LM -> M3UA Purpose: LM requests that M3UA report the status of a local or remote ASP.
M-ASP_状态请求方向：LM->M3UA目的：LM请求M3UA报告本地或远程ASP的状态。
M-ASP_STATUS confirm Direction: M3UA -> LM Purpose: M3UA reports the status of local or remote ASP.
M-ASP_状态确认方向：M3UA->LM目的：M3UA报告本地或远程ASP的状态。
M-AS_STATUS request Direction: LM -> M3UA Purpose: LM requests that M3UA report the status of an AS.
M-AS_状态请求方向：LM->M3UA目的：LM请求M3UA报告AS的状态。
M-AS_STATUS confirm Direction: M3UA -> LM Purpose: M3UA reports the status of an AS.
M-AS_状态确认方向：M3UA->LM目的：M3UA报告AS的状态。
M-NOTIFY indication Direction: M3UA -> LM Purpose: M3UA reports that it has received a Notify message from its peer.
M-NOTIFY指示方向：M3UA->LM目的：M3UA报告已收到来自其对等方的NOTIFY消息。
M-ERROR indication Direction: M3UA -> LM Purpose: M3UA reports that it has received an Error message from its peer or that a local operation has been unsuccessful.
M-错误指示方向：M3UA->LM目的：M3UA报告其已收到来自其对等方的错误消息或本地操作已失败。
M-ASP_UP request Direction: LM -> M3UA Purpose: LM requests that ASP start its operation and send an ASP Up message to its peer.
M-ASP_UP请求方向：LM->M3UA目的：LM请求ASP启动其操作并向其对等方发送ASP UP消息。
M-ASP_UP confirm Direction: M3UA -> LM Purpose: ASP reports that it has received an ASP UP Ack message from its peer.
M-ASP_UP confirm Direction:M3UA->LM Purpose:ASP报告已从其对等方收到ASP UP Ack消息。
M-ASP_UP indication Direction: M3UA -> LM Purpose: M3UA reports that it has successfully processed an incoming ASP Up message from its peer.
M-ASP\U UP指示方向：M3UA->LM目的：M3UA报告已成功处理来自其对等方的传入ASP UP消息。
M-ASP_DOWN request Direction: LM -> M3UA Purpose: LM requests that ASP stop its operation and send an ASP Down message to its peer.
M-ASP_DOWN请求方向：LM->M3UA目的：LM请求ASP停止其操作并向其对等方发送ASP DOWN消息。
M-ASP_DOWN confirm Direction: M3UA -> LM Purpose: ASP reports that it has received an ASP Down Ack message from its peer.
M-ASP_DOWN confirm Direction:M3UA->LM Purpose:ASP报告已收到来自对等方的ASP DOWN确认消息。
M-ASP_DOWN indication Direction: M3UA -> LM Purpose: M3UA reports that it has successfully processed an incoming ASP Down message from its peer, or the SCTP association has been lost/reset.
M-ASP_向下指示方向：M3UA->LM目的：M3UA报告已成功处理来自其对等方的传入ASP向下消息，或者SCTP关联已丢失/重置。
M-ASP_ACTIVE request Direction: LM -> M3UA Purpose: LM requests that ASP send an ASP Active message to its peer.
M-ASP_活动请求方向：LM->M3UA目的：LM请求ASP向其对等方发送ASP活动消息。
M-ASP_ACTIVE confirm Direction: M3UA -> LM Purpose: ASP reports that it has received an ASP Active Ack message from its peer.
M-ASP_活动确认方向：M3UA->LM目的：ASP报告已从其对等方收到ASP活动确认消息。
M-ASP_ACTIVE indication Direction: M3UA -> LM Purpose: M3UA reports that it has successfully processed an incoming ASP Active message from its peer.
M-ASP_活动指示方向：M3UA->LM目的：M3UA报告已成功处理来自其对等方的传入ASP活动消息。
M-ASP_INACTIVE request Direction: LM -> M3UA Purpose: LM requests that ASP send an ASP Inactive message to its peer.
M-ASP_非活动请求方向：LM->M3UA目的：LM请求ASP向其对等方发送ASP非活动消息。
M-ASP_INACTIVE confirm Direction: LM -> M3UA Purpose: ASP reports that it has received an ASP Inactive Ack message from its peer.
M-ASP_非活动确认方向：LM->M3UA目的：ASP报告已从其对等方收到ASP非活动确认消息。
M-ASP_INACTIVE indication Direction: M3UA -> LM Purpose: M3UA reports that it has successfully processed an incoming ASP Inactive message from its peer.
M-ASP_非活动指示方向：M3UA->LM目的：M3UA报告已成功处理来自其对等方的传入ASP非活动消息。
M-AS_ACTIVE indication Direction: M3UA -> LM Purpose: M3UA reports that an AS has moved to the AS-ACTIVE state.
M-AS_活动指示方向：M3UA->LM目的：M3UA报告AS已移动到活动状态。
M-AS_INACTIVE indication Direction: M3UA -> LM Purpose: M3UA reports that an AS has moved to the AS-INACTIVE state.
M-AS_非活动指示方向：M3UA->LM目的：M3UA报告AS已移动到非活动状态。
M-AS_DOWN indication Direction: M3UA -> LM Purpose: M3UA reports that an AS has moved to the AS-DOWN state.
M-AS_下降指示方向：M3UA->LM目的：M3UA报告AS已移动到AS下降状态。
If dynamic registration of RK is supported by the M3UA layer, the layer MAY support the following additional primitives:
如果M3UA层支持RK的动态注册，则该层可能支持以下附加原语：
M-RK_REG request Direction: LM -> M3UA Purpose: LM requests that ASP register RK(s) with its peer by sending an REG REQ message
M-RK_REG请求方向：LM->M3UA目的：LM通过发送REG REQ消息请求ASP向其对等方注册RK
M-RK_REG confirm Direction: M3UA -> LM Purpose: ASP reports that it has received REG RSP message with a registration status of successful from its peer.
M-RK_REG confirm Direction:M3UA->LM Purpose:ASP报告已从其对等方收到注册状态为成功的REG RSP消息。
M-RK_REG indication Direction: M3UA -> LM Purpose: M3UA informs LM that it has successfully processed an incoming REG REQ message.
M-RK_REG指示方向：M3UA->LM目的：M3UA通知LM已成功处理传入REG REQ消息。
M-RK_DEREG request Direction: LM -> M3UA Purpose: LM requests that ASP deregister RK(s) with its peer by sending a DEREG REQ message.
M-RK_撤销请求方向：LM->M3UA目的：LM通过发送撤销请求消息请求ASP撤销RK与其对等方的注册。
M-RK_DEREG confirm Direction: M3UA -> LM Purpose: ASP reports that it has received DEREG REQ message with a deregistration status of successful from its peer.
M-RK_DEREG confirm Direction:M3UA->LM Purpose:ASP报告其已从对等方收到注销状态为successful的DEREG REQ消息。
M-RK_DEREG indication Direction: M3UA -> LM Purpose: M3UA informs LM that it has successfully processed an incoming DEREG REQ from its peer.
M-RK_DEREG指示方向：M3UA->LM目的：M3UA通知LM已成功处理来自其对等方的传入DEREG REQ。
In this document, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [21].
在本文件中，关键字必须、不得、必需、应、不应、应、不应、建议、不建议、可和可选的解释如[21]所述。
The general M3UA message format includes a Common Message Header followed by zero or more parameters as defined by the Message Type. For forward compatibility, all Message Types may have attached parameters even if none are specified in this version.
通用M3UA消息格式包括一个公共消息头，后跟消息类型定义的零个或多个参数。为了向前兼容，即使在此版本中未指定任何参数，所有消息类型都可能具有附加参数。
The protocol messages for MTP3-User Adaptation require a message header that contains the adaptation layer version, the message type, and message length.
MTP3用户自适应的协议消息需要包含自适应层版本、消息类型和消息长度的消息头。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
All fields in an M3UA message MUST be transmitted in network byte order, unless otherwise stated.
除非另有说明，否则M3UA消息中的所有字段必须以网络字节顺序传输。
The version field contains the version of the M3UA adaptation layer.
版本字段包含M3UA适配层的版本。
The supported versions are as follows:
支持的版本如下：
1 Release 1.0
1发行版1.0
The following list contains the valid Message Classes:
以下列表包含有效的消息类：
Message Class: 8 bits (unsigned integer)
消息类：8位（无符号整数）
The following list contains the valid Message Type Classes:
以下列表包含有效的消息类型类：
0 Management (MGMT) Messages 1 Transfer Messages 2 SS7 Signalling Network Management (SSNM) Messages 3 ASP State Maintenance (ASPSM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages 5 Reserved for Other SIGTRAN Adaptation Layers
0管理（MGMT）消息1传输消息2 SS7信令网络管理（SSNM）消息3 ASP状态维护（ASPSM）消息4 ASP流量维护（ASPTM）消息5保留给其他SIGTRAN适配层
6 Reserved for Other SIGTRAN Adaptation Layers 7 Reserved for Other SIGTRAN Adaptation Layers 8 Reserved for Other SIGTRAN Adaptation Layers 9 Routing Key Management (RKM) Messages 10 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined Message Class extensions
6保留给其他SIGTRAN适配层7保留给其他SIGTRAN适配层8保留给其他SIGTRAN适配层9路由密钥管理（RKM）消息10到127保留给IETF 128到255保留给IETF定义的消息类扩展
Message Type: 8 bits (unsigned integer)
消息类型：8位（无符号整数）
The following list contains the message types for the defined messages.
以下列表包含已定义消息的消息类型。
Management (MGMT) Messages (see Section 3.8)
管理（MGMT）信息（见第3.8节）
0 Error (ERR) 1 Notify (NTFY) 2 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined MGMT extensions
0错误（ERR）1通知（NTFY）2到127由IETF保留128到255为IETF定义的管理扩展保留
Transfer Messages (see Section 3.3)
传输信息（见第3.3节）
0 Reserved 1 Payload Data (DATA) 2 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined Transfer extensions
0保留1有效负载数据（数据）2至127由IETF保留128至255为IETF定义的传输扩展保留
SS7 Signalling Network Management (SSNM) Messages (see Section 3.4)
SS7信令网络管理（SSNM）消息（见第3.4节）
0 Reserved 1 Destination Unavailable (DUNA) 2 Destination Available (DAVA) 3 Destination State Audit (DAUD) 4 Signalling Congestion (SCON) 5 Destination User Part Unavailable (DUPU) 6 Destination Restricted (DRST) 7 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined SSNM extensions
0保留1目的地不可用（DUNA）2目的地可用（DAVA）3目的地状态审核（DAUD）4信令拥塞（SCON）5目的地用户部分不可用（DUPU）6目的地限制（DRST）7至127由IETF保留128至255为IETF定义的SSNM扩展保留
ASP State Maintenance (ASPSM) Messages (see Section 3.5)
ASP状态维护（ASPSM）消息（见第3.5节）
0 Reserved 1 ASP Up (ASPUP) 2 ASP Down (ASPDN) 3 Heartbeat (BEAT) 4 ASP Up Acknowledgement (ASPUP ACK) 5 ASP Down Acknowledgement (ASPDN ACK) 6 Heartbeat Acknowledgement (BEAT ACK)
0保留1 ASP向上（ASPUP）2 ASP向下（ASPDN）3心跳（节拍）4 ASP向上确认（ASPUP ACK）5 ASP向下确认（ASPDN ACK）6心跳确认（节拍ACK）
7 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined ASPSM extensions
IETF保留的7到127 128到255为IETF定义的ASPSM扩展保留
ASP Traffic Maintenance (ASPTM) Messages (see Section 3.7)
ASP流量维护（ASPTM）消息（见第3.7节）
0 Reserved 1 ASP Active (ASPAC) 2 ASP Inactive (ASPIA) 3 ASP Active Acknowledgement (ASPAC ACK) 4 ASP Inactive Acknowledgement (ASPIA ACK) 5 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined ASPTM extensions
0保留1 ASP活动（ASPAC）2 ASP非活动（ASPIA）3 ASP活动确认（ASPAC ACK）4 ASP非活动确认（ASPIA ACK）5到127由IETF保留128到255为IETF定义的ASPTM扩展保留
Routing Key Management (RKM) Messages (see Section 3.6)
路由密钥管理（RKM）消息（见第3.6节）
0 Reserved 1 Registration Request (REG REQ) 2 Registration Response (REG RSP) 3 Deregistration Request (DEREG REQ) 4 Deregistration Response (DEREG RSP) 5 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined RKM extensions
0保留1注册请求（REG REQ）2注册响应（REG RSP）3注销请求（DEREG REQ）4注销响应（DEREG RSP）5至127由IETF保留128至255为IETF定义的RKM扩展保留
The Reserved field SHOULD be set to all '0's and ignored by the receiver.
保留字段应设置为所有“0”，并由接收方忽略。
The Message Length defines the length of the message in octets, including the Common Header. The Message Length MUST include parameter padding octets, if there are any.
消息长度以八位字节定义消息的长度，包括公共头。消息长度必须包括参数填充八位字节（如果有）。
Note: A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length.
注意：无论消息长度中是否包含最终参数填充，接收方都应接受消息。
M3UA messages consist of a Common Header followed by zero or more variable-length parameters, as defined by the message type. All the parameters contained in a message are defined in a Tag Length-Value format, as shown below.
M3UA消息由一个公共头和零个或多个可变长度参数组成，这些参数由消息类型定义。消息中包含的所有参数都以标记长度值格式定义，如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver SHOULD accept the parameters in any order.
如果消息中包含多个参数，则这些参数可以是任何顺序，除非明确授权。接收器应以任何顺序接受参数。
Unless explicitly stated or shown in a message format diagram, only one parameter of the same type is allowed in a message.
除非在消息格式图中明确说明或显示，否则消息中只允许有一个相同类型的参数。
Parameter Tag: 16 bits (unsigned integer)
参数标记：16位（无符号整数）
The Tag field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534. Common parameters used by adaptation layers are in the range of 0x00 to 0x3f. M3UA-specific parameters have Tags in the range 0x0200 to 0x02ff. The parameter Tags defined are as follows:
标记字段是参数类型的16位标识符。它的值为0到65534。适配层使用的通用参数范围为0x00到0x3f。M3UA特定参数的标记范围为0x0200至0x02ff。定义的参数标记如下所示：
Common Parameters. These TLV parameters are common across the different adaptation layers:
公共参数。这些TLV参数在不同的适配层中是通用的：
Parameter Name Parameter ID
============== ============
Reserved 0x0000
Not Used in M3UA 0x0001
Not Used in M3UA 0x0002
Not Used in M3UA 0x0003
INFO String 0x0004
Not Used in M3UA 0x0005
Routing Context 0x0006
Diagnostic Information 0x0007
Not Used in M3UA 0x0008
Heartbeat Data 0x0009
Not Used in M3UA 0x000a
Traffic Mode Type 0x000b
Error Code 0x000c
Status 0x000d
Not Used in M3UA 0x000e
Not Used in M3UA 0x000f
Not Used in M3UA 0x0010
ASP Identifier 0x0011
Parameter Name Parameter ID
============== ============
Reserved 0x0000
Not Used in M3UA 0x0001
Not Used in M3UA 0x0002
Not Used in M3UA 0x0003
INFO String 0x0004
Not Used in M3UA 0x0005
Routing Context 0x0006
Diagnostic Information 0x0007
Not Used in M3UA 0x0008
Heartbeat Data 0x0009
Not Used in M3UA 0x000a
Traffic Mode Type 0x000b
Error Code 0x000c
Status 0x000d
Not Used in M3UA 0x000e
Not Used in M3UA 0x000f
Not Used in M3UA 0x0010
ASP Identifier 0x0011
Affected Point Code 0x0012 Correlation ID 0x0013
受影响点代码0x0012相关ID 0x0013
M3UA-Specific parameters. These TLV parameters are specific to the M3UA protocol:
M3UA特定参数。这些TLV参数特定于M3UA协议：
Network Appearance 0x0200 Reserved 0x0201 Reserved 0x0202 Reserved 0x0203 User/Cause 0x0204 Congestion Indications 0x0205 Concerned Destination 0x0206 Routing Key 0x0207 Registration Result 0x0208 Deregistration Result 0x0209 Local Routing Key Identifier 0x020a Destination Point Code 0x020b Service Indicators 0x020c Reserved 0x020d Originating Point Code List 0x020e Reserved 0x020f Protocol Data 0x0210 Reserved 0x0211 Registration Status 0x0212 Deregistration Status 0x0213 Reserved by the IETF 0x0214 to 0xffff
网络外观0x0200保留0x0201保留0x0202保留0x0203用户/原因0x0204拥塞指示0x0205相关目标0x0206路由密钥0x0207注册结果0x0208注销结果0x0209本地路由密钥标识符0x020a目标点代码0x020b服务指示器0x020c保留0x020d点代码列表0x020e保留0x020f协议数据0x0210保留0x0211注册状态0x0212注销状态0x0213由IETF 0x0214保留到0xffff
The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific parameter descriptions are reserved for use by the IETF. An RFC is required to make use of parameter values "Reserved by the IETF".
65535的值保留给IETF定义的扩展。特定参数描述中定义的值以外的值保留供IETF使用。RFC需要使用“由IETF保留”的参数值。
Parameter Length: 16 bits (unsigned integer)
参数长度：16位（无符号整数）
The Parameter Length field contains the size of the parameter in octets, including the Parameter Tag, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding octets. If the parameter contains subparameters, the Parameter Length field will include all the octets of each subparameter, including subparameter padding octets (if there are any).
参数长度字段包含以八位字节为单位的参数大小，包括参数标记、参数长度和参数值字段。因此，具有零长度参数值字段的参数的长度字段为4。参数长度不包括任何填充八位字节。如果参数包含子参数，则参数长度字段将包括每个子参数的所有八位字节，包括子参数填充八位字节（如果有）。
Parameter Value: variable length
参数值：可变长度
The Parameter Value field contains the actual information to be transferred in the parameter.
参数值字段包含要在参数中传输的实际信息。
The total length of a parameter (including Tag, Parameter Length, and Value fields) MUST be a multiple of 4 octets. If the length of the parameter is not a multiple of 4 octets, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero octets. The length of the padding is NOT included in the parameter length field. A sender MUST NOT pad with more than 3 octets. The receiver MUST ignore the padding octets.
参数的总长度（包括标记、参数长度和值字段）必须是4个八位字节的倍数。如果参数的长度不是4个八位字节的倍数，则发送方将参数的末尾（即参数值字段之后）填入所有零个八位字节。填充的长度不包括在参数长度字段中。发送方的pad不能超过3个八位字节。接收器必须忽略填充八位字节。
The following section describes the Transfer messages and parameter contents.
以下部分介绍传输消息和参数内容。
The DATA message contains the SS7 MTP3-User protocol data, which is an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The DATA message contains the following variable-length parameters:
数据消息包含SS7 MTP3用户协议数据，这是一个MTP传输原语，包括完整的MTP3路由标签。数据消息包含以下可变长度参数：
Network Appearance Optional Routing Context Conditional Protocol Data Mandatory Correlation Id Optional
网络外观可选路由上下文条件协议数据强制相关Id可选
The following format MUST be used for the Data Message:
数据消息必须使用以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0013 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0013 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32 bits (unsigned integer)
网络外观：32位（无符号整数）
The Network Appearance parameter identifies the SS7 network context for the message and implicitly identifies the SS7 Point Code format used, the SS7 Network Indicator value, and the MTP3 and possibly the MTP3-User protocol type/variant/version used within the specific SS7 network. Where an SG operates in the context of a single SS7 network, or if individual SCTP associations are dedicated to each SS7 network context, the Network Appearance parameter is not required. In other cases, the parameter may be configured to be present for the use of the receiver.
Network Appearance（网络外观）参数标识消息的SS7网络上下文，并隐式标识所使用的SS7点代码格式、SS7网络指示符值、MTP3以及特定SS7网络内使用的MTP3用户协议类型/变体/版本。如果SG在单个SS7网络的上下文中运行，或者如果单个SCTP关联专用于每个SS7网络上下文，则不需要网络外观参数。在其他情况下，参数可被配置为存在以供接收器使用。
The Network Appearance parameter value is of local significance only, coordinated between the SGP and ASP. Therefore, in the case where an ASP is connected to more than one SGP, the same SS7 network context may be identified by different Network Appearance values, depending on which SGP a message is being transmitted/ received.
网络外观参数值仅具有局部意义，由SGP和ASP协调。因此，在ASP连接到多个SGP的情况下，可以通过不同的网络外观值来识别相同的SS7网络上下文，这取决于正在发送/接收消息的SGP。
Where the optional Network Appearance parameter is present, it MUST be the first parameter in the message, as it defines the format of the Protocol Data field.
如果存在可选网络外观参数，则它必须是消息中的第一个参数，因为它定义了协议数据字段的格式。
IMPLEMENTATION NOTE: For simplicity of configuration, it may be desirable to use the same NA value across all nodes sharing a particular network context.
实现说明：为简化配置，可能需要在共享特定网络上下文的所有节点上使用相同的NA值。
Routing Context: 32 bits (unsigned integer)
路由上下文：32位（无符号整数）
The Routing Context parameter contains the Routing Context value associated with the DATA message. Where a Routing Key has not been coordinated between the SGP and ASP, sending of Routing Context is not required. Where multiple Routing Keys and Routing Contexts are used across a common association, the Routing Context MUST be sent to identify the traffic flow, assisting in the internal distribution of Data messages.
路由上下文参数包含与数据消息关联的路由上下文值。如果SGP和ASP之间没有协调路由密钥，则不需要发送路由上下文。如果在公共关联中使用多个路由密钥和路由上下文，则必须发送路由上下文以识别流量，从而帮助数据消息的内部分发。
Protocol Data: variable length
协议数据：可变长度
The Protocol Data parameter contains the original SS7 MTP3 message, including the Service Information Octet and Routing Label.
协议数据参数包含原始SS7 MTP3消息，包括服务信息八位字节和路由标签。
The Protocol Data parameter contains the following fields:
协议数据参数包含以下字段：
Service Indicator Network Indicator Message Priority
服务指示符网络指示符消息优先级
Destination Point Code Originating Point Code
目的地点代码起始点代码
Signalling Link Selection Code (SLS)
信令链路选择码（SLS）
User Protocol Data, which includes
用户协议数据，包括
MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP parameters)
MTP3用户协议元素（例如ISUP、SCCP或TUP参数）
The Protocol Data parameter is encoded as follows:
协议数据参数编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI | NI | MP | SLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI | NI | MP | SLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Originating Point Code: 32 bits (unsigned integer)
起始点代码：32位（无符号整数）
Destination Point Code: 32 bits (unsigned integer)
目标点代码：32位（无符号整数）
The Originating and Destination Point Code fields contains the OPC and DPC from the routing label of the original SS7 message in Network Byte Order, justified to the least significant bit. Unused bits are coded `0'.
起始点和目的点代码字段包含原始SS7消息路由标签中的OPC和DPC，按网络字节顺序排列，对齐至最低有效位。未使用的位被编码为“0”。
Service Indicator: 8 bits (unsigned integer)
服务指示符：8位（无符号整数）
The Service Indicator field contains the SI field from the original SS7 message justified to the least significant bit. Unused bits are coded `0'.
服务指示器字段包含从原始SS7消息到最低有效位的SI字段。未使用的位被编码为“0”。
Network Indicator: 8 bits (unsigned integer)
网络指示器：8位（无符号整数）
The Network Indicator contains the NI field from the original SS7 message justified to the least significant bit. Unused bits are coded `0'.
网络指示器包含从原始SS7消息到最低有效位的NI字段。未使用的位被编码为“0”。
Message Priority: 8 bits (unsigned integer)
消息优先级：8位（无符号整数）
The Message Priority field contains the MP bits (if any) from the original SS7 message, both for ANSI-style and TTC-style [26] message priority bits. The MP bits are aligned to the least significant bit. Unused bits are coded `0'.
消息优先级字段包含原始SS7消息的MP位（如果有），用于ANSI样式和TTC样式[26]消息优先级位。MP位与最低有效位对齐。未使用的位被编码为“0”。
Signalling Link Selection: 8 bits (unsigned integer)
信令链路选择：8位（无符号整数）
The Signalling Link Selection field contains the SLS bits from the routing label of the original SS7 message justified to the least significant bit and in Network Byte Order. Unused bits are coded `0'.
信令链路选择字段包含来自原始SS7消息的路由标签的SLS位，其对齐为最低有效位，并按网络字节顺序排列。未使用的位被编码为“0”。
User Protocol Data: variable-length octet string
用户协议数据：可变长度八位字节字符串
The User Protocol Data field contains an octet string of MTP-User information from the original SS7 message, starting with the first octet of the original SS7 message following the Routing Label [7][8][26].
用户协议数据字段包含来自原始SS7消息的MTP用户信息的八位字节字符串，从路由标签[7][8][26]后面的原始SS7消息的第一个八位字节开始。
Correlation Id: 32 bits (unsigned integer)
相关Id:32位（无符号整数）
The Correlation Id parameter uniquely identifies the MSU carried in the Protocol Data within an AS. This Correlation Id parameter is assigned by the sending M3UA.
Correlation Id参数唯一标识AS中协议数据中携带的MSU。此相关Id参数由发送M3UA分配。
The DUNA message is sent from an SGP in an SG to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are unreachable. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. As an implementation option, the SG may suppress the sending of subsequent "response" DUNA messages regarding a certain unreachable SS7 destination for a certain period to give the remote side time to react. If there is no alternate route via another SG, the MTP3-User at the ASP is expected to stop traffic to the affected destination via the SG as per the defined MTP3-User procedures.
DUNA消息从SG中的SGP发送到所有相关的ASP，以指示SG已确定一个或多个SS7目的地不可到达。它也由SGP发送，以响应来自ASP的消息，并发送到无法到达的SS7目的地。作为一个实现选项，SG可以在特定时间段内抑制关于某个不可到达的SS7目的地的后续“响应”DUNA消息的发送，以给远程侧反应的时间。如果没有通过另一个SG的备用路线，则ASP处的MTP3用户应根据定义的MTP3用户程序，停止通过SG到达受影响目的地的交通。
The DUNA message contains the following parameters:
DUNA消息包含以下参数：
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory INFO String Optional
网络外观可选路由上下文条件受影响点代码强制信息字符串可选
The format for DUNA Message parameters is as follows:
DUNA消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bit unsigned integer
网络外观：32位无符号整数
The description of Network Appearance in Section 3.3.1 applies, with the exception that Network Appearance does not have to be the first parameter in this message.
第3.3.1节中对网络外观的描述适用，但网络外观不必是此消息中的第一个参数。
Routing Context: n x 32 bits (unsigned integer)
路由上下文：n x 32位（无符号整数）
The conditional Routing Context parameter contains the Routing Context values associated with the DUNA message. Where a Routing Key has not been coordinated between the SGP and ASP, sending of Routing Context is not required. Where multiple Routing Keys and Routing Contexts are used across a common association, the Routing Context(s) MUST be sent to identify the concerned traffic flows for which the DUNA message applies, assisting in outgoing traffic management and internal distribution of MTP-PAUSE indications to MTP3-Users at the receiver.
条件路由上下文参数包含与DUNA消息关联的路由上下文值。如果SGP和ASP之间没有协调路由密钥，则不需要发送路由上下文。如果在公共关联中使用多个路由密钥和路由上下文，则必须发送路由上下文以识别DUNA消息适用的相关业务流，从而有助于传出业务管理和在接收方向MTP3用户内部分发MTP-PAUSE指示。
Affected Point Code: n x 32 bits
受影响点代码：n x 32位
The Affected Point Code parameter contains a list of Affected Destination Point Code fields, each a three-octet parameter to allow for 14-, 16-, and 24-bit binary formatted SS7 Point Codes. Affected Point Codes that are less than 24 bits are padded on the left to the 24-bit boundary. The encoding is shown below for ANSI and ITU Point Code examples.
“受影响点代码”参数包含受影响目标点代码字段的列表，每个字段都有一个三个八位参数，以允许使用14、16和24位二进制格式的SS7点代码。小于24位的受影响点代码填充在24位边界的左侧。ANSI和ITU点代码示例的编码如下所示。
ANSI 24-bit Point Code
ANSI 24位点代码
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Network | Cluster | Member |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Network | Cluster | Member |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB-----------------------------------------LSB|
|MSB-----------------------------------------LSB|
ITU 14-bit Point Code
ITU 14位点码
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB|
|MSB--------------------LSB|
It is optional to send an Affected Point Code parameter with more than one Affected PC, but it is mandatory to receive it. Including multiple Affected PCs may be useful when receipt of an MTP3 management message or a linkset event simultaneously affects the availability status of a list of destinations at an SG.
可以选择与多台受影响的PC一起发送受影响的点代码参数，但必须接收该参数。当收到MTP3管理消息或链路集事件同时影响SG上目的地列表的可用性状态时，包括多个受影响的PC可能有用。
Mask: 8 bits (unsigned integer)
掩码：8位（无符号整数）
The Mask field can be used to identify a contiguous range of Affected Destination Point Codes. Identifying a contiguous range of Affected DPCs may be useful when receipt of an MTP3 management message or a linkset event simultaneously affects the availability status of a series of destinations at an SG.
掩码字段可用于识别受影响的目的地代码的连续范围。当接收到MTP3管理消息或链路集事件同时影响SG处一系列目的地的可用性状态时，识别受影响DPC的连续范围可能很有用。
The Mask parameter is an integer representing a bit mask that can be applied to the related Affected PC field. The bit mask identifies how many bits of the Affected PC field are significant and which are effectively "wildcarded". For example, a mask of "8" indicates that the last eight bits of the PC are "wildcarded". For an ANSI 24-bit Affected PC, this is equivalent to signalling that all PCs in an ANSI Cluster are unavailable. A mask of "3" indicates that the last three bits of the PC are "wildcarded". For a 14-bit ITU Affected PC, this is equivalent to signaling that an ITU Region is unavailable. A mask value equal (or greater than) the number of bits in the PC indicates that the entire network appearance is affected; this is used to indicate network isolation to the ASP.
掩码参数是一个整数，表示可应用于相关受影响PC字段的位掩码。位掩码标识受影响PC字段中有多少位是有效的，哪些位是有效的“通配符”。例如，掩码“8”表示PC的最后八位为“通配符”。对于受ANSI 24位影响的PC，这相当于发出ANSI集群中所有PC均不可用的信号。掩码为“3”表示PC的最后三位为“通配符”。对于受ITU影响的14位PC，这相当于发出ITU区域不可用的信号。掩码值等于（或大于）PC中的位数表示整个网络外观受到影响；这用于向ASP指示网络隔离。
INFO String: variable length
信息字符串：可变长度
The optional INFO String parameter can carry any meaningful UTF-8 [10] character string along with the message. Length of the INFO String parameter is from 0 to 255 octets. No procedures are presently identified for its use, but the INFO String MAY be used for debugging purposes. An INFO String with a zero-length parameter is not considered an error (a zero length parameter is one in which the Length field in the TLV will be set to 4).
可选信息字符串参数可以携带任何有意义的UTF-8[10]字符串以及消息。信息字符串参数的长度为0到255个八位字节。目前还没有为其使用标识任何过程，但信息字符串可用于调试目的。具有零长度参数的信息字符串不被视为错误（零长度参数是TLV中的长度字段将设置为4的参数）。
The DAVA message is sent from an SGP to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are now reachable (and not restricted), or in response to a DAUD message, if appropriate. If the ASP M3UA layer previously had no routes to the affected destinations, the ASP MTP3-User protocol is informed and may now resume traffic to the affected destination. The ASP M3UA layer now routes the MTP3-user traffic through the SG initiating the DAVA message.
DAVA消息从SGP发送到所有相关的ASP，以表明SG已确定一个或多个SS7目的地现在可到达（且不受限制），或响应DAUD消息（如适用）。如果ASP M3UA层以前没有到受影响目的地的路由，则会通知ASP MTP3用户协议，现在可能会恢复到受影响目的地的通信。ASP M3UA层现在通过发起DAVA消息的SG路由MTP3用户流量。
The DAVA message contains the following parameters:
DAVA消息包含以下参数：
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory INFO String Optional
网络外观可选路由上下文条件受影响点代码强制信息字符串可选
The format and description of the Network Appearance, Routing Context, Affected Point Code, and INFO String parameters are the same as for the DUNA message (See Section 3.4.1).
网络外观、路由上下文、受影响点代码和信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The DAUD message MAY be sent from the ASP to the SGP to audit the availability/congestion state of SS7 routes from the SG to one or more affected destinations.
DAUD消息可以从ASP发送到SGP，以审核从SG到一个或多个受影响目的地的SS7路由的可用性/拥塞状态。
The DAUD message contains the following parameters:
DAUD消息包含以下参数：
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory INFO String Optional
网络外观可选路由上下文条件受影响点代码强制信息字符串可选
The format and description of DAUD Message parameters are the same as for the DUNA message (See Section 3.4.1).
DAUD消息参数的格式和说明与DUNA消息相同（见第3.4.1节）。
It is recommended that during normal operation (traffic handling) the mask field of the Affected Point Code parameter in the DAUD message be kept to a zero value in order to avoid SG overloading.
建议在正常操作（交通处理）期间，DAUD消息中受影响点代码参数的掩码字段保持为零值，以避免SG过载。
The SCON message can be sent from an SGP to all concerned ASPs to indicate that an SG has determined that there is congestion in the SS7 network to one or more destinations, or to an ASP in response to a DATA or DAUD message, as appropriate. For some MTP protocol variants (e.g., ANSI MTP) the SCON message may be sent when the SS7 congestion level changes. The SCON message MAY also be sent from the M3UA layer of an ASP to an M3UA peer, indicating that the congestion level of the M3UA layer or the ASP has changed.
SCON消息可从SGP发送到所有相关的ASP，以指示SG已确定SS7网络中存在到一个或多个目的地的拥塞，或发送到ASP以响应数据或DAUD消息（视情况而定）。对于某些MTP协议变体（例如ANSI MTP），当SS7拥塞级别发生变化时，可能会发送SCON消息。SCON消息也可以从ASP的M3UA层发送到M3UA对等方，指示M3UA层或ASP的拥塞级别已更改。
IMPLEMENTATION NOTE: An M3UA node may maintain a timer to control congestion notification validity, if desired. This timer will be useful in cases where the peer node fails to indicate congestion abatement.
实施说明：如果需要，M3UA节点可以维护一个计时器来控制拥塞通知的有效性。当对等节点无法指示拥塞缓解时，此计时器将非常有用。
The SCON message contains the following parameters:
SCON消息包含以下参数：
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory Concerned Destination Optional Congestion Indications Optional INFO String Optional
网络外观可选路由上下文条件受影响点代码强制性相关目的地可选拥塞指示可选信息字符串可选
The format for SCON Message parameters is as follows:
SCON消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the Network Appearance, Routing Context, Affected Point Code, and INFO String parameters are the same as for the DUNA message (see Section 3.4.1).
网络外观、路由上下文、受影响点代码和信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The Affected Point Code parameter can be used to indicate congestion of multiple destinations or ranges of destinations.
“受影响点代码”参数可用于指示多个目的地或目的地范围的拥挤情况。
Concerned Destination: 32 bits
相关目的地：32位
The optional Concerned Destination parameter is only used if the SCON message is sent from an ASP to the SGP. It contains the point code of the originator of the message that triggered the SCON message. The Concerned Destination parameter contains one Concerned Destination Point Code field, a three-octet parameter to allow for 14-, 16-, and 24-bit binary formatted SS7 Point Codes. A Concerned Point Code that is less than 24 bits is padded on the left to the 24-bit boundary. Any resulting Transfer Controlled (TFC) message from the SG is sent to the Concerned Point Code using the single Affected DPC contained in the SCON message to populate the (affected) Destination field of the TFC message
只有当SCON消息从ASP发送到SGP时，才使用可选的相关目标参数。它包含触发SCON消息的消息发起人的点代码。相关目的地参数包含一个相关目的地点代码字段，一个三个八位参数，用于14、16和24位二进制格式的SS7点代码。小于24位的相关点代码填充在24位边界的左侧。使用SCON消息中包含的单个受影响的DPC将来自SG的任何结果传输控制（TFC）消息发送到相关点代码，以填充TFC消息的（受影响的）目的地字段
Congested Indications: 32 bits
拥塞指示：32位
The optional Congestion Indications parameter contains a Congestion Level field. This optional parameter is used to communicate congestion levels in national MTP networks with multiple congestion thresholds, such as in ANSI MTP3. For MTP congestion methods without multiple congestion levels (e.g., the ITU international method) the parameter is not included.
可选的拥塞指示参数包含拥塞级别字段。此可选参数用于在具有多个拥塞阈值的国家MTP网络（如ANSI MTP3）中传达拥塞级别。对于没有多个拥塞级别的MTP拥塞方法（例如，ITU国际方法），不包括该参数。
Congestion Level field: 8 bits (unsigned integer)
拥塞级别字段：8位（无符号整数）
The Congestion Level field, associated with all of the Affected DPC(s) in the Affected Destinations parameter, contains one of the following values:
与受影响目的地参数中所有受影响的DPC关联的拥塞级别字段包含以下值之一：
0 No Congestion or Undefined 1 Congestion Level 1 2 Congestion Level 2 3 Congestion Level 3
0无拥塞或未定义1拥塞级别1 2拥塞级别2 3拥塞级别3
The congestion levels are defined in the congestion method in the appropriate national MTP recommendations [7,8].
拥塞水平在适当的国家MTP建议[7,8]中的拥塞方法中定义。
The DUPU message is used by an SGP to inform concerned ASPs that a remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable.
SGP使用DUPU消息通知相关ASP SS7节点处的远程对等MTP3用户部件（例如ISUP或SCCP）不可用。
The DUPU message contains the following parameters:
DUPU消息包含以下参数：
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory User/Cause Mandatory INFO String Optional
网络外观可选路由上下文条件受影响点代码强制用户/原因强制信息字符串可选
The format for DUPU message parameters is as follows:
消息DUPU的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User/Cause: 32 bits
用户/原因：32位
The Unavailability Cause and MTP3-User Identity fields, associated with the Affected PC in the Affected Point Code parameter, are encoded as follows:
与受影响点代码参数中受影响PC相关的不可用原因和MTP3用户标识字段编码如下：
Unavailability Cause field: 16 bits (unsigned integer)
不可用原因字段：16位（无符号整数）
The Unavailability Cause parameter provides the reason for the unavailability of the MTP3-User. The valid values for the Unavailability Cause parameter are shown in the following table. The values agree with those provided in the SS7 MTP3 User Part Unavailable message. Depending on the MTP3 protocol used in the Network Appearance, additional values may be used; the specification of the relevant MTP3 protocol variant/version recommendation is definitive.
不可用原因参数提供MTP3用户不可用的原因。下表显示了不可用原因参数的有效值。这些值与SS7 MTP3用户部件不可用消息中提供的值一致。根据网络外观中使用的MTP3协议，可以使用附加值；相关MTP3协议变体/版本建议的规范是确定的。
0 Unknown 1 Unequipped Remote User 2 Inaccessible Remote User
0未知1未配置的远程用户2无法访问的远程用户
MTP3-User Identity field: 16 bits (unsigned integer)
MTP3用户标识字段：16位（无符号整数）
The MTP3-User Identity describes the specific MTP3-User that is unavailable (e.g., ISUP, SCCP, etc.). Some of the valid values for the MTP3-User Identity are shown below. The values align with those provided in the SS7 MTP3 User Part Unavailable message and Service Indicator. Depending on the MTP3 protocol variant/version used in the Network Appearance, additional values may be used. The relevant MTP3 protocol variant/version recommendation is definitive.
MTP3用户标识描述了不可用的特定MTP3用户（例如ISUP、SCCP等）。MTP3用户标识的一些有效值如下所示。这些值与SS7 MTP3用户部件不可用消息和服务指示器中提供的值一致。根据网络外观中使用的MTP3协议变体/版本，可以使用附加值。相关MTP3协议变体/版本建议是确定的。
0 to 2 Reserved 3 SCCP 4 TUP 5 ISUP 6 to 8 Reserved 9 Broadband ISUP 10 Satellite ISUP 11 Reserved 12 AAL type 2 Signalling 13 Bearer Independent Call Control (BICC) 14 Gateway Control Protocol 15 Reserved
0到2保留3 SCCP 4 TUP 5 ISUP 6到8保留9宽带ISUP 10卫星ISUP 11保留12 AAL类型2信令13承载独立呼叫控制（BICC）14网关控制协议15保留
The format and description of the Affected Point Code parameter are the same as for the DUNA message (see Section 3.4.1.) except that the Mask field is not used and only a single Affected DPC is
受影响点代码参数的格式和说明与DUNA消息的格式和说明相同（见第3.4.1节），但不使用掩码字段，仅使用一个受影响的DPC
included. Ranges and lists of Affected DPCs cannot be signaled in a DUPU message, but this is consistent with UPU operation in the SS7 network. The Affected Destinations parameter in an MTP3 User Part Unavailable message (UPU) received by an SGP from the SS7 network contains only one destination.
包括。受影响DPC的范围和列表无法在DUPU消息中发出信号，但这与SS7网络中的UPU操作一致。SGP从SS7网络接收的MTP3用户部件不可用消息（UPU）中的受影响目的地参数仅包含一个目的地。
The format and description of the Network Appearance, Routing Context, and INFO String parameters are the same as for the DUNA message (see Section 3.4.1).
网络外观、路由上下文和信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The DRST message is optionally sent from the SGP to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are now restricted from the point of view of the SG, or in response to a DAUD message, if appropriate. The M3UA layer at the ASP is expected to send traffic to the affected destination via an alternate SG with a route of equal priority, but only if such an alternate route exists and is available. If the affected destination is currently considered unavailable by the ASP, The MTP3-User should be informed that traffic to the affected destination can be resumed. In this case, the M3UA layer should route the traffic through the SG initiating the DRST message.
DRST消息可选地从SGP发送到所有相关的ASPs，以指示SG已经确定从SG的角度或响应DAUD消息（如果合适）一个或多个SS7目的地现在受到限制。ASP处的M3UA层预计将通过具有同等优先级路由的备用SG向受影响的目的地发送流量，但前提是此类备用路由存在且可用。如果ASP当前认为受影响的目的地不可用，则应通知MTP3用户可以恢复到受影响目的地的通信。在这种情况下，M3UA层应通过发起DRST消息的SG路由流量。
This message is optional for the SG to send, and it is optional for the ASP to act on any information received in the message. It is for use in the "STP" case described in Section 1.4.1.
此消息对于SG发送是可选的，对于ASP对消息中接收到的任何信息采取行动也是可选的。用于第1.4.1节所述的“STP”情况。
The DRST message contains the following parameters:
DRST消息包含以下参数：
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory INFO String Optional
网络外观可选路由上下文条件受影响点代码强制信息字符串可选
The format and description of the Network Appearance, Routing Context, Affected Point Code, and INFO String parameters are the same as for the DUNA message (see Section 3.4.1).
网络外观、路由上下文、受影响点代码和信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The ASP Up message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any ASPSM/ASPTM messages for all Routing Keys that the ASP is configured to serve.
ASP Up消息用于向远程M3UA对等方指示适配层已准备好接收ASP配置为服务的所有路由密钥的任何ASPSM/ASPTM消息。
The ASP Up message contains the following parameters:
ASP Up消息包含以下参数：
ASP Identifier Optional INFO String Optional
可选字符串标识符ASP
The format for ASP Up message parameters is as follows:
ASP Up消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASP Identifier: 32-bit unsigned integer
ASP标识符：32位无符号整数
The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SGP should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.8.2).
可选的ASP标识符参数包含一个唯一值，该值在支持AS的ASP中具有本地意义。SGP应保存ASP标识符，以便在必要时与Notify消息一起使用（参见第3.8.2节）。
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1).
可选信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The ASP UP Ack message is used to acknowledge an ASP Up message received from a remote M3UA peer.
ASP UP Ack消息用于确认从远程M3UA对等方接收到的ASP UP消息。
The ASP Up Ack message contains the following parameters:
ASP Up Ack消息包含以下参数：
ASP Identifier Optional INFO String Optional
可选字符串标识符ASP
The format for ASP Up Ack message parameters is as follows:
ASP Up Ack消息参数的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter is specifically useful for IPSP communication. In that case, the IPSP answering the ASP Up message MAY include its own ASP Identifier value.
可选的ASP标识符参数对于IPSP通信特别有用。在这种情况下，应答ASP Up消息的IPSP可以包括其自己的ASP标识符值。
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1). The INFO String in an ASP Up Ack message is independent from the INFO String in the ASP Up message (i.e., it does not have to echo back the INFO String received).
可选信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。ASP Up Ack消息中的信息字符串独立于ASP Up消息中的信息字符串（即，它不必回显收到的信息字符串）。
The ASP Down message is used to indicate to a remote M3UA peer that the adaptation layer is NOT ready to receive DATA, SSNM, RKM, or ASPTM messages.
ASP Down消息用于向远程M3UA对等方指示适配层未准备好接收数据、SSNM、RKM或ASPTM消息。
The ASP Down message contains the following parameter:
ASP Down消息包含以下参数：
INFO String Optional
信息字符串可选
The format for the ASP Down message parameters is as follows:
ASP Down消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1).
可选信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M3UA peer.
ASP Down Ack消息用于确认从远程M3UA对等方接收到的ASP Down消息。
The ASP Down Ack message contains the following parameter:
ASP Down Ack消息包含以下参数：
INFO String Optional
信息字符串可选
The format for the ASP Down Ack message parameters is as follows:
ASP Down Ack消息参数的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the DUNA message (See Section 3.4.1).
可选信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The INFO String in an ASP Down Ack message is independent from the INFO String in the ASP Down message (i.e., it does not have to echo back the INFO String received).
ASP Down Ack消息中的信息字符串独立于ASP Down消息中的信息字符串（即，它不必回显收到的信息字符串）。
The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. It is recommended for use when the M3UA runs over a transport layer other than the SCTP, which has its own heartbeat.
节拍消息可选择性地用于确保M3UA对等点彼此仍然可用。当M3UA运行在SCTP以外的传输层上时，建议使用它，因为SCTP有自己的心跳信号。
The BEAT message contains the following parameter:
节拍消息包含以下参数：
Heartbeat Data Optional
心跳数据可选
The format for the BEAT message is as follows:
节拍信息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending node. The Heartbeat Data could include, for example, a Heartbeat Sequence Number and/or Timestamp. The receiver of a BEAT message does not process this field, as it is only of significance to the sender. The receiver MUST respond with a BEAT Ack message.
心跳数据参数内容由发送节点定义。心跳数据可以包括例如心跳序列号和/或时间戳。节拍消息的接收者不处理该字段，因为它仅对发送者重要。接收器必须以节拍确认消息进行响应。
The BEAT Ack message is sent in response to a received BEAT message. It includes all the parameters of the received BEAT message, without any change.
发送节拍确认消息以响应接收到的节拍消息。它包括接收到的节拍消息的所有参数，没有任何变化。
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to register one or more given Routing Keys with the remote peer. Typically, an ASP would send this message to an SGP and expect to receive a REG RSP message in return with an associated Routing Context value.
REG REQ消息由ASP发送，以指示远程M3UA对等机希望向远程对等机注册一个或多个给定路由密钥。通常，ASP会将此消息发送给SGP，并期望收到REG RSP消息以及相关的路由上下文值。
The REG REQ message contains the following parameter:
REG REQ消息包含以下参数：
Routing Key Mandatory
路由密钥是必需的
One or more Routing Key parameters MAY be included. The format for the REG REQ message is as follows:
可以包括一个或多个路由密钥参数。REG REQ消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Key: variable length
路由键：可变长度
The Routing Key parameter is mandatory. The sender of this message expects that the receiver of this message will create a Routing Key entry and assign a unique Routing Context value to it, if the Routing Key entry does not already exist.
路由密钥参数是必需的。如果路由密钥项不存在，则此消息的发送方希望此消息的接收方创建路由密钥项并为其分配唯一的路由上下文值。
The Routing Key parameter may be present multiple times in the same message. This is used to allow the registration of multiple Routing Keys in a single message.
路由密钥参数可能在同一消息中出现多次。这用于允许在单个消息中注册多个路由密钥。
The format of the Routing Key parameter is as follows:
路由密钥参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The Destination Point Code, Service Indicators, and Originating Point Code List parameters MAY be repeated as a grouping within the Routing Key parameter, in the structure shown above.
注意：在如上所示的结构中，目的地点代码、服务指示符和起始点代码列表参数可以作为路由密钥参数内的分组重复。
Local-RK-Identifier: 32-bit unsigned integer
本地RK标识符：32位无符号整数
The mandatory Local-RK-Identifier field is used to uniquely identify the registration request. The Identifier value is assigned by the ASP and used to correlate the response in an REG RSP message with the original registration request. The Identifier value must remain unique until the REG RSP message is received.
强制本地RK标识符字段用于唯一标识注册请求。标识符值由ASP分配，用于将REG RSP消息中的响应与原始注册请求关联。在收到REG RSP消息之前，标识符值必须保持唯一。
The format of the Local-RK-Identifier field is as follows:
本地RK标识符字段的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer)
流量模式类型：32位（无符号整数）
The optional Traffic Mode Type parameter identifies the traffic mode of operation of the ASP(s) within an Application Server. The format of the Traffic Mode Type Identifier is as follows:
可选的Traffic Mode Type参数标识应用程序服务器内ASP的操作流量模式。交通模式类型标识符的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Traffic Mode Type are shown in the following table:
交通模式类型的有效值如下表所示：
1 Override 2 Loadshare 3 Broadcast
1覆盖2负载共享3广播
Destination Point Code
目的地代码
The Destination Point Code parameter is mandatory, and it identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. For an alias point code configuration, the DPC parameter would be repeated for each point code. The format is the same as described for the Affected Destination parameter in the DUNA message (see Section 3.4.1). Its format is:
Destination Point Code参数是必需的，它标识ASP正在注册的传入SS7流量的目的地代码。对于别名点代码配置，将为每个点代码重复DPC参数。格式与DUNA消息中受影响目的地参数的描述相同（见第3.4.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance
网络外观
The optional Network Appearance parameter field identifies the SS7 network context for the Routing Key, and it has the same format as in the DATA message (see Section 3.3.1) with the exception that it does not have to be the first parameter in the message. If the Network Appearance is not specified and the Routing Key applies to all Network Appearances, then this Routing Key MUST be the only one registered for the association; that is, Routing Context is implied, and DATA and SSNM messages are discriminated on Network Appearance rather than on Routing Context. Where Network Appearance is not specified and there is only one Network Appearance, then Network Appearance is implied. Its format is:
可选网络外观参数字段标识路由密钥的SS7网络上下文，其格式与数据消息中的格式相同（见第3.3.1节），但不必是消息中的第一个参数。如果未指定网络外观，且路由密钥适用于所有网络外观，则此路由密钥必须是为关联注册的唯一路由密钥；也就是说，隐含路由上下文，数据和SSNM消息根据网络外观而不是路由上下文进行区分。如果未指定网络外观且只有一个网络外观，则暗示网络外观。其格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Indicators (SI): n X 8-bit integers
服务指示器（SI）：n X 8位整数
The optional SI [7,8] field contains one or more Service Indicators from the values described in the MTP3-User Identity field of the DUPU message. The absence of the SI parameter in the Routing Key indicates the use of any SI value, excluding of course MTP management. Where an SI parameter does not contain a multiple of four SIs, the parameter is padded out to 32-byte alignment.
可选SI[7,8]字段包含DUPU消息MTP3用户标识字段中描述的值中的一个或多个服务指示器。路由密钥中缺少SI参数表示使用任何SI值，当然MTP管理除外。如果SI参数不包含四个SI的倍数，则该参数将填充为32字节对齐。
The SI format is:
SI格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPC List
OPC列表
The Originating Point Code List parameter contains one or more SS7 OPC entries, and its format is the same as for the Destination Point Code parameter. The absence of the OPC List parameter in the Routing Key indicates the use of any OPC value.
起始点代码列表参数包含一个或多个SS7 OPC条目，其格式与目标点代码参数相同。路由键中没有OPC列表参数表示使用了任何OPC值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The REG RSP message is used as a response to the REG REQ message from a remote M3UA peer. It contains indications of success/failure for registration requests and returns a unique Routing Context value for successful registration requests, to be used in subsequent M3UA Traffic Management protocol.
REG RSP消息用作远程M3UA对等方对REG REQ消息的响应。它包含注册请求成功/失败的指示，并返回成功注册请求的唯一路由上下文值，用于后续M3UA流量管理协议。
The REG RSP message contains the following parameter:
REG RSP消息包含以下参数：
Registration Result Mandatory
注册结果是强制性的
One or more Registration Result parameters MUST be included. The format for the REG RSP message is as follows:
必须包括一个或多个注册结果参数。REG RSP报文格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Registration Results
注册结果
The Registration Result parameter contains the registration result for a single Routing Key in an REG REQ message. The number of results in a single REG RSP message MUST be anywhere from one to the total number of number of Routing Key parameters found in the corresponding REG REQ message. Where multiple REG RSP messages are used in reply to REG REQ message, a specific result SHOULD be in only one REG RSP message. The format of each result is as follows:
Registration Result参数包含REG REQ消息中单个路由密钥的注册结果。单个REG RSP消息中的结果数必须介于1到相应REG REQ消息中找到的路由密钥参数总数之间。如果使用多个REG RSP消息来回复REG REQ消息，则特定结果应仅出现在一个REG RSP消息中。每个结果的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0212 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0212 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-RK-Identifier: 32-bit integer
本地RK标识符：32位整数
The Local-RK-Identifier contains the same value as found in the matching Routing Key parameter found in the REG REQ message (See Section 3.6.1).
本地RK标识符包含与REG REQ消息中匹配的路由密钥参数相同的值（见第3.6.1节）。
Registration Status: 32-bit integer
注册状态：32位整数
The Registration Result Status field indicates the success or the reason for failure of a registration request.
注册结果状态字段指示注册请求成功或失败的原因。
Its values may be:
其值可能是：
0 Successfully Registered 1 Error - Unknown 2 Error - Invalid DPC 3 Error - Invalid Network Appearance 4 Error - Invalid Routing Key 5 Error - Permission Denied 6 Error - Cannot Support Unique Routing 7 Error - Routing Key not Currently Provisioned 8 Error - Insufficient Resources 9 Error - Unsupported RK parameter Field 10 Error - Unsupported/Invalid Traffic Handling Mode 11 Error - Routing Key Change Refused 12 Error - Routing Key Already Registered
0成功注册1错误-未知2错误-无效DPC 3错误-无效网络外观4错误-无效路由密钥5错误-权限被拒绝6错误-无法支持唯一路由7错误-路由密钥当前未设置8错误-资源不足9错误-不支持的RK参数字段10错误-不支持/无效的流量处理模式11错误-路由密钥更改被拒绝12错误-路由密钥已注册
Routing Context: 32-bit integer
路由上下文：32位整数
The Routing Context field contains the Routing Context value for the associated Routing Key if the registration was successful. It is set to "0" if the registration was not successful.
如果路由项的上下文注册成功，则该路由字段包含该值。如果注册未成功，则将其设置为“0”。
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to deregister a given Routing Key. Typically, an ASP would send this message to an SGP and expects to receive a DEREG RSP message in return with the associated Routing Context value.
DEREG REQ消息由ASP发送，以指示远程M3UA对等方希望取消注册给定的路由密钥。通常，ASP会将此消息发送给SGP，并期望收到一条带相关路由上下文值的DEREG RSP消息。
The DEREG REQ message contains the following parameters:
DEREG REQ消息包含以下参数：
Routing Context Mandatory
路由上下文是必需的
The format for the DEREG REQ message is as follows:
DEREG REQ消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: n X 32-bit integers
路由上下文：n X 32位整数
The Routing Context parameter contains (a list of) integers indexing the Application Server traffic that the sending ASP is currently registered to receive from the SGP but now wishes to deregister.
Routing Context参数包含（一组）整数，用于索引发送ASP当前注册为从SGP接收但现在希望取消注册的应用程序服务器流量。
The DEREG RSP message is used as a response to the DEREG REQ message from a remote M3UA peer.
DEREG RSP消息用作远程M3UA对等方对DEREG REQ消息的响应。
The DEREG RSP message contains the following parameter:
DEREG RSP消息包含以下参数：
Deregistration Result Mandatory
强制撤销注册结果
One or more Deregistration Result parameters MUST be included. The format for the DEREG RSP message is as follows:
必须包括一个或多个注销结果参数。DEREG RSP报文格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deregistration Results
撤销注册结果
The Deregistration Result parameter contains the deregistration status for a single Routing Context in a DEREG REQ message. The number of results in a single DEREG RSP message MAY be anywhere from one to the total number of number of Routing Context values found in the corresponding DEREG REQ message.
Deregistration Result参数包含DEREG REQ消息中单个路由上下文的取消注册状态。单个DEREG RSP消息中的结果数可以是从1到在相应DEREG REQ消息中找到的路由上下文值总数的任意数量。
Where multiple DEREG RSP messages are used in reply to DEREG REQ message, a specific result SHOULD be in only one DEREG RSP message. The format of each result is as follows:
如果使用多条DEREG RSP消息来回复DEREG REQ消息，则特定结果应仅出现在一条DEREG RSP消息中。每个结果的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0213 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0213 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: 32-bit integer
路由上下文：32位整数
The Routing Context field contains the Routing Context value of the matching Routing Key to deregister, as found in the DEREG REQ message.
路由上下文字段包含要注销的匹配路由密钥的路由上下文值，如在DEREG REQ消息中找到的。
Deregistration Status: 32-bit integer
注销状态：32位整数
The Deregistration Result Status field indicates the success or the reason for failure of the deregistration.
注销结果状态字段指示注销成功或失败的原因。
Its values may be:
其值可能是：
0 Successfully Deregistered 1 Error - Unknown 2 Error - Invalid Routing Context 3 Error - Permission Denied 4 Error - Not Registered 5 Error - ASP Currently Active for Routing Context
0已成功取消注册1错误-未知2错误-路由上下文无效3错误-权限被拒绝4错误-未注册5错误-ASP当前对路由上下文处于活动状态
The ASP Active message is sent by an ASP to indicate to a remote M3UA peer that it is ready to process signalling traffic for a particular Application Server. The ASP Active message affects only the ASP state for the Routing Keys identified by the Routing Contexts, if present.
ASP活动消息由ASP发送，以向远程M3UA对等方表明它已准备好处理特定应用程序服务器的信令流量。ASP活动消息仅影响路由上下文标识的路由密钥（如果存在）的ASP状态。
The ASP Active message contains the following parameters:
ASP活动消息包含以下参数：
Traffic Mode Type Optional Routing Context Optional INFO String Optional
交通模式类型可选路由上下文可选信息字符串可选
The format for the ASP Active message is as follows:
ASP活动消息的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer)
流量模式类型：32位（无符号整数）
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Traffic Mode Type are shown in the following table:
Traffic Mode Type参数标识AS中ASP的运行流量模式。交通模式类型的有效值如下表所示：
1 Override 2 Loadshare 3 Broadcast
1覆盖2负载共享3广播
Within a particular Routing Context, Override, Loadshare, and Broadcast SHOULD NOT be mixed. The Override value indicates that the ASP is operating in Override mode, in which the ASP takes over all traffic in an Application Server (i.e., primary/backup operation), overriding any currently active ASPs in the AS. In Loadshare mode, the ASP will share in the traffic distribution with any other currently active ASPs. In Broadcast mode, the ASP will receive the same messages as any other currently active ASP.
在特定路由上下文中，覆盖、负载共享和广播不应混合使用。Override值表示ASP正在Override模式下运行，在此模式下，ASP将接管应用程序服务器中的所有流量（即主/备份操作），从而覆盖AS中任何当前活动的ASP。当前，在任何其他ASP分发模式下，ASP将与其他ASP共享流量。在广播模式下，ASP将接收与任何其他当前活动ASP相同的消息。
Routing Context: n X 32-bit integers
路由上下文：n X 32位整数
The optional Routing Context parameter contains (a list of) integers indexing the Application Server traffic that the sending ASP is configured/registered to receive.
可选的路由上下文参数包含（一组）整数，用于索引发送ASP配置/注册为接收的应用程序服务器流量。
There is a one-to-one relationship between an index entry and an SGP Routing Key or AS Name. Because an AS can only appear in one Network Appearance, the Network Appearance parameter is not required in the ASP Active message.
索引项和SGP路由键或AS名称之间存在一对一的关系。由于AS只能出现在一个网络外观中，因此ASP活动消息中不需要网络外观参数。
An Application Server Process may be configured to process traffic for more than one logical Application Server. From the perspective of an ASP, a Routing Context defines a range of signalling traffic that the ASP is currently configured to receive from the SGP. For example, an ASP could be configured to support signalling for multiple MTP3-Users, identified by separate SS7 DPC/OPC/SI ranges.
应用服务器进程可以配置为处理多个逻辑应用服务器的流量。从ASP的角度来看，路由上下文定义了ASP当前配置为从SGP接收的信令通信量的范围。例如，ASP可配置为支持多个MTP3用户的信令，由单独的SS7 DPC/OPC/SI范围标识。
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1).
可选信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The ASP Active Ack message is used to acknowledge an ASP Active message received from a remote M3UA peer.
ASP Active Ack消息用于确认从远程M3UA对等方接收到的ASP Active消息。
The ASP Active Ack message contains the following parameters:
ASP活动确认消息包含以下参数：
Traffic Mode Type Optional Routing Context Optional INFO String Optional
交通模式类型可选路由上下文可选信息字符串可选
The format for the ASP Active Ack message is as follows:
ASP活动确认消息的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1).
可选信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The INFO String in an ASP Active Ack message is independent from the INFO String in the ASP Active message (i.e., it does not have to echo back the INFO String received).
ASP活动确认消息中的信息字符串独立于ASP活动消息中的信息字符串（即，它不必回显收到的信息字符串）。
The format of the Traffic Mode Type and Routing Context parameters is the same as for the ASP Active message. (See Section 3.7.1.)
流量模式类型和路由上下文参数的格式与ASP活动消息的格式相同。（见第3.7.1节。）
The ASP Inactive message is sent by an ASP to indicate to a remote M3UA peer that it is no longer an active ASP to be used from within a list of ASPs. The ASP Inactive message affects only the ASP state in the Routing Keys identified by the Routing Contexts, if present.
ASP Inactive消息由ASP发送，以向远程M3UA对等方表明它不再是要从ASP列表中使用的活动ASP。ASP Inactive消息仅影响路由上下文（如果存在）标识的路由密钥中的ASP状态。
The ASP Inactive message contains the following parameters:
ASP非活动消息包含以下参数：
Routing Context Optional INFO String Optional
路由上下文可选信息字符串可选
The format for the ASP Inactive message parameters is as follows:
ASP非活动消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Routing Context and INFO String parameters are the same as for the ASP Active message (see Section 3.5.5.)
可选路由上下文和信息字符串参数的格式和说明与ASP活动消息的格式和说明相同（见第3.5.5节）
The ASP Inactive Ack message is used to acknowledge an ASP Inactive message received from a remote M3UA peer.
ASP Inactive Ack消息用于确认从远程M3UA对等方接收到的ASP Inactive消息。
The ASP Inactive Ack message contains the following parameters:
ASP非活动确认消息包含以下参数：
Routing Context Optional INFO String Optional
路由上下文可选信息字符串可选
The format for the ASP Inactive Ack message is as follows:
ASP非活动确认消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1).
可选信息字符串参数的格式和说明与DUNA消息相同（见第3.4.1节）。
The INFO String in an ASP Inactive Ack message is independent from the INFO String in the ASP Inactive message (i.e., it does not have to echo back the INFO String received).
ASP非活动确认消息中的信息字符串独立于ASP非活动消息中的信息字符串（即，它不必回显收到的信息字符串）。
The format of the Routing Context parameter is the same as for the ASP Inactive message. (see Section 3.7.3.)
路由上下文参数的格式与ASP非活动消息的格式相同。（见第3.7.3节。）
The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid. Error messages MUST NOT be generated in response to other Error messages.
错误消息用于通知对等方与传入消息关联的错误事件。例如，给定当前状态，消息类型可能是意外的，或者参数值可能无效。不得为响应其他错误消息而生成错误消息。
The Error message contains the following parameters:
错误消息包含以下参数：
Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Conditional
Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Conditional
* Only mandatory for specific Error Codes.
* 仅对特定错误代码是强制性的。
The format for the Error message is as follows:
错误消息的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag - 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Diagnostic Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag - 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Diagnostic Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code: 32 bits (unsigned integer)
错误代码：32位（无符号整数）
The Error Code parameter indicates the reason for the Error Message. The Error parameter value can be one of the following values:
Error Code参数指示错误消息的原因。错误参数值可以是以下值之一：
0x01 Invalid Version 0x02 Not Used in M3UA 0x03 Unsupported Message Class 0x04 Unsupported Message Type 0x05 Unsupported Traffic Mode Type 0x06 Unexpected Message
0x01无效版本0x02未在M3UA中使用0x03不支持的消息类0x04不支持的消息类型0x05不支持的通信模式类型0x06意外消息
0x07 Protocol Error 0x08 Not Used in M3UA 0x09 Invalid Stream Identifier 0x0a Not Used in M3UA 0x0b Not Used in M3UA 0x0c Not Used in M3UA 0x0d Refused - Management Blocking 0x0e ASP Identifier Required 0x0f Invalid ASP Identifier 0x10 Not Used in M3UA 0x11 Invalid Parameter Value 0x12 Parameter Field Error 0x13 Unexpected Parameter 0x14 Destination Status Unknown 0x15 Invalid Network Appearance 0x16 Missing Parameter 0x17 Not Used in M3UA 0x18 Not Used in M3UA 0x19 Invalid Routing Context 0x1a No Configured AS for ASP
0x07协议错误0x08未在M3UA中使用0x09无效流标识符0x0a未在M3UA中使用0x0b未在M3UA中使用0x0c未在M3UA中使用0x0d被拒绝-管理阻止0x0e ASP标识符必需0x0f无效ASP标识符0x10未在M3UA中使用0x11无效参数值0x12参数字段错误0x13意外参数0x14目标状态未知0x15无效网络外观0x16缺少参数0x17未在M3UA中使用0x18未在M3UA中使用0x19无效路由上下文0x1a未为ASP配置
The "Invalid Version" error is sent if a message with an unsupported version is received. The receiving end responds with an Error message, indicating the version the receiving node supports, and notifies layer management.
如果收到版本不受支持的消息，则会发送“版本无效”错误。接收端响应错误消息，指示接收节点支持的版本，并通知层管理。
The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received. For this error, the Diagnostic Information parameter MUST be included with the first 40 octets of the offending message.
如果收到包含意外或不支持的消息类的消息，则会发送“不支持的消息类”错误。对于此错误，诊断信息参数必须包含在出错消息的前40个八位字节中。
The "Unsupported Message Type" error is sent if a message with an unexpected or unsupported Message Type is received. For this error, the Diagnostic Information parameter MUST be included with the first 40 octets of the offending message.
如果收到具有意外或不支持的消息类型的消息，则会发送“不支持的消息类型”错误。对于此错误，诊断信息参数必须包含在出错消息的前40个八位字节中。
The "Unsupported Traffic Mode Type" error is sent by a SGP if an ASP sends an ASP Active message with an unsupported Traffic Mode Type or a Traffic Mode Type that is inconsistent with the presently configured mode for the Application Server. An example would be a case in which the SGP did not support loadsharing.
如果ASP发送的ASP活动消息具有不受支持的流量模式类型或与应用程序服务器当前配置的模式不一致的流量模式类型，则SGP将发送“不受支持的流量模式类型”错误。例如，SGP不支持负载共享。
The "Unexpected Message" error MAY be sent if a defined and recognized message is received that is not expected in the current state (in some cases, the ASP may optionally silently discard the message and not send an Error message). For example, silent discard is used by an ASP if it received a DATA message from an SGP while it was in the ASP-INACTIVE state. If the Unexpected message contained
如果接收到当前状态下不期望的已定义和已识别的消息，则可能会发送“意外消息”错误（在某些情况下，ASP可能会选择以静默方式放弃该消息，而不发送错误消息）。例如，如果ASP在ASP-INACTIVE状态下收到来自SGP的数据消息，则ASP将使用静默丢弃。如果包含意外消息
Routing Contexts, the Routing Contexts SHOULD be included in the Error message.
路由上下文，路由上下文应包含在错误消息中。
The "Protocol Error" error is sent for any protocol anomaly (i.e., receipt of a parameter that is syntactically correct but unexpected in the current situation).
针对任何协议异常发送“协议错误”错误（即，接收到语法正确但在当前情况下意外的参数）。
The "Invalid Stream Identifier" error is sent if a message is received on an unexpected SCTP stream (e.g., a Management message was received on a stream other than "0").
如果在意外的SCTP流上接收到消息（例如，在“0”以外的流上接收到管理消息），则发送“无效流标识符”错误。
The "Refused - Management Blocking" error is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons (e.g., management lockout). If this error is in response to an ASP Active message, the Routing Context(s) in the ASP Active message SHOULD be included in the Error message.
当收到ASP Up或ASP Active消息并且由于管理原因（例如，管理锁定）拒绝请求时，将发送“拒绝-管理阻止”错误。如果此错误是对ASP活动消息的响应，则ASP活动消息中的路由上下文应包含在错误消息中。
The "ASP Identifier Required" error is sent by an SGP in response to an ASP Up message that does not contain an ASP Identifier parameter when the SGP requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier.
当SGP需要ASP标识符参数时，“需要ASP标识符”错误由SGP发送，以响应不包含ASP标识符参数的ASP Up消息。ASP应使用ASP标识符重新发送ASP Up消息。
The "Invalid ASP Identifier" error is sent by an SGP in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
“无效ASP标识符”错误由SGP发送，以响应带有无效（即非唯一）ASP标识符的ASP Up消息。
The "Invalid Parameter Value" error is sent if a message is received with an invalid parameter value (e.g., a DUPU message was received with a Mask value other than "0".
如果接收到具有无效参数值的消息（例如，接收到的DUPU消息的掩码值不是“0”），则会发送“无效参数值”错误。
The "Parameter Field Error" would be sent if a message is received with a parameter having a wrong length field.
如果接收到带有错误长度字段的参数的消息，将发送“参数字段错误”。
The "Unexpected Parameter" error would be sent if a message contains an invalid parameter.
如果消息包含无效参数，将发送“意外参数”错误。
The "Destination Status Unknown" error MAY be sent if a DAUD is received at an SG enquiring of the availability/congestion status of a destination and the SG does not wish to provide the status (e.g., the sender is not authorized to know the status). For this error, the invalid or unauthorized Point Code(s) MUST be included along with the Network Appearance and/or Routing Context associated with the Point Code(s).
如果SG收到DAUD询问目的地的可用性/拥塞状态，且SG不希望提供该状态（例如，发送方无权了解该状态），则可能会发送“目的地状态未知”错误。对于此错误，必须包括无效或未经授权的点代码以及与点代码关联的网络外观和/或路由上下文。
The "Invalid Network Appearance" error is sent by an SGP if an ASP sends a message with an invalid (unconfigured) Network Appearance value. For this error, the invalid (unconfigured) Network Appearance MUST be included in the Network Appearance parameter.
如果ASP发送具有无效（未配置）网络外观值的消息，则SGP将发送“无效网络外观”错误。对于此错误，网络外观参数中必须包含无效（未配置）的网络外观。
The "Missing Parameter" error would be sent if a mandatory parameter were not included in a message. This error is also sent if a conditional parameter is not included in the message but is required in the context of the received message.
如果消息中未包含强制参数，则会发送“缺少参数”错误。如果消息中未包含条件参数，但在接收消息的上下文中需要条件参数，则也会发送此错误。
The "Invalid Routing Context" error is sent if a message is received from a peer with an invalid (unconfigured) Routing Context value. For this error, the invalid Routing Context(s) MUST be included in the Error message.
如果从具有无效（未配置）路由上下文值的对等方接收到消息，则会发送“无效路由上下文”错误。对于此错误，错误消息中必须包含无效的路由上下文。
The "No Configured AS for ASP" error is sent if a message is received from a peer without a Routing Context parameter and it is not known by configuration data which Application Servers are referenced.
如果从没有路由上下文参数的对等方接收到消息，并且配置数据不知道引用了哪些应用程序服务器，则会发送“No Configured AS for ASP”错误。
Diagnostic Information: variable length
诊断信息：可变长度
When included, the optional Diagnostic Information can be any information germane to the error condition, to assist in identification of the error condition. The Diagnostic Information SHOULD contain the offending message. A Diagnostic Information parameter with a zero length parameter is not considered an error (this means that the Length field in the TLV will be set to 4).
包括时，可选诊断信息可以是与错误条件相关的任何信息，以帮助识别错误条件。诊断信息应包含有问题的信息。长度参数为零的诊断信息参数不被视为错误（这意味着TLV中的长度字段将设置为4）。
The Notify message used to provide an autonomous indication of M3UA events to an M3UA peer.
Notify消息用于向M3UA对等方提供M3UA事件的自主指示。
The Notify message contains the following parameters:
通知消息包含以下参数：
Status Mandatory ASP Identifier Conditional Routing Context Optional INFO String Optional
状态强制ASP标识符条件路由上下文可选信息字符串可选
The format for the Notify message is as follows:
通知消息的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status Type: 16 bits (unsigned integer)
状态类型：16位（无符号整数）
The Status Type parameter identifies the type of the Notify message. The following are the valid Status Type values:
Status Type参数标识通知消息的类型。以下是有效的状态类型值：
1 Application Server State Change (AS-State_Change) 2 Other
1应用程序服务器状态更改（AS-State_更改）2其他
Status Information: 16 bits (unsigned integer)
状态信息：16位（无符号整数）
The Status Information parameter contains more detailed information for the notification, based on the value of the Status Type. If the Status Type is AS-State_Change the following Status Information values are used:
Status Information参数根据状态类型的值包含通知的更详细信息。如果状态类型为AS-State\u Change，则使用以下状态信息值：
1 Reserved 2 Application Server Inactive (AS-INACTIVE) 3 Application Server Active (AS-ACTIVE) 4 Application Server Pending (AS-PENDING)
1保留2应用程序服务器不活动（AS-Inactive）3应用程序服务器活动（AS-Active）4应用程序服务器挂起（AS-Pending）
These notifications are sent from an SGP to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the Application Server.
这些通知在特定应用程序服务器的状态发生变化时从SGP发送到ASP。该值反映应用程序服务器的新状态。
If the Status Type is Other, then the following Status Information values are defined:
如果状态类型为“其他”，则定义以下状态信息值：
1 Insufficient ASP Resources Active in AS 2 Alternate ASP Active 3 ASP Failure
1活动的ASP资源不足，如2备用ASP活动3 ASP失败
These notifications are not based on the SGP reporting the state change of an ASP or AS. In the Insufficient ASP Resources case, the SGP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is required to handle the load of the AS (Loadsharing or Broadcast mode). For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in Override mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For the ASP Failure case, the SGP is indicating to ASPs in the AS that one of the ASPs has failed. The ASP Identifier (if available) of the failed ASP MUST be placed in the message.
这些通知不是基于报告ASP或AS状态更改的SGP。在ASP资源不足的情况下，SGP向AS中的ASP_非活动ASP指示需要另一个ASP来处理AS的负载（负载共享或广播模式）。对于备用ASP-Active情况，当备用ASP在覆盖模式下转换为ASP-Active状态时，会通知ASP。备用ASP的ASP标识符（如果可用）必须放在消息中。对于ASP失败案例，SGP向中的ASP指示其中一个ASP已失败。失败ASP的ASP标识符（如果可用）必须放在消息中。
The format and description of the conditional ASP Identifier is the same as for the ASP Up message (see Section 3.5.1). The format and description of the Routing Context and Info String parameters are the same as for the ASP Active message (See Section 3.7.1)
条件ASP标识符的格式和说明与ASP Up消息的格式和说明相同（见第3.5.1节）。路由上下文和信息字符串参数的格式和说明与ASP活动消息的格式和说明相同（见第3.7.1节）
The M3UA layer needs to respond to various local primitives it receives from other layers, as well as to the messages that it receives from the peer M3UA layer. This section describes the M3UA procedures in response to these events.
M3UA层需要响应从其他层接收的各种本地原语，以及从对等M3UA层接收的消息。本节描述了应对这些事件的M3UA程序。
On receiving an MTP-TRANSFER request primitive from an upper layer at an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA layer sends a corresponding DATA message (see Section 3) to its M3UA peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER indication primitive to the upper layer.
当从ASP/IPSP的上层接收MTP-TRANSFER request原语，或从SGP的节点互通功能接收MTP-TRANSFER request原语时，M3UA层向其M3UA对等方发送相应的数据消息（见第3节）。接收数据消息的M3UA对等机向上层发送MTP传输指示原语。
The M3UA message distribution function (see Section 1.4.2.1) determines the Application Server (AS) by comparing the information in the MTP-TRANSFER request primitive with a provisioned Routing Key.
M3UA消息分发功能（请参阅第1.4.2.1节）通过比较MTP-TRANSFER request原语中的信息和配置的路由密钥来确定应用程序服务器（AS）。
From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE state is selected and a DATA message is constructed and issued on the corresponding SCTP association. If more than one ASP is in the ASP-ACTIVE state (i.e., traffic is to be loadshared across more than one ASP), one of the ASPs in the ASP-ACTIVE state is selected from the list. If the ASPs are in Broadcast Mode, all active ASPs will be selected, and the message will be sent to each of the active ASPs. The selection algorithm is implementation dependent but could, for example, be round robin or based on the SLS or ISUP CIC. The appropriate selection algorithm must be chosen carefully, as it is dependent on application assumptions and understanding of the degree of state coordination between the ASP-ACTIVE ASPs in the AS.
从AS表中的ASP列表中，选择处于ASP-ACTIVE状态的ASP，并在相应的SCTP关联上构造和发布数据消息。如果多个ASP处于ASP-ACTIVE状态（即，流量将在多个ASP之间进行负载共享），则会从列表中选择一个处于ASP-ACTIVE状态的ASP。如果ASP处于广播模式，将选择所有活动ASP，并将消息发送到每个活动ASP。选择算法取决于实现，但例如可以是循环或基于SLS或ISUP CIC。必须仔细选择适当的选择算法，因为它取决于应用程序假设和对as中ASP-ACTIVE ASP之间状态协调程度的理解。
In addition, the message needs to be sent on the appropriate SCTP stream, again taking care to meet the message sequencing needs of the signalling application. DATA messages MUST be sent on an SCTP stream other than stream '0'.
此外，需要在适当的SCTP流上发送消息，再次注意满足信令应用程序的消息排序需求。数据消息必须在流“0”以外的SCTP流上发送。
When there is no Routing Key match, or only a partial match, for an incoming SS7 message, a default treatment MAY be specified. Possible solutions are to provide a default Application Server at the SGP that directs all unallocated traffic to a (set of) default ASP(s), or to drop the message and provide a notification to Layer Management in an M-ERROR indication primitive. The treatment of unallocated traffic is implementation dependent.
当传入SS7消息没有路由密钥匹配或只有部分匹配时，可以指定默认处理。可能的解决方案是在SGP上提供一个默认应用程序服务器，将所有未分配的流量定向到（一组）默认ASP，或者删除消息并在M错误指示原语中向层管理提供通知。未分配流量的处理取决于实现。
On receiving primitives from the local Layer Management, the M3UA layer will take the requested action and provide an appropriate response primitive to Layer Management.
从本地层管理接收原语后，M3UA层将采取请求的操作，并向层管理提供适当的响应原语。
An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP or IPSP will initiate the establishment of an SCTP association. The M3UA layer will attempt to establish an SCTP association with the remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP layer.
来自ASP或IPSP层管理的M-SCTP_建立请求原语将启动SCTP关联的建立。M3UA层将通过向本地SCTP层发送SCTP-ASSOCIATE原语，尝试与远程M3UA对等方建立SCTP关联。
When an SCTP association has been successfully established, the SCTP will send an SCTP-COMMUNICATION_UP notification primitive to the local M3UA layer. At the SGP or IPSP that initiated the request, the M3UA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer Management when the association setup is complete. At the peer M3UA layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer Management upon successful completion of an incoming SCTP association setup.
成功建立SCTP关联后，SCTP将向本地M3UA层发送SCTP-COMMUNICATION_UP通知原语。在发起请求的SGP或IPSP处，关联设置完成后，M3UA层将向层管理发送一个M-SCTP_建立确认原语。在对等M3UA层，成功完成传入SCTP关联设置后，将M-SCTP_建立指示原语发送到层管理。
An M-SCTP_RELEASE request primitive from Layer Management initiates the teardown of an SCTP association. The M3UA layer accomplishes a graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN primitive to the SCTP layer.
来自层管理的M-SCTP_释放请求原语启动SCTP关联的拆卸。M3UA层通过向SCTP层发送SCTP-shutdown原语，实现SCTP关联的正常关闭。
When the graceful shutdown of the SCTP association has been accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE notification primitive to the local M3UA layer. At the M3UA Layer that initiated the request, the M3UA layer will send an M-SCTP_RELEASE confirm primitive to Layer Management when the association shutdown is complete. At the peer M3UA Layer, an M-SCTP_RELEASE indication primitive is sent to Layer Management upon abort or successful shutdown of an SCTP association.
当SCTP关联的正常关闭完成后，SCTP层向本地M3UA层返回SCTP-shutdown_COMPLETE通知原语。在发起请求的M3UA层，关联关闭完成后，M3UA层将向层管理发送一个M-SCTP_RELEASE confirm原语。在对等M3UA层，当SCTP关联中止或成功关闭时，M-SCTP_释放指示原语被发送到层管理。
An M-SCTP_STATUS request primitive supports a Layer Management query of the local status of a particular SCTP association. The M3UA layer simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS primitive to the SCTP layer. When the SCTP responds, the M3UA layer maps the association status information to an M-SCTP_STATUS confirm primitive. No peer protocol is invoked.
M-SCTP_状态请求原语支持对特定SCTP关联的本地状态的层管理查询。M3UA层只是将M-SCTP_状态请求原语映射到SCTP层的SCTP-STATUS原语。当SCTP响应时，M3UA层将关联状态信息映射到M-SCTP_状态确认原语。没有调用对等协议。
Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings can be described for the various other SCTP Upper Layer primitives in RFC2960 [18], such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, and NETWORK STATUS CHANGE. Alternatively, these SCTP Upper Layer
对于RFC2960[18]中的各种其他SCTP上层原语，可以描述类似的LM-to-M3UA-to-SCTP和/或SCTP-to-M3UA-to-LM原语映射，例如初始化、设置主要、更改心跳、请求心跳、获取SRTT报告、设置故障阈值、设置协议参数、销毁SCTP实例、发送故障、，以及网络状态的变化。或者，这些SCTP位于上层
primitives (and Status as well) can be considered, for modeling purposes, as a Layer Management interaction directly with the SCTP Layer.
出于建模目的，可以将原语（以及状态）视为直接与SCTP层进行的层管理交互。
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M3UA Notify or Error message, respectively. These indications can also be generated based on local M3UA events.
M-NOTIFY指示和M-ERROR指示原语分别向层管理层指示接收到的M3UA NOTIFY或ERROR消息中包含的通知或错误信息。也可以根据本地M3UA事件生成这些指示。
An M-ASP_STATUS request primitive supports a Layer Management query of the status of a particular local or remote ASP. The M3UA layer responds with the status in an M-ASP_STATUS confirm primitive. No M3UA peer protocol is invoked.
M-ASP_状态请求原语支持对特定本地或远程ASP的状态进行层管理查询。“确认”层以ASP状态响应“确认”。未调用M3UA对等协议。
An M-AS_STATUS request supports a Layer Management query of the status of a particular AS. The M3UA responds with an M-AS_STATUS confirm primitive. No M3UA peer protocol is invoked.
M-AS_状态请求支持对特定AS状态的层管理查询。M3UA以M-AS_状态确认原语进行响应。未调用M3UA对等协议。
M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE, and M-ASP_INACTIVE request primitives allow Layer Management at an ASP to initiate state changes. Upon successful completion, a corresponding confirm primitive is provided by the M3UA layer to Layer Management. If an invocation is unsuccessful, an Error indication primitive is provided in the primitive. These requests result in outgoing ASP Up, ASP Down, ASP Active, and ASP Inactive messages to the remote M3UA peer at an SGP or IPSP.
M-ASP\U UP、M-ASP\U DOWN、M-ASP\U ACTIVE和M-ASP\U INACTIVE请求原语允许ASP的层管理启动状态更改。成功完成后，M3UA层对层管理将提供相应的确认原语。如果调用失败，则在原语中提供错误指示原语。这些请求将向SGP或IPSP上的远程M3UA对等方发出ASP Up、ASP Down、ASP Active和ASP Inactive消息。
Upon successful state changes resulting from reception of ASP Up, ASP Down, ASP Active, and ASP Inactive messages from a peer M3UA, the M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE, M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication primitives to the local Layer Management.
当从对等M3UA接收到ASP Up、ASP Down、ASP Active和ASP Inactive消息而导致状态成功更改时，M3UA层可以向本地管理层调用相应的M-ASP Up、M-ASP Down、M-ASP Active、M-ASP Down、M-ASU Active和M-ASU Down指示原语。
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M3UA Notify or Error message. These indications can also be generated based on local M3UA events.
M-NOTIFY指示和M-ERROR指示原语向层管理层指示接收到的M3UA NOTIFY或ERROR消息中包含的通知或错误信息。也可以根据本地M3UA事件生成这些指示。
All non-Transfer and non-SSNM messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. ASPTM messages MAY be sent on one of the streams used to carry the data traffic related to the Routing Context(s), to minimize possible message loss. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery and MAY be sent on any stream.
除BEAT和BEAT Ack外，所有非传输和非SSNM消息应按顺序发送，以确保订购。ASPTM消息可在用于承载与路由上下文相关的数据流量的流之一上发送，以最小化可能的消息丢失。BEAT和BEAT Ack消息可以使用无序交付发送，并且可以在任何流上发送。
The M3UA layer on the SGP maintains the state of each remote ASP, in each Application Server that the ASP is configured to receive traffic, as input to the M3UA message distribution function. Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP maintains the state of remote IPSPs.
SGP上的M3UA层维护每个应用服务器中每个远程ASP的状态，该ASP配置为接收流量，作为M3UA消息分发功能的输入。类似地，当IPSP以点对点的方式使用M3UA时，IPSP中的M3UA层保持远程IPSP的状态。
Two IPSP models are defined as follows:
两种IPSP模型定义如下：
1. IPSP Single Exchange (SE) model. Only a single exchange of ASPTM and ASPSM messages is needed to change the IPSP states. This means that a set of requests from one end and acknowledgements from the other will be enough. The RK must define both sides of the traffic flow. Each exchange of ASPTM or ASPSM messages can be initiated by either IPSP. For this exchange, the initiating IPSP follows the procedures described in Section 4.3.1.
1. IPSP单一交换（SE）模型。更改IPSP状态只需交换一次ASPTM和ASPSM消息。这意味着一组来自一端的请求和来自另一端的确认就足够了。RK必须定义交通流的两侧。每次交换ASPTM或ASPSM消息都可以由IPSP启动。对于该交换，初始IPSP遵循第4.3.1节中描述的程序。
2. IPSP Double Exchange (DE) model. A double exchange of ASPTM and ASPSM messages is normally needed (ASPSM single exchange is optional as a simplification). Each exchange of ASPTM or ASPSM messages can be initiated by either IPSP. The RKs define the traffic to be directed to the peer as in the AS-SG model. Therefore, two different RKs are usually used, one installed on each peer.
2. IPSP双交换（DE）模型。通常需要双重交换ASPTM和ASPSM消息（作为简化，ASPSM单一交换是可选的）。每次交换ASPTM或ASPSM消息都可以由IPSP启动。在as-SG模型中，RK定义了要定向到对等方的通信量。因此，通常使用两个不同的RK，每个对等机上安装一个RK。
When using double exchanges for ASPSM messages, the management of the connection in the two directions is considered independent. This means that connections from IPSP-A to IPSP-B is handled independently of connections from IPSP-B to IPSP-A. Therefore, it could happen that only one of the two directions is activated or closed, while the other remains in the same state as it was.
当对ASPSM消息使用双交换时，两个方向上的连接管理被认为是独立的。这意味着从IPSP-A到IPSP-B的连接是独立于从IPSP-B到IPSP-A的连接来处理的。因此，可能只有两个方向中的一个被激活或关闭，而另一个方向保持原来的状态。
When using single exchange of ASPSM, what is seen as a simplification, only the activation phase (ASPTM messages) is independent for each of the two directions. In this case, it could happen that the sending of the ASPSM from IPSP-A or IPSP-B could have an effect in the whole communication, as it is defined in the standard SG-AS communication.
当使用单一的ASPSM交换时（这被看作是一种简化），只有激活阶段（ASPTM消息）对两个方向中的每一个都是独立的。在这种情况下，根据标准SG-as通信中的定义，从IPSP-A或IPSP-B发送ASPSM可能会对整个通信产生影响。
Because of these differences, there should be an agreement on the way ASPSM messages are being handled before starting DE-IPSP communication.
由于这些差异，在开始DE-IPSP通信之前，应对ASPSM消息的处理方式达成一致。
In order to ensure interoperability, an M3UA implementation supporting IPSP communication MUST support the IPSP SE model and MAY implement the IPSP DE model.
为了确保互操作性，支持IPSP通信的M3UA实现必须支持IPSP SE模型，并且可以实现IPSP DE模型。
In Section 4.3.1, ASP/IPSP States are described.
第4.3.1节描述了ASP/IPSP状态。
In Section 4.3.2, only the SGP-ASP scenario is described. All of the procedures referring to an AS served by ASPs are also applicable to ASes served by IPSPs.
在第4.3.2节中，仅描述了SGP-ASP场景。所有涉及ASP提供的AS的程序也适用于IPSP提供的AS。
In Section 4.3.3, only the Management procedures for the SGP-ASP scenario are described. The corresponding Management procedures for IPSPs are directly implied.
在第4.3.3节中，仅描述了SGP-ASP场景的管理程序。直接暗示了IPSP的相应管理程序。
The remaining sections contain specific IPSP Considerations subsections.
其余部分包含特定的IPSP注意事项小节。
The state of each remote ASP/IPSP, in each AS that it is configured to operate, is maintained in the peer M3UA layer (i.e., in the SGP or peer IPSP, respectively). The state of a particular ASP/IPSP in a particular AS changes due to events. The events include:
每个远程ASP/IPSP在其配置为运行的每个AS中的状态都在对等M3UA层（即分别在SGP或对等IPSP中）中维护。特定ASP/IPSP在特定环境中的状态，由于事件而发生更改。这些活动包括：
* Receipt of messages from the peer M3UA layer at the ASP/IPSP; * Receipt of some messages from the peer M3UA layer at other ASPs/IPSPs in the AS (e.g., ASP Active message indicating "Override"); * Receipt of indications from the SCTP layer; and * Local Management intervention.
* 从ASP/IPSP的对等M3UA层接收消息；*从AS中其他ASP/IPSP的对等M3UA层接收一些消息（例如，ASP活动消息指示“覆盖”）；*接收来自SCTP层的指示；以及*地方管理干预。
The ASP/C-IPSP/D-IPSP state transition diagram is shown in Figure 3. The possible states of an ASP/D-IPSP/C-IPSP are:
ASP/C-IPSP/D-IPSP状态转换图如图3所示。ASP/D-IPSP/C-IPSP的可能状态为：
ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable, and/or the related SCTP association is down. Initially, all ASPs/IPSPs will be in this state. An ASP/IPSP in this state SHOULD NOT be sent any M3UA messages, with the exception of Heartbeat, ASP Down Ack, and Error messages.
ASP-DOWN：ASP/IPSP上的远程M3UA对等机不可用，和/或相关SCTP关联已关闭。最初，所有ASP/IPSP都将处于此状态。处于此状态的ASP/IPSP不应发送任何M3UA消息，但心跳、ASP停机确认和错误消息除外。
ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and the related SCTP association is up), but application traffic is stopped. In this state, the ASP/IPSP SHOULD NOT be sent any DATA or SSNM messages for the AS for which the ASP/IPSP is inactive.
ASP-INACTIVE：ASP/IPSP上的远程M3UA对等机可用（且相关SCTP关联已启动），但应用程序通信已停止。在此状态下，对于ASP/IPSP处于非活动状态的AS，不应向ASP/IPSP发送任何数据或SSNM消息。
ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and application traffic is active (for a particular Routing Context or set of Routing Contexts).
ASP-ACTIVE:ASP/IPSP上的远程M3UA对等方可用，且应用程序流量处于活动状态（对于特定路由上下文或一组路由上下文）。
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The local SCTP layer will send this indication when it detects the loss
SCTP CDI：SCTP CDI表示本地SCTP层与SGP上上层协议（M3UA）的通信下行指示。本地SCTP层在检测到丢失时将发送此指示
of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN_COMPLETE notification or a COMMUNICATION_LOST notification from the SCTP layer.
与ASP的对等SCTP层的连接。SCTP CDI被理解为来自SCTP层的关机完成通知或通信丢失通知。
SCTP RI: The local SCTP layer's Restart indication to the upper-layer protocol (M3UA) on an SG. The local SCTP will send this indication when it detects a restart from the peer SCTP layer.
SCTP RI：本地SCTP层对SG上上层协议（M3UA）的重启指示。当本地SCTP检测到来自对等SCTP层的重启时，将发送此指示。
+--------------+
| |
+----------------------| ASP-ACTIVE |
| Other ASP/ +-------| |
| IPSP in AS | +--------------+
| Overrides | ^ |
| | ASPAC/ | | ASPIA/
| |[ASPAC-Ack]| | [ASPIA-Ack]
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| | |
| +--------------+
| ^ |
ASPDN/ | | | ASPDN /
[ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]
SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/
SCTP RI | | | SCTP RI
| | v
| +--------------+
| | |
+--------------------->| ASP-DOWN |
| |
+--------------+
+--------------+
| |
+----------------------| ASP-ACTIVE |
| Other ASP/ +-------| |
| IPSP in AS | +--------------+
| Overrides | ^ |
| | ASPAC/ | | ASPIA/
| |[ASPAC-Ack]| | [ASPIA-Ack]
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| | |
| +--------------+
| ^ |
ASPDN/ | | | ASPDN /
[ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]
SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/
SCTP RI | | | SCTP RI
| | v
| +--------------+
| | |
+--------------------->| ASP-DOWN |
| |
+--------------+
Figure 3: ASP State Transition Diagram, per AS
图3:ASP状态转换图，根据AS
The transitions are depicted as a result of the reception of ASP*M messages or other events. In some of the transitions, there are some messages in brackets. They mean that for a given node the state transition will be different, depending on its role: whether or not it is generating the ASP*M request message (i.e., ASPUP, ASPAC, ASPIA or ASPDN) or simply receiving it. In a peer-to-peer based architecture (IPSP), this role may change between the peers.
转换被描述为接收ASP*M消息或其他事件的结果。在一些转换中，括号中有一些消息。它们意味着，对于给定节点，状态转换将有所不同，这取决于其角色：是生成ASP*M请求消息（即ASPUP、ASPAC、ASPIA还是ASPDN）还是仅仅接收它。在基于点对点的体系结构（IPSP）中，此角色可能在对等方之间发生变化。
The transitions not in brackets are valid to track the states of ASPs and IPSPs that send an ASP*M request message at the peer node.
括号中未包含的转换可用于跟踪在对等节点发送ASP*M请求消息的ASP和IPSP的状态。
The transition in brackets may be used in an ASP or in the IPSP that receives an ASP*M request to track the peer SGP/IPSP states, respectively. There may be an SGP per AS state machine at ASPs.
括号中的转换可分别用于ASP或接收ASP*M请求以跟踪对等SGP/IPSP状态的IPSP中。ASPs上可能有一个SGP per AS状态机。
Then, the transitions in brackets can be used for the IPSP DE model communication (DE-IPSPs) and are related to the special cases when just one ASP*M messages exchange is needed, as follows:
然后，括号中的转换可用于IPSP DE模型通信（DE IPSPs），并与仅需要一次ASP*M消息交换的特殊情况相关，如下所示：
- ASPSM messages. When ASPSM messages are exchanged using only a single exchange (only one request and one acknowledgement). Example (see Section 5.6.2): Whenever a DE-IPSP is taking the leading role to start communication to a peer DE-IPSP, it sends an ASP Up message to the peer DE-IPSP. The peer MAY consider the initiating DE-IPSPs to be in ASP-INACTIVE state, as it already sent a message, and answer back with ASP Up Ack. Upon receipt of this answer by the initiating DE-IPSP, it also MAY consider the peer to be in ASP-INACTIVE state, since it did respond. Therefore, a second ASP Up message exchange to be started by the peer DE-IPSP could be avoided. In this case, the receipt of ASP Up Ack will turn into a state change.
- ASPSM消息。仅使用单个交换（仅一个请求和一个确认）交换ASPSM消息时。示例（见第5.6.2节）：当DE-IPSP担任与对等DE-IPSP开始通信的领导角色时，它会向对等DE-IPSP发送ASP Up消息。对等体可能会认为发起的DIPSPs处于ASP-STATABLE状态，因为它已经发送了一条消息，并用ASPUP ACK进行应答。当发起DE-IPSP接收到该答案时，它也可以考虑该对等点处于ASP-非活动状态，因为它确实响应。因此，可以避免由对等DE-IPSP启动的第二次ASP Up消息交换。在这种情况下，ASP Up Ack的接收将变为状态更改。
- ASPTM messages. When sending ASPTM messages to activate/deactivate all the traffic independently of routing keys by not specifying any RC, a single exchange could be sufficient.
- ASPTM消息。当发送ASPTM消息以通过不指定任何RC来独立于路由密钥激活/停用所有流量时，单次交换就足够了。
The state of the AS is maintained in the M3UA layer on the SGPs. The state of an AS changes due to events. These events include:
AS的状态保持在SGP上的M3UA层中。AS的状态因事件而更改。这些活动包括：
* ASP state transitions * Recovery timer triggers
* ASP状态转换*恢复计时器触发器
The possible states of an AS are:
AS的可能状态为：
AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in ASP-DOWN state for this AS. Initially the AS will be in this state. An Application Server is in the AS-DOWN state when it is removed from a configuration.
AS-DOWN：应用程序服务器不可用。此状态表示此AS的所有相关ASP都处于ASP-DOWN状态。最初，AS将处于此状态。从配置中删除应用程序服务器时，应用程序服务器处于AS-DOWN状态。
AS-INACTIVE: The Application Server is available, but no application traffic is active. One or more related ASPs are in ASP-INACTIVE state, and/or the number of related ASPs in ASP-ACTIVE state has not reached n (n is the number of ASPs required to be in ASP-ACTIVE state before AS can transition to AS-ACTIVE; n = 1 for Override Traffic Mode) for this AS. The recovery timer T(r) is not running or has expired.
AS-INACTIVE：应用程序服务器可用，但没有应用程序通信处于活动状态。一个或多个相关ASP处于ASP-INACTIVE状态，和/或此AS处于ASP-ACTIVE状态的相关ASP的数量尚未达到n（n是AS转换为AS-ACTIVE之前需要处于ASP-ACTIVE状态的ASP的数量；n=1表示覆盖流量模式）。恢复计时器T（r）未运行或已过期。
AS-ACTIVE: The Application Server is available and application traffic is active. The AS moves to this state after being in AS-INACTIVE and getting n ASPs (n is the number of ASPs required to be in ASP-ACTIVE state before AS can transition to AS-ACTIVE; n = 1 for Override Traffic Mode) in ASP-ACTIVE state or after reaching AS-ACTIVE and keeping one or more ASPs in ASP-ACTIVE state. When one ASP is considered enough to handle traffic (smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon as the first ASP moves to the ASP-ACTIVE state.
AS-ACTIVE：应用程序服务器可用，且应用程序流量处于活动状态。AS在处于AS-INACTIVE状态并在ASP-ACTIVE状态或达到AS-ACTIVE状态并将一个或多个ASP保持在ASP-ACTIVE状态后（n是AS可以转换为AS-ACTIVE之前需要处于ASP-ACTIVE状态的ASP数；n=1表示覆盖流量模式）移动到此状态。当一个ASP被认为足以处理流量（平稳启动）时，AS-INACTIVE中的AS可能会在第一个ASP移动到ASP-ACTIVE状态后立即到达AS-ACTIVE。
AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP DOWN and it was the last remaining active ASP in the AS. A recovery timer T(r) SHOULD be started, and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state, and all the queued messages will be sent to the ASP.
AS-PENDING：活动ASP已转换为ASP-INACTIVE或ASP DOWN，它是AS中最后一个剩余的活动ASP。应启动恢复计时器T（r），所有传入的信令消息应由SGP排队。如果ASP在T（r）到期之前变为ASP-ACTIVE，则AS将移动到AS-ACTIVE状态，并且所有排队的消息都将发送到ASP。
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no alternative, the SGP may stop queuing messages and discard all previously queued messages. The AS will move to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE; otherwise, it will move to AS-DOWN state.
如果T（r）在ASP变为ASP-ACTIVE之前过期，并且SGP没有其他选择，则SGP可能会停止对消息进行排队，并放弃所有先前排队的消息。如果至少有一个ASP处于ASP-INACTIVE状态，AS将移动到AS-INACTIVE状态；否则，它将移动到AS-DOWN状态。
Figure 4 shows an example AS state machine for the case where the AS/ASP data is preconfigured and is an n+k redundancy model. In other cases where the AS/ASP configuration data is created dynamically, there would be differences in the state machine, especially at creation of the AS.
图4显示了AS/ASP数据预配置且为n+k冗余模型的情况下的AS状态机示例。在动态创建AS/ASP配置数据的其他情况下，状态机中会存在差异，尤其是在创建AS时。
+----------+ IA2AC +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<----------- | |
+----------+ \ +-------------+
^ | \ ^ |
| | IA2DN \ PN2IA | | AC2PN
| | \ | |
DN2IA | | \ PN2AC | |
| v \ | v
+----------+ \ +-------------+
| | ----------| |
| AS-DOWN | | AS-PENDING |
| | PN2DN | (queueing) |
| |<----------------------------| |
+----------+ +-------------+
+----------+ IA2AC +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<----------- | |
+----------+ \ +-------------+
^ | \ ^ |
| | IA2DN \ PN2IA | | AC2PN
| | \ | |
DN2IA | | \ PN2AC | |
| v \ | v
+----------+ \ +-------------+
| | ----------| |
| AS-DOWN | | AS-PENDING |
| | PN2DN | (queueing) |
| |<----------------------------| |
+----------+ +-------------+
Figure 4: AS State Transition Diagram
图4:AS状态转换图
DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state.
DN2A：一个ASP从ASP-DOWN状态移动到ASP-INACTIVE状态。
IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN, causing all the ASPs to be in ASP-DOWN state.
IA2DN:ASP-INACTIVE中的最后一个ASP移动到ASP-DOWN，导致所有ASP处于ASP-DOWN状态。
IA2AC: One ASP moves to ASP-ACTIVE, causing the number of ASPs in the ASP-ACTIVE state to be n. In a special case of smooth start, this transition MAY be done when the first ASP moves to ASP-ACTIVE state.
IA2AC:一个ASP移动到ASP-ACTIVE，导致处于ASP-ACTIVE状态的ASP数量为n。在平滑启动的特殊情况下，可在第一个ASP移动到ASP-ACTIVE状态时完成此转换。
AC2PN: The last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-DOWN states, causing the number of ASPs in ASP-ACTIVE to drop below 1.
AC2PN:处于ASP-ACTIVE状态的最后一个ASP移动到ASP-INACTIVE或ASP-DOWN状态，导致ASP-ACTIVE中的ASP数量降至1以下。
PN2AC: One ASP moves to ASP-ACTIVE.
PN2AC:一个ASP移动到ASP-ACTIVE。
PN2IA: T(r) expiry; an ASP is in ASP-INACTIVE state but no ASPs are in ASP-ACTIVE state.
PN2IA:T（r）到期；ASP处于ASP-INACTIVE状态，但没有ASP处于ASP-ACTIVE状态。
PN2DN: T(r) expiry; all the ASPs are in ASP-DOWN state.
PN2DN:T（r）到期；所有ASP都处于ASP-DOWN状态。
An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state during the startup phase (except for smooth start). Once the traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns to another state different from ASP-ACTIVE, avoiding unnecessary traffic disturbances as long as there are ASPs available (this assumes that the system will not always be exposed to the maximum load).
在启动阶段，当n个ASP达到ASP-ACTIVE状态后，AS立即变为AS-ACTIVE（平滑启动除外）。一旦流量流动，AS将保持AS-ACTIVE状态，直到最后一个ASP变为与ASP-ACTIVE不同的另一个状态，只要有可用的ASP，就可以避免不必要的流量干扰（这假设系统不会始终暴露在最大负载下）。
There are other cases where the AS/ASP configuration data is created dynamically. In those cases there would be differences in the state machine, especially at creation of the AS. For example, where the AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the nth successful REG REQ from an ASP belonging to that AS. Another example is where the AS/ASP configuration data is not created until the nth ASP successfully enters the ASP-ACTIVE state. In this latter case, the AS-ACTIVE state is entered directly.
在其他情况下，AS/ASP配置数据是动态创建的。在这些情况下，状态机会有所不同，尤其是在创建AS时。例如，在AS/ASP配置数据直到第一个ASP注册后才创建的情况下，AS-INACTIVE状态在来自属于该AS的ASP的第n个成功REG REQ时直接进入。另一个示例是，在第n个ASP成功进入ASP-ACTIVE状态之前，不会创建AS/ASP配置数据。在后一种情况下，直接进入AS-ACTIVE状态。
Before the establishment of an SCTP association, the ASP state at both the SGP and ASP is assumed to be in the state ASP-DOWN.
在建立SCTP关联之前，假定SGP和ASP的ASP状态都处于ASP-DOWN状态。
Once the SCTP association is established (see Section 4.2), assuming that the local M3UA-User is ready, the local M3UA ASP Maintenance (ASPM) function will initiate the relevant procedures, using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey the ASP state to the SGP (see Section 4.3.4).
一旦建立SCTP关联（见第4.2节），假设本地M3UA用户已准备就绪，本地M3UA ASP维护（ASPM）功能将启动相关程序，使用ASP Up/ASP Down/ASP Active/ASP Inactive消息将ASP状态传送给SGP（见第4.3.4节）。
If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the ASP will be moved to ASP-DOWN. At an ASP, the MTP3-User will be informed of the unavailability of any affected SS7 destinations through the use of MTP-PAUSE indication primitives.
如果M3UA层随后从底层SCTP层接收到SCTP-COMMUNICATION_DOWN或SCTP-RESTART指示原语，它将通过调用M-SCTP_状态指示原语通知层管理。ASP的状态将移动到ASP-DOWN。在ASP中，MTP3用户将通过使用MTP-PAUSE指示原语被告知任何受影响的SS7目的地不可用。
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-establish the SCTP Association. This MAY be done by the M3UA layer automatically, or Layer Management MAY reestablish using the M-SCTP_ESTABLISH request primitive.
在SCTP通信中断的情况下，SCTP客户端可以尝试重新建立SCTP关联。这可以由M3UA层自动完成，或者层管理可以使用M-SCTP_建立请求原语重新建立。
In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered to be in the ASP-DOWN state by its M3UA peer. The ASP, if it is to recover, must begin any recovery with the ASP-Up procedure.
在ASP处出现SCTP-RESTART指示的情况下，ASP现在被其M3UA对等方视为处于ASP-DOWN状态。如果要恢复，ASP必须使用ASP Up过程开始任何恢复。
After an ASP has successfully established an SCTP association to an SGP, the SGP waits for the ASP to send an ASP Up message, indicating that the ASP M3UA peer is available. The ASP is always the initiator of the ASP Up message. This action MAY be initiated at the ASP by an M-ASP_UP request primitive from Layer Management or MAY be initiated automatically by an M3UA management function.
ASP成功建立与SGP的SCTP关联后，SGP将等待ASP发送ASP Up消息，指示ASP M3UA对等机可用。ASP始终是ASP Up消息的发起方。此操作可以由层管理的M-ASP_UP request原语在ASP处启动，也可以由M3UA管理功能自动启动。
When an ASP Up message is received at an SGP and, internally, the remote ASP is in the ASP-DOWN state and is not considered locked out for local management reasons, the SGP marks the remote ASP in the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication primitive. If the SGP is aware, via current configuration data, which Application Servers the ASP is configured to operate in, the SGP updates the ASP state to ASP-INACTIVE in each AS that it is a member.
当SGP收到ASP Up消息，并且在内部，远程ASP处于ASP-DOWN状态，并且由于本地管理原因未被视为锁定时，SGP将远程ASP标记为ASP-INACTIVE状态，并使用M-ASP_Up指示原语通知层管理。如果SGP通过当前配置数据知道ASP配置为在哪些应用服务器中运行，则SGP会将每个应用服务器中的ASP状态更新为ASP-INACTIVE，因为它是一个成员。
Alternatively, the SGP may move the ASP into a pool of Inactive ASPs available for future configuration within Application Servers, determined in a subsequent Registration Request or ASP Active procedure. If the ASP Up message contains an ASP Identifier, the SGP should save the ASP Identifier for that ASP. The SGP MUST send an ASP Up Ack message in response to a received ASP Up message even if the ASP is already marked as ASP-INACTIVE at the SGP.
或者，SGP可以将ASP移动到非活动ASP池中，该非活动ASP池可用于在随后的注册请求或ASP活动过程中确定的应用服务器内的未来配置。如果ASP Up消息包含ASP标识符，则SGP应保存该ASP的ASP标识符。SGP必须发送ASP Up Ack消息以响应收到的ASP Up消息，即使该ASP已在SGP上标记为ASP-INACTIVE。
If for any local reason (e.g., management lockout) the SGP cannot respond with an ASP Up Ack message, the SGP responds to an ASP Up message with an Error message with the reason "Refused - Management Blocking".
如果由于任何本地原因（例如，管理锁定），SGP无法响应ASP Up Ack消息，则SGP会响应ASP Up消息，并返回错误消息，原因为“拒绝-管理阻塞”。
At the ASP, the ASP Up Ack message received is not acknowledged. Layer Management is informed with an M-ASP_UP confirm primitive.
在ASP上，接收到的ASP Up Ack消息未得到确认。层管理由M-ASP\U UP确认原语通知。
When the ASP sends an ASP Up message, it starts timer T(ack). If the ASP does not receive a response to an ASP Up message within T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until it receives an ASP Up Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication.
当ASP发送ASP Up消息时，它启动计时器T（确认）。如果ASP在T（确认）内未收到对ASP Up消息的响应，则ASP可重新启动T（确认）并重新发送ASP Up消息，直到收到ASP Up ack消息。T（ack）是可设置的，默认值为2秒。或者，ASP Up消息的重新传输可以置于层管理的控制之下。在这种方法中，T（ack）的到期将导致带有否定指示的M-ASP_UP confirm原语。
The ASP must wait for the ASP Up Ack message before sending any other M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any other M3UA messages before an ASP Up message is received (other than ASP Down; see Section 4.3.4.2), the SGP MAY discard them.
ASP必须等待ASP Up Ack消息，然后再发送任何其他M3UA消息（例如ASP Active或REG REQ）。如果SGP在收到ASP Up消息（ASP Down除外；请参阅第4.3.4.2节）之前收到任何其他M3UA消息，则SGP可能会放弃这些消息。
If an ASP Up message is received and, internally, the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message"). In addition, the remote ASP state is changed to ASP-INACTIVE in all relevant Application Servers, and all registered Routing Keys are considered deregistered.
如果收到ASP Up消息，并且远程ASP在内部处于ASP-ACTIVE状态，则返回ASP Up Ack消息以及错误消息（“意外消息”）。此外，所有相关应用程序服务器中的远程ASP状态都更改为ASP-INACTIVE，所有已注册的路由密钥都被视为已注销。
If an ASP Up message is received and, internally, the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned, and no further action is taken.
如果收到ASP Up消息，并且远程ASP在内部已处于ASP-INACTIVE状态，则返回ASP Up Ack消息，并且不采取进一步的操作。
If the ASP receives an unexpected ASP Up Ack message, the ASP should consider itself in the ASP-INACTIVE state. If the ASP was not in the ASP-INACTIVE state, it SHOULD send an Error message and then initiate procedures to return itself to its previous state.
如果ASP收到一个意外的ASP UP ACK消息，那么ASP应该考虑自己处于ASP-UNACTIVE状态。如果ASP未处于ASP-INACTIVE状态，则应发送一条错误消息，然后启动过程以将自身恢复到以前的状态。
If an ASP Up message with an unsupported version is received, the receiving end responds with an Error message, indicating the version the receiving node supports and notifies Layer Management. See Section 4.8 for more on this issue.
如果接收到版本不受支持的ASP Up消息，接收端将以错误消息响应，指示接收节点支持的版本，并通知层管理。有关此问题的更多信息，请参见第4.8节。
An IPSP may be considered in the ASP-INACTIVE state after an ASP Up or ASP Up Ack has been received from it. An IPSP can be considered
在接收到来自IPSP的ASP Up或ASP Up Ack后，可以认为IPSP处于ASP-INACTIVE状态。可以考虑IPSP
in the ASP-DOWN state after an ASP Down or ASP Down Ack has been received from it. The IPSP may inform Layer Management of the change in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or confirmation primitives.
在收到ASP-DOWN或ASP-DOWN确认后，处于ASP-DOWN状态。IPSP可以使用M-ASP\U UP或M-ASP\U DN指示或确认原语将远程IPSP的状态变化通知给层管理。
Alternatively, when using the IPSP DE model, an interchange of ASP Up messages from each end MUST be performed. Four messages are needed for completion.
或者，当使用IPSP DE模型时，必须从每一端交换ASP Up消息。完成需要四条消息。
If for any local reason (e.g., management lockout) an IPSP cannot respond to an ASP Up message with an ASP Up Ack message, it responds to an ASP Up message with an Error message with the reason "Refused Management Blocking" and leaves the remote IPSP in the ASP-DOWN state.
如果由于任何本地原因（例如，管理锁定），IPSP无法使用ASP Up Ack消息响应ASP Up消息，则IPSP将使用错误消息响应ASP Up消息，原因为“拒绝管理阻塞”，并使远程IPSP处于ASP-DOWN状态。
The ASP will send an ASP Down message to an SGP when the ASP wishes to be removed from service in all Application Servers that it is a member and no longer receive any DATA, SSNM or, ASPTM messages. This action MAY be initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management or MAY be initiated automatically by an M3UA management function.
当ASP希望从其作为成员的所有应用程序服务器的服务中删除并且不再接收任何数据、SSNM或ASPTM消息时，ASP将向SGP发送ASP关闭消息。此操作可由层管理的M-ASP_DOWN request原语在ASP处启动，也可由M3UA管理功能自动启动。
Whether the ASP is permanently removed from any AS is a function of configuration management. In the case where the ASP previously used the Registration procedures (see Section 4.4.1) to register within Application Servers but has not deregistered from all of them prior to sending the ASP Down message, the SGP MUST consider the ASP Deregistered in all Application Servers that it is still a member.
ASP是否从任何AS中永久删除是配置管理的一项功能。在ASP以前使用登记程序（见4.4.1节）在应用服务器中注册但尚未在发送ASP向下消息之前取消所有注册时，SGP必须考虑在所有应用服务器中取消其仍然是成员的ASP。
The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the ASP.
SGP将ASP标记为ASP-DOWN，使用M-ASP\U DOWN指示原语通知层管理，并向ASP返回ASP-DOWN确认消息。
The SGP MUST send an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as ASP-DOWN at the SGP.
即使ASP已在SGP上标记为ASP-Down，SGP也必须发送ASP Down Ack消息以响应从ASP接收到的ASP Down消息。
At the ASP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with an M-ASP_DOWN confirm primitive. If the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP should now consider itself to be in the ASP-DOWN state.
在ASP上，接收到的ASP Down Ack消息未得到确认。通过M-ASP_DOWN confirm原语通知层管理。如果ASP在没有发送ASP向下消息的情况下接收到ASP Unk ACK，那么ASP现在应该认为自己处于ASP-DOWN状态。
If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the ASP should then initiate procedures to return itself to its previous state.
如果ASP以前处于ASP-ACTIVE或ASP-INACTIVE状态，则ASP应启动过程以将自身恢复到以前的状态。
When the ASP sends an ASP Down message, it starts timer T(ack). If the ASP does not receive a response to an ASP Down message within T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive, carrying a negative indication.
当ASP发送ASP Down消息时，它启动定时器T（ack）。如果ASP在T（ack）内未收到对ASP Down消息的响应，则ASP可重新启动T（ack）并重新发送ASP Down消息，直到收到ASP Down ack消息。T（ack）是可设置的，默认值为2秒。或者，ASP Down消息的重传可以置于层管理的控制之下。在这种方法中，T（ack）的到期将导致M-ASP_DOWN confirm原语，带有否定指示。
Anytime after the ASP has received an ASP Up Ack message from the SGP or IPSP, the ASP MAY send an ASP Active message to the SGP, indicating that the ASP is ready to start processing traffic. This action MAY be initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. In the case where an ASP wishes to process the traffic for more than one Application Server across a common SCTP association, the ASP Active message(s) SHOULD contain a list of one or more Routing Contexts to indicate for which Application Servers the ASP Active message applies. It is not necessary for the ASP to include all Routing Contexts of interest in a single ASP Active message, thus requesting to become active in all Routing Contexts at the same time. Multiple ASP Active messages MAY be used to activate within the Application Servers independently, or in sets.
在ASP从SGP或IPSP收到ASP Up Ack消息后的任何时候，ASP都可以向SGP发送ASP活动消息，指示ASP已准备好开始处理流量。此操作可以由层管理的M-ASP_活动请求原语在ASP处启动，也可以由M3UA管理功能自动启动。如果ASP希望通过公共SCTP关联处理多个应用程序服务器的流量，则ASP活动消息应包含一个或多个路由上下文的列表，以指示ASP活动消息适用于哪些应用程序服务器。ASP不必在单个ASP活动消息中包含所有感兴趣的路由上下文，因此请求同时在所有路由上下文中变为活动。多个ASP活动消息可用于在应用程序服务器内单独激活，或以集合形式激活。
In the case where an ASP Active message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Server(s) the ASP is a member.
如果ASP活动消息不包含路由上下文参数，则接收方必须通过配置数据知道ASP是哪个应用程序服务器的成员。
For the Application Servers for which the ASP can be successfully activated, the SGP or IPSP responds with one or more ASP Active Ack messages, including the associated Routing Context(s) and reflecting any Traffic Mode Type value present in the related ASP Active message. The Routing Context parameter MUST be included in the ASP Active Ack message(s) if the received ASP Active message contained any Routing Contexts. Depending on any Traffic Mode Type request in the ASP Active message, or local configuration data if there is no request, the SGP moves the ASP to the correct ASP traffic state within the associated Application Server(s). Layer Management is informed with an M-ASP_Active indication. If the SGP or IPSP receives any Data messages before an ASP Active message is received, the SGP or IPSP MAY discard them. By sending an ASP Active Ack message, the SGP or IPSP is now ready to receive and send traffic for the related Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages for the related Routing Context(s) before receiving an ASP Active Ack message, or it will risk message loss.
对于可以成功激活ASP的应用程序服务器，SGP或IPSP使用一个或多个ASP活动Ack消息进行响应，包括关联的路由上下文，并反映相关ASP活动消息中存在的任何流量模式类型值。如果收到的ASP活动消息包含任何路由上下文，则必须在ASP活动确认消息中包含路由上下文参数。根据ASP活动消息中的任何流量模式类型请求，或者如果没有请求，则根据本地配置数据，SGP将ASP移动到相关应用程序服务器内的正确ASP流量状态。通过M-ASP\U活动指示通知图层管理。如果SGP或IPSP在收到ASP活动消息之前收到任何数据消息，则SGP或IPSP可能会丢弃这些数据消息。通过发送ASP活动Ack消息，SGP或IPSP现在可以接收和发送相关路由上下文的通信量。在收到ASP活动Ack消息之前，ASP不应发送相关路由上下文的数据或SSNM消息，否则将有消息丢失的风险。
Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge the ASP Active message for different (sets of) Routing Contexts.
多个ASP活动Ack消息可用于响应包含多个路由上下文的ASP活动消息，从而允许SGP或IPSP针对不同（组）路由上下文独立地确认ASP活动消息。
The ASP Active message will be responded to in the following way as a function of the presence/need of the RC parameter:
根据RC参数的存在/需要，ASP活动消息将以以下方式响应：
- If the RC parameter is included in the ASP Active message and the corresponding RK has been previously defined (by either static configuration or dynamic registration), the peer node MUST respond with an ASP Active Ack message. If for any local reason (e.g., management lockout) the SGP responds to an ASP Active message with an Error message with reason "Refused Management Blocking".
- 如果RC参数包含在ASP活动消息中，并且之前已定义了相应的RK（通过静态配置或动态注册），则对等节点必须使用ASP活动确认消息进行响应。如果由于任何本地原因（例如，管理锁定），SGP响应ASP活动消息时会显示错误消息，原因为“拒绝管理阻塞”。
- If the RC parameter is included in the ASP Active message and a corresponding RK has not been previously defined (by either static configuration or dynamic registration), the peer MUST respond with an ERROR message with the Error Code "No configured AS for ASP".
- 如果RC参数包含在ASP活动消息中，并且之前未定义相应的RK（通过静态配置或动态注册），则对等方必须以错误消息响应，错误代码为“No configured AS for ASP”。
- If (1) the RC parameter is not included in the ASP Active message, (2) there are RKs defined (by either static configuration or dynamic registration) and (3) RC is not mandatory, the peer node SHOULD respond with an ASP Active Ack message and activate all the RKs it has defined for that specific ASP.
- 如果（1）ASP活动消息中未包含RC参数，（2）存在定义的RK（通过静态配置或动态注册），并且（3）RC不是强制性的，则对等节点应使用ASP活动Ack消息进行响应，并激活它为该特定ASP定义的所有RK。
- If (!) the RC parameter is not included in the ASP Active message, (2) there are RKs defined (by either static configuration or dynamic registration), (3) and RC is mandatory, the peer node MUST respond with an ERROR message with the Error Code "Missing Parameter".
- 如果（！）RC参数未包含在ASP活动消息中，（2）存在定义的RK（通过静态配置或动态注册），（3）并且RC是必需的，则对等节点必须以错误代码“Missing parameter”的错误消息进行响应。
- If (1) the RC parameter is not included in the ASP Active message, (2) there are RKs defined (by either static configuration or dynamic registration) and (3) RC is not mandatory, the peer node MUST respond with an ASP Active Ack message if it is ready to handle traffic; otherwise, it will send an ERROR message with the Error Code "No Configured AS for ASP" (meaning that it is not ready to become active).
- 如果（1）ASP活动消息中未包含RC参数，（2）存在定义的RK（通过静态配置或动态注册），并且（3）RC不是强制性的，则对等节点必须使用ASP活动Ack消息进行响应，前提是它已准备好处理流量；否则，它将发送一条错误消息，错误代码为“No Configured AS for ASP”（表示它尚未准备好激活）。
- If the RC parameter is not included in the ASP Active message and there are no RKs defined, the peer node SHOULD respond with and ERROR message with the Error Code "Invalid Routing Context".
- 如果ASP活动消息中未包含RC参数，且未定义RK，则对等节点应使用错误代码“无效路由上下文”响应和错误消息。
Independently of the RC, the SGP MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the APS-ACTIVE state.
独立于RC，如果ASP已标记为APS-Active状态，则SGP必须发送ASP Active Ack消息以响应从ASP接收到的ASP Active消息。
At the ASP, the ASP Active Ack message received is not acknowledged. Layer Management is informed with an M-ASP_ACTIVE confirm primitive. It is possible for the ASP to receive Data messages before the ASP Active Ack message as the ASP Active Ack and Data messages from an SG or IPSP may be sent on different SCTP streams. Message loss is possible, as the ASP does not consider itself in the ASP-ACTIVE state until receipt of the ASP Active Ack message.
在ASP上，接收到的ASP活动确认消息未得到确认。层管理由M-ASP_活动确认原语通知。ASP可以在ASP活动Ack消息之前接收数据消息，因为ASP活动Ack和来自SG或IPSP的数据消息可以在不同的SCTP流上发送。消息丢失是可能的，因为ASP在接收到ASP活动ACK消息之前不认为自己处于ASP-Active状态。
When the ASP sends an ASP Active message, it starts the timer T(ack). If the ASP does not receive a response to an ASP Active message within T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until it receives an ASP Active Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Active messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying a negative indication.
当ASP发送ASP活动消息时，它启动计时器T（确认）。如果ASP在T（确认）内未收到对ASP活动消息的响应，则ASP可重新启动T（确认）并重新发送ASP活动消息，直到收到ASP活动确认消息。T（ack）是可设置的，默认值为2秒。或者，ASP活动消息的重传可以置于层管理的控制之下。在这种方法中，T（ack）的到期会导致带有否定指示的M-ASP_活动确认原语。
There are three modes of Application Server traffic handling in the SGP M3UA layer: Override, Loadshare and Broadcast. When included, the Traffic Mode Type parameter in the ASP Active message indicates the traffic handling mode to be used in a particular Application Server. If the SGP determines that the mode indicated in an ASP Active message is unsupported or incompatible with the mode currently configured for the AS, the SGP responds with an Error message ("Unsupported / Invalid Traffic Handling Mode"). If the traffic handling mode of the Application Server is not already known via configuration data, then the traffic handling mode indicated in the first ASP Active message causing the transition of the Application Server state to AS-ACTIVE MAY be used to set the mode.
SGP M3UA层中有三种应用程序服务器流量处理模式：覆盖、负载共享和广播。包含时，ASP Active message中的Traffic Mode Type参数表示要在特定应用程序服务器中使用的流量处理模式。如果SGP确定ASP活动消息中指示的模式不受支持或与当前为AS配置的模式不兼容，SGP将以错误消息（“不支持/无效流量处理模式”）进行响应。如果通过配置数据还不知道应用服务器的流量处理模式，则可以使用导致应用服务器状态转换为AS-Active的第一条ASP-Active消息中指示的流量处理模式来设置模式。
In the case of an Override mode AS, receipt of an ASP Active message at an SGP causes the (re)direction of all traffic for the AS to the ASP that sent the ASP Active message. Any previously active ASP in the AS is now considered to be in the state ASP-INACTIVE and SHOULD no longer receive traffic from the SGP within the AS. The SGP or IPSP then MUST send a Notify message ("Alternate ASP_Active") to the previously active ASP in the AS and SHOULD stop traffic to/from that ASP. The ASP receiving this Notify MUST consider itself now in the ASP-INACTIVE state, if it is not already aware of this via inter-ASP communication with the Overriding ASP.
在覆盖模式AS的情况下，在SGP接收ASP活动消息会导致AS的所有通信量（重新）指向发送ASP活动消息的ASP。AS中任何以前处于活动状态的ASP现在被视为处于ASP-INACTIVE状态，并且不应再从AS中的SGP接收流量。然后，SGP或IPSP必须向AS中先前处于活动状态的ASP发送通知消息（“备用ASP_Active”），并应停止与该ASP之间的通信。接收到此通知的ASP现在必须在ASP非活动状态下考虑自身，如果它还没有通过与ASP的ASP间通信来意识到这一点的话。
In the case of a Loadshare mode AS, receipt of an ASP Active message at an SGP or IPSP causes direction of traffic to the ASP sending the ASP Active message, in addition to all the other ASPs that are currently active in the AS. The algorithm at the SGP for loadsharing traffic within an AS to all the active ASPs is implementation dependent. The algorithm could, for example, be round-robin or based on information in the Data message (e.g., the SLS, SCCP SSN, or ISUP
在Loadshare模式AS的情况下，在SGP或IPSP接收ASP活动消息时，除了AS中当前活动的所有其他ASP外，还会向发送ASP活动消息的ASP发送流量方向。SGP中用于AS内所有活动ASP的负载共享流量的算法取决于实现。例如，该算法可以是循环的或基于数据消息中的信息（例如，SLS、SCCP SSN或ISUP）
CIC value). An SGP or IPSP, upon receipt of an ASP Active message for the first ASP in a Loadshare AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources.
CIC值）。SGP或IPSP在收到负载共享AS中第一个ASP的ASP活动消息后，可以选择不将流量定向到新活动的ASP，直到它确定有足够的资源来处理预期负载（例如，直到AS中有“n”个ASP处于ASP-Active状态）。在这种情况下，SGP或IPSP应保留通知（作为活动），直到有足够的资源。
For the n+k redundancy case, ASPs that are in that AS should coordinate among themselves the number of active ASPs in the AS and should start sending traffic only after n ASPs are active. All ASPs within a loadsharing mode AS must be able to process any Data message received for the AS, to accommodate any potential failover or rebalancing of the offered load.
对于n+k冗余情况，AS中的ASP应相互协调AS中活动ASP的数量，并且应仅在n个ASP活动后开始发送流量。负载共享模式AS中的所有ASP必须能够处理为AS接收的任何数据消息，以适应所提供负载的任何潜在故障切换或重新平衡。
In the case of a Broadcast mode AS, receipt of an ASP Active message at an SGP or IPSP causes direction of traffic to the ASP sending the ASP Active message, in addition to all the other ASPs that are currently active in the AS. The algorithm at the SGP for broadcasting traffic within an AS to all the active ASPs is a simple broadcast algorithm, where every message is sent to each of the active ASPs.
在广播模式AS的情况下，除了AS中当前处于活动状态的所有其他ASP外，在SGP或IPSP处接收ASP活动消息会导致发送ASP活动消息的ASP的流量方向。SGP中用于将AS内的业务广播到所有活动ASP的算法是一种简单的广播算法，其中每个消息都发送到每个活动ASP。
At startup or restart phases, an SGP or IPSP, upon receipt of an ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources.
在启动或重新启动阶段，SGP或IPSP在收到Loadshare AS中第一个ASP的ASP活动消息后，不应将流量定向到新活动的ASP，直到它确定有足够的资源来处理预期负载（例如，直到AS中有“n”个ASP处于ASP-Active状态）。在这种情况下，SGP或IPSP应保留通知（作为活动），直到有足够的资源。
An SGP or IPSP, upon receipt of an ASP Active message for the first ASP in a Broadcast AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources.
SGP或IPSP在接收到广播AS中第一个ASP的ASP活动消息后，可以选择不将流量定向到新活动的ASP，直到它确定有足够的资源来处理预期负载（例如，直到AS中有“n”个ASP处于ASP-Active状态）。在这种情况下，SGP或IPSP应保留通知（作为活动），直到有足够的资源。
For the n+k redundancy case, ASPs that are in that AS should coordinate among themselves the number of active ASPs in the AS and should start sending traffic only after n ASPs are active.
对于n+k冗余情况，AS中的ASP应相互协调AS中活动ASP的数量，并且应仅在n个ASP活动后开始发送流量。
Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP MUST tag the first DATA message broadcast in each traffic flow with a unique Correlation Id parameter. The purpose of this Id is to permit the newly active ASP to synchronize its processing of traffic in each traffic flow with the other ASPs in the broadcast group.
每当处于广播模式AS的ASP变为ASP-ACTIVE时，SGP必须使用唯一的相关Id参数标记每个交通流中广播的第一条数据消息。此Id的目的是允许新激活的ASP将其对每个流量中的流量的处理与广播组中的其他ASP同步。
Either of the IPSPs can initiate communication. When an IPSP receives an ASP Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE state.
任何一个IPSP都可以启动通信。当IPSP接收到ASP-Active时，它应将对等方标记为ASP-Active并返回ASP-Active Ack消息。如果对等方尚未处于ASP-Active状态，则接收ASP-Active Ack消息的ASP可能会将其标记为ASP-Active。
Alternatively, when using the IPSP DE model, an interchange of ASP Active messages from each end MUST be performed. Four messages are needed for completion.
或者，当使用IPSP DE模型时，必须执行来自各端的ASP活动消息交换。完成需要四条消息。
When an ASP wishes to withdraw from receiving traffic within an AS or the ASP wants to initiate the process of deactivation, the ASP sends an ASP Inactive message to the SGP or IPSP.
当ASP希望退出AS内的接收流量或ASP希望启动停用过程时，ASP向SGP或IPSP发送ASP Inactive消息。
An ASP Inactive message MUST always be responded to by the peer (although other messages may be sent in the middle) in the following way:
对等方必须始终以以下方式响应ASP非活动消息（尽管其他消息可能在中间发送）：
- If the received ASP Inactive message contains an RC parameter and the corresponding RK is defined (by either static configuration or dynamic registration), the SGP/IPSP MUST respond with an ASP Inactive Ack message.
- 如果收到的ASP Inactive消息包含RC参数，并且定义了相应的RK（通过静态配置或动态注册），则SGP/IPSP必须使用ASP Inactive Ack消息进行响应。
- If the received ASP Inactive message contains an RC parameter that is not defined (by either static configuration or dynamic registration), the SGP/IPSP MUST respond with an ERROR message with the Error Code "Invalid Routing Context".
- 如果收到的ASP Inactive消息包含未定义的RC参数（通过静态配置或动态注册），则SGP/IPSP必须以错误代码“Invalid Routing Context”的错误消息进行响应。
- If the received ASP Inactive message does not contain an RC parameter and the RK is defined (by either static configuration or dynamic registration), the SGP/IPSP must turn the ASP/IPSP to ASP-INACTIVE state in all the ASes it serves and MUST respond with an ASP Inactive Ack message.
- 如果收到的ASP-Inactive消息不包含RC参数，并且RK已定义（通过静态配置或动态注册），则SGP/IPSP必须在其服务的所有ASE中将ASP/IPSP转换为ASP-Inactive状态，并且必须使用ASP-Inactive Ack消息进行响应。
- If the received ASP Inactive message does not contain an RC parameter and the RK is not defined (by either static configuration or dynamic registration), the SGP/IPSP MUST respond with an ERROR message with the Error Code "No configured AS for ASP".
- 如果收到的ASP Inactive消息不包含RC参数，且RK未定义（通过静态配置或动态注册），则SGP/IPSP必须以错误消息响应，错误代码为“No configured AS for ASP”。
The action of sending the ASP Inactive message MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. In the case where an ASP is processing the traffic for more than one
发送ASP非活动消息的操作可以通过层管理的M-ASP_非活动请求原语在ASP处启动，也可以通过M3UA管理功能自动启动。如果ASP正在处理一个以上的流量
Application Server across a common SCTP association, the ASP Inactive message contains one or more Routing Contexts to indicate for which Application Servers the ASP Inactive message applies.
ASP非活动消息包含一个或多个路由上下文，用于指示ASP非活动消息应用于哪些应用程序服务器。
In the case where an ASP Inactive message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Servers the ASP is a member of and then move the ASP to the ASP-INACTIVE state in all Application Servers.
如果ASP非活动消息不包含路由上下文参数，则接收方必须通过配置数据知道ASP是哪个应用程序服务器的成员，然后在所有应用程序服务器中将ASP移动到ASP非活动状态。
In the case of an Override mode AS, where another ASP has already taken over the traffic within the AS with an ASP Active ("Override") message, the ASP that sends the ASP Inactive message is already considered to be in ASP-INACTIVE state by the SGP. An ASP Inactive Ack message is sent to the ASP, after ensuring that all traffic is stopped to the ASP.
在覆盖模式AS的情况下，如果另一个ASP已通过ASP Active（“覆盖”）消息接管AS内的流量，则发送ASP Inactive消息的ASP已被SGP视为处于ASP-Inactive状态。在确保所有到ASP的通信都已停止后，ASP Inactive Ack消息将发送到ASP。
In the case of a Loadshare mode AS, the SGP moves the ASP to the ASP-INACTIVE state, and the AS traffic is reallocated across the remaining ASPs in the state ASP-ACTIVE, as per the loadsharing algorithm currently used within the AS. A Notify message ("Insufficient ASP resources active in AS") MAY be sent to all inactive ASPs, if required. An ASP Inactive Ack message is sent to the ASP after all traffic is halted, and Layer Management is informed with an M-ASP_INACTIVE indication primitive.
在负载共享模式AS的情况下，SGP将ASP移动到ASP-INACTIVE状态，并且AS流量根据AS中当前使用的负载共享算法在ASP-ACTIVE状态下的其余ASP之间重新分配。如果需要，可以向所有非活动的ASP发送通知消息（“AS中活动的ASP资源不足”）。在所有通信停止后，ASP Inactive Ack消息被发送到ASP，并且层管理被M-ASP_Inactive指示原语通知。
In the case of a Broadcast mode AS, the SGP moves the ASP to the ASP-INACTIVE state, and the AS traffic is broadcast only to the remaining ASPs in the state ASP-ACTIVE. A Notify message ("Insufficient ASP resources active in AS") MAY be sent to all inactive ASPs, if required. An ASP Inactive Ack message is sent to the ASP after all traffic is halted, and Layer Management is informed with an M-ASP_INACTIVE indication primitive.
在广播模式AS的情况下，SGP将ASP移动到ASP-INACTIVE状态，并且AS通信量仅广播到处于ASP-ACTIVE状态的其余ASP。如果需要，可以向所有非活动的ASP发送通知消息（“AS中活动的ASP资源不足”）。在所有通信停止后，ASP Inactive Ack消息被发送到ASP，并且层管理被M-ASP_Inactive指示原语通知。
Multiple ASP Inactive Ack messages MAY be used in response to an ASP Inactive message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge for different (sets of) Routing Contexts. The SGP or IPSP sends an Error message ("Invalid Routing Context") message for each invalid or unconfigured Routing Context value in a received ASP Inactive message.
多个ASP非活动Ack消息可用于响应包含多个路由上下文的ASP非活动消息，从而允许SGP或IPSP独立地确认不同（组）路由上下文。SGP或IPSP为接收到的ASP非活动消息中的每个无效或未配置的路由上下文值发送错误消息（“无效路由上下文”）。
The SGP MUST send an ASP Inactive Ack message in response to a received ASP Inactive message from the ASP; the ASP is already marked as ASP-INACTIVE at the SGP.
SGP必须发送ASP非活动Ack消息，以响应从ASP接收到的ASP非活动消息；ASP已在SGP上标记为ASP-INACTIVE。
At the ASP, the ASP Inactive Ack message received is not acknowledged. Layer Management is informed with an M-ASP_INACTIVE confirm primitive. If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive message, the ASP should now consider
在ASP上，接收到的ASP非活动确认消息未得到确认。使用M-ASP\U非活动确认原语通知图层管理。如果ASP接收到ASP非活动ACK而不发送ASP非激活消息，那么ASP现在应该考虑
itself to be in the ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE state, the ASP should then initiate procedures to return itself to its previous state.
它本身将处于ASP-INACTIVE状态。如果ASP以前处于ASP-ACTIVE状态，则ASP应启动过程以将自身恢复到以前的状态。
When the ASP sends an ASP Inactive message, it starts the timer T(ack). If the ASP does not receive a response to an ASP Inactive message within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it receives an ASP Inactive Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_Inactive confirm primitive carrying a negative indication.
当ASP发送ASP非活动消息时，它启动计时器T（确认）。如果ASP在T（确认）内未收到对ASP非活动消息的响应，则ASP可重新启动T（确认）并重新发送ASP非活动消息，直到收到ASP非活动确认消息。T（ack）是可设置的，默认值为2秒。或者，ASP非活动消息的重新传输可以置于层管理的控制之下。在这种方法中，T（ack）的到期导致M-ASP_非活动确认原语携带负指示。
If no other ASPs in the Application Server are in the state ASP-ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all ASPs in the AS that are in the state ASP-INACTIVE. The SGP SHOULD start buffering the incoming messages for T(r) seconds, after which messages MAY be discarded. T(r) is configurable by the network operator. If the SGP receives an ASP Active message from an ASP in the AS before expiry of T(r), the buffered traffic is directed to that ASP, and the timer is cancelled. If T(r) expires, the AS is moved to the AS-INACTIVE state.
如果应用程序服务器中没有其他ASP处于ASP-ACTIVE状态，则SGP必须向AS中处于ASP-ACTIVE状态的所有ASP发送通知消息（“AS Pending”）。SGP应开始将传入消息缓冲T（r）秒，之后可能会丢弃消息。T（r）可由网络运营商配置。如果SGP在T（r）到期之前从AS中的ASP接收到ASP活动消息，则缓冲的通信量被定向到该ASP，并且定时器被取消。如果T（r）过期，AS将移至AS-INACTIVE状态。
An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive or ASP Inactive Ack message has been received from it.
在从远程IPSP接收到ASP INACTIVE或ASP INACTIVE Ack消息后，远程IPSP可能认为IPSP处于ASP-INACTIVE状态。
Alternatively, when using IPSP DE model, an interchange of ASP Inactive messages from each end MUST be performed. Four messages are needed for completion.
或者，当使用IPSP DE模型时，必须从每一端交换ASP非活动消息。完成需要四条消息。
A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an ASP failure or receipt of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack).
必须向AS中的所有ASP发送反映AS状态更改的Notify消息（ASP-DOWN状态的ASP除外），其中包含相应的状态信息和失败ASP的任何ASP标识符。在ASP中，层管理通过M-NOTIFY指示原语通知。无论AS状态更改是由于ASP失败还是收到ASP状态管理（ASPSM）/ASP流量管理（ASPTM）消息，都必须发送Notify消息。在第二种情况下，通知消息必须在任何相关确认消息（例如，ASP Up Ack、ASP Down Ack、ASP Active Ack或ASP Inactive Ack）之后发送。
When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after
当ASP在特定AS内从ASP-DOWN移动到ASP-INACTIVE时，ASP-UP接收器应在
sending the ASP-UP-ACK, in order to inform the ASP of the current AS state.
发送ASP-UP-ACK，以通知ASP当前AS状态。
In the case where a Notify message ("AS-PENDING") message is sent by an SGP that now has no ASPs active to service the traffic, or where a Notify ("Insufficient ASP resources active in AS") message is sent in the Loadshare or Broadcast mode, the Notify message does not explicitly compel the ASP(s) receiving the message to become active. The ASPs remain in control of what (and when) traffic action is taken.
如果通知消息（“AS-PENDING”）消息是由现在没有活动的ASP来服务流量的SGP发送的，或者如果通知消息（“AS中活动的ASP资源不足”）是以Loadshare或广播模式发送的，则通知消息不会显式强制接收消息的ASP变为活动状态。ASP仍然控制采取什么（以及何时）交通行动。
In the case where a Notify message does not contain a Routing Context parameter, the receiver must know, via configuration data, of which Application Servers the ASP is a member and take the appropriate action in each AS.
在Notify消息不包含路由上下文参数的情况下，接收方必须通过配置数据知道ASP是哪个应用程序服务器的成员，并在每个AS中采取适当的操作。
Notify works in the same manner as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state.
以与SG-as案例相同的方式通知工程。其中一个IPSP可以将此消息发送到任何未处于ASP-DOWN状态的远程IPSP。
The optional Heartbeat procedures MAY be used when operating over transport layers that do not have their own heartbeat mechanism for detecting loss of the transport association (i.e., other than SCTP). Either M3UA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer, T(beat). Upon receiving a Heartbeat message, the M3UA peer MUST respond with a Heartbeat Ack message.
可选的心跳程序可用于在没有自己的心跳机制来检测传输关联丢失（即，除了SCTP）的传输层上操作。任何一个M3UA对等方都可以选择性地根据可配置的定时器T（beat）定期发送心跳消息。收到心跳消息后，M3UA对等方必须使用心跳确认消息进行响应。
If no Heartbeat Ack message (or any other M3UA message) is received from the M3UA peer within 2*T(beat), the remote M3UA peer is considered unavailable. Transmission of Heartbeat messages is stopped, and the signalling process SHOULD attempt to re-establish communication if it is configured as the client for the disconnected M3UA peer.
如果在2*T（beat）内未从M3UA对等方接收到心跳确认消息（或任何其他M3UA消息），则认为远程M3UA对等方不可用。心跳消息的传输已停止，如果信令进程配置为断开连接的M3UA对等方的客户端，则应尝试重新建立通信。
The Heartbeat message may optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Heartbeat Ack message. The sender, upon examining the contents of the returned Heartbeat Ack message, MAY choose to consider the remote M3UA peer as unavailable. The contents/format of the Heartbeat Data parameter is implementation-dependent and only of local interest to the original sender. The contents may be used, for example, to support a Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a timestamp mechanism (to evaluate delays).
Heartbeat消息可以选择性地包含不透明的Heartbeat数据参数，该参数必须在相关Heartbeat Ack消息中原封不动地回显。发送者在检查返回的心跳ACK消息的内容时，可以选择考虑远程M3UA对等体不可用。Heartbeat数据参数的内容/格式取决于实现，仅与原始发送方的本地兴趣相关。例如，内容可用于支持心跳序列算法（检测丢失的心跳）和/或时间戳机制（评估延迟）。
Note: Heartbeat-related events are not shown in Figure 3 "ASP state transition diagram".
注意：图3“ASP状态转换图”中未显示心跳相关事件。
An ASP MAY dynamically register with an SGP as an ASP within an Application Server using the REG REQ message. A Routing Key parameter in the REG REQ message specifies the parameters associated with the Routing Key.
ASP可以使用REG REQ消息在应用服务器内动态地向SGP注册为ASP。REG REQ消息中的路由密钥参数指定与路由密钥相关的参数。
The SGP examines the contents of the received Routing Key parameter and compares it with the currently provisioned Routing Keys. If the received Routing Key matches an existing SGP Routing Key entry and the ASP is not currently included in the list of ASPs for the related Application Server, the SGP MAY authorize the ASP to be added to the AS. Or, if the Routing Key does not currently exist and the received Routing Key data is valid and unique, an SGP supporting dynamic configuration MAY authorize the creation of a new Routing Key and related Application Server and add the ASP to the new AS. In either case, the SGP returns a Registration Response message to the ASP, containing the same Local-RK-Identifier as provided in the initial request, and a Registration Result "Successfully Registered". A unique Routing Context value assigned to the SGP Routing Key is included. The method of Routing Context value assignment at the SGP is implementation dependent but must be guaranteed to be unique for each Application Server or Routing Key supported by the SGP.
SGP检查接收到的路由密钥参数的内容，并将其与当前配置的路由密钥进行比较。如果收到的路由密钥与现有SGP路由密钥条目匹配，并且ASP当前未包括在相关应用服务器的ASP列表中，则SGP可以授权将ASP添加到AS。或者，如果路由密钥当前不存在且接收到的路由密钥数据有效且唯一，则支持动态配置的SGP可授权创建新路由密钥和相关应用程序服务器，并将ASP添加到新AS。在任何一种情况下，SGP都会向ASP返回注册响应消息，其中包含与初始请求中提供的相同的本地RK标识符，以及“成功注册”的注册结果。包括分配给SGP路由密钥的唯一路由上下文值。SGP上的路由上下文值分配方法取决于实现，但必须保证对于SGP支持的每个应用服务器或路由密钥是唯一的。
If the SGP does not support the registration procedure, the SGP returns an Error message to the ASP, with an error code of "Unsupported Message Class".
如果SGP不支持注册过程，SGP将向ASP返回一条错误消息，错误代码为“Unsupported message Class”。
If the SGP determines that the received Routing Key data is invalid, or contains invalid parameter values, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error Invalid Routing Key", "Error - Invalid DPC", or "Error - Invalid Network Appearance", as appropriate.
如果SGP确定接收到的路由密钥数据无效，或包含无效参数值，则SGP将向ASP返回注册响应消息，其中包含注册结果“错误无效路由密钥”、“错误无效DPC”或“错误无效网络外观”（视情况而定）。
If the SGP determines that the requested RK partially, but not exactly, matches an existing RK, and that an incoming signalling message received at an SGP could possibly match both the requested and the existing RK, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - "Cannot Support Unique Routing". An incoming signalling message received at an SGP should not match against more than one Routing Key.
如果SGP确定请求的RK部分（但不完全）与现有RK匹配，并且在SGP接收的传入信令消息可能与请求的RK和现有RK都匹配，则SGP将注册响应消息返回给ASP，注册状态为“Error-”无法支持唯一路由“。在SGP接收的传入信令消息不应与多个路由密钥匹配。
If the SGP determines that the received RK was already registered, fully and exactly, either statically or dynamically, by the sending ASP, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key Already Registered". This error applies whether the sending ASP/IPSP is in ASP-ACTIVE or ASP-INACTIVE for the corresponding AS. For this error code, the RC field in the Registration Response message MUST be populated with the actual value of RC in SGP corresponding to the specified RK in the Registration Request message.
如果SGP确定接收到的RK已经被发送的ASP以静态或动态方式完全准确地注册，则SGP将注册响应消息返回给ASP，其中包含注册结果“错误-路由密钥已注册”。对于相应的AS，无论发送ASP/IPSP处于ASP-ACTIVE还是ASP-INACTIVE状态，此错误都适用。对于此错误代码，注册响应消息中的RC字段必须填充与注册请求消息中指定RK对应的实际值RC in SGP。
An ASP MAY request modification of an existing Routing Key by including a Routing Context parameter in a Registration Request message. Upon receipt of a Registration Request message containing a Routing Context, if the SGP determines that the Routing Context applies to an existing Routing Key, the SGP MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter. A Registration Response "ERR Routing Key Change Refused" is returned if the SGP does not support this re-registration procedure or RC does not exist. Otherwise, a Registration Response "Successfully Registered" is returned.
ASP可以通过在注册请求消息中包含路由上下文参数来请求修改现有路由密钥。在接收到包含路由上下文的注册请求消息时，如果SGP确定路由上下文应用于现有路由密钥，则SGP可以调整现有路由密钥以匹配路由密钥参数中提供的新信息。如果SGP不支持此重新注册过程或RC不存在，则会返回注册响应“ERR Routing Key Change REQUIRED”。否则，将返回注册响应“成功注册”。
If the SGP does not authorize an otherwise valid registration request, the SGP returns a REG RSP message to the ASP containing the Registration Result "Error - Permission Denied".
如果SGP未授权其他有效的注册请求，SGP将向ASP返回一条REG RSP消息，其中包含注册结果“错误-权限被拒绝”。
If an SGP determines that a received Routing Key does not currently exist, and that the SGP does not support dynamic configuration, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key not Currently Provisioned".
如果SGP确定接收到的路由密钥当前不存在，并且SGP不支持动态配置，则SGP将向ASP返回注册响应消息，其中包含注册结果“错误-当前未设置路由密钥”。
If an SGP determines that a received Routing Key does not currently exist and that the SGP supports dynamic configuration but does not have the capacity to add new Routing Key and Application Server entries, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Insufficient Resources".
如果SGP确定当前不存在收到的路由密钥，并且SGP支持动态配置，但没有能力添加新的路由密钥和应用程序服务器条目，则SGP将向ASP返回注册响应消息，其中包含注册结果“错误-资源不足”。
If an SGP determines that a received Routing Key does not currently exist, and the SGP supports dynamic configuration but requires that the Routing Key first be manually provisioned at the SGP, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key not Currently Provisioned".
如果SGP确定当前不存在接收到的路由密钥，并且SGP支持动态配置，但要求首先在SGP手动设置路由密钥，则SGP将注册响应消息返回给ASP，其中包含注册结果“错误-当前未设置路由密钥”。
If an SGP determines that one or more of the Routing Key parameters are not supported for the purpose of creating new Routing Key entries, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Unsupported RK parameter field".
如果SGP确定不支持一个或多个路由密钥参数来创建新的路由密钥条目，SGP将向ASP返回注册响应消息，其中包含注册结果“错误-不支持的RK参数字段”。
A Registration Response "Error - Unsupported Traffic Handling Mode" is returned if the Routing Key in the REG REQ contains an Traffic Handling Mode that is inconsistent with the presently configured mode for the matching Application Server.
如果REG REQ中的路由密钥包含与匹配应用程序服务器当前配置的模式不一致的流量处理模式，则返回注册响应“错误-不支持的流量处理模式”。
An ASP MAY register multiple Routing Keys at once by including a number of Routing Key parameters in a single REG REQ message. The SGP MAY respond to each registration request in a single REG RSP message, indicating the success or failure result for each Routing Key in a separate Registration Result parameter. Alternatively the SGP MAY respond with multiple REG RSP messages, each with one or more Registration Result parameters. The ASP uses the Local-RK-Identifier parameter to correlate the requests with the responses.
ASP可以通过在单个REG REQ消息中包含多个路由密钥参数，一次注册多个路由密钥。SGP可以在单个REG RSP消息中响应每个注册请求，在单独的注册结果参数中指示每个路由密钥的成功或失败结果。或者，SGP可以使用多个REG-RSP消息进行响应，每个消息具有一个或多个注册结果参数。ASP使用本地RK标识符参数将请求与响应关联起来。
Upon successful registration of an ASP in an AS, the SGP can now send related SS7 Signalling Network Management messaging, if this did not previously start upon the ASP transitioning to state ASP-INACTIVE
在AS中成功注册ASP后，SGP现在可以发送相关的SS7信令网络管理消息，前提是该消息在ASP转换为ASP-INACTIVE状态时未启动
An ASP MAY dynamically deregister with an SGP as an ASP within an Application Server using the DEREG REQ message. A Routing Context parameter in the DEREG REQ message specifies which Routing Keys to deregister. An ASP SHOULD move to the ASP-INACTIVE state for an Application Server before attempting to deregister the Routing Key (i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP SHOULD deregister from all Application Servers of which it is a member before attempting to move to the ASP-Down state.
ASP可以使用DEREG REQ消息在应用程序服务器内以ASP的形式动态地向SGP注销。DEREG REQ消息中的路由上下文参数指定要取消注册的路由密钥。ASP应在尝试取消注册路由密钥（即，在收到ASP非活动Ack后取消注册）之前，将应用程序服务器移动到ASP非活动状态。此外，在尝试移动到ASP关闭状态之前，ASP应该从其所属的所有应用程序服务器注销。
The SGP examines the contents of the received Routing Context parameter and validates that the ASP is currently registered in the Application Server(s) related to the included Routing Context(s). If validated, the ASP is deregistered as an ASP in the related Application Server.
SGP检查接收到的路由上下文参数的内容，并验证ASP当前是否已在与包含的路由上下文相关的应用程序服务器中注册。如果已验证，则ASP将在相关应用程序服务器中注销为ASP。
The deregistration procedure does not necessarily imply the deletion of Routing Key and Application Server configuration data at the SG.
注销过程不一定意味着删除SG处的路由密钥和应用程序服务器配置数据。
Other ASPs may continue to be associated with the Application Server, in which case the Routing Key data SHOULD NOT be deleted. If a Deregistration results in no more ASPs in an Application Server, an SG MAY delete the Routing Key data.
其他ASP可能会继续与应用服务器关联，在这种情况下，不应删除路由密钥数据。如果取消注册导致应用服务器中没有更多的ASP，则SG可以删除路由密钥数据。
The SGP acknowledges the deregistration request by returning a DEREG RSP message to the requesting ASP. The result of the deregistration is found in the Deregistration Result parameter, indicating success or failure with cause.
SGP通过向请求ASP返回撤销RSP消息来确认撤销注册请求。注销结果可在“注销结果”参数中找到，表示成功或失败的原因。
An ASP MAY deregister multiple Routing Contexts at once by including a number of Routing Contexts in a single DEREG REQ message. The SGP MAY respond to each deregistration request in a single DEREG RSP message, indicating the success or failure result for each Routing Context in a separate Deregistration Result parameter.
ASP可以通过在单个DEREG REQ消息中包含多个路由上下文，一次取消注册多个路由上下文。SGP可以在单个撤销RSP消息中响应每个撤销注册请求，在单独的撤销注册结果参数中指示每个路由上下文的成功或失败结果。
The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered.
注册/注销程序在IPSP案例中的工作方式与as-SG案例中的工作方式相同。IPSP可以在远程IPSP中注册RK。IPSP负责注销其已注册的RK。
4.5. Procedures to Support the Availability or Congestion Status of SS7 Destination
4.5. 支持SS7目的地可用性或拥塞状态的程序
On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication primitive from the nodal interworking function at an SGP, the SGP M3UA layer will send a corresponding SS7 Signalling Network Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the M3UA peers at concerned ASPs. The M3UA layer must fill in various fields of the SSNM messages consistently with the information received in the primitives.
从SGP节点互通功能接收MTP-PAUSE、MTP-RESUME或MTP-STATUS指示原语时，SGP M3UA层将向相关ASP的M3UA对等方发送相应的SS7信令网络管理（SSNM）DUNA、DAVA、SCON或DUPU消息（见第3.4节）。M3UA层必须与原语中接收到的信息一致地填写SSNM消息的各个字段。
The SGP M3UA layer determines the set of concerned ASPs to be informed based on the specific SS7 network for which the primitive indication is relevant. In this way, all ASPs configured to send/receive traffic within a particular Network Appearance are informed. If the SGP operates within a single SS7 Network Appearance, then all ASPs are informed.
SGP M3UA层根据与原语指示相关的特定SS7网络确定要通知的相关ASP集。这样，所有配置为在特定网络外观内发送/接收流量的ASP都会得到通知。如果SGP在单个SS7网络外观内运行，则通知所有ASP。
For the particular case that an ASP becomes active for an AS and destinations normally accessible to the AS are inaccessible, restricted, or congested, the SG MAY send DUNA, DRST, or SCON messages for the inaccessible, restricted, or congested destinations to the ASP newly active for the AS to prevent the ASP from sending traffic for destinations that it might not otherwise know that are inaccessible, restricted, or congested. For the newly activating ASP from which the SGP has received an ASP Active message, these DUNA, DRST, and SCON messages MAY be sent before sending the ASP Active Ack that completes the activation procedure.
对于AS的ASP变为活动状态且AS通常可访问的目的地不可访问、受限或拥塞的特定情况，SG可为不可访问、受限的目的地发送DUNA、DRST或SCON消息，或将拥塞的目的地发送到AS新激活的ASP，以防止ASP向其可能不知道的不可访问、受限或拥塞的目的地发送流量。对于SGP从中收到ASP活动消息的新激活ASP，这些DUNA、DRST和SCON消息可在发送完成激活过程的ASP活动Ack之前发送。
DUNA, DAVA, SCON, and DRST messages may be sent sequentially and processed at the receiver in the order sent.
DUNA、DAVA、SCON和DRST消息可以按顺序发送，并在接收方按照发送顺序进行处理。
Sequencing is not required for the DUPU or DAUD messages, which MAY be sent unsequenced.
DUPU或DAUD消息不需要排序，它们可能未排序发送。
At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) message from the remote M3UA Peer, the M3UA layer invokes the appropriate primitive indications to the resident M3UA-Users. Local management is informed.
在ASP上，当从远程M3UA对等方接收到SS7信令网络管理（SSNM）消息时，M3UA层向常驻M3UA用户调用适当的原语指示。通知当地管理层。
In the case where a local event has caused the unavailability or congestion status of SS7 destinations, the M3UA layer at the ASP SHOULD pass up appropriate indications in the primitives to the M3UA User, as though equivalent SSNM messages were received. For example, the loss of an SCTP association to an SGP may cause the unavailability of a set of SS7 destinations. MTP-PAUSE indication primitives to the M3UA User are appropriate.
在本地事件导致SS7目的地不可用或拥塞状态的情况下，ASP处的M3UA层应将原语中的适当指示传递给M3UA用户，就像接收到等效的SSNM消息一样。例如，丢失与SGP的SCTP关联可能导致一组SS7目的地不可用。适用于M3UA用户的MTP暂停指示原语。
At an ASP, upon receiving a Signalling Network Management message from the remote M3UA Peer, the M3UA layer updates the status of the affected route(s) via the originating SG and determines whether or not the overall availability or congestion status of the affected destination(s) has changed. If so, the M3UA layer invokes the appropriate primitive indications to the resident M3UA-Users. Local management is informed.
在ASP中，当从远程M3UA对等方接收到信令网络管理消息时，M3UA层通过发起SG更新受影响路由的状态，并确定受影响目的地的总体可用性或拥塞状态是否已改变。如果是这样，M3UA层将向驻留的M3UA用户调用适当的原语指示。通知当地管理层。
Implementation Note: To accomplish this, the M3UA layer at an ASP maintains the status of routes via the SG, much like an MTP3 layer maintains route-set status.
实现说明：为了实现这一点，ASP的M3UA层通过SG维护路由状态，就像MTP3层维护路由集状态一样。
An ASP may optionally initiate an audit procedure to enquire of an SGP the availability and (if the national congestion method with multiple congestion levels and message priorities is used) congestion status of an SS7 destination or set of destinations. A Destination Audit (DAUD) message is sent from the ASP to the SGP, requesting the current availability and congestion status of one or more SS7 Destination Point Codes.
ASP可以选择性地启动审计程序，向SGP询问SS7目的地或目的地集的可用性和（如果使用具有多个拥塞级别和消息优先级的国家拥塞方法）拥塞状态。目标审核（DAUD）消息从ASP发送到SGP，请求一个或多个SS7目标点代码的当前可用性和拥塞状态。
The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by the ASP in the following cases:
DAUD消息可以不按顺序发送。在以下情况下，ASP可发送DAUD：
- Periodic. A Timer originally set upon receipt of a DUNA, SCON, or DRST message has expired without a subsequent DAVA, DUNA, SCON, or DRST message updating the availability/congestion status of the affected Destination Point Codes. The Timer is reset upon issuing a DAUD. In this case, the DAUD is sent to the SGP that originally sent the SSNM message.
- 周期性最初在接收到DUNA、SCON或DRST消息时设置的计时器已过期，而没有后续的DAVA、DUNA、SCON或DRST消息更新受影响目的地代码的可用性/拥塞状态。发出DAUD后，定时器复位。在这种情况下，DAUD被发送到最初发送SSNM消息的SGP。
- Isolation. The ASP is newly ASP-ACTIVE or has been isolated from an SGP for an extended period. The ASP MAY request the availability/congestion status of one or more SS7 destinations to which it expects to communicate.
- 隔离ASP是新的ASP-ACTIVE或已与SGP隔离较长时间。ASP可请求其预期与之通信的一个或多个SS7目的地的可用性/拥塞状态。
Implementation Note: In the first of the cases above, the auditing procedure must not be invoked for the case of a received SCON message containing a congestion level value of "no congestion" or "undefined" (i.e., congestion Level = "0").
实施说明：在上述第一种情况下，如果收到的SCON消息包含拥塞级别值“无拥塞”或“未定义”（即拥塞级别=“0”），则不得调用审核过程。
The SGP SHOULD respond to a DAUD message with the MTP3 availability/congestion status of the routeset associated with each Destination Point Codes in the DAUD message. The status of each SS7 destination requested is indicated in a DUNA message (if unavailable), a DAVA message (if available), or a DRST (if restricted and the SGP supports this feature in national networks). For national networks, the SGP SHOULD additionally respond with a SCON message (if the destination is congested) before the DAVA or DRST.
SGP应使用与DAUD消息中每个目的地点代码相关联的路由集的MTP3可用性/拥塞状态来响应DAUD消息。请求的每个SS7目的地的状态在DUNA消息（如果不可用）、DAVA消息（如果可用）或DRST（如果受限且SGP在国家网络中支持此功能）中指示。对于国家网络，SGP还应在DAVA或DRST之前响应SCON消息（如果目的地拥挤）。
Where the SGP does not maintain the congestion status of the SS7 destination, the response to a DAUD message should always only be a DAVA, DRST, or DUNA message, as appropriate.
如果SGP未保持SS7目的地的拥塞状态，则对DAUD消息的响应应始终仅为DAVA、DRST或DUNA消息（视情况而定）。
Any DUNA or DAVA message in response to a DAUD message MAY contain a list of Affected Point Codes.
响应DAUD消息的任何DUNA或DAVA消息可能包含受影响点代码的列表。
An SG MAY refuse to provide the availability or congestion status of a destination if, for example, the ASP is not authorized to know the status of the destination. The SG MAY respond with an Error Message (Error Code = "Destination Status Unknown").
例如，如果ASP无权了解目的地的状态，则SG可能拒绝提供目的地的可用性或拥塞状态。SG可能会响应错误消息（错误代码=“目的地状态未知”）。
An SG SHOULD respond with a DUNA message when DAUD was received with an unknown Signalling Point Code.
当收到带有未知信令点代码的DAUD时，SG应以DUNA消息响应。
In the case where the MTP3 in the SG undergoes an MTP restart, event communication SHOULD be handled as follows:
如果SG中的MTP3经历MTP重启，事件通信应按如下方式处理：
When the SG discovers SS7 network isolation, the SGPs send an indication to all concerned available ASPs (i.e., ASPs in the ASP-ACTIVE state), using DUNA messages for the concerned destinations.
当SG发现SS7网络隔离时，SGP使用相关目的地的DUNA消息向所有相关可用的ASP（即处于ASP-ACTIVE状态的ASP）发送指示。
When the SG has completed the MTP Restart procedure, the M3UA layers at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any available/restricted SS7 destinations, using the DAVA/DRST messages. No message is necessary for those destinations still unavailable after the restart procedure.
当SG完成MTP重启程序后，SGP的M3UA层使用DAVA/DRST消息通知处于ASP-ACTIVE状态的所有相关ASP，任何可用/受限的SS7目的地。对于重新启动过程后仍不可用的目标，不需要任何消息。
When the M3UA layer at an ASP receives a DUNA message indicating SS7 destination unavailability at an SG, MTP Users will receive an MTP-PAUSE indication and will stop any affected traffic to this destination. When the M3UA receives a DAVA/DRST message, MTP Users will receive an MTP-RESUME indication and can resume traffic to the newly available SS7 destination, provided that the ASP is in the ASP-ACTIVE state towards this SGP.
当ASP处的M3UA层接收到指示SG处SS7目的地不可用的DUNA消息时，MTP用户将接收到MTP-PAUSE指示，并将停止到此目的地的任何受影响流量。当M3UA收到DAVA/DRST消息时，MTP用户将收到MTP-RESUME指示，并且可以恢复到新可用SS7目的地的通信量，前提是ASP对此SGP处于ASP-ACTIVE状态。
The ASP MAY choose to audit the availability of unavailable destinations by sending DAUD messages. This would be the case when, for example, an AS becomes active at an ASP and does not have current destination statuses. If MTP restart is in progress at the SG, the SGP returns a DUNA message for that destination, even if it received an indication that the destination became available or restricted.
ASP可以选择通过发送DAUD消息来审核不可用目的地的可用性。例如，当AS在ASP处变为活动状态且没有当前目标状态时，就会出现这种情况。如果SG处正在进行MTP重启，则SGP将返回该目的地的DUNA消息，即使它收到目的地可用或受限的指示。
When an ASP becomes active for an AS and the SG is experiencing SS7 network isolation or is performing the MTP Restart procedure for the AS, the SG MAY send a DUNA message for the concerned destinations to the newly active ASP to prevent the ASP from sending traffic. These messages can be sent after receiving the ASP Active, and before sending the ASP Active Ack, to ensure that traffic is not initiated by the ASP to these destinations before the SSNM are received. In addition to DUNA messages, SCON, DRST, and DAVA can also be sent.
当AS的ASP变为活动状态且SG正在经历SS7网络隔离或正在为AS执行MTP重启过程时，SG可向新活动的ASP发送有关目的地的DUNA消息，以防止ASP发送流量。这些消息可以在接收到ASP Active后和发送ASP Active Ack前发送，以确保在收到SSNM之前，ASP不会向这些目的地发起流量。除了DUNA消息外，还可以发送SCON、DRST和DAVA。
In the IPSP case, MTP restart could be considered if the IPSP also has connection to an SS7 network. In that case, the same behavior as described above for the SGP would apply to the restarting IPSP. This would also be the case if the IPSPs were perceived as exchanging MTP Peer PDUs, instead of MTP primitives between MTP User and MTP Provider. In other words, M3UA does not provide the equivalent to Traffic Restart Allowed messages indicating the end of the restart procedure between peer IPSPs that would also be connected to an SS7 network.
在IPSP情况下，如果IPSP还连接到SS7网络，则可以考虑MTP重启。在这种情况下，与上述SGP相同的行为将应用于重新启动的IPSP。如果IPSP被视为在MTP用户和MTP提供商之间交换MTP对等PDU，而不是MTP原语，也会出现这种情况。换句话说，M3UA不提供等同于允许流量重启的消息，指示也将连接到SS7网络的对等IPSP之间重启过程的结束。
Implementation Note: Although the NIF is decided to be an implementation dependent function, here are some guidelines that may be useful to follow:
实现说明：尽管NIF被确定为依赖于实现的函数，但以下是一些可能有用的指南：
- If an SGP is isolated entirely from the NIF, the SGP should send ASP Down Ack to all its connected ASPs. Upon receiving an ASP Up message while isolated from the NIF, the SGP should respond with an Error ("Refused - Management Blocking").
- 如果SGP与NIF完全隔离，则SGP应向其所有连接的ASP发送ASP Down Ack。当从NIF隔离时收到ASP Up消息时，SGP应响应错误（“拒绝-管理阻塞”）。
- If an SGP suffers a partial failure (where an SGP can continue to service one or more active AS but due to a partial failure it is unable to service one or more other active AS), the SGP should send ASP Inactive Ack to all its connected ASPs for the affected AS. Upon receiving an ASP Active message for an affected AS while still partially isolated from the NIF, the SGP should respond with an Error ("Refused - Management Blocking").
- 如果SGP发生部分故障（其中SGP可以继续为一个或多个活动AS提供服务，但由于部分故障，它无法为一个或多个其他活动AS提供服务），SGP应向其所有连接的ASP发送ASP Inactive Ack，以用于受影响的AS。当收到受影响AS的ASP活动消息时，同时仍与NIF部分隔离，SGP应以错误（“拒绝-管理阻塞”）进行响应。
- If SG is isolated from NIF, it means that each SGP within an SG should follow the procedure mentioned above.
- 如果SG与NIF隔离，则意味着SG内的每个SGP应遵循上述程序。
If a message with an unsupported version is received, the receiving end responds with an Error message indicating the version the receiving node supports and notifies Layer Management.
如果接收到版本不受支持的消息，则接收端响应错误消息，指示接收节点支持的版本，并通知层管理。
This is useful when protocol version upgrades are being performed in a network. A node upgraded to a newer version should support the older versions used on other nodes it is communicating with. Because ASPs initiate the ASP Up procedure, it is likely that the message having an unsupported version is an ASP Up message and therefore that the Error message would normally come from the SGP.
这在网络中执行协议版本升级时非常有用。升级到较新版本的节点应支持与之通信的其他节点上使用的较旧版本。由于ASP启动ASP Up过程，因此具有不受支持版本的消息可能是ASP Up消息，因此错误消息通常来自SGP。
Whenever a M3UA node wants to stop the communication with the peer node, it MAY use one of the following procedures:
每当M3UA节点想要停止与对等节点的通信时，它可以使用以下过程之一：
a) Send the sequence of ASP-INACTIVE, DEREG (optionally whenever dynamic registration is used), and ASP-DOWN messages and perform the SCTP Shutdown procedure after that.
a) 发送ASP-INACTIVE、DEREG（在使用动态注册时可选）和ASP-DOWN消息的序列，然后执行SCTP Shutdown过程。
b) Just do the SCTP Shutdown procedure.
b) 只需执行SCTP关闭程序。
These scenarios show examples of M3UA message flows for the establishment of traffic between an SGP and an ASP or between two IPSPs. In all cases it is assumed that the SCTP association is already set up.
这些场景显示了用于在SGP和ASP之间或两个IPSP之间建立流量的M3UA消息流示例。在所有情况下，都假定已建立SCTP关联。
5.1.1. Single ASP in an Application Server ("1+0" sparing), No Registration
5.1.1. 应用服务器中的单个ASP（“1+0”备用），无需注册
These scenarios show examples of M3UA message flows for the establishment of traffic between an SGP and an ASP where only one ASP is configured within an AS (no backup).
这些场景显示了用于在SGP和ASP之间建立流量的M3UA消息流示例，其中AS中仅配置了一个ASP（无备份）。
5.1.1.1. Single ASP in an Application Server ("1+0" Sparing), No Registration
5.1.1.1. 应用服务器中的单个ASP（“1+0”备用），无需注册
SGP ASP1
| |
|<-------------ASP Up-----------|
|-----------ASP Up Ack--------->|
| |
|-----NTFY(AS-INACTIVE)(RCn)--->|
| |
|<------- ASP Active(RCn)-------| RC: Routing Context
|-----ASP Active Ack (RCn)----->| (optional)
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
SGP ASP1
| |
|<-------------ASP Up-----------|
|-----------ASP Up Ack--------->|
| |
|-----NTFY(AS-INACTIVE)(RCn)--->|
| |
|<------- ASP Active(RCn)-------| RC: Routing Context
|-----ASP Active Ack (RCn)----->| (optional)
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
Note: If the ASP Active message contains an optional Routing Context parameter, the ASP Active message only applies for the specified RC value(s). For an unknown RC value, the SGP responds with an Error message.
注意：如果ASP活动消息包含可选的路由上下文参数，则ASP活动消息仅适用于指定的RC值。对于未知的RC值，SGP将以错误消息进行响应。
5.1.1.2. Single ASP in Application Server ("1+0" Sparing), Dynamic Registration
5.1.1.2. 应用服务器中的单个ASP（“1+0”备用），动态注册
This scenario is the same as for 5.1.1.1 but with the optional exchange of registration information. In this case, the Registration is accepted by the SGP.
此场景与5.1.1.1相同，但具有可选的注册信息交换。在这种情况下，SGP接受注册。
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
| |
|<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing
| | Key Id
|----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key
| | RC: Routing Context
|----NTFY(AS-INACTIVE)(RCn)---->|
| |
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
| |
|<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing
| | Key Id
|----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key
| | RC: Routing Context
|----NTFY(AS-INACTIVE)(RCn)---->|
| |
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g., invalid RKn), the Register Response message will contain an unsuccessful indication, and the ASP will not subsequently send an ASP Active message.
注意：如果注册尝试不成功（例如，无效RKn），则注册响应消息将包含不成功指示，ASP随后不会发送ASP活动消息。
5.1.1.3. Single ASP in Multiple Application Servers (Each with "1+0" Sparing), Dynamic Registration (Case 1 - Multiple Registration Requests)
5.1.1.3. 多个应用服务器中的单个ASP（每个服务器都有“1+0”备用），动态注册（案例1-多个注册请求）
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing
| | Key Id
|----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key
| | RC: Routing Context
|---NOTIFY(AS-INACTIVE)(RC1)--->|
| |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
|----NOTIFY(AS-ACTIVE)(RC1)---->|
| |
~ ~
| |
|<----REGISTER REQ(LRCn,RKn)----|
| |
|----REGISTER RESP(LRCn,RCn)--->|
| |
|---NOTIFY(AS-INACTIVE)(RCn)--->|
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|----NOTIFY(AS-ACTIVE)(RCn)---->|
| |
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing
| | Key Id
|----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key
| | RC: Routing Context
|---NOTIFY(AS-INACTIVE)(RC1)--->|
| |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
|----NOTIFY(AS-ACTIVE)(RC1)---->|
| |
~ ~
| |
|<----REGISTER REQ(LRCn,RKn)----|
| |
|----REGISTER RESP(LRCn,RCn)--->|
| |
|---NOTIFY(AS-INACTIVE)(RCn)--->|
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|----NOTIFY(AS-ACTIVE)(RCn)---->|
| |
Note: In the case of an unsuccessful registration attempt (e.g., invalid RKn), the Register Response message will contain an unsuccessful indication, and the ASP will not subsequently send an ASP Active message. Each LRC/RK pair registration is considered independently.
注意：如果注册尝试不成功（例如，无效RKn），则注册响应消息将包含不成功指示，ASP随后不会发送ASP活动消息。每个LRC/RK对注册都是独立考虑的。
It is not necessary to follow a Registration Request/Response message pair with an ASP Active message before sending the next Registration Request. The ASP Active message can be sent at any time after the related successful registration.
在发送下一个注册请求之前，无需在注册请求/响应消息对之后发送ASP活动消息。ASP活动消息可在相关成功注册后随时发送。
5.1.1.4. Single ASP in Multiple Application Servers (each with "1+0" sparing), Dynamic Registration (Case 2 - Single Registration Request)
5.1.1.4. 多个应用服务器中的单个ASP（每个服务器都有“1+0”备用），动态注册（案例2-单个注册请求）
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
| |
|<---REGISTER REQ({LRC1,RK1}, |
| ..., |
| {LRCn,RKn}),--|
| |
|---REGISTER RESP({LRC1,RC1},-->|
| ..., |
| (LRCn,RCn}) |
| |
|--NTFY(AS-INACTIVE)(RC1..RCn)->|
| |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
|----NOTIFY(AS-ACTIVE)(RC1)---->|
| |
: :
: :
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|----NOTIFY(AS-ACTIVE)(RCn)---->|
| |
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
| |
|<---REGISTER REQ({LRC1,RK1}, |
| ..., |
| {LRCn,RKn}),--|
| |
|---REGISTER RESP({LRC1,RC1},-->|
| ..., |
| (LRCn,RCn}) |
| |
|--NTFY(AS-INACTIVE)(RC1..RCn)->|
| |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
|----NOTIFY(AS-ACTIVE)(RC1)---->|
| |
: :
: :
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|----NOTIFY(AS-ACTIVE)(RCn)---->|
| |
Note: In the case of an unsuccessful registration attempt (e.g., Invalid RKn), the Register Response message will contain an unsuccessful indication, and the ASP will not subsequently send an ASP Active message. Each LRC/RK pair registration is considered independently.
注意：如果注册尝试不成功（例如，无效RKn），则注册响应消息将包含不成功指示，ASP随后不会发送ASP活动消息。每个LRC/RK对注册都是独立考虑的。
The ASP Active message can be sent at any time after the related successful registration and may have more than one RC.
ASP活动消息可以在相关成功注册后的任何时间发送，并且可能有多个RC。
This scenario shows example M3UA message flows for the establishment of traffic between an SGP and two ASPs in the same Application Server, where ASP1 is configured to be in the ASP-ACTIVE state and ASP2 is to be a "backup" in the event of communication failure or the withdrawal from service of ASP1. ASP2 may act as a hot, warm, or cold backup, depending on the extent to which ASP1 and ASP2 share call/transaction state or can communicate call state under failure/withdrawal events. The example message flow is the same whether the ASP Active messages indicate "Override", "Loadshare", or "Broadcast" mode, although typically this example would use an Override mode.
此场景显示了用于在同一应用服务器中的一个SGP和两个ASP之间建立流量的示例M3UA消息流，其中ASP1配置为处于ASP-ACTIVE状态，而ASP2将在通信故障或ASP1退出服务时作为“备份”。ASP2可以作为热备份、热备份或冷备份，具体取决于ASP1和ASP2在多大程度上共享呼叫/事务状态，或者在故障/退出事件下可以通信呼叫状态。无论ASP活动消息指示“覆盖”、“加载共享”或“广播”模式，示例消息流都是相同的，尽管此示例通常使用覆盖模式。
SGP ASP1 ASP2
| | |
|<--------ASP Up---------| |
|-------ASP Up Ack------>| |
| | |
|--NOTIFY(AS-INACTIVE)-->| |
| | |
|<----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------>|
| | |
|--------------------------NOTIFY(AS-INACTIVE)----->|
| | |
| | |
|<-------ASP Active------| |
|------ASP Active Ack--->| |
| | |
|---NOTIFY(AS-ACTIVE)--->| |
|--------------------------NOTIFY(AS-ACTIVE)------->|
| | |
SGP ASP1 ASP2
| | |
|<--------ASP Up---------| |
|-------ASP Up Ack------>| |
| | |
|--NOTIFY(AS-INACTIVE)-->| |
| | |
|<----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------>|
| | |
|--------------------------NOTIFY(AS-INACTIVE)----->|
| | |
| | |
|<-------ASP Active------| |
|------ASP Active Ack--->| |
| | |
|---NOTIFY(AS-ACTIVE)--->| |
|--------------------------NOTIFY(AS-ACTIVE)------->|
| | |
5.1.3. Two ASPs in an Application Server ("1+1" Sparing, Loadsharing Case)
5.1.3. 应用服务器中的两个ASP（“1+1”备用，负载共享情况）
This scenario shows a case similar to Section 5.1.2, but where the two ASPs are brought to the state ASP-ACTIVE and subsequently loadshare the traffic. In this case, one ASP is sufficient to handle the total traffic load.
此场景显示了与第5.1.2节类似的情况，但两个ASP处于ASP-ACTIVE状态，随后加载共享流量。在这种情况下，一个ASP足以处理总流量负载。
SGP ASP1 ASP2
| | |
|<---------ASP Up--------| |
|--------ASP Up Ack----->| |
| | |
|--NOTIFY(AS-INACTIVE)-->| |
| | |
|<-----------------------------ASP Up---------------|
|----------------------------ASP Up Ack------------>|
| | |
|--------------------------NOTIFY(AS-INACTIVE)----->|
| | |
|<--ASP Active (Ldshr)---| |
|-----ASP-Active Ack---->| |
| | |
|---NOTIFY (AS-ACTIVE)-->| |
|-----------------------------NOTIFY(AS-ACTIVE)---->|
| | |
|<---------------------------ASP Active (Ldshr)-----|
|------------------------------ASP Active Ack------>|
| | |
SGP ASP1 ASP2
| | |
|<---------ASP Up--------| |
|--------ASP Up Ack----->| |
| | |
|--NOTIFY(AS-INACTIVE)-->| |
| | |
|<-----------------------------ASP Up---------------|
|----------------------------ASP Up Ack------------>|
| | |
|--------------------------NOTIFY(AS-INACTIVE)----->|
| | |
|<--ASP Active (Ldshr)---| |
|-----ASP-Active Ack---->| |
| | |
|---NOTIFY (AS-ACTIVE)-->| |
|-----------------------------NOTIFY(AS-ACTIVE)---->|
| | |
|<---------------------------ASP Active (Ldshr)-----|
|------------------------------ASP Active Ack------>|
| | |
5.1.4. Three ASPs in an Application Server ("n+k" Sparing, Loadsharing Case)
5.1.4. 应用服务器中的三个ASP（“n+k”备用，负载共享情况）
This scenario shows example M3UA message flows for the establishment of traffic between an SGP and three ASPs in the same Application Server, where two of the ASPs are brought to the state ASP-ACTIVE and subsequently share the load. In this case, a minimum of two ASPs are required to handle the total traffic load (2+1 sparing).
此场景显示了用于在同一应用程序服务器中的一个SGP和三个ASP之间建立流量的示例M3UA消息流，其中两个ASP处于ASP-ACTIVE状态，并随后共享负载。在这种情况下，至少需要两个ASP来处理总流量负载（2+1备用）。
SGP ASP1 ASP2 ASP3
| | | |
|<------ASP Up------| | |
|-----ASP Up Ack--->| | |
| | | |
|NTFY(AS-INACTIVE)->| | |
| | | |
|<-------------------------ASP Up-------| |
|------------------------ASP Up Ack---->| |
| | | |
|------------------NOTIFY(AS-INACTIVE)->| |
| | | |
|<--------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack---->|
| | | |
|--------------------------------------NOTIFY(AS-INACTIVE)->|
| | | |
| | | |
|<--ASP Act (Ldshr)-| | |
|----ASP Act Ack--->| | |
| | | |
| | | |
|<-------------------ASP Act. (Ldshr)---| |
|----------------------ASP Act Ack----->| |
| | | |
|--NTFY(AS-ACTIVE)->| | |
|--------------------NOTIFY(AS-ACTIVE)->| |
|----------------------------------------NOTIFY(AS-ACTIVE)->|
| | | |
| | | |
SGP ASP1 ASP2 ASP3
| | | |
|<------ASP Up------| | |
|-----ASP Up Ack--->| | |
| | | |
|NTFY(AS-INACTIVE)->| | |
| | | |
|<-------------------------ASP Up-------| |
|------------------------ASP Up Ack---->| |
| | | |
|------------------NOTIFY(AS-INACTIVE)->| |
| | | |
|<--------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack---->|
| | | |
|--------------------------------------NOTIFY(AS-INACTIVE)->|
| | | |
| | | |
|<--ASP Act (Ldshr)-| | |
|----ASP Act Ack--->| | |
| | | |
| | | |
|<-------------------ASP Act. (Ldshr)---| |
|----------------------ASP Act Ack----->| |
| | | |
|--NTFY(AS-ACTIVE)->| | |
|--------------------NOTIFY(AS-ACTIVE)->| |
|----------------------------------------NOTIFY(AS-ACTIVE)->|
| | | |
| | | |
Following from the example in Section 5.1.2, ASP1 withdraws from service:
根据第5.1.2节中的示例，ASP1退出服务：
SGP ASP1 ASP2
| | |
|<-----ASP Inactive------| |
|----ASP Inactive Ack--->| |
| | |
|----NTFY(AS-PENDING)--->| |
|-----------------------NTFY(AS-PENDING)----------->|
| | |
|<----------------------------- ASP Active----------|
|-----------------------------ASP Active Ack------->|
| | |
|----NTFY(AS-ACTIVE)---->| |
|-----------------------NTFY(AS-ACTIVE)------------>|
SGP ASP1 ASP2
| | |
|<-----ASP Inactive------| |
|----ASP Inactive Ack--->| |
| | |
|----NTFY(AS-PENDING)--->| |
|-----------------------NTFY(AS-PENDING)----------->|
| | |
|<----------------------------- ASP Active----------|
|-----------------------------ASP Active Ack------->|
| | |
|----NTFY(AS-ACTIVE)---->| |
|-----------------------NTFY(AS-ACTIVE)------------>|
Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur.
注意：如果SGP M3UA层检测到M3UA对等节点丢失（例如，M3UA心跳丢失或检测到SCTP故障），则不会发生初始ASP非活动消息交换（即，SGP到ASP1）。
Following on from the example in Section 5.1.2, ASP2 wishes to Override ASP1 and take over the traffic:
根据第5.1.2节中的示例，ASP2希望覆盖ASP1并接管流量：
SGP ASP1 ASP2
| | |
|<----------------------------- ASP Active----------|
|------------------------------ASP Active Ack------>|
|----NTFY(Alt ASP-Act)-->| |
| | |
SGP ASP1 ASP2
| | |
|<----------------------------- ASP Active----------|
|------------------------------ASP Active Ack------>|
|----NTFY(Alt ASP-Act)-->| |
| | |
Following from the example in Section 5.1.4, ASP1 withdraws from service:
根据第5.1.4节中的示例，ASP1退出服务：
SGP ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.----| | |
|---ASP Inact Ack-->| | |
| | | |
|--NTFY(Ins. ASPs)->| | |
|---------------------------------------NOTIFY(Ins. ASPs)-->|
| | | |
| | | |
|<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->|
| | | |
|-NTFY(AS-ACTIVE)-->| | |
|-------------------NOTIFY(AS-ACTIVE)-->| |
|---------------------------------------NOTIFY(AS-ACTIVE)-->|
| | | |
| | | |
SGP ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.----| | |
|---ASP Inact Ack-->| | |
| | | |
|--NTFY(Ins. ASPs)->| | |
|---------------------------------------NOTIFY(Ins. ASPs)-->|
| | | |
| | | |
|<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->|
| | | |
|-NTFY(AS-ACTIVE)-->| | |
|-------------------NOTIFY(AS-ACTIVE)-->| |
|---------------------------------------NOTIFY(AS-ACTIVE)-->|
| | | |
| | | |
For the Notify message to be sent, the SG maintains knowledge of the minimum ASP resources required (e.g., if the SG knows that "n+k" = "2+1" for a Loadshare AS and "n" currently equals "1").
对于要发送的通知消息，SG保持对所需最小ASP资源的了解（例如，如果SG知道Loadshare AS的“n+k”=“2+1”和“n”当前等于“1”）。
Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP-ASP1) would not occur.
注意：如果SGP检测到ASP1 M3UA对等丢失（例如，M3UA心跳丢失或检测到SCTP故障），则不会发生初始ASP非活动消息交换（即SGP-ASP1）。
5.3. Normal Withdrawal of an ASP from an Application Server and Teardown of an Association
5.3. ASP从应用程序服务器的正常退出和关联的解除
An ASP that is now confirmed in the state ASP-INACTIVE (i.e., the ASP has received an ASP Inactive Ack message) may now proceed to the ASP-DOWN state, if it is to be removed from service. Following from Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" state:
现在确认处于ASP-INACTIVE状态（即，ASP已收到ASP INACTIVE Ack消息）的ASP现在可以进入ASP-DOWN状态（如果要将其从服务中删除）。根据第5.2.1节或第5.2.3节，其中ASP1已移动到“非活动”状态：
SGP ASP1
| |
|<-----ASP Inactive (RCn)------| RC: Routing Context
|----ASP Inactive Ack (RCn)--->|
| |
|<-----DEREGISTER REQ(RCn)-----| See Notes
| |
|---DEREGISTER RESP(LRCn,RCn)->|
| |
: :
| |
|<-----------ASP Down----------|
|---------ASP Down Ack-------->|
| |
SGP ASP1
| |
|<-----ASP Inactive (RCn)------| RC: Routing Context
|----ASP Inactive Ack (RCn)--->|
| |
|<-----DEREGISTER REQ(RCn)-----| See Notes
| |
|---DEREGISTER RESP(LRCn,RCn)->|
| |
: :
| |
|<-----------ASP Down----------|
|---------ASP Down Ack-------->|
| |
Note: The Deregistration procedure will typically be used if the ASP previously used the Registration procedures for configuration within the Application Server. ASP Inactive and Deregister messages exchanges may contain multiple Routing Contexts.
注意：如果ASP以前在应用程序服务器内使用注册过程进行配置，则通常会使用注销过程。ASP非活动和注销消息交换可能包含多个路由上下文。
The ASP should be in the ASP-INACTIVE state and should have deregistered in all its Routing Contexts before attempting to move to the ASP-DOWN state.
ASP应处于ASP-INACTIVE状态，并且在尝试移动到ASP-DOWN状态之前，应在其所有路由上下文中取消注册。
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(0) -------- |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(0) -------- |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(2) -------- |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(2) -------- |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DUNA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DUNA ---------- |
This section describes the primitive mapping between the MTP3 User and the M3UA layer at an ASP.
本节描述了MTP3用户与ASP.NET上的M3UA层之间的基本映射。
When the MTP3-User on the ASP has data to send to a remote MTP3-User, it uses the MTP-TRANSFER request primitive. The M3UA layer at the ASP will do the following when it receives an MTP-TRANSFER request primitive from the M3UA user:
当ASP上的MTP3用户有数据要发送给远程MTP3用户时，它将使用MTP-TRANSFER request原语。ASP的M3UA层在从M3UA用户接收MTP-TRANSFER request原语时将执行以下操作：
- Determine the correct SGP.
- 确定正确的SGP。
- Determine the correct association to the chosen SGP.
- 确定与所选SGP的正确关联。
- Determine the correct stream in the association (e.g., based on SLS).
- 确定关联中的正确流（例如，基于SLS）。
- Determine whether to complete the optional fields of the DATA message.
- 要确定是否完成消息的可选数据字段。
- Map the MTP-TRANSFER request primitive into the Protocol Data field of a DATA message.
- 将MTP-TRANSFER请求原语映射到数据消息的协议数据字段中。
- Send the DATA message to the remote M3UA peer at the SGP, over the SCTP association.
- 通过SCTP关联将数据消息发送到SGP的远程M3UA对等方。
SGP ASP
| |
|<-----DATA Message-------|<--MTP-TRANSFER req.
| |
SGP ASP
| |
|<-----DATA Message-------|<--MTP-TRANSFER req.
| |
When the M3UA layer on the ASP receives a DATA message from the M3UA peer at the remote SGP, it will do the following:
当ASP上的M3UA层从远程SGP的M3UA对等方接收到数据消息时，它将执行以下操作：
- Evaluate the optional fields of the DATA message, if present.
- 评估数据消息的可选字段（如果存在）。
- Map the Protocol Data field of a DATA message into the MTP-TRANSFER indication primitive.
- 将数据消息的协议数据字段映射到MTP-TRANSFER指示原语中。
- Pass the MTP-TRANSFER indication primitive to the user part. In case of multiple user parts, the optional fields of the Data message are used to determine the concerned user part.
- 将MTP传输指示原语传递给用户部件。如果有多个用户部件，数据消息的可选字段用于确定相关的用户部件。
SGP ASP
| |
|------Data Message------>|-->MTP-Transfer ind.
| |
SGP ASP
| |
|------Data Message------>|-->MTP-Transfer ind.
| |
There are situations such as temporary loss of connectivity to the SGP that may cause the M3UA layer at the ASP to audit SS7 destination availability/congestion states. Note: there is no primitive for the MTP3-User to request this audit from the M3UA layer, as this is initiated by an internal M3UA management function.
存在与SGP的连接暂时中断等情况，可能导致ASP处的M3UA层审核SS7目标可用性/拥塞状态。注意：MTP3用户没有从M3UA层请求此审核的原语，因为这是由内部M3UA管理功能启动的。
SGP ASP
| |
|<----------DAUD-----------|
|<----------DAUD-----------|
|<----------DAUD-----------|
| |
| |
SGP ASP
| |
|<----------DAUD-----------|
|<----------DAUD-----------|
|<----------DAUD-----------|
| |
| |
This section describes the primitive mapping between the MTP3-User and the M3UA layer at an SGP.
本节描述了MTP3用户与SGP上的M3UA层之间的基本映射。
When the M3UA layer at the SGP has received DATA messages from its peer destined to the SS7 network, it will do the following:
当SGP的M3UA层从其目的地为SS7网络的对等方接收到数据消息时，它将执行以下操作：
- Evaluate the optional fields of the DATA message, if present, to determine the Network Appearance.
- 评估数据消息的可选字段（如果存在），以确定网络外观。
- Map the Protocol data field of the DATA message into an MTP-TRANSFER request primitive.
- 将数据消息的协议数据字段映射到MTP-TRANSFER请求原语中。
- Pass the MTP-TRANSFER request primitive to the MTP3 of the concerned Network Appearance.
- 将MTP-TRANSFER request原语传递给相关网络外观的MTP3。
SGP ASP
| |
<---MTP-TRANSFER req.|<---------DATA -----------|
| |
SGP ASP
| |
<---MTP-TRANSFER req.|<---------DATA -----------|
| |
When the MTP3 layer at the SGP has data to pass its user parts, it will use the MTP-TRANSFER indication primitive. The M3UA layer at the SGP will do the following when it receives an MTP-TRANSFER indication primitive:
当SGP的MTP3层有数据通过其用户部件时，它将使用MTP-TRANSFER指示原语。SGP的M3UA层在收到MTP-TRANSFER指示原语时将执行以下操作：
- Determine the correct AS, using the distribution function;
- 使用分布函数确定正确的AS；
- Select an ASP in the ASP-ACTIVE state.
- 选择处于ASP-ACTIVE状态的ASP。
- Determine the correct association to the chosen ASP.
- 确定与所选ASP的正确关联。
- Determine the correct stream in the SCTP association (e.g., based on SLS).
- 确定SCTP关联中的正确流（例如，基于SLS）。
- Determine whether to complete the optional fields of the DATA message.
- 要确定是否完成消息的可选数据字段。
- Map the MTP-TRANSFER indication primitive into the Protocol Data field of a DATA message.
- 将MTP传输指示原语映射到数据消息的协议数据字段中。
- Send the DATA message to the remote M3UA peer in the ASP, over the SCTP association.
- 通过SCTP关联向ASP中的远程M3UA对等方发送数据消息。
SGP ASP
| |
--MTP-TRANSFER ind.->|-----------DATA --------->|
| |
SGP ASP
| |
--MTP-TRANSFER ind.->|-----------DATA --------->|
| |
5.5.2.3. Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication Primitives
5.5.2.3. 支持MTP暂停、MTP恢复、MTP状态指示原语
The MTP-PAUSE, MTP-RESUME, and MTP-STATUS indication primitives from the MTP3 upper layer interface at the SGP need to be made available to the remote MTP3 User Part lower-layer interface at the concerned ASP(s).
来自SGP的MTP3上层接口的MTP-PAUSE、MTP-RESUME和MTP-STATUS指示原语需要可用于相关ASP的远程MTP3用户部件下层接口。
The MTP3 layer at the SGP will generate an MTP-PAUSE indication primitive when it determines locally that an SS7 destination is unreachable. The M3UA layer will map this primitive to a DUNA
当SGP的MTP3层在本地确定无法到达SS7目的地时，它将生成MTP-PAUSE指示原语。M3UA层将此基本体映射到DUNA
message. The SGP M3UA layer determines the set of concerned ASPs to be informed based on internal SS7 network information associated with the MTP-PAUSE indication primitive indication.
消息SGP M3UA层根据与MTP-PAUSE指示原语相关的内部SS7网络信息确定要通知的相关ASP集。
SGP ASP
| |
--MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.-->
| |
5.5.2.3.2. Destination Available
SGP ASP
| |
--MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.-->
| |
5.5.2.3.2. Destination Available
The MTP3 at the SGP will generate an MTP-RESUME indication primitive when it determines locally that an SS7 destination that was previously unreachable is now reachable. The M3UA layer will map this primitive to a DAVA message. The SGP M3UA determines the set of concerned ASPs to be informed based on internal SS7 network information associated with the MTP-RESUME indication primitive.
当SGP的MTP3在本地确定以前无法到达的SS7目的地现在可以到达时，它将生成MTP-RESUME指示原语。M3UA层将此原语映射到DAVA消息。SGP M3UA根据与MTP-RESUME指示原语相关的内部SS7网络信息确定要通知的相关ASP集。
SGP ASP
| |
--MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.-->
| |
SGP ASP
| |
--MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.-->
| |
The MTP3 layer at the SGP will generate an MTP-STATUS indication primitive when it determines locally that the route to an SS7 destination is congested. The M3UA layer will map this primitive to a SCON message. It will determine which ASP(s) to send the SCON message to, based on the intended Application Server.
当SGP的MTP3层在本地确定到SS7目的地的路由拥塞时，它将生成MTP-STATUS指示原语。M3UA层将此原语映射到SCON消息。它将根据预期的应用程序服务器确定要向哪个ASP发送SCON消息。
SGP ASP
| |
--MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.-->
| |
SGP ASP
| |
--MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.-->
| |
The MTP3 layer at the SGP will generate an MTP-STATUS indication primitive when it receives an UPU message from the SS7 network. The M3UA layer will map this primitive to a DUPU message. It will determine which ASP(s) to send the DUPU to based on the intended Application Server.
SGP的MTP3层在从SS7网络接收UPU消息时将生成MTP状态指示原语。M3UA层将此原语映射到DUPU消息。它将根据预期的应用程序服务器确定将DUPU发送到哪个ASP。
SGP ASP
| |
--MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
| |
SGP ASP
| |
--MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
| |
These scenarios show a basic example for IPSP communication for the three phases of the connection (establishment, data exchange, disconnection). It is assumed that the SCTP association is already set up. Both single exchange and double exchange behavior are included for illustrative purposes.
这些场景显示了连接三个阶段（建立、数据交换、断开）的IPSP通信的基本示例。假定已建立SCTP关联。出于说明目的，包括单交换和双交换行为。
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context is previously agreed to be the same in both directions.
路由上下文先前被认为在两个方向上是相同的。
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
In this approach, only one single exchange of ASP Up message can be considered sufficient since the response by the other peer can be considered a notice that it is in ASP_UP state.
在这种方法中，只有一次ASP Up消息交换就足够了，因为另一个对等方的响应可以被视为处于ASP_Up状态的通知。
For the same reason, only one ASP Down message is needed, since once an IPSP receives ASP_Down ack message it is itself considered to be in the ASP_Down state and not allowed to receive ASPSM messages.
出于同样的原因，只需要一条ASP Down消息，因为一旦IPSP收到ASP_Down ack消息，它本身就被认为处于ASP_Down状态，不允许接收ASPSM消息。
Implementations MUST follow the normative guidance of RFC3788 [11] on the integration and usage of security mechanisms in SIGTRAN protocols.
实施必须遵循RFC3788[11]关于SIGTRAN协议中安全机制的集成和使用的规范指南。
This document contains no new actions for IANA. The subsections below are retained for historical purposes.
本文档不包含IANA的新操作。以下各小节保留用于历史目的。
IANA has assigned an M3UA value for the Payload Protocol Identifier in the SCTP DATA chunk. The following SCTP Payload Protocol Identifier has been registered:
IANA已为SCTP数据块中的有效负载协议标识符分配了一个M3UA值。已注册以下SCTP有效负载协议标识符：
M3UA "3"
M3UA“3”
The SCTP Payload Protocol Identifier value "3" SHOULD be included in each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA protocol. The value "0" (unspecified) is also allowed but any other values MUST not be used. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a DATA chunk.
SCTP有效负载协议标识符值“3”应包含在每个SCTP数据块中，以指示SCTP正在承载M3UA协议。也允许使用值“0”（未指定），但不得使用任何其他值。此有效负载协议标识符不直接由SCTP使用，但可由某些网络实体用于标识数据块中承载的信息类型。
The User Adaptation peer MAY use the Payload Protocol Identifier as a way of determining additional information about the data being presented to it by SCTP.
用户适配对等方可以使用有效负载协议标识符作为确定关于由SCTP呈现给它的数据的附加信息的方式。
IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It is recommended that SGPs use this SCTP port number for listening for new connections. SGPs MAY also use statically configured SCTP port numbers instead.
IANA已为M3UA注册了SCTP（和UDP/TCP）端口号2905。建议SGP使用此SCTP端口号侦听新连接。SGP也可以使用静态配置的SCTP端口号。
This protocol may also be extended through IANA in three ways:
本协议也可通过IANA以三种方式扩展：
- Through definition of additional message classes. - Through definition of additional message types. - Through definition of additional message parameters.
- 通过定义其他消息类。-通过定义其他消息类型。-通过定义附加的消息参数。
The definition and use of new message classes, types, and parameters is an integral part of SIGTRAN adaptation layers. Thus, these extensions are assigned by IANA through an IETF Consensus action as defined in Guidelines for Writing an IANA Considerations Section in RFCs [23].
新消息类、类型和参数的定义和使用是SIGTRAN适配层不可分割的一部分。因此，这些扩展由IANA通过IETF协商一致行动分配，如RFCs[23]中编写IANA注意事项部分的指南所定义。
The proposed extension must in no way adversely affect the general working of the protocol.
拟议的延期决不能对议定书的一般工作产生不利影响。
The documentation for a new message class MUST include the following information:
新消息类的文档必须包括以下信息：
(a) A long and short name for the new message class. (b) A detailed description of the purpose of the message class.
(a) 新消息类的长名称和短名称。（b） 消息类用途的详细说明。
The documentation for a new message type MUST include the following information:
新消息类型的文档必须包括以下信息：
(a) A long and short name for the new message type. (b) A detailed description of the structure of the message. (c) A detailed definition and description of intended use for each field within the message. (d) A detailed procedural description of the use of the new message type within the operation of the protocol. (e) A detailed description of error conditions when receiving this message type.
(a) 新消息类型的长名称和短名称。（b） 对消息结构的详细描述。（c） 消息中每个字段的详细定义和预期用途说明。（d） 协议操作中使用新消息类型的详细过程描述。（e） 接收此消息类型时错误情况的详细说明。
When an implementation receives a message type that it does not support, it MUST respond with an Error (ERR) message ("Unsupported Message Type").
当实现接收到不支持的消息类型时，它必须以错误（ERR）消息（“不支持的消息类型”）进行响应。
Documentation of the message parameter MUST contain the following information:
消息参数的文档必须包含以下信息：
(a) Name of the parameter type. (b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2. (c) Detailed definition of each component of the parameter value. (d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same message.
(a) 参数类型的名称。（b） 参数字段结构的详细说明。该结构必须符合第3.2节所述的通用类型长度值格式。（c） 参数值的每个组件的详细定义。（d） 此参数类型的预期用途的详细说明，以及是否以及在何种情况下可在同一消息中找到此参数类型的多个实例的指示。
The authors would like to thank Antonio Roque Alvarez, Joyce Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Antonio Canete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal
作者要感谢安东尼奥·罗克·阿尔瓦雷斯、乔伊斯·阿奇博尔德、托尔加·阿斯维伦、玛丽亚·克鲁斯·巴托洛姆·罗德里戈、丹·布伦德斯、安东尼奥·卡内特、尼基尔·贾恩、罗兰·杰斯克、乔·凯勒、库尔特·凯特、林明、史蒂夫·洛鲁索、纳奥托·马金奈、霍华德·梅、弗朗索瓦·莫伊劳德、巴里·纳格尔伯格、尼尔·奥尔森、海因茨·普兰特纳、沙马尔
Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo Watanabe, Ben Wilson, and many others for their valuable comments and suggestions.
Prasad、Mukesh Punhani、Selvam Rengasami、John Schantz、Ray Singh、Michael Tuexen、Nitin Tomar、Gery Verwimp、Tim Vetter、渡边和夫、Ben Wilson和许多其他人的宝贵意见和建议。
Ian Rytina - Ericsson Guy Mousseau - Nortel Networks Lyndon Ong - Ciena Hanns Juergen Schwarzbauer - Siemens Klaus Gradischnig - Detecon Inc. Mallesh Kalla - Telcordia Normand Glaude - Performance Technologies Brian Bidulock - OpenSS7 John Loughney - Nokia Greg Sidebottom - Signatus Technologies
Ian Rytina-爱立信Guy Mousseau-北电网络Lyndon Ong-Ciena Hanns Juergen Schwarzbauer-西门子Klaus Gradischnig-Detecon Inc.Mallesh Kalla-Telcordia Normand Glaude-性能技术部Brian Bidulock-OpenSS7 John Loughney-诺基亚Greg Sidebottom-Signatus Technologies
[1] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 (SS7) - ISDN User Part (ISUP)"
[1] ITU-T建议Q.761至Q.767，“第7号信令系统（SS7）-ISDN用户部分（ISUP）”
[2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[2] ANSI T1.113-“7号信号系统-ISDN用户部分”
[3] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services"
[3] ETSI ETS 300 356-1“综合业务数字网（ISDN）.第7号信令系统.国际接口用ISDN用户部分（ISUP）第2版.第1部分：基本业务”
[4] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7 (SS7) - Signalling Connection Control Part (SCCP)"
[4] ITU-T建议Q.711至Q.715，“第7号信令系统（SS7）-信令连接控制部分（SCCP）”
[5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection Control Part"
[5] ANSI T1.112“7号信号系统-信号连接控制部分”
[6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Signalling Connection Control Part (SCCP) (connectionless and connection-oriented class 2) to support international interconnection; Part 1: Protocol specification"
[6] ETSI ETS 300 009-1，“综合业务数字网（ISDN）.第7号信令系统.支持国际互连的信令连接控制部分（SCCP）（无连接和面向连接的2级）.第1部分：协议规范”
[7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7 (SS7) - Message Transfer Part (MTP)"
[7] ITU-T建议Q.700至Q.705，“第7号信令系统（SS7）-消息传输部分（MTP）”
[8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
[8] ANSI T1.111“7号信号系统-信息传输部分”
[9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer Part (MTP) to support international interconnection; Part 1: Protocol specification"
[9] ETSI ETS 300 008-1，“综合业务数字网（ISDN）.第7号信令系统.支持国际互连的报文传输部分（MTP）.第1部分：协议规范”
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[10] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[11] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, June 2004.
[11] Loughney，J.，Tuexen，M.，和J.Pastor Balbas，“信号传输（SIGTRAN）协议的安全考虑”，RFC 3788，2004年6月。
[12] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[12] Ong，L.，Rytina，I.，Garcia，M.，Schwarzbauer，H.，Coene，L.，Lin，H.，Juhasz，I.，Holdrege，M.，和C.Sharp，“信号传输的框架架构”，RFC 2719，1999年10月。
[13] ITU-T Recommendation Q.720, "Telephone User Part"
[13] ITU-T建议Q.720，“电话用户部分”
[14] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7) - Transaction Capabilities (TCAP)"
[14] ITU-T建议Q.771至Q.775“第7号信令系统（SS7）-事务处理能力（TCAP）”
[15] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities Application Part"
[15] ANSI T1.114“7号信号系统-交易能力应用部分”
[16] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification"
[16] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification"
[17] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd Generation partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface: General Aspects and Principles"
[17] 3G TS 25.410 V4.0.0（2001-04）“技术规范-第三代合作伙伴关系项目；技术规范组无线接入网；UTRAN Iu接口：一般方面和原则”
[18] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[18] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[19] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - Service Specific Coordination Function for signalling at the Network Node Interface (SSCF at NNI)"
[19] ITU-T建议Q.2140“B-ISDN ATM适配层-网络节点接口信令的特定服务协调功能（NNI的SSCF）”
[20] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP)"
[20] ITU-T建议Q.2110“B-ISDN ATM适配层-特定于服务的面向连接协议（SSCOP）”
[21] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[21] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[22] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 functions and messages using the services of ITU Recommendation Q.2140"
[22] ITU-T建议Q.2210“使用ITU建议Q.2140服务的报文传输第3级功能和报文”
[23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[23] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[24] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J. Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", RFC 3331, September 2002.
[24] Morneault，K.，Dantu，R.，Sidebottom，G.，Bidulock，B.，和J.Heitz，“信令系统7（SS7）消息传输第2部分（MTP2）-用户适配层”，RFC 33312002年9月。
[25] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H., and K. Morneault, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)", RFC 4165, September 2005.
[25] George，T.，Bidulock，B.，Dantu，R.，Schwarzbauer，H.，和K.Morneault，“信令系统7（SS7）消息传输第2部分（MTP2）-用户对等适配层（M2PA）”，RFC 41652005年9月。
[26] Telecommunication Technology Committee (TTC) Standard JT-Q704, "Message Transfer Part Signaling Network Functions", April 28, 1992.
[26] 电信技术委员会（TTC）标准JT-Q704，“信息传输部分信令网络功能”，1992年4月28日。
A Signalling Gateway is used to support the transport of MTP3-User signalling traffic received from the SS7 network to multiple distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA protocol is not designed to meet the performance and reliability requirements for such transport by itself. However, the conjunction of distributed architecture and redundant networks provides support for reliable transport of signalling traffic over IP. The M3UA protocol is flexible enough to allow its operation and management in a variety of physical configurations, enabling Network Operators to meet their performance and reliability requirements.
信令网关用于支持将从SS7网络接收的MTP3用户信令流量传输到多个分布式ASP（例如MGC和IP数据库）。显然，M3UA协议本身并不能满足此类传输的性能和可靠性要求。然而，分布式体系结构和冗余网络的结合为IP上信令业务的可靠传输提供了支持。M3UA协议足够灵活，允许在各种物理配置中进行操作和管理，使网络运营商能够满足其性能和可靠性要求。
To meet the stringent SS7 signalling reliability and performance requirements for carrier grade networks, Network Operators might require that no single point of failure is present in the end-to-end network architecture between an SS7 node and an IP-based application. This can typically be achieved through the use of redundant SGPs or SGs, redundant hosts, and the provision of redundant QOS-bounded IP network paths for SCTP Associations between SCTP End Points. Obviously, the reliability of the SG, the MGC, and other IP-based functional elements also needs to be taken into account. The distribution of ASPs and SGPs within the available Hosts MAY also be considered. As an example, for a particular Application Server, the related ASPs could be distributed over at least two Hosts.
为了满足运营商级网络严格的SS7信令可靠性和性能要求，网络运营商可能要求在SS7节点和基于IP的应用程序之间的端到端网络架构中不存在单点故障。这通常可以通过使用冗余SGP或SGs、冗余主机以及为SCTP端点之间的SCTP关联提供冗余QOS受限IP网络路径来实现。显然，还需要考虑SG、MGC和其他基于IP的功能元件的可靠性。还可以考虑在可用主机内分配ASP和SGP。例如，对于特定的应用服务器，相关的ASP可以分布在至少两台主机上。
One example of a physical network architecture relevant to SS7 carrier grade operation in the IP network domain is shown in Figure A-1, below:
与IP网络域中的SS7载波级操作相关的物理网络架构的一个示例如图a-1所示，如下所示：
SGs MGCs
SGs MGCs
Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * =
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * =
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
SGP1.1 and SGP1.2 are part of SG1 SGP2.1 and SGP2.2 are part of SG2
SGP1.1和SGP1.2是SG1的一部分SGP2.1和SGP2.2是SG2的一部分
Figure A-1 - Physical Model
图A-1-物理模型
In this model, each host may have many application processes. In the case of the MGC, an ASP may provide service to one or more Application Servers, and is identified as an SCTP end point. One or more Signalling Gateway Processes make up a single Signalling Gateway.
在此模型中，每个主机可能有许多应用程序进程。在MGC的情况下，ASP可以向一个或多个应用服务器提供服务，并且被标识为SCTP端点。一个或多个信令网关进程构成单个信令网关。
This example model can also be applied to IPSP-IPSP signalling. In this case, each IPSP may have its services distributed across 2 or more hosts, and may have multiple server processes on each host.
该示例模型也可应用于IPSP-IPSP信令。在这种情况下，每个IPSP的服务可能分布在2个或多个主机上，并且每个主机上可能有多个服务器进程。
In the example above, each signalling process (SGP, ASP, or IPSP) is the end point to more than one SCTP association, leading to more than one other signalling processes. To support this, a signalling process must be able to support distribution of M3UA messages to many simultaneous active associations. This message distribution function
在上面的示例中，每个信令过程（SGP、ASP或IPSP）是多个SCTP关联的端点，导致多个其他信令过程。为了支持这一点，信令过程必须能够支持将M3UA消息分发给多个同时活动的关联。此消息分发功能
is based on the status of provisioned Routing Keys, the status of the signalling routes to signalling points in the SS7 network, and the redundancy model (active-standby, load sharing, broadcast, n+k) of the remote signalling processes.
基于已配置路由密钥的状态、到SS7网络中的信令点的信令路由的状态以及远程信令过程的冗余模型（主备、负载共享、广播、n+k）。
For carrier grade networks, the failure or isolation of a particular signalling process should not cause stable calls or transactions to be lost. This implies that signalling processes need, in some cases, to share the call/transaction state or be able to pass the call state information between each other. In the case of ASPs performing call processing, coordination may also be required with the related Media Gateway to transfer the MGC control for a particular trunk termination. However, this sharing or communication of call/transaction state information is outside the scope of this document.
对于载波级网络，特定信令过程的故障或隔离不应导致稳定呼叫或事务丢失。这意味着在某些情况下，信令进程需要共享呼叫/事务状态或能够在彼此之间传递呼叫状态信息。在ASPs执行呼叫处理的情况下，还可能需要与相关媒体网关进行协调，以传输特定中继终端的MGC控制。但是，呼叫/事务状态信息的共享或通信不在本文档范围内。
This model serves as an example. M3UA imposes no restrictions as to the exact layout of the network elements, the message distribution algorithms, and the distribution of the signalling processes. Instead, it provides a framework and a set of messages that allow for a flexible and scalable signalling network architecture, aiming to provide reliability and performance.
这个模型就是一个例子。M3UA对网元的精确布局、消息分发算法和信令进程的分发没有任何限制。相反，它提供了一个框架和一组消息，允许灵活和可扩展的信令网络体系结构，旨在提供可靠性和性能。
At the SGP, an Application Server list contains active and inactive ASPs to support ASP broadcast, loadsharing, and failover procedures. The list of ASPs within a logical Application Server is kept updated in the SGP to reflect the active Application Server Process(es).
在SGP中，应用程序服务器列表包含活动和非活动的ASP，以支持ASP广播、负载共享和故障切换过程。逻辑应用程序服务器中的ASP列表在SGP中保持更新，以反映活动的应用程序服务器进程。
For example, in the network shown in Figure 1, all messages to DPC x could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1 in Host 1 might look like the following:
例如，在图1所示的网络中，发送到DPC x的所有消息都可以发送到Host3中的ASP1或Host4中的ASP1。主机1中SGP1处的AS列表可能如下所示：
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Inactive
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Inactive
In this "1+1" redundancy case, ASP1 in Host3 would be sent any incoming message with DPC=x. ASP1 in Host4 would normally be brought to the "active" state upon failure of, or loss of connectivity to, ASP1/Host1.
在这种“1+1”冗余情况下，主机3中的ASP1将被发送任何DPC=x的传入消息。当ASP1/Host1发生故障或失去与ASP1/Host1的连接时，Host4中的ASP1通常会进入“活动”状态。
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
主机1中SGP1处的AS列表也可以在loadshare模式下设置：
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Active
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Active
In this case, both the ASPs would be sent a portion of the traffic. For example, the two ASPs could together form a database, where incoming queries may be sent to any active ASP.
在这种情况下，两个ASP都将被发送一部分流量。例如，这两个ASP可以一起构成一个数据库，其中传入的查询可以发送到任何活动的ASP。
Care might need to be exercised by a Network Operator in the selection of the routing information to be used as the Routing Key for a particular AS.
网络运营商在选择用作特定as的路由密钥的路由信息时可能需要小心。
In the process of failover, it is recommended that, in the case of ASPs supporting call processing, stable calls do not fail. It is possible that calls in "transition" may fail, although measures of communication between the ASPs involved can be used to mitigate this.
在故障切换过程中，建议在ASP支持呼叫处理的情况下，稳定呼叫不要失败。“转换”中的调用可能会失败，尽管可以使用相关ASP之间的通信措施来缓解这种情况。
For example, the two ASPs may share call state via shared memory, or may use an ASP to ASP protocol to pass call state information. Any ASP-to-ASP protocol to support this function is outside the scope of this document.
例如，两个ASP可以通过共享内存共享呼叫状态，或者可以使用ASP-to-ASP协议传递呼叫状态信息。任何支持此功能的ASP到ASP协议都不在本文档的范围内。
Signalling Gateways may also be distributed over multiple hosts. Much like the AS model, SGs may comprise one or more SG Processes (SGPs), distributed over one or more hosts, using an active/backup or a loadsharing model. Should an SGP lose all or partial SS7 connectivity and other SGPs exist, the SGP may terminate the SCTP associations to the concerned ASPs.
信令网关也可以分布在多个主机上。与AS模型非常相似，SGs可以包括一个或多个SG进程（SGP），使用主动/备份或负载共享模型分布在一个或多个主机上。如果存在到所有其他SGP的部分SGP或ASPP连接，则可能会终止到所有其他SGP的连接。
It is therefore possible for an ASP to route signalling messages destined to the SS7 network using more than one SGP. In this model, a Signalling Gateway is deployed as a cluster of hosts acting as a single SG. A primary/backup redundancy model is possible, where the unavailability of the SCTP association to a primary SGP could be used to reroute affected traffic to an alternate SGP. A loadsharing model is possible, where the signalling messages are loadshared between multiple SGPs. A broadcast model is also possible, where signalling messages are sent to each active SGP in the SG. The distribution of the MTP3-user messages over the SGPs should be done in such a way to minimize message missequencing, as required by the SS7 User Parts.
因此，ASP可以使用多个SGP路由发往SS7网络的信令消息。在该模型中，信令网关被部署为充当单个SG的主机集群。主/备份冗余模型是可能的，其中SCTP关联到主SGP的不可用性可用于将受影响的流量重新路由到备用SGP。负载共享模型是可能的，其中信令消息在多个SGP之间进行负载共享。广播模型也是可能的，其中信令消息被发送到SG中的每个活动SGP。应按照SS7用户部件的要求，通过SGP分发MTP3用户消息，以尽量减少消息失序。
It may also be possible for an ASP to use more than one SG to access a specific SS7 end point, in a model that resembles an SS7 STP mated pair. Typically, SS7 STPs are deployed in mated pairs, with traffic loadshared between them. Other models are also possible, subject to the limitations of the local SS7 network provisioning guidelines.
在类似于SS7 STP配对的模型中，ASP也可能使用多个SG访问特定的SS7端点。通常，SS7 STP成对部署，并在它们之间共享流量负载。根据本地SS7网络供应指南的限制，也可以使用其他型号。
From the perspective of the M3UA layer at an ASP, a particular SG is capable of transferring traffic to a provisioned SS7 destination X if an SCTP association with at least one SGP of the SG is established, the SGP has returned an acknowledgement to the ASP to indicate that the ASP is actively handling traffic for that destination X, the SGP has not indicated that the destination X is inaccessible, and the SGP has not indicated MTP Restart. When an ASP is configured to use multiple SGPs for transferring traffic to the SS7 network, the ASP must maintain knowledge of the current capability of the SGPs to handle traffic to destinations of interest. This information is crucial to the overall reliability of the service, for active/backup, loadsharing, and broadcast models, in the event of failures and recovery and maintenance activities. The ASP M3UA may also use this information for congestion avoidance purposes. The distribution of the MTP3-user messages over the SGPs should be done in such a way as to minimize message missequencing, as required by the SS7 User Parts.
从ASP处的M3UA层的角度来看，特定SG能够将通信量传输到配置的SS7目的地X。如果与SG的至少一个SGP建立了SCTP关联，则SGP已向ASP返回确认，以指示ASP正在积极处理该目的地X的通信量，SGP未指示目标X不可访问，且SGP未指示MTP重新启动。当ASP配置为使用多个SGP将流量传输到SS7网络时，ASP必须了解SGP处理到感兴趣目的地的流量的当前能力。对于主动/备份、负载共享和广播模式，在发生故障以及恢复和维护活动时，此信息对于服务的整体可靠性至关重要。ASP M3UA也可将此信息用于避免拥塞。根据SS7用户部件的要求，通过SGP分发MTP3用户消息的方式应尽量减少消息失序。
Editors' Addresses
编辑地址
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA, USA 20171
Ken Morneault Cisco Systems Inc.美国弗吉尼亚州赫恩顿杜勒斯技术大道13615号，邮编20171
EMail: kmorneau@cisco.com
EMail: kmorneau@cisco.com
Javier Pastor-Balbas Ericsson Espana S.A. C/ Retama 1 28045 Madrid - Spain
西班牙马德里哈维尔·帕斯托尔·巴尔巴斯·爱立信西班牙公司C/Retama 12845
EMail: j.javier.pastor@ericsson.com
EMail: j.javier.pastor@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。