[要約] 要約： RFC 4666は、SS7のMTP3とM3UAに関する仕様を定義しています。 目的： M3UAは、IPネットワーク上でSS7メッセージを転送するためのプロトコルであり、異なるネットワーク間の相互接続を可能にします。
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)
Signaling System 7（SS7）Message Transfer Part 3（MTP3）-User Adaptation Layer（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).
Copyright（C）The Internet Society（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-Userピアのシームレスな操作を可能にするプロトコル要素が提供されます。このプロトコルは、シグナリングゲートウェイ（SG）とメディアゲートウェイコントローラー（MGC）またはIP常駐データベース間、または2つのIPベースのアプリケーション間で使用されます。 SGは、SS7 Message Transfer Part（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
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
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.
このメモは、Stream Control Transmission Protocol [18]のサービスを使用して、IPを介したSS7 MTP3-Userシグナリング（ISUPおよびSCCPメッセージなど）のトランスポートをサポートするためのプロトコルを定義します。また、SS7およびIPドメインでMTP3-Userピアのシームレスな操作を可能にするプロトコル要素が提供されます。このプロトコルは、シグナリングゲートウェイ（SG）とメディアゲートウェイコントローラー（MGC）またはIP常駐データベース[12]の間、または2つの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:
シグナリングトランスポートのフレームワークアーキテクチャ[12]で説明されているように、SS7シグナリングゲートウェイ（SG）からメディアゲートウェイコントローラー（MGC）またはIP常駐データベースへのSwitched Circuit Network（SCN）シグナリングプロトコルの配信が必要です。配信メカニズムは、次の基準を満たす必要があります。
* 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-User Partメッセージの転送のサポート（ISUP [1,2,3]、SCCP [4,5,6]、TUP [13]など）* MTP3-のシームレスな操作のサポートユーザープロトコルピア* SCTPトランスポートアソシエーションの管理と、SGと1つ以上のMGCまたはIP常駐データベースとの間のトラフィックのサポート* 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-Userプロトコルメッセージ、および特定の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には、1つまたは複数の一意のアプリケーションサーバープロセスのセットが含まれ、通常、そのうちの1つまたは複数がアクティブにトラフィックを処理しています。 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-Userプロトコルデータユニットと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.
リンクセット-モジュールとして使用される2つのシグナリングポイントを直接相互接続する多数のシグナリングリンク。
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-User-通常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 element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks.
ネットワークアピアランス-ネットワークアピアランスは、SGおよびAS（通常は整数）によって共有されるM3UAローカル参照であり、シグナリングポイントコードとともに、所属する特定のSS7ネットワークを示すことによってSS7ノードを一意に識別します。これは、共通のSCTPアソシエーションを介してSGとASPの間で送信される異なるネットワークに関連付けられているシグナリングトラフィックを区別するために使用できます。シナリオ例は、SGが複数の別個の国内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には、1つまたは複数の一意のシグナリングゲートウェイプロセスのセットが含まれており、そのうちの1つまたは複数が通常アクティブにトラフィックを処理しています。 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）-1つの特定のネットワークアピアランス内の単一のMTPエンティティ（シグナルポイント）の下でSS7ネットワークに表されるアプリケーションサーバーの完全なセット。 SPMCは、SS7ネットワークへのMTP3管理手順をサポートする目的で、IPドメインで配布されるMTPエンティティ（シグナルポイント）の可用性、輻輳、およびユーザーパーツステータスを集約するために使用されます。場合によっては、SG自体がSPMCのメンバーになることもあります。この場合、サポートしているMTP3管理アクションを検討するときは、SGの可用性/輻輳/ User_Partステータスも考慮する必要があります。
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ストリーム。 1つの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.
フレームワークアーキテクチャ内で、このドキュメントは、MTPレベル3でMTPユーザーとして識別される任意のプロトコルレイヤーのメッセージの転送をサポートするのに適したMTP3ユーザー適応モジュールを定義します。これらのプロトコルレイヤーのリストには、ISDNユーザーパーツ（ISUP）[1,2,3]、シグナリング接続制御パーツ（SCCP）[4,5,6]、電話ユーザーパーツ（TUP）[13]が含まれますが、これらに限定されません。 ]。 TCAP [14、15、16]またはRANAP [16]メッセージは、SCCPユーザープロトコルであるため、M3UAプロトコルによって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レイヤーは、MTPレベル3がSS7 SEPのローカルMTP3-Userに提供するのと同じように、上位レイヤーの同等のプリミティブセットをMTP3-Userに提供します。このようにして、ASPまたはIPSPのISUPおよび/またはSCCP層は、期待されるMTP3サービスがローカルMTP3層ではなく、SGPの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レイヤーは、2つの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-TRANSFERプリミティブのトランスポートを提供します。
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 size. Some configurations (e.g., Broadband MTP [19,20,22]) may permit larger block sizes.
M3UA層は、SS7 MTPレベル2プロトコル[7,8,9]で指定されているように、272オクテットのシグナリング情報フィールド（SIF）の長さの制限を課しません。最近のSCCPまたはISUPバージョンで指定されている上位層のセグメンテーション/再組み立て手順を必要とせずに、M3UA / SCTPでより大きな情報ブロックに直接対応できます。ただし、SGのコンテキストでは、最終的な宛先へのより大きな情報ブロックの転送をサポートしないSS7ネットワークへのインターワーキング時には、最大272オクテットのブロックサイズに従う必要があります。これにより、SGPでの潜在的なISUPまたはSCCPフラグメンテーション要件が回避されます。 SS7ネットワークのプロビジョニングと構成により、最大ブロックサイズに対する制限が決まります。一部の構成（ブロードバンド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;
- SS7ネットワークの宛先に到達できないことをASPのMTP3ユーザーに示します。
- providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is now reachable;
- ASP7のMTP3ユーザーに、SS7ネットワーク内の宛先が到達可能であることを示す。
- providing an indication to MTP3-Users at an ASP that messages to a destination in the SS7 network are experiencing SS7 congestion;
- SS7ネットワークの宛先へのメッセージがSS7輻輳を経験していることをASPのMTP3ユーザーに示します。
- providing an indication to the M3UA layer at an ASP that the routes to a destination in the SS7 network are restricted; and
- SS7ネットワークの宛先へのルートが制限されていることをASPのM3UAレイヤーに示す。そして
- providing an indication to MTP3-Users at an ASP that a MTP3-User peer is unavailable.
- ASPでMTP3-UserにMTP3-Userピアが利用できないことを示す。
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レイヤーは、M3UAレイヤー自体またはASPまたはASPのホストが輻輳していることをSGに示すこともあります。
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 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).
M3UA層は、ローカル管理から、ピアM3UAノードへのSCTPアソシエーションを確立するように指示される場合があります。これは、M-SCTP_ESTABLISHプリミティブ（管理プリミティブの説明については、セクション1.6.3を参照）を使用して、ピアM3UAノードとのSCTPアソシエーションの確立を要求、表示、および確認することで実現できます。 2つのM3UAピア間の冗長なSCTPアソシエーションを回避するために、片側（クライアント）は、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_STATUSリクエストを使用して、基になるSCTPアソシエーションのステータスをM3UAレイヤーからリクエストし、プリミティブを確認できます。また、M3UAは、M3UAレイヤー内でローカルに、またはSCTPからのプリミティブによって決定された、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のステータスの変化をローカル管理に通知してもよい（MAY）。これは、M-ASP_STATUS要求またはM-AS_STATUS要求プリミティブを使用して達成される場合があります。
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を介して到達可能です。つまり、複数のルートを経由します。 MTP3ユーザーは、ルートではなく宛先のステータスのみを維持するため、M3UAレイヤーは個々のルートのステータス（可用性、制限、および/または宛先へのルートの輻輳）を維持し、全体的な可用性または輻輳ステータスを導出する必要があります。個々のルートのステータスから宛先を指定し、変更された場合はいつでもこの派生ステータスを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ネットワークのシグナリングポイントとしてのSG自体も、MTP3管理の目的でSS7ポイントコードでアドレス指定できる場合があります。 SGポイントコードは、ローカルSCCPレイヤーなど、SGでローカルMTP3ユーザーをアドレス指定するためにも使用できます。
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は各ネットワークの外観でポイントコードを使用してアドレス指定でき、IPドメインのノードのセットを各SS7ネットワークに表します。エイリアスポイントコード[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のMTP3ルートセット、SPMC、およびリモートAS / ASP状態は、すべてのSGPで調整する必要があります（SHOULD）。 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ネットワークで利用でき、それぞれに独自のポイントコードがある場合、ASPは通常、SGポイントコードとは別のポイントコードで表されます。これにより、たとえば、これらのSGをSS7ネットワークから「STP」として見ることができ、それぞれが同じASPへの継続的な「ルート」を持っています。 ASPがSGの1つから利用できなくなる障害状態では、このアプローチにより、SGとSS7ネットワーク間のMTP3ルート管理メッセージングが可能になり、宛先ポイントコードアドレスを変更せずに、代替SGを介して簡単なSS7再ルーティングが可能になります。 ASPへのSS7トラフィック。
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).
特定のASが複数のSGP経由で到達できる場合、SGP内の対応するルーティングキーは同一である必要があります。 （注：構成の更新中に、SGPルーティングキー構成データが一時的に同期されなくなる可能性があります）。
+--------+
| |
+------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ----
| SEP +---+ +--------+ +---/ \
| or | |* | ASPs |
| STP +---+ +--------+ +---\ /
+-------+ | | | | ----
+------------+ SG 2 +--------------+
| "STP" |
+--------+
Figure 1. Example with mated SGs
図1. SGを組み合わせた例
* Note: SG-to-SG communication (i.e., "C-links") is recommended for carrier grade networks, using an MTP3 linkset or an 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.
*注：MTP3リンクセットまたは同等のものを使用するキャリアグレードのネットワークでは、SG間の通信（つまり、「Cリンク」）をお勧めします。これにより、ルートに障害が発生した場合にSG間の再ルーティングが可能になります。 SGPが使用される場合、SGP間通信が使用される場合があります。 Inter-SGPプロトコルは、このドキュメントの範囲外です。
The following example shows a signalling gateway partitioned into two network appearances.
次の例は、2つのネットワークアピアランスに分割されたシグナリングゲートウェイを示しています。
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.
SGPとアプリケーションサーバー間のSS7メッセージの配信は、ルーティングキーとそれに関連付けられたルーティングコンテキストによって決定されます。ルーティングキーは、基本的にSS7メッセージのフィルターに使用されるSS7パラメーターのセットですが、ルーティングコンテキストパラメーターは、1：1の関係でそのルーティングキーに関連付けられている4オクテットの値（整数）です。したがって、ルーティングコンテキストは、ルーティングキーエントリを含む送信ノードのメッセージ配布テーブルへのインデックスとして表示できます。
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アクティブおよびASP非アクティブ管理メッセージでは、開始または停止されるシグナリングトラフィックは、ルーティングコンテキストパラメータによって区別されます。 ASPで、ルーティングコンテキストパラメータは、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シグナリングメッセージが単一のルーティング結果と完全または部分的に一致する必要があるという意味で一意である必要があります（SHOULD）。部分一致の例としては、デフォルトのルーティングキーが挙げられます。これは、メッセージが属する他のルーティングキーがない場合の結果です。特定のルーティングキー内のパラメータ範囲の値が連続している必要はありません。
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でルーティングキーをプロビジョニングするには、2つの方法があります。ルーティングキーは、実装依存の管理インターフェイスを使用して静的に構成することも、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-Userメッセージからの情報を使用してメッセージ配信機能を実行する必要があります。
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.
これらのルーティングキーは、1つ以上の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.
通常、1つ以上のASPがASでアクティブ（つまり、現在トラフィックを処理している）ですが、特定の障害や移行のケースでは、アクティブな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メッセージに一致するルーティングキーエントリがない場合、デフォルトの処理を指定できます。可能な解決策は、割り当てられていないすべてのトラフィックをデフォルトASP（のセット）に送るデフォルトアプリケーションサーバーをSGPで提供するか、メッセージをドロップしてレイヤー管理に通知を提供することです。未割り当てのトラフィックの処理は実装に依存します。
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).
実装上の注意：SS7ネットワークへのルーティングに複数のルート（またはSGP）が可能な場合、ASPは、たとえば、SS7宛先の可用性/制限を考慮して、SS7宛先に使用可能なSGPルートの動的テーブルを維持できます。 SGPから受信した/ congestionステータス、個々のSGPの可用性ステータス、および構成変更とフェイルオーバーメカニズム。ただし、SGPのステータスを管理するM3UAメッセージングはありません（SGP-Up / Down / Active / Inactiveメッセージングなど）。
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-User Adaptation Layer（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）で終端できます。 SGはMTP3のサービスを使用して、準関連方式でリモート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-Userプロトコルレイヤーが存在するIPベースのアプリケーションサーバープロセスとの間で、MTP3-Userシグナリングメッセージを転送できます。
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ユーザーパーツ管理では、ASPのMTP3-Userプロトコルが、SS7 SEPノードで予想されるように、SS7シグナリングポイントの可用性、SS7ネットワークの輻輳、およびリモートユーザーパーツの非可用性の指示を受信する必要があります。これを実現するには、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に送信してはなりません（MUST NOT）。 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.
アプリケーションサーバーのクラスターは、1つ以上の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-Userメッセージ（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がアクティブになった後にトラフィックを送信する必要があります（SHOULD）。 "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層は、適切な上位層の応答を呼び出すために、現在のMTP3手順に従って、MTP-STATUSプリミティブによってローカルMTP3-Userに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.
SS7メッセージのシグナリングポイント管理クラスター（SPMC）へのトランスポートでIPネットワークの輻輳が発生しているとSGが判断すると、SGは、関連するMTP3標準の輻輳手順に従って、発信元のSS7ノードへのSS7 MTP3転送制御管理メッセージをトリガーできます（MAY）。 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ピアへのローカルの輻輳を示してもよい（MAY）。 SGがASPから輻輳メッセージ（SCON）を受信し、SPMCで輻輳が発生しているとSGが判断した場合、SGは、関連するMTP3標準の輻輳手順に従って、SS7 MTP3転送制御管理メッセージを関連するSS7宛先にトリガーできます（MAY）。
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アソシエーション内のストリームへのシグナリングトラフィックの割り当てもサポートします。シーケンスを必要とするトラフィックは、同じストリームに割り当てる必要があります（SHOULD）。これを実現するために、MTP3ユーザートラフィックは、たとえば、基になるSCTPアソシエーションでサポートされるストリームの最大数に従って、MTP3ルーティングラベルのSLS値に基づいて個々のストリームに割り当てることができます。
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. DATAメッセージはストリーム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 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.
SGPとASPがクライアントとサーバーの両方の操作をサポートできるようにすることをお勧めします。 M3UAを使用するピアエンドポイントは、一方が常にクライアントの役割を果たし、もう一方がSCTPアソシエーションを開始するためのサーバーの役割を担うように構成する必要があります（SHOULD）。デフォルトの方向は、ASPがクライアントである間にSGPがサーバーの役割を引き受けることです。この場合、ASPはSGPへのSCTPアソシエーションを開始する必要があります（SHOULD）。
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アソシエーションを開始するためのサーバーの役割を担うように構成する必要があります（SHOULD）。
The SCTP and TCP Registered User Port Number Assignment for M3UA is 2905.
M3UAのSCTPおよびTCP登録ユーザーポート番号の割り当ては2905です。
******** SS7 ***************** IP ********
* SEP *---------* SGP *--------* ASP *
******** ***************** ********
+------+ +---------------+ +------+
| 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シグナリングメッセージをSS7ベースのSEPと交換できるようにします。 SGP内のNIFは、MTP3とM3UA間のSGP内のインターフェースとして機能します。このノードインターワーキング機能には、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, 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.
内部SGPモデリングの目的で、NIFレベルで、MGC宛てのSS7シグナリングメッセージは、MTPレベル3上位層インターフェイスからMTP-TRANSFER指示プリミティブとして受信され、MTP-TRANSFER要求プリミティブに変換され、ローカルに送信されます。最終的なIP宛先への継続的なルーティングのためのM3UA常駐メッセージ配信機能。ローカルM3UAネットワークアドレス変換およびMTP-TRANSFER表示プリミティブとしてマッピング機能から受信したメッセージは、SS7 SEPへの進行中のMTPレベル3ルーティングのMTP-TRANSFER要求プリミティブとしてMTPレベル3上位層インターフェイスに送信されます。 SS7ネットワークステータス情報を提供する目的で、NIFはMTPレベル3上位層インターフェイスから受信したMTP-PAUSE、MTP-RESUME、およびMTP-STATUS表示プリミティブもローカルM3UA常駐管理機能に配信します。さらに、実装およびネットワークオプションとして、制限された宛先がMTPネットワーク管理からローカルのM3UA常駐管理機能に伝達されます。
******** IP ********
* IPSP * * IPSP *
******** ********
+------+ +------+
|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メッセージは、RANAPまたはTCAPなどの常駐SCCP-Userプロトコルインスタンスを持つ2つのIP常駐IPSP間で直接交換されます。 SS7ネットワークインターワーキングは必要ありません。したがって、SCCPおよびSCCP-Userプロトコルで考慮すべきMTP3ネットワーク管理ステータス情報はありません。 M3UA層からSCCP層へのMTP-PAUSE、MTP-RESUME、またはMTP-STATUSの指示は、SCTPアソシエーションのステータスと基礎となるIPネットワーク、およびリモートサイトから受信した輻輳情報を考慮する必要があります。
******** 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 |
+------+ +------+ +------+ +------+
|_______________| |______________|
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要求プリミティブは、ローカルの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-TRANSFER表示プリミティブは、ローカルのM3UA常駐ネットワークアドレス変換およびマッピング機能からGTTのSCCPに送信されます。 GTTの結果がSS7ネットワークのSCCPピアのアドレスを生成する場合、結果のMTP-TRANSFER要求プリミティブがSS7常駐ノードへの配信のためにMTP3に渡されます。
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要求プリミティブがIP宛先への配信のためにM3UAレイヤーに送り返される可能性があります。
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の下に効果的に配置され、MTP-TRANSFER要求/指示メッセージをMTP3レイヤーとM3UAレイヤーの両方にルーティングします。 SS7 DPCまたはDPC / SIアドレス情報に基づく。このノードインターワーキング機能には、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 |
+-----------+
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-TRANSFER要求MTP-TRANSFER表示MTP-PAUSE表示MTP-RESUME表示MTP-STATUS表示
An example of the upper-layer primitives provided by the SCTP are provided in Reference [18], Section 10.
SCTPによって提供される上位層プリミティブの例は、参考文献[18]、セクション10に記載されています。
M-SCTP_ESTABLISH request Direction: LM -> M3UA Purpose: LM requests that ASP establish an SCTP association with its peer.
M-SCTP_ESTABLISH要求の方向：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_ESTABLISH確認方向：M3UA-> LM目的：ASPがピアとのSCTPアソシエーションを確立したことをLMに確認します。
M-SCTP_ESTABLISH indication Direction: M3UA -> LM Purpose: M3UA informs LM that a remote ASP has established an SCTP association.
M-SCTP_ESTABLISH指示方向：M3UA-> LM目的：M3UAは、リモートASPがSCTPアソシエーションを確立したことをLMに通知します。
M-SCTP_RELEASE request Direction: LM -> M3UA Purpose: LM requests that ASP release an SCTP association with its peer.
M-SCTP_RELEASE要求の方向：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_RELEASE確認方向：M3UA-> LM目的：ASPがピアとのSCTPアソシエーションを解放したことをLMに確認します。
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_RELEASE指示方向：M3UA-> LM目的：M3UAは、リモートASPがSCTPアソシエーションを解放したか、SCTPアソシエーションが失敗したことをLMに通知します。
M-SCTP_RESTART indication Direction: M3UA -> LM Purpose: M3UA informs LM that an SCTP restart indication has been received.
M-SCTP_RESTARTインジケーション方向：M3UA-> LM目的：M3UAは、SCTPリスタートインジケーションが受信されたことをLMに通知します。
M-SCTP_STATUS request Direction: LM -> M3UA Purpose: LM requests that M3UA report the status of an SCTP association.
M-SCTP_STATUS要求の方向：LM-> M3UA目的：LMは、M3UAがSCTPアソシエーションのステータスを報告することを要求します。
M-SCTP_STATUS confirm Direction: M3UA -> LM Purpose: M3UA responds with the status of an SCTP association.
M-SCTP_STATUS確認方向：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_STATUS要求の方向：LM-> M3UA目的：LMは、M3UAがローカルまたはリモートASPのステータスを報告することを要求します。
M-ASP_STATUS confirm Direction: M3UA -> LM Purpose: M3UA reports the status of local or remote ASP.
M-ASP_STATUS確認方向：M3UA-> LM目的：M3UAはローカルまたはリモートASPのステータスを報告します。
M-AS_STATUS request Direction: LM -> M3UA Purpose: LM requests that M3UA report the status of an AS.
M-AS_STATUS要求の方向：LM-> M3UA目的：LMは、M3UAがASのステータスを報告することを要求します。
M-AS_STATUS confirm Direction: M3UA -> LM Purpose: M3UA reports the status of an AS.
M-AS_STATUS確認方向：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は、ピアから通知メッセージを受信したことを報告します。
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-ERROR指示方向：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確認方向：M3UA-> LM目的：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_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ダウンメッセージをピアに送信することを要求します。
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確認方向：M3UA-> LM目的：ASPは、ピアからASP Down Ackメッセージを受信したことを報告します。
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_DOWN指示方向：M3UA-> LM目的：M3UAは、ピアからの着信ASP Downメッセージを正常に処理したか、SCTPアソシエーションが失われたかリセットされたことを報告します。
M-ASP_ACTIVE request Direction: LM -> M3UA Purpose: LM requests that ASP send an ASP Active message to its peer.
M-ASP_ACTIVE要求の方向：LM-> M3UA目的：ASPがASPアクティブメッセージをピアに送信するLM要求。
M-ASP_ACTIVE confirm Direction: M3UA -> LM Purpose: ASP reports that it has received an ASP Active Ack message from its peer.
M-ASP_ACTIVE確認方向：M3UA-> LM目的：ASPは、ピアからASP Active Ackメッセージを受信したことを報告します。
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_ACTIVE指示方向：M3UA-> LM目的：M3UAは、ピアからの着信ASP Activeメッセージを正常に処理したことを報告します。
M-ASP_INACTIVE request Direction: LM -> M3UA Purpose: LM requests that ASP send an ASP Inactive message to its peer.
M-ASP_INACTIVE要求の方向：LM-> M3UA目的：ASPがASP非アクティブメッセージをピアに送信するLM要求。
M-ASP_INACTIVE confirm Direction: LM -> M3UA Purpose: ASP reports that it has received an ASP Inactive Ack message from its peer.
M-ASP_INACTIVE確認方向：LM-> M3UA目的：ASPは、ピアからASP非アクティブACKメッセージを受信したことを報告します。
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_INACTIVE指示方向：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_ACTIVE指示方向：M3UA-> LM目的：M3UAは、ASがAS-ACTIVE状態に移行したことを報告します。
M-AS_INACTIVE indication Direction: M3UA -> LM Purpose: M3UA reports that an AS has moved to the AS-INACTIVE state.
M-AS_INACTIVE指示方向：M3UA-> LM目的：M3UAは、ASがAS-INACTIVE状態に移行したことを報告します。
M-AS_DOWN indication Direction: M3UA -> LM Purpose: M3UA reports that an AS has moved to the AS-DOWN state.
M-AS_DOWN指示方向：M3UA-> LM目的：M3UAは、ASがAS-DOWN状態に移行したことを報告します。
If dynamic registration of RK is supported by the M3UA layer, the layer MAY support the following additional primitives:
RKの動的登録がM3UAレイヤーでサポートされている場合、レイヤーは次の追加のプリミティブをサポートしてもかまいません（MAY）。
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は、ASPがREG REQメッセージを送信してピアに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確認方向：M3UA-> LM目的：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は、着信REG REQメッセージを正常に処理したことをLMに通知します。
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_DEREG要求の方向：LM-> M3UA目的：LMは、DEREG REQメッセージを送信して、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確認方向：M3UA-> LM目的：ASPは、ピアからの登録解除ステータスが成功した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は、ピアからの着信DEREG REQを正常に処理したことをLMに通知します。
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メッセージ形式には、共通メッセージヘッダーと、それに続くメッセージタイプで定義された0個以上のパラメーターが含まれます。上位互換性のため、このバージョンで何も指定されていない場合でも、すべてのメッセージタイプにパラメータがアタッチされている場合があります。
The protocol messages for MTP3-User Adaptation require a message header that contains the adaptation layer version, the message type, and message length.
MTP3-User Adaptationのプロトコルメッセージには、アダプテーション層のバージョン、メッセージタイプ、およびメッセージ長を含むメッセージヘッダーが必要です。
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.
versionフィールドには、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 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
0管理（MGMT）メッセージ1転送メッセージ2 SS7シグナリングネットワーク管理（SSNM）メッセージ3 ASP状態保守（ASPSM）メッセージ4 ASPトラフィック保守（ASPTM）メッセージ5他のSIGTRAN適応層用に予約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定義のMGMT拡張用に予約
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ペイロードデータ（DATA）2〜127 IETFによって予約128〜255 IETF定義転送拡張用に予約
SS7 Signalling Network Management (SSNM) Messages (see Section 3.4)
SS7 Signaling Network Management（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ハートビート（BEAT）4 ASPアップ確認（ASPUP ACK）5 ASPダウン確認（ASPDN ACK）6ハートビート確認（BEAT ACK）
7 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined ASPSM extensions
7〜127 IETFによって予約済み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.
注：受信者は、最後のパラメーターパディングがメッセージ長に含まれているかどうかに関係なく、メッセージを受け入れる必要があります（SHOULD）。
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個以上の可変長パラメーターで構成されます。メッセージに含まれるすべてのパラメーターは、以下に示すように、タグの長さ-値の形式で定義されます。
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.
メッセージに複数のパラメーターが含まれている場合、明示的に指示されている場合を除き、パラメーターの順序は任意です。レシーバーは、パラメーターを任意の順序で受け入れる必要があります（SHOULD）。
Unless explicitly stated or shown in a message format diagram, only one parameter of the same type is allowed in a message.
明示的に述べられていないか、メッセージ形式の図に示されていなければ、同じタイプの1つのパラメーターのみがメッセージで許可されます。
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
Affected Point Code 0x0012
Correlation 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宛先ポイントコード0x020c宛先ポイントコードコード0x020b送信元ポイントコード0x020bデータ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オクテットの倍数でない場合、送信者はパラメータを最後に（つまり、[パラメータ値]フィールドの後に）すべてゼロのオクテットで埋めます。パディングの長さは、パラメーターの長さフィールドには含まれません。送信者は、3オクテットを超えてパディングしてはなりません（MUST NOT）。受信機はパディングオクテットを無視しなければなりません。
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:
DATAメッセージには、完全なMTP3ルーティングラベルを含むMTP-TRANSFERプリミティブであるSS7 MTP3-Userプロトコルデータが含まれています。 DATAメッセージには、以下の可変長パラメーターが含まれています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ネットワークインジケーターの値、および特定の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.
Network Appearanceパラメータ値はローカルでのみ重要であり、SGPとASPの間で調整されます。したがって、ASPが複数のSGPに接続されている場合、メッセージが送受信されているSGPに応じて、同じSS7ネットワークコンテキストが異なるネットワークアピアランス値によって識別されることがあります。
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.
ルーティングコンテキストパラメータには、DATAメッセージに関連付けられたルーティングコンテキスト値が含まれます。 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:
Protocol Dataパラメータには、次のフィールドが含まれています。
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-Userプロトコル要素（ISUP、SCCP、またはTUPパラメータなど）
The Protocol Data parameter is encoded as follows:
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'.
Message Priorityフィールドには、元の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'.
Signaling Link Selectionフィールドには、最下位ビットに揃えられた元の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].
ユーザープロトコルデータフィールドには、ルーティングラベル[7] [8] [26]に続く元のSS7メッセージの最初のオクテットで始まる、元のSS7メッセージからのMTPユーザー情報のオクテット文字列が含まれています。
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が1つ以上のSS7宛先に到達できないと判断したことを示します。また、ASPから到達不能なSS7宛先へのメッセージへの応答として、SGPによって送信されます。実装オプションとして、SGは、リモート側に反応する時間を与えるために、特定の到達不能なSS7宛先に関する特定の期間の後続の「応答」DUNAメッセージの送信を抑制します。別のSGを介した代替ルートがない場合、ASPのMTP3-Userは、定義されたMTP3-User手順に従って、SGを介して影響を受ける宛先へのトラフィックを停止すると予想されます。
The DUNA message contains the following parameters:
DUNAメッセージには、以下のパラメーターが含まれています。
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory INFO String Optional
ネットワークの外観オプションルーティングコンテキスト条件付き影響を受けるポイントコード必須INFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージが適用される関係するトラフィックフローを識別し、送信トラフィック管理とMTP-PAUSE表示の内部配信を支援する必要があります。受信側のMTP3ユーザー。
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.
影響を受けるポイントコードパラメータには、影響を受ける宛先ポイントコードフィールドのリストが含まれています。それぞれ3オクテットのパラメータで、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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に送信することはオプションですが、受信することは必須です。複数の影響を受けるPCを含めることは、MTP3管理メッセージまたはリンクセットイベントの受信が同時にSGの宛先リストの可用性ステータスに影響を与える場合に役立ちます。
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.
Maskフィールドは、影響を受ける宛先ポイントコードの連続した範囲を識別するために使用できます。 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.
Maskパラメーターは、関連する影響を受けるPCフィールドに適用できるビットマスクを表す整数です。ビットマスクは、影響を受けるPCフィールドの何ビットが重要で、どれが効果的に「ワイルドカード化」されるかを識別します。たとえば、「8」のマスクは、PCの最後の8ビットが「ワイルドカード」であることを示します。 ANSI 24ビットの影響を受けるPCの場合、これはANSIクラスター内のすべてのPCが利用できないことを通知することと同じです。 「3」のマスクは、PCの最後の3ビットが「ワイルドカード」であることを示します。 14ビットのITUの影響を受けるPCの場合、これはITU領域が利用できないことを通知することに相当します。 PCのビット数と等しい（またはそれより大きい）マスク値は、ネットワーク全体の外観に影響があることを示します。これは、ASPへのネットワーク分離を示すために使用されます。
INFO String: variable length
INFO文字列：可変長
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).
オプションのINFO Stringパラメーターは、メッセージとともに、意味のあるUTF-8 [10]文字列を運ぶことができます。 INFO文字列パラメータの長さは0〜255オクテットです。現在、その使用法については識別されていませんが、INFO文字列はデバッグ目的で使用できます。長さゼロのパラメーターを持つINFO文字列はエラーとは見なされません（長さゼロのパラメーターとは、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が、1つ以上のSS7宛先が現在到達可能（かつ制限されていない）であると判断したことを示すか、必要に応じてDAUDメッセージに応答します。以前に影響を受けた宛先へのルートがASP M3UAレイヤーになかった場合、ASP MTP3-Userプロトコルが通知され、影響を受けた宛先へのトラフィックを再開する可能性があります。 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
ネットワークの外観オプションルーティングコンテキスト条件付き影響を受けるポイントコード必須INFO文字列オプション
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).
ネットワークの外観、ルーティングコンテキスト、影響を受けるポイントコード、INFO文字列パラメーターの形式と説明は、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から1つ以上の影響を受ける宛先へのSS7ルートの可用性/輻輳状態を監査できます。
The DAUD message contains the following parameters:
DAUDメッセージには、以下のパラメーターが含まれています。
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory INFO String Optional
ネットワークの外観オプションルーティングコンテキスト条件付き影響を受けるポイントコード必須INFO文字列オプション
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.
SGの過負荷を回避するために、通常の操作（トラフィック処理）の間、DAUDメッセージ内の影響を受けるポイントコードパラメーターのマスクフィールドをゼロ値に保つことをお勧めします。
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に送信して、SS7ネットワークで1つ以上の宛先への輻輳があるか、またはDATAまたはDAUDメッセージに応じてASPへの輻輳があると判断したことを示すことができます。一部の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
ネットワークの外観オプションのルーティングコンテキスト条件付きの影響を受けるポイントコード必須の懸念される宛先オプションの輻輳表示オプションのINFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
ネットワークの外観、ルーティングコンテキスト、影響を受けるポイントコード、INFO文字列パラメーターの形式と説明は、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メッセージをトリガーしたメッセージの発信者のポイントコードが含まれています。 Concerned Destinationパラメータには、1つのConcerned Destination Point Codeフィールドが含まれます。これは、14、16、および24ビットのバイナリ形式のSS7ポイントコードを可能にする3オクテットパラメータです。 24ビット未満の関連ポイントコードは、24ビット境界の左側に埋め込まれます。結果のSGからの転送制御（TFC）メッセージは、SCONメッセージに含まれる単一の影響を受けるDPCを使用して当該のポイントコードに送信され、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.
オプションのCongestion Indicationsパラメータには、Congestion Levelフィールドが含まれています。このオプションパラメータは、ANSI MTP3などのように、複数の輻輳しきい値を持つ国内MTPネットワークの輻輳レベルを伝達するために使用されます。複数の輻輳レベルのない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:
Affected DestinationsパラメータのすべてのAffected DPCに関連付けられているCongestion Levelフィールドには、次のいずれかの値が含まれています。
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.
DUPUメッセージはSGPによって使用され、SS7ノードのリモートピアMTP3ユーザーパーツ（ISUPまたはSCCPなど）が利用できないことを関係するASPに通知します。
The DUPU message contains the following parameters:
DUPUメッセージには、次のパラメーターが含まれます。
Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory User/Cause Mandatory INFO String Optional
ネットワークの外観オプションルーティングコンテキスト条件付き影響を受けるポイントコード必須ユーザー/原因必須INFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に関連付けられているUnavailability CauseフィールドとMTP3-User Identityフィールドは、次のようにエンコードされます。
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.
Unavailability Causeパラメータは、MTP3-Userを使用できない理由を提供します。 Unavailability Causeパラメータの有効な値を次の表に示します。値は、SS7 MTP3 User Part Unavailableメッセージで提供される値と一致します。ネットワークアピアランスで使用されるMTP3プロトコルによっては、追加の値が使用される場合があります。関連するMTP3プロトコルバリアント/バージョンの推奨の仕様が決定的です。
0 Unknown 1 Unequipped Remote User 2 Inaccessible Remote User
0不明1装備されていないリモートユーザー2アクセスできないリモートユーザー
MTP3-User Identity field: 16 bits (unsigned integer)
MTP3-User Identityフィールド：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-User Identityは、利用できない特定のMTP3-Userを表します（ISUP、SCCPなど）。 MTP3-User Identityの有効な値の一部を以下に示します。値は、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 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が1つだけ含まれることを除いて、DUNAメッセージ（セクション3.4.1を参照）と同じです。影響を受けるDPCの範囲とリストをDUPUメッセージで通知することはできませんが、これはSS7ネットワークでのUPUの動作と一致しています。 SGPがSS7ネットワークから受信したMTP3 User Part Unavailableメッセージ（UPU）のAffected Destinationsパラメーターには、宛先が1つだけ含まれています。
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).
ネットワークの外観、ルーティングコンテキスト、INFO文字列パラメーターの形式と説明は、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からすべての関係するASPに送信され、SGが1つ以上のSS7宛先がSGの観点から制限されていると判断したこと、または必要に応じてDAUDメッセージへの応答として、SGが判断したことを示します。 ASPのM3UA層は、同じ優先度のルートを持つ代替SGを介して、影響を受ける宛先にトラフィックを送信することが期待されますが、そのような代替ルートが存在し、利用できる場合に限られます。影響を受ける宛先がASPによって現在利用できないと見なされている場合、影響を受ける宛先へのトラフィックを再開できることをMTP3-Userに通知する必要があります。この場合、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
ネットワークの外観オプションルーティングコンテキスト条件付き影響を受けるポイントコード必須INFO文字列オプション
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).
ネットワークの外観、ルーティングコンテキスト、影響を受けるポイントコード、INFO文字列パラメーターの形式と説明は、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メッセージは、適応層が、ASPが提供するように構成されているすべてのルーティングキーのASPSM / ASPTMメッセージを受信する準備ができていることをリモートM3UAピアに示すために使用されます。
The ASP Up message contains the following parameters:
ASP Upメッセージには、次のパラメーターが含まれています。
ASP Identifier Optional INFO String Optional
ASP IDオプションINFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Identifierパラメーターには、ASをサポートするASPの中でローカルに重要な一意の値が含まれています。 SGPは、必要に応じて、使用するASP識別子を通知メッセージとともに保存する必要があります（セクション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).
オプションのINFO Stringパラメータの形式と説明は、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 IDオプションINFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Identifierパラメーターは、IPSP通信に特に役立ちます。その場合、ASP Upメッセージに応答するIPSPには、独自のASP ID値が含まれる場合があります。
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).
オプションのINFO Stringパラメータの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。 ASP Up AckメッセージのINFO文字列は、ASP UpメッセージのINFO文字列から独立しています（つまり、受信したINFO文字列をエコーバックする必要はありません）。
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ピアに、アダプテーションレイヤーがDATA、SSNM、RKM、またはASPTMメッセージを受信する準備ができていないことを示すために使用されます。
The ASP Down message contains the following parameter:
ASP Downメッセージには、次のパラメーターが含まれています。
INFO String Optional
INFO文字列オプション
The format for the ASP Down 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 =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).
オプションのINFO Stringパラメータの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M3UA peer.
ASPダウンACKメッセージは、リモートM3UAピアから受信したASPダウンメッセージを確認するために使用されます。
The ASP Down Ack message contains the following parameter:
ASP Down Ackメッセージには、次のパラメーターが含まれています。
INFO String Optional
INFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the DUNA message (See Section 3.4.1).
オプションのINFO Stringパラメータの形式と説明は、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ダウンACKメッセージのINFO文字列は、ASPダウンメッセージのINFO文字列から独立しています（つまり、受信したINFO文字列をエコーバックする必要はありません）。
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.
オプションでBEATメッセージを使用して、M3UAピアが引き続き相互に利用できるようにします。 M3UAが、独自のハートビートを持つSCTP以外のトランスポート層を介して実行される場合に使用することをお勧めします。
The BEAT message contains the following parameter:
BEATメッセージには次のパラメーターが含まれます。
Heartbeat Data Optional
ハートビートデータオプション
The format for the BEAT message is as follows:
BEATメッセージの形式は次のとおりです。
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.
ハートビートデータパラメータの内容は、送信ノードによって定義されます。ハートビートデータには、たとえば、ハートビートシーケンス番号やタイムスタンプが含まれます。 BEATメッセージの受信者はこのフィールドを処理しません。これは送信者にとってのみ重要であるためです。受信者はBEAT Ackメッセージで応答する必要があります。
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.
BEAT Ackメッセージは、受信したBEATメッセージへの応答として送信されます。受信したBEATメッセージのすべてのパラメーターが変更なしに含まれています。
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ピアに、リモートピアに1つ以上の所定のルーティングキーを登録することを希望することを示します。通常、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:
1つ以上のルーティングキーパラメータが含まれる場合があります。 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
必須のLocal-RK-Identifierフィールドは、登録要求を一意に識別するために使用されます。 ID値はASPによって割り当てられ、REG RSPメッセージの応答を元の登録要求と関連付けるために使用されます。 REG RSPメッセージが受信されるまで、識別子の値は一意である必要があります。
The format of the Local-RK-Identifier field is as follows:
Local-RK-Identifierフィールドの形式は次のとおりです。
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:
オプションのトラフィックモードタイプパラメータは、アプリケーションサーバー内の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
宛先ポイントコードパラメータは必須であり、ASPが登録している着信SS7トラフィックの宛先ポイントコードを識別します。エイリアスポイントコード設定の場合、DPCパラメータは各ポイントコードに対して繰り返されます。形式は、DUNAメッセージのセクションAffected Destinationの説明と同じです（セクション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ネットワークコンテキストを識別し、メッセージの最初のパラメータである必要がないことを除いて、DATAメッセージ（セクション3.3.1を参照）と同じ形式です。 。ネットワークアピアランスが指定されておらず、ルーティングキーがすべてのネットワークアピアランスに適用される場合、このルーティングキーは、関連付けに登録された唯一のものでなければなりません。つまり、ルーティングコンテキストが暗示され、DATAおよびSSNMメッセージは、ルーティングコンテキストではなくネットワークアピアランスで区別されます。ネットワークの外観が指定されておらず、ネットワークの外観が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 = 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-User Identityフィールドに記述されている値からの1つ以上のサービスインジケーターが含まれます。ルーティングキーにSIパラメータがない場合は、MTP管理を除いて、SI値が使用されていることを示します。 SIパラメータに4の倍数の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Originating Point Code Listパラメータには1つ以上のSS7 OPCエントリが含まれており、その形式はDestination Point Codeパラメータと同じです。ルーティングキーに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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
1つ以上の登録結果パラメータを含める必要があります。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 REQメッセージに応答して複数のREG RSPメッセージが使用される場合、特定の結果は1つの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
Local-RK-Identifierには、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.
Registration Result Statusフィールドは、登録要求の成功または失敗の理由を示します。
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ルーティングコンテキストパラメータには、送信ASPが現在SGPから受信するように登録されているが、今は登録解除したいApplication Serverトラフィックにインデックスを付ける整数（のリスト）が含まれています。
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:
1つ以上の登録解除結果パラメーターを含める必要があります。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージへの応答で使用される場合、特定の結果は1つのDEREG RSPメッセージだけにあるべきです（SHOULD）。各結果の形式は次のとおりです。
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.
Deregistration Result Statusフィールドは、登録解除の成功または失敗の理由を示します。
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 ActiveメッセージはASPによって送信され、特定のアプリケーションサーバーのシグナリングトラフィックを処理する準備ができていることをリモートM3UAピアに示します。 ASPアクティブメッセージは、ルーティングコンテキストが存在する場合、ルーティングコンテキストによって識別されるルーティングキーのASP状態にのみ影響します。
The ASP Active message contains the following parameters:
ASP Activeメッセージには、次のパラメーターが含まれています。
Traffic Mode Type Optional Routing Context Optional INFO String Optional
トラフィックモードタイプオプションのルーティングコンテキストオプションINFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
トラフィックモードタイプパラメーターは、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.
特定のルーティングコンテキスト内では、オーバーライド、ロードシェア、およびブロードキャストを混在させるべきではありません。オーバーライド値は、ASPがオーバーライドモードで動作していることを示します。このモードでは、ASPがアプリケーションサーバーのすべてのトラフィックを引き継ぎ（プライマリ/バックアップ操作）、ASで現在アクティブな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が受信するように構成/登録されているApplication Serverトラフィックにインデックスを付ける整数（のリスト）が含まれています。
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名の間には1対1の関係があります。 ASは1つのネットワークアピアランスにしか表示できないため、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は、個別のSS7 DPC / OPC / SI範囲で識別される複数のMTP3ユーザーのシグナリングをサポートするように構成できます。
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1).
オプションのINFO Stringパラメータの形式と説明は、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 Active Ackメッセージには、次のパラメーターが含まれています。
Traffic Mode Type Optional Routing Context Optional INFO String Optional
トラフィックモードタイプオプションのルーティングコンテキストオプションINFO文字列オプション
The format for the ASP Active Ack message is as follows:
ASP Active 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 = 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).
オプションのINFO Stringパラメータの形式と説明は、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アクティブACKメッセージのINFO文字列は、ASPアクティブメッセージのINFO文字列から独立しています（つまり、受信したINFO文字列をエコーバックする必要はありません）。
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非アクティブメッセージはASPによって送信され、ASPのリスト内から使用されるアクティブなASPではなくなったことをリモートM3UAピアに示します。 ASP非アクティブメッセージは、ルーティングコンテキスト（存在する場合）によって識別されるルーティングキーのASP状態にのみ影響します。
The ASP Inactive message contains the following parameters:
ASP非アクティブメッセージには、次のパラメーターが含まれています。
Routing Context Optional INFO String Optional
ルーティングコンテキストオプションINFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.)
オプションのルーティングコンテキストとINFO文字列パラメーターの形式と説明は、ASPアクティブメッセージの場合と同じです（セクション3.5.5を参照）。
The ASP Inactive Ack message is used to acknowledge an ASP Inactive message received from a remote M3UA peer.
ASP非アクティブACKメッセージは、リモートM3UAピアから受信したASP非アクティブメッセージを確認するために使用されます。
The ASP Inactive Ack message contains the following parameters:
ASP Inactive Ackメッセージには、次のパラメーターが含まれています。
Routing Context Optional INFO String Optional
ルーティングコンテキストオプションINFO文字列オプション
The format for the ASP Inactive Ack message is as follows:
ASP Inactive 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 = 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).
オプションのINFO Stringパラメータの形式と説明は、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非アクティブACKメッセージのINFO文字列は、ASP非アクティブメッセージのINFO文字列から独立しています（つまり、受信したINFO文字列をエコーバックする必要はありません）。
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
* 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パラメータは、エラーメッセージの理由を示します。 Errorパラメータ値は、次のいずれかの値になります。
0x01 Invalid Version 0x02 Not Used in M3UA 0x03 Unsupported Message Class 0x04 Unsupported Message Type 0x05 Unsupported Traffic Mode Type 0x06 Unexpected Message 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
0x01無効なバージョン0x02はM3UAで使用されていません0x03サポートされていないメッセージクラス0x04サポートされていないメッセージタイプ0x05サポートされていないトラフィックモードタイプ0x06予期しないメッセージ0x07プロトコルエラー0x08 M3UAで使用されていません0x09無効なストリーム識別子0x0a M3UAで使用されていません0x0b M3UAで使用されていません0x0c使用されていませんM3UA 0x0d拒否-管理ブロック0x0e ASP識別子が必要0x0f無効なASP識別子0x10がM3UAで使用されていない0x11無効なパラメータ値0x12パラメータフィールドエラー0x13予期しないパラメータ0x14宛先ステータスが不明0x15無効なネットワークの外観0x16使用されていないパラメータ0x17使用されていない0x17 M3UA 0x19 Invalid Routing Context 0x1a No Configured AS for 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 Routing Contexts, the Routing Contexts SHOULD be included in the Error message.
「予期しないメッセージ」エラーは、現在の状態では予期されない定義済みの認識されたメッセージが受信された場合に送信される場合があります（場合によっては、ASPがメッセージを破棄し、エラーメッセージを送信しないこともあります）。たとえば、ASP-INACTIVE状態のときにSGPからDATAメッセージを受信した場合、ASPはサイレント破棄を使用します。予期しないメッセージにルーティングコンテキストが含まれていた場合、ルーティングコンテキストをエラーメッセージに含める必要があります（SHOULD）。
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アクティブメッセージのルーティングコンテキストをエラーメッセージに含める必要があります（SHOULD）。
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.
「ASP Identifier Required」エラーは、SGPが必要なときにASP Identifierパラメータを含まないASP Upメッセージに応答してSGPによって送信されます。 ASPはASP IDを使用してASP Upメッセージを再送信する必要があります（SHOULD）。
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識別子」エラーは、無効な（つまり、一意ではない）ASP識別子を持つASP Upメッセージに応答してSGPによって送信されます。
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).
「宛先ステータス不明」エラーは、DAUDが宛先の可用性/輻輳ステータスを問い合わせるSGで受信され、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.
ルーティングコンテキストパラメータのないピアからメッセージが受信され、どのアプリケーションサーバーが参照されているかが構成データで認識されていない場合、「ASPに構成されていないAS」エラーが送信されます。
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.
M3UAピアにM3UAイベントの自律表示を提供するために使用される通知メッセージ。
The Notify message contains the following parameters:
通知メッセージには、次のパラメーターが含まれます。
Status Mandatory ASP Identifier Conditional Routing Context Optional INFO String Optional
ステータス必須ASP識別子条件付きルーティングコンテキストオプションINFO文字列オプション
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パラメータは、Notifyメッセージのタイプを識別します。有効なステータスタイプ値は次のとおりです。
1 Application Server State Change (AS-State_Change) 2 Other
1アプリケーションサーバーの状態変更（AS-State_Change）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:
[ステータス情報]パラメーターには、ステータスタイプの値に基づいた通知の詳細情報が含まれています。ステータスタイプがAS-State_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 ASでアクティブな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_INACTIVE ASPに対して、ASの負荷を処理するために別のASPが必要であることを示しています（ロードシェアリングモードまたはブロードキャストモード）。代替ASPアクティブの場合、代替ASPがオーバーライドモードでASP-ACTIVE状態に移行するとASPに通知されます。代替ASPのASP識別子（利用可能な場合）は、メッセージに配置する必要があります。 ASP失敗の場合、SGPは、ASPの1つが失敗したことをAS内の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を参照）。 Routing ContextパラメータとInfo Stringパラメータの形式と説明は、ASP Activeメッセージの場合と同じです（セクション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の上位層、またはSGPのノードインターワーキング機能からMTP-TRANSFER要求プリミティブを受信すると、M3UA層は対応するDATAメッセージ（セクション3を参照）をそのM3UAピアに送信します。 DATAメッセージを受信するM3UAピアは、MTP-TRANSFER表示プリミティブを上位層に送信します。
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要求プリミティブの情報をプロビジョニングされたルーティングキーと比較することにより、アプリケーションサーバー（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が選択され、DATAメッセージが作成され、対応するSCTPアソシエーションで発行されます。複数のASPがASP-ACTIVE状態にある場合（つまり、トラフィックが複数のASP間でロードシェアリングされる場合）、ASP-ACTIVE状態のASPの1つがリストから選択されます。 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ストリームで送信される必要があり、シグナリングアプリケーションのメッセージシーケンスのニーズを満たすように注意を払います。 DATAメッセージは、ストリーム '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メッセージに対して、デフォルトの処理を指定できます。可能な解決策は、割り当てられていないすべてのトラフィックをデフォルトASP（のセット）に送るデフォルトアプリケーションサーバーをSGPで提供するか、メッセージをドロップしてM-ERROR表示プリミティブでレイヤー管理に通知を提供することです。未割り当てのトラフィックの処理は実装に依存します。
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_ESTABLISH要求プリミティブは、SCTPアソシエーションの確立を開始します。 M3UA層は、SCTP-ASSOCIATEプリミティブをローカルSCTP層に送信することにより、リモート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はSCTP-COMMUNICATION_UP通知プリミティブをローカルM3UAレイヤーに送信します。要求を開始したSGPまたはIPSPで、関連付けの設定が完了すると、M3UAレイヤーはレイヤー管理にM-SCTP_ESTABLISH確認プリミティブを送信します。ピアM3UAレイヤーでは、着信SCTPアソシエーションセットアップが正常に完了すると、M-SCTP_ESTABLISH表示プリミティブがレイヤー管理に送信されます。
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_RELEASE要求プリミティブは、SCTPアソシエーションのティアダウンを開始します。 M3UA層は、SCTP-SHUTDOWNプリミティブをSCTP層に送信することにより、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層はSCTP-SHUTDOWN_COMPLETE通知プリミティブをローカルM3UA層に返します。要求を開始したM3UAレイヤーでは、関連付けのシャットダウンが完了すると、M3UAレイヤーがレイヤー管理にM-SCTP_RELEASE確認プリミティブを送信します。ピアM3UAレイヤーでは、SCTPアソシエーションのシャットダウンまたはシャットダウンが成功すると、M-SCTP_RELEASE表示プリミティブがレイヤー管理に送信されます。
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_STATUS要求プリミティブは、特定のSCTPアソシエーションのローカルステータスのレイヤ管理クエリをサポートします。 M3UA層は、単にM-SCTP_STATUS要求プリミティブをSCTP-STATUSプリミティブからSCTP層にマッピングします。 SCTPが応答すると、M3UA層は関連付けステータス情報をM-SCTP_STATUS確認プリミティブにマップします。ピアプロトコルは呼び出されません。
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 primitives (and Status as well) can be considered, for modeling purposes, as a Layer Management interaction directly with the SCTP Layer.
同様のLM-to-M3UA-to-SCTPおよび/またはSCTP-to-M3UA-to-LMプリミティブマッピングは、INITIALIZE、SET PRIMARY、CHANGE HEARTBEATなど、RFC2960 [18]の他のさまざまなSCTP上位層プリミティブについて説明できます。 、ハートビートのリクエスト、SRTTレポートの取得、失敗しきい値の設定、プロトコルパラメータの設定、SCTPインスタンスの破棄、失敗の送信、ネットワークステータスの変更。または、これらのSCTP上位層プリミティブ（およびステータスも）は、モデリングの目的で、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通知またはエラーメッセージに含まれる通知またはエラー情報をそれぞれレイヤー管理に示します。これらの指標は、ローカルの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_STATUS要求プリミティブは、特定のローカルまたはリモートASPのステータスのレイヤー管理クエリをサポートします。 M3UAレイヤーは、M-ASP_STATUS確認プリミティブのステータスで応答します。 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_STATUSリクエストは、特定のASのステータスのレイヤー管理クエリをサポートします。 M3UAはM-AS_STATUS確認プリミティブで応答します。 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_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.
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_INACTIVE、M-を呼び出すことができます（MAY）。 AS_ACTIVE、M-AS_INACTIVE、およびM-AS_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通知またはエラーメッセージに含まれる通知またはエラー情報をレイヤー管理に示します。これらの指標は、ローカルの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メッセージは、順序付けを確実にするために、シーケンス配信で送信する必要があります（SHOULD）。 ASPTMメッセージは、可能なメッセージ損失を最小限に抑えるために、ルーティングコンテキストに関連するデータトラフィックを運ぶために使用されるストリームの1つで送信される場合があります。 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層は、M3UAメッセージ配信機能への入力として、ASPがトラフィックを受信するように構成されている各アプリケーションサーバーで、各リモートASPの状態を維持します。同様に、IPSPがポイントツーポイント方式でM3UAを使用する場合、IPSPのM3UAレイヤーはリモートIPSPの状態を維持します。
Two IPSP models are defined as follows:
2つの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メッセージを1回交換するだけで済みます。これは、一方の端からの一連の要求と、もう一方からの確認応答で十分であることを意味します。 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 Double Exchange（DE）モデル。通常、ASPTMおよびASPSMメッセージの二重交換が必要です（簡略化として、ASPSM単一交換はオプションです）。 ASPTMまたはASPSMメッセージの各交換は、いずれかのIPSPによって開始できます。 RKは、AS-SGモデルと同様に、ピアに送信されるトラフィックを定義します。したがって、通常は2つの異なるRKが使用され、1つは各ピアにインストールされます。
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メッセージに二重交換を使用する場合、2方向の接続の管理は独立していると見なされます。つまり、IPSP-AからIPSP-Bへの接続は、IPSP-BからIPSP-Aへの接続とは無関係に処理されます。したがって、2つの方向のうち1つだけがアクティブ化またはクローズされる一方で、もう1つは同じ状態のままになることがあります。
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メッセージ）のみが2つの方向のそれぞれについて独立しています。この場合、IPSP-AまたはIPSP-BからASPSMを送信すると、標準のSG-AS通信で定義されているように、通信全体に影響を与える可能性があります。
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.
In order to ensure interoperability, an M3UA implementation supporting IPSP communication MUST support the IPSP SE model and MAY implement the IPSP DE model.
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:
動作するように構成されている各ASの各リモートASP / IPSPの状態は、ピアM3UAレイヤーで（つまり、それぞれSGPまたはピアIPSPで）維持されます。特定のAS内の特定の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には、ハートビート、ASPダウンACK、およびエラーメッセージを除いて、M3UAメッセージを送信しないでください。
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のDATAまたはSSNMメッセージをASP / IPSPに送信してはなりません（SHOULD NOT）。
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 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.
SCTP CDI：SCTP CDIは、SGP上の上位層プロトコル（M3UA）へのローカルSCTP層の通信ダウン表示を示します。ローカルSCTP層は、ASPのピアSCTP層への接続が失われたことを検出すると、この表示を送信します。 SCTP CDIは、SCTP層からのSHUTDOWN_COMPLETE通知またはCOMMUNICATION_LOST通知として理解されます。
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：SGの上位層プロトコル（M3UA）に対するローカルSCTP層の再起動指示。ローカル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 |
| |
+--------------+
Figure 3: ASP State Transition Diagram, per AS
図3：ASごとのASP状態遷移図
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要求を受信するIPSPで使用して、ピアのSGP / IPSP状態をそれぞれ追跡できます。 ASPにはAS状態マシンごとにSGPが存在する場合があります。
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-IPSP）に使用でき、次のように1つの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メッセージが単一の交換（1つの要求と1つの確認のみ）を使用して交換される場合。例（セクション5.6.2を参照）：DE-IPSPが主導的役割を果たしてピアDE-IPSPとの通信を開始するときは常に、ASP UpメッセージをピアDE-IPSPに送信します。ピアは、メッセージを既に送信しているため、開始DE-IPSPがASP-INACTIVE状態であると見なして、ASP Up Ackで応答してもよい（MAY）。開始側のDE-IPSPがこの応答を受信すると、応答があったため、ピアがASP-INACTIVE状態であると見なすこともできます（MAY）。したがって、ピアDE-IPSPによって開始される2番目の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メッセージ。 RCを指定せずにルーティングキーとは無関係にすべてのトラフィックをアクティブ化/非アクティブ化するASPTMメッセージを送信する場合、1回の交換で十分です。
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：アプリケーションサーバーは利用できません。この状態は、関連するすべてのASPがこのASのASP-DOWN状態であることを意味します。最初、ASはこの状態になります。 Application Serverは、構成から削除されると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：アプリケーションサーバーは使用可能ですが、アクティブなアプリケーショントラフィックはありません。 1つ以上の関連ASPがASP-INACTIVE状態であるか、ASP-ACTIVE状態の関連ASPの数がnに達していません（nは、ASがASに移行する前にASP-ACTIVE状態である必要があるASPの数です） -ACTIVE;このASの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：アプリケーションサーバーが使用可能で、アプリケーショントラフィックがアクティブです。 ASPでASがAS-INACTIVEになり、n個のASP（nは、ASがAS-ACTIVEに移行する前にASP-ACTIVE状態である必要があるASPの数です;オーバーライドトラフィックモードではn = 1）を取得した後、この状態に移行します。 -ACTIVE状態、またはAS-ACTIVEに到達し、1つ以上のASPをASP-ACTIVE状態に維持した後。 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）を開始する必要があり（SHOULD）、すべての着信シグナリングメッセージはSGPによってキューに入れられる必要があります（SHOULD）。 T（r）が期限切れになる前にASPが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.
ASPがASP-ACTIVEになる前にT（r）が期限切れになり、SGPに代替手段がない場合、SGPはメッセージのキューイングを停止し、以前にキューイングされたすべてのメッセージを破棄します。少なくとも1つの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) |
| |<----------------------------| |
+----------+ +-------------+
Figure 4: AS State Transition Diagram
図4：AS状態遷移図
DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state.
DN2IA：1つの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：1つの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：1つの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-ACTIVE状態のASPはありません。
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は最後のASPがASP-ACTIVEとは異なる別の状態になるまでAS-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-Userの準備ができていると想定して、ローカルM3UA ASPメンテナンス（ASPM）機能がASPアップ/ ASPダウン/ ASPアクティブ/ ASP非アクティブを使用して関連する手順を開始します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_STATUS指示プリミティブを呼び出すことにより、レイヤー管理に通知します。 ASPの状態はASP-DOWNに移動します。 ASPでは、MTP-PAUSE指示プリミティブを使用して、影響を受けるSS7宛先が使用できないことをMTP3-Userに通知します。
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-COMMUNICATION_DOWNの場合、SCTPクライアントはSCTPアソシエーションの再確立を試みてもよい（MAY）。これはM3UAレイヤーによって自動的に行われる場合と、M-SCTP_ESTABLISH要求プリミティブを使用してレイヤー管理が再確立される場合があります。
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要求プリミティブによって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.
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.
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識別子が含まれている場合、SGPはそのASPのASP識別子を保存する必要があります。 ASPがすでにSGPでASP-INACTIVEとしてマークされている場合でも、SGPは受信したASP Upメッセージに応答してASP Up Ackメッセージを送信する必要があります。
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メッセージに応答し、「拒否-管理ブロック」という理由のエラーメッセージを返します。
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_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（ack）を開始します。 ASPがT（ack）内にASP Upメッセージへの応答を受信しない場合、ASPはT（ack）を再開し、ASP Up Ackメッセージを受信するまでASP Upメッセージを再送信できます。 T（ack）はプロビジョニング可能で、デフォルトは2秒です。または、ASP Upメッセージの再送信は、レイヤー管理の制御下に置かれる場合があります。この方法では、T（ack）の期限が切れると、M-ASP_UP確認プリミティブに否定的な指示が含まれます。
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は、他のM3UAメッセージ（ASP ActiveやREG REQなど）を送信する前に、ASP Up Ackメッセージを待つ必要があります。 ASPアップメッセージを受信する前にSGPが他のM3UAメッセージを受信した場合（ASPダウン以外。セクション4.3.4.2を参照）、SGPはそれらを破棄してもよい（MAY）。
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-INACTIVE状態と見なす必要があります。 ASPがASP-INACTIVE状態でなかった場合、エラーメッセージを送信してから、それ自体を以前の状態に戻すための手順を開始する必要があります（SHOULD）。
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 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.
IPSPは、ASP UpまたはASP Up Ackを受信した後、ASP-INACTIVE状態と見なされる場合があります。 IPSPは、ASPダウンまたはASPダウンACKを受信した後、ASP-DOWN状態と見なすことができます。 IPSPは、M-ASP_UPまたはM-ASP_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メッセージの交換を実行する必要があります。完了するには4つのメッセージが必要です。
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メッセージにASP Up Ackメッセージで応答できない場合、ASP Upメッセージに「拒否された管理ブロック」という理由のエラーメッセージで応答し、リモートから離れます。 ASP-DOWN状態のIPSP。
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がメンバーであるすべてのアプリケーションサーバーのサービスからASPを削除し、DATA、SSNM、またはASPTMメッセージを受信しない場合、ASPはASPダウンメッセージをSGPに送信します。このアクションは、レイヤ管理からのM-ASP_DOWN要求プリミティブによって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_Down指示プリミティブを通知し、ASPにASP Down Ackメッセージを返します。
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から受信したASPダウンメッセージに応答してASPダウンACKメッセージを送信する必要があります。
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確認プリミティブで通知されます。 ASPがASP Downメッセージを送信せずにASP Down 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ダウンメッセージへの応答を受信しない場合、ASPはT（ack）を再開して、ASPダウンACKメッセージを受信するまでASPダウンメッセージを再送信できます。 T（ack）はプロビジョニング可能で、デフォルトは2秒です。または、ASPダウンメッセージの再送信は、レイヤー管理の制御下に置かれる場合があります。この方法では、T（ack）の期限切れにより、M-ASP_DOWN確認プリミティブが発生し、否定的な指示が示されます。
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はASPがトラフィックの処理を開始する準備ができていることを示すASPアクティブメッセージをSGPに送信できます（MAY）。このアクションは、レイヤ管理からのM-ASP_ACTIVE要求プリミティブによってASPで開始される場合と、M3UA管理機能によって自動的に開始される場合があります。 ASPが共通のSCTPアソシエーション全体で複数のアプリケーションサーバーのトラフィックを処理したい場合、ASPアクティブメッセージには、1つ以上のルーティングコンテキストのリストを含めて、どのアプリケーションサーバーに対してASPアクティブメッセージを示すかを示す必要があります。適用されます。 ASPが1つの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.
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.
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は、関連するルーティングコンテキストを含む1つ以上のASPアクティブACKメッセージで応答し、関連するASPアクティブメッセージに存在するトラフィックモードタイプの値を反映します。受信したASPアクティブメッセージにルーティングコンテキストが含まれている場合は、ルーティングコンテキストパラメータをASPアクティブACKメッセージに含める必要があります。 ASPアクティブメッセージのトラフィックモードタイプ要求、または要求がない場合のローカル構成データに応じて、SGPはASPを関連するアプリケーションサーバー内の正しいASPトラフィック状態に移動します。レイヤ管理は、M-ASP_Active通知で通知されます。 ASPアクティブメッセージが受信される前にSGPまたはIPSPがデータメッセージを受信した場合、SGPまたはIPSPはそれらを破棄してもよい（MAY）。 ASP Active Ackメッセージを送信することにより、SGPまたはIPSPは、関連するルーティングコンテキストのトラフィックを送受信できるようになります。 ASPは、ASP Active Ackメッセージを受信する前に、関連するルーティングコンテキストのデータまたはSSNMメッセージを送信してはなりません（SHOULD NOT）。送信しないと、メッセージが失われるおそれがあります。
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アクティブメッセージに応答して、複数のASPアクティブACKメッセージを使用できます。これにより、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:
ASP Activeメッセージは、RCパラメータの存在/必要性に応じて、次のように応答されます。
- 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アクティブACKメッセージで応答する必要があります。ローカルの理由（管理ロックアウトなど）の場合、SGPはASP Activeメッセージに、「拒否された管理ブロック」という理由のエラーメッセージを返します。
- 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 ASPの構成済みAS」を含むエラーメッセージで応答する必要があります。
- 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）RCパラメータがASPアクティブメッセージに含まれていない場合、（2）RKが（静的構成または動的登録のいずれかによって）定義されており、（3）RCが必須ではない場合、ピアノードはASPアクティブで応答する必要があります（SHOULD）メッセージを確認し、その特定の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).
- 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).
- 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".
- RCパラメータがASPアクティブメッセージに含まれておらず、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から受信したASP Activeメッセージに応答してASP Active Ackメッセージを送信する必要があります。
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 Active Ackメッセージは確認されません。レイヤ管理は、M-ASP_ACTIVE確認プリミティブで通知されます。 SGまたはIPSPからのASPアクティブACKおよびデータメッセージは異なるSCTPストリームで送信される可能性があるため、ASPがASPアクティブACKメッセージの前にデータメッセージを受信する可能性があります。 ASPは、ASP Active 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 Activeメッセージを送信すると、タイマーT（ack）を開始します。 ASPがT（ack）内にASP Activeメッセージへの応答を受信しない場合、ASPはT（ack）を再開して、ASP Active Ackメッセージを受信するまでASP Activeメッセージを再送信できます。 T（ack）はプロビジョニング可能で、デフォルトは2秒です。あるいは、ASPアクティブメッセージの再送信は、レイヤー管理の制御下に置かれる場合があります。この方法では、T（ack）の有効期限が切れると、M-ASP_ACTIVE確認プリミティブが負の指示を伝えます。
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.
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.
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は、通知メッセージ（「代替ASP_Active」）をASの以前のアクティブなASPに送信しなければならず（MUST）、そのASPとのトラフィックを停止する必要があります（SHOULD）。この通知を受信するASPは、オーバーライドASPとのASP間通信を介してこれをまだ認識していない場合、ASP-INACTIVE状態にあると見なす必要があります。
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 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.
ロードシェアモードASの場合、SGPまたはIPSPでASPアクティブメッセージを受信すると、ASで現在アクティブな他のすべてのASPに加えて、ASPアクティブメッセージを送信するASPにトラフィックが送信されます。 AS内のトラフィックをすべてのアクティブなASPにロードシェアするためのSGPでのアルゴリズムは、実装に依存します。アルゴリズムは、たとえば、ラウンドロビンまたはデータメッセージ内の情報（SLS、SCCP SSN、ISUP CIC値など）に基づくことができます。 SGPまたはIPSPは、ロードシェアASの最初のASPのASPアクティブメッセージを受信すると、予想される負荷を処理するのに十分なリソースがあると判断するまで（たとえば、 ASのASP-ACTIVE状態の "n" ASPです）。この場合、SGPまたはIPSPは、十分なリソースが確保されるまで通知（AS-ACTIVE）を保留する必要があります（SHOULD）。
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の場合、SGPまたはIPSPでASPアクティブメッセージを受信すると、ASで現在アクティブな他のすべてのASPに加えて、ASPアクティブメッセージを送信するASPにトラフィックが送信されます。 AS内のトラフィックをすべてのアクティブなASPにブロードキャストするためのSGPでのアルゴリズムは、すべてのメッセージが各アクティブな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は、ロードシェアASの最初のASPのASPアクティブメッセージを受信すると、予想される負荷を処理するのに十分なリソースがあると判断するまで、トラフィックを新しくアクティブなASPに転送しないでください（たとえば、ASにASP-ACTIVE状態の「n」個のASPがあるまで）。この場合、SGPまたはIPSPは、十分なリソースが確保されるまで通知（AS-ACTIVE）を保留する必要があります（SHOULD）。
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.
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.
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.
ブロードキャストモードのASPのASPがASP-ACTIVEになると、SGPは各トラフィックフローでブロードキャストされる最初のDATAメッセージに一意の相関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 Ackメッセージを受信するASPは、まだASP-ACTIVE状態になっていない場合、ピアを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アクティブメッセージの交換を実行する必要があります。完了するには4つのメッセージが必要です。
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はASP非アクティブメッセージをSGPまたはIPSPに送信します。
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非アクティブメッセージにRCパラメータが含まれ、対応するRKが（静的構成または動的登録のいずれかによって）定義されている場合、SGP / IPSPはASP非アクティブ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非アクティブメッセージに（静的構成または動的登録のいずれかで）定義されていないRCパラメーターが含まれている場合、SGP / IPSPはエラーメッセージ「無効なルーティングコンテキスト」を含むエラーメッセージで応答する必要があります。
- 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非アクティブメッセージにRCパラメータが含まれておらず、RKが（静的構成または動的登録のいずれかによって）定義されている場合、SGP / IPSPは、サービスするすべてのASで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非アクティブメッセージに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 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非アクティブメッセージを送信するアクションは、レイヤ管理からのM-ASP_INACTIVE要求プリミティブによってASPで開始される場合と、M3UA管理機能によって自動的に開始される場合があります。 ASPが共通のSCTPアソシエーション全体で複数のアプリケーションサーバーのトラフィックを処理している場合、ASP非アクティブメッセージには、ASP非アクティブメッセージがどのアプリケーションサーバーに適用されるかを示す1つ以上のルーティングコンテキストが含まれます。
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-INACTIVE状態に移行する必要があります。
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.
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.
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に再割り当てされます。通知メッセージ（「ASでアクティブなASPリソースが不足しています」）は、必要に応じてすべての非アクティブなASPに送信できます（MAY）。 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にのみブロードキャストされます。通知メッセージ（「ASでアクティブなASPリソースが不足しています」）は、必要に応じてすべての非アクティブなASPに送信できます（MAY）。 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非アクティブメッセージに応答して、複数のASP非アクティブACKメッセージを使用できます。これにより、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.
ASPから受信したASP非アクティブメッセージに応答して、SGPはASP非アクティブACKメッセージを送信する必要があります。 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 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では、受信したASP Inactive Ackメッセージは確認されません。レイヤ管理は、M-ASP_INACTIVE確認プリミティブで通知されます。 ASPがASP非アクティブメッセージを送信せずにASP非アクティブACKを受信した場合、ASPは自身が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（ack）を開始します。 ASPがT（ack）内にASP非アクティブメッセージへの応答を受信しない場合、ASPはT（ack）を再開し、ASP非アクティブACKメッセージを受信するまでASP非アクティブメッセージを再送信できます。 T（ack）はプロビジョニング可能で、デフォルトは2秒です。または、ASP非アクティブメッセージの再送信は、レイヤー管理の制御下に置かれる場合があります。この方法では、T（ack）の有効期限が切れると、M-ASP_Inactive確認プリミティブが負の表示になります。
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は、ASP-INACTIVE状態にあるAS内のすべてのASPに通知メッセージ（ "AS-Pending"）を送信する必要があります。 SGP SHOULDは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非アクティブまたはASP非アクティブACKメッセージが受信された後、リモート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非アクティブメッセージの交換を実行する必要があります。完了するには4つのメッセージが必要です。
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のASP IDとともに、ASP-DOWN状態にあるものを除いて、AS内のすべてのASPに送信する必要があります。 ASPでは、レイヤー管理はM-NOTIFY表示プリミティブで通知されます。通知メッセージは、AS状態の変化がASPの障害の結果なのか、ASP状態管理（ASPSM）/ ASPトラフィック管理（ASPTM）メッセージの受信の結果なのかに関わらず送信する必要があります。 2番目のケースでは、関連する確認応答メッセージ（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 sending the ASP-UP-ACK, in order to inform the ASP of the current AS state.
ASPが特定のAS内でASP-DOWNからASP-INACTIVEに移動する場合、ASP-UP-ACKを送信した後、ASPに現在のASを通知するために、ASP-UP受容体によって通知メッセージを送信する必要があります（SHOULD）。状態。
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.
トラフィックを処理するためにアクティブなASPがなくなったSGPから通知メッセージ（「AS-PENDING」）メッセージが送信された場合、または通知（「ASでアクティブなASPリソースが不足しています」）メッセージがロードシェアまたはブロードキャストモードの場合、通知メッセージは、メッセージを受信する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.
通知メッセージにルーティングコンテキストパラメータが含まれていない場合、受信者は構成データを介して、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.
Notifyは、SG-ASの場合と同じように機能します。 IPSPの1つは、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以外）で動作する場合に使用できます（MAY）。どちらのM3UAピアも、プロビジョニング可能なタイマーT（beat）に従って、オプションで定期的にハートビートメッセージを送信できます。ハートビートメッセージを受信すると、M3UAピアはハートビートACKメッセージで応答する必要があります。
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ピアからハートビートACKメッセージ（またはその他のM3UAメッセージ）が受信されない場合、リモートM3UAピアは使用不可と見なされます。ハートビートメッセージの送信は停止され、切断されたM3UAピアのクライアントとして構成されている場合、シグナリングプロセスは通信の再確立を試みる必要があります（SHOULD）。
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).
ハートビートメッセージには、関連するハートビートACKメッセージで変更せずにエコーバックする必要がある不透明なハートビートデータパラメータをオプションで含めることができます。送信者は、返されたハートビートACKメッセージの内容を調べると、リモートM3UAピアを使用不可と見なすことを選択できます（MAY）。ハートビートデータパラメーターの内容/形式は実装に依存し、元の送信者がローカルでのみ関心を持つものです。コンテンツは、たとえば、ハートビートシーケンスアルゴリズム（欠落したハートビートを検出するため）やタイムスタンプメカニズム（遅延を評価するため）をサポートするために使用できます。
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メッセージを使用して、アプリケーションサーバー内のASPとしてSGPに動的に登録できます。 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に追加することを許可してもよい（MAY）。または、ルーティングキーが現在存在せず、受信したルーティングキーデータが有効かつ一意である場合、動的構成をサポートするSGPは、新しいルーティングキーと関連するアプリケーションサーバーの作成を承認し、新しいASPにASPを追加できます。どちらの場合でも、SGPは、最初の要求で提供されたものと同じLocal-RK-Identifierと「Successfully Registered」の登録結果を含む登録応答メッセージをASPに返します。 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に返します。
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は登録結果メッセージ「Error Invalid Routing Key」、「Error-Invalid 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.
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.
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.
受信したRKが送信ASPによって静的または動的に完全かつ正確にすでに登録されているとSGPが判断した場合、SGPは登録結果「エラー-ルーティングキーはすでに登録されています」を含む登録応答メッセージをASPに返します。このエラーは、送信するASP / IPSPが、対応するASのASP-ACTIVEまたはASP-INACTIVEのどちらにあっても適用されます。このエラーコードの場合、Registration ResponseメッセージのRCフィールドに、Registration Requestメッセージで指定されたRKに対応するSGPのRCの実際の値を入力する必要があります。
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は、Registration Requestメッセージにルーティングコンテキストパラメータを含めることにより、既存のルーティングキーの変更を要求する場合があります。ルーティングコンテキストを含む登録要求メッセージを受信すると、ルーティングコンテキストが既存のルーティングキーに適用されるとSGPが判断した場合、SGPは既存のルーティングキーを調整して、ルーティングキーパラメータで提供される新しい情報と一致させることができます。 SGPがこの再登録手順をサポートしていないか、RCが存在しない場合、登録応答「ERR Routing Key Change Refused」が返されます。それ以外の場合は、「正常に登録されました」という登録応答が返されます。
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は登録結果「エラー-許可が拒否されました」を含むREG RSPメッセージをASPに返します。
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".
新しいルーティングキーエントリを作成する目的で1つ以上のルーティングキーパラメータがサポートされていないとSGPが判断した場合、SGPは登録結果「エラー-サポートされていないRKパラメータフィールド」を含む登録応答メッセージをASPに返します。
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は、1つのREG RSPメッセージで各登録要求に応答して、個別の登録結果パラメータで各ルーティングキーの成功または失敗の結果を示してもよい（MAY）。あるいは、SGPは複数のREG RSPメッセージで応答する場合があり、それぞれに1つ以上の登録結果パラメーターがあります。 ASPはLocal-RK-Identifierパラメーターを使用して、要求と応答を関連付けます。
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
ASPがASに正常に登録されると、ASPが状態ASP-INACTIVEに遷移するときに以前に開始していなかった場合、SGPは関連するSS7シグナリングネットワーク管理メッセージングを送信できるようになりました。
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-INACTIVE状態に移行する必要があります（つまり、ASP非アクティブACKの受信後に登録を解除します）。また、ASPは、ASPダウン状態への移行を試みる前に、それがメンバーであるすべてのアプリケーションサーバーから登録解除する必要があります（SHOULD）。
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はルーティングキーデータを削除できます（MAY）。
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にDEREG RSPメッセージを返すことにより、登録解除要求を確認します。登録解除の結果は、Deregistration Resultパラメーターにあり、成功または失敗の原因を示します。
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は、1つのDEREG RSPメッセージで各登録解除要求に応答して、個別の登録解除結果パラメーターで各ルーティングコンテキストの成功または失敗の結果を示してもよい（MAY）。
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.
登録/登録解除の手順は、AS-SGの場合と同じ方法でIPSPの場合に機能します。 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レイヤーは、対応するSS7シグナリングネットワーク管理（SSNM）DUNA、DAVA、SCON、またはDUPUメッセージ（関係するASPのM3UAピアへのセクション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.
ASPがASに対してアクティブになり、ASに通常アクセス可能な宛先がアクセス不能、制限、または輻輳している特定の場合、SGは、アクセス不能、制限、または輻輳した宛先のDUNA、DRST、またはSCONメッセージをASPに送信できます（MAY）。 ASPがアクセスできない、制限されている、または混雑していることを他の方法ではわからない可能性がある宛先へのトラフィックの送信を防ぐために、ASで新たにアクティブになります。 SGPがASPアクティブメッセージを受信した新しくアクティブ化されたASPの場合、アクティブ化手順を完了するASPアクティブAckを送信する前に、これらのDUNA、DRST、およびSCONメッセージを送信できます。
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-Usersに呼び出します。地元の管理者に通知されます。
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宛先の利用不可または輻輳ステータスを引き起こした場合、同等のSSNMメッセージが受信されたかのように、ASPのM3UAレイヤーは、プリミティブの適切な指示をM3UAユーザーに渡す必要があります。たとえば、SGPへのSCTPアソシエーションが失われると、SS7宛先のセットが使用できなくなる場合があります。 M3UAユーザーへのMTP-PAUSE指示プリミティブが適切です。
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を介して影響を受けるルートのステータスを更新し、影響を受ける宛先の全体的な可用性または輻輳ステータスかどうかを判断します（ s）が変更されました。その場合、M3UAレイヤーは、常駐M3UA-Usersに適切なプリミティブ表示を呼び出します。地元の管理者に通知されます。
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.
実装上の注意：これを実現するために、MTP3レイヤーがルートセットステータスを維持するように、ASPのM3UAレイヤーはSGを介してルートのステータスを維持します。
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に送信され、1つ以上のSS7宛先ポイントコードの現在の可用性と輻輳ステータスを要求します。
The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by the ASP in the following cases:
DAUDメッセージはシーケンスなしで送信される場合があります。 DAUDは、次の場合にASPによって送信される場合があります。
- 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は、通信する予定の1つ以上の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").
実装上の注意：上記の最初のケースでは、「no congestion」または「undefined」（つまり、輻輳レベル=「0」）の輻輳レベル値を含む受信したSCONメッセージの場合、監査手順を呼び出さないでください。 。
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 SHOULDは、DAUDメッセージ内の各宛先ポイントコードに関連付けられたルートセットのMTP3可用性/輻輳ステータスでDAUDメッセージに応答する必要があります（SHOULD）。要求された各SS7宛先のステータスは、DUNAメッセージ（利用できない場合）、DAVAメッセージ（利用できる場合）、またはDRST（制限されていて、SGPが国内ネットワークでこの機能をサポートしている場合）で示されます。国内ネットワークの場合、SGP SHOULDは、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").
SGは、たとえば、ASPが宛先のステータスを知ることが許可されていない場合、宛先のアベイラビリティまたは輻輳ステータスの提供を拒否する場合があります。 SGはエラーメッセージ（エラーコード=「宛先ステータス不明」）で応答する場合があります。
An SG SHOULD respond with a DUNA message when DAUD was received with an unknown Signalling Point Code.
SGは、DAUDが不明なシグナリングポイントコードで受信されたときに、DUNAメッセージで応答する必要があります（SHOULD）。
In the case where the MTP3 in the SG undergoes an MTP restart, event communication SHOULD be handled as follows:
SGのMTP3がMTP再起動を受ける場合、イベント通信は次のように処理する必要があります（SHOULD）。
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.
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.
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通知を受信し、ASPがこのSGPに対してASP-ACTIVE状態にある場合、新しく利用可能なSS7宛先へのトラフィックを再開できます。
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.
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.
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.
ASPがASに対してアクティブになり、SGがSS7ネットワーク分離を経験している場合、またはASに対してMTP再起動手順を実行している場合、SGは、関連する宛先のDUNAメッセージを新しくアクティブなASPに送信して、ASPがトラフィックを送信しないようにすることができます。 。これらのメッセージは、ASPアクティブを受信した後、ASPアクティブ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.
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.
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は1つ以上のアクティブなASにサービスを提供し続けることができますが、部分的な障害のために1つ以上の他のアクティブなASにサービスを提供できない場合）、SGPは接続されているすべてのデバイスにASP Inactive Ackを送信する必要があります影響を受けるASのASP。 NIFから部分的に隔離されているにもかかわらず、影響を受けるASのASPアクティブメッセージを受信すると、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シャットダウン手順を実行します。
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間、または2つの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が1つだけ構成されています（バックアップなし）。
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)----->|
| |
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)----->|
| |
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など）、Register Responseメッセージには失敗の表示が含まれ、ASPはその後ASP Activeメッセージを送信しません。
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)---->|
| |
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など）、Register Responseメッセージには失敗の表示が含まれ、ASPはその後ASP Activeメッセージを送信しません。各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.
次のRegistration Requestを送信する前に、Registration Request / ResponseメッセージのペアにASP Activeメッセージを従う必要はありません。 ASP Activeメッセージは、関連する登録が成功した後、いつでも送信できます。
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)---->|
| |
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など）、Register Responseメッセージには失敗の指示が含まれ、ASPはその後ASP Activeメッセージを送信しません。各LRC / RKペア登録は個別に考慮されます。
The ASP Active message can be sent at any time after the related successful registration and may have more than one RC.
The ASP Active message can be sent at any time after the related successful registration and may have more than one 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と2つのASP間のトラフィックを確立するためのM3UAメッセージフローの例を示しています。失敗または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)------->|
| | |
5.1.3. Two ASPs in an Application Server ("1+1" Sparing, Loadsharing Case)
5.1.3. アプリケーションサーバー内の2つの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.
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.
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. アプリケーションサーバー内の3つの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と3つのASPの間のトラフィックを確立するためのM3UAメッセージフローの例を示しています。2つのASPがASP-ACTIVE状態になり、その後で負荷を共有します。この場合、総トラフィック負荷（2 + 1スペアリング）を処理するには、最低2つのASPが必要です。
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)------------>|
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)-->| |
| | |
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)-->|
| | | |
| | | |
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がロードシェア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がASP非アクティブACKメッセージを受信した）は、サービスから削除される場合、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-------->|
| |
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が以前にApplication Server内の構成に登録手順を使用していた場合は、通常、登録解除手順が使用されます。 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(2) -------- |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DAVA ---------- |
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DUNA ---------- |
This section describes the primitive mapping between the MTP3 User and the M3UA layer at an ASP.
このセクションでは、MTP3ユーザーとASPの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-UserにリモートMTP3-Userに送信するデータがある場合、MTP-TRANSFER要求プリミティブを使用します。 ASPのM3UA層は、M3UAユーザーからMTP-TRANSFER要求プリミティブを受信すると、次のことを行います。
- 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.
- DATAメッセージのオプションフィールドに入力するかどうかを決定します。
- Map the MTP-TRANSFER request primitive into the Protocol Data field of a DATA message.
- MTP-TRANSFER要求プリミティブをDATAメッセージのプロトコルデータフィールドにマップします。
- Send the DATA message to the remote M3UA peer at the SGP, over the SCTP association.
- SCTPアソシエーションを介して、SGPのリモートM3UAピアにDATAメッセージを送信します。
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ピアからDATAメッセージを受信すると、次のことを行います。
- Evaluate the optional fields of the DATA message, if present.
- 存在する場合は、DATAメッセージのオプションフィールドを評価します。
- Map the Protocol Data field of a DATA message into the MTP-TRANSFER indication primitive.
- DATAメッセージのプロトコルデータフィールドを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.
- 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.
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宛先の可用性/輻輳状態を監査する可能性がある状況があります。注：これは内部M3UA管理機能によって開始されるため、MTP3-UserがM3UA層からこの監査を要求するためのプリミティブはありません。
SGP ASP
| |
|<----------DAUD-----------|
|<----------DAUD-----------|
|<----------DAUD-----------|
| |
| |
This section describes the primitive mapping between the MTP3-User and the M3UA layer at an SGP.
このセクションでは、STPでのMTP3-Userと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ネットワークを宛先とするピアからDATAメッセージを受信すると、次のことを行います。
- Evaluate the optional fields of the DATA message, if present, to determine the Network Appearance.
- DATAメッセージのオプションのフィールドがある場合はそれを評価して、ネットワークの外観を決定します。
- Map the Protocol data field of the DATA message into an MTP-TRANSFER request primitive.
- DATAメッセージのプロトコルデータフィールドをMTP-TRANSFER要求プリミティブにマッピングします。
- Pass the MTP-TRANSFER request primitive to the MTP3 of the concerned Network Appearance.
- MTP-TRANSFER要求プリミティブを関係するネットワークアピアランスのMTP3に渡します。
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.
- DATAメッセージのオプションフィールドに入力するかどうかを決定します。
- Map the MTP-TRANSFER indication primitive into the Protocol Data field of a DATA message.
- MTP-TRANSFER表示プリミティブをDATAメッセージのプロトコルデータフィールドにマッピングします。
- Send the DATA message to the remote M3UA peer in the ASP, over the SCTP association.
- Send the DATA message to the remote M3UA peer in the ASP, over the SCTP association.
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-PAUSE、MTP-RESUME、MTP-STATUS表示プリミティブのサポート
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 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のMTP3層は、SS7宛先に到達できないとローカルで判断したときに、MTP-PAUSE指示プリミティブを生成します。 M3UAレイヤーは、このプリミティブをDUNAメッセージにマップします。 SGP M3UA層は、MTP-PAUSE表示プリミティブ表示に関連付けられた内部SS7ネットワーク情報に基づいて、通知される一連の関連ASPを決定します。
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.-->
| |
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メッセージにマップします。目的のアプリケーションサーバーに基づいて、SCONメッセージを送信するASPを決定します。
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-STATUS表示プリミティブを生成します。 M3UAレイヤーは、このプリミティブをDUPUメッセージにマップします。目的のアプリケーションサーバーに基づいて、DUPUを送信するASPを決定します。
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.
これらのシナリオは、接続の3つのフェーズ（確立、データ交換、切断）のための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---------->|
| |
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)
| |
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.
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.
Implementations MUST follow the normative guidance of RFC3788 [11] on the integration and usage of security mechanisms in SIGTRAN protocols.
実装は、SIGTRANプロトコルのセキュリティメカニズムの統合と使用に関するRFC3788 [11]の規範的なガイダンスに従う必要があります。
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 DATAチャンクのペイロードプロトコル識別子にM3UA値を割り当てました。次のSCTP Payload Protocol Identifierが登録されています。
M3UA "3"
一緒に "p"
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がM3UAプロトコルを伝送していることを示すために、各SCTP DATAチャンクに含める必要があります（SHOULD）。値 "0"（未指定）も許可されますが、他の値は使用してはなりません（MUST NOT）。このPayload Protocol IdentifierはSCTPで直接使用されませんが、DATAチャンクで運ばれる情報のタイプを識別するために特定のネットワークエンティティで使用される場合があります。
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によって提示されるデータに関する追加情報を決定する方法として、ペイロードプロトコル識別子を使用してもよい（MAY）。
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 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.
This protocol may also be extended through IANA in three ways:
このプロトコルは、IANAを介して次の3つの方法で拡張することもできます。
- 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アダプテーションレイヤーの不可欠な部分です。したがって、これらの拡張機能は、RFC [23]のIANA考慮事項セクションを作成するためのガイドラインで定義されているIETFコンセンサスアクションを通じて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) A long and short name for the new message class. (b) A detailed description of the purpose of the message class.
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) 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.
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.
著者は、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、に感謝します。ハワード・メイ、フランソワ・ムイヤード、バリー・ナーゲルベルク、ニール・オルソン、ハインツ・プラントナー、シャマル・プラサド、ムケシュ・プンハニ、セルヴァム・レンガサミ、ジョン・シャンツ、レイ・シン、マイケル・トゥクセン、ニティン・トマール、ジェリー・ヴェルインプ、ティム・ベッター、渡辺一夫、ベン・ウィルソン、その他多数彼らの貴重なコメントや提案のために他の人。
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
イアン・リティナ-エリクソン・ガイ・ムソー-ノーテル・ネットワークス・リンドン・オン-シエナ・ハンス・ユルゲン・シュワルツバウアー-シーメンス・クラウス・グラディシュニグ-デテコン・インクマレッシュ・カラ-パフォーマンス・テクノロジーブライアン・ビデュロック-OpenSS7ジョン・ローニー-ノキア・グレッグ・サイドボトム-サインアット
[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、「Signalling System No.7（SS7）-ISDN User Part（ISUP）」
[2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[2] ANSI T1.113-"Signaling System Number 7-ISDN User Part"
[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）、信号システムNo.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、「Signalling System No. 7（SS7）-Signaling Connection Control Part（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, "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"
[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、「Signaling System No. 7（SS7）-Message Transfer Part（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、「Integrated Services Digital Network（ISDN）; Signaling System No.7; Message Transfer Part（MTP）to support international interconnecting; Part 1：Protocol specification」
[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、「Signaling Transport for Signaling Transport（SIGTRAN）Protocols」、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., and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[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 Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7) - Transaction Capabilities (TCAP)"
[15] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities Application Part"
[15] ANSI T1.114「Signaling System Number 7-Transaction Capabilities Application Part」
[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）「技術仕様-第3世代パートナーシッププロジェクト;技術仕様グループ無線アクセスネットワーク; 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] スチュワート、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV. Paxson、 「ストリーム制御伝送プロトコル」、RFC 2960、2000年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、「RFCで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.、and J. Heitz、 "Signaling System 7（SS7）Message Transfer Part 2（MTP2）-User Adaptation Layer"、RFC 3331、September 2002 。
[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.、and K. Morneault、 "Signaling System 7（SS7）Message Transfer Part 2（MTP2）-User Peer-to-Peer Adaptation Layer（M2PA ） "、RFC 4165、2005年9月。
[26] Telecommunication Technology Committee (TTC) Standard JT-Q704, "Message Transfer Part Signaling Network Functions", April 28, 1992.
[26] Telecommunication Technology Committee（TTC）Standard JT-Q704、「Message Transfer Part Signaling Network Functions」、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-Userシグナリングトラフィックを複数の分散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またはSG、冗長ホストの使用、およびSCTPエンドポイント間のSCTPアソシエーション用の冗長QOS境界IPネットワークパスのプロビジョニングによって実現できます。明らかに、SG、MGC、およびその他のIPベースの機能要素の信頼性も考慮する必要があります。利用可能なホスト内でのASPとSGPの配布も考慮される場合があります。例として、特定のアプリケーションサーバーの場合、関連するASPを少なくとも2つのホストに分散できます。
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:
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:
SGs MGCs
SG MGC
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は1つ以上のアプリケーションサーバーにサービスを提供することができ、SCTPエンドポイントとして識別されます。 1つ以上のシグナリングゲートウェイプロセスが1つのシグナリングゲートウェイを構成します。
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 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.
上記の例では、各シグナリングプロセス（SGP、ASP、またはIPSP）が複数のSCTPアソシエーションのエンドポイントであり、他の複数のシグナリングプロセスにつながります。これをサポートするには、シグナリングプロセスが、多数の同時アクティブアソシエーションへのM3UAメッセージの配信をサポートできる必要があります。このメッセージ配信機能は、プロビジョニングされたルーティングキーのステータス、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.
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.
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
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」冗長性の場合、Host3のASP1には、DPC = xの着信メッセージが送信されます。 Host4のASP1は、通常、ASP1 / Host1の障害または接続の喪失時に「アクティブ」状態になります。
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
Host1のSGP1にあるASリストは、ロードシェアモードで設定することもできます。
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にトラフィックの一部が送信されます。たとえば、2つの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.
たとえば、2つのASPは共有メモリを介して呼状態を共有するか、ASP to ASPプロトコルを使用して呼状態情報を渡すことができます。この機能をサポートするASP-to-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モデルと同様に、SGは、アクティブ/バックアップモデルまたはロードシェアリングモデルを使用して、1つ以上のホストに分散された1つ以上のSGプロセス（SGP）で構成されます。 SGPがすべてまたは一部のSS7接続を失い、他のSGPが存在する場合、SGPは関係するASPへのSCTPアソシエーションを終了する場合があります。
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として機能するホストのクラスターとして展開されます。プライマリ/バックアップ冗長モデルが可能です。プライマリSGPへのSCTPアソシエーションが使用できないことを利用して、影響を受けるトラフィックを代替SGPに再ルーティングできます。シグナリングメッセージが複数のSGP間でロードシェアされるロードシェアリングモデルが可能です。 SG内のアクティブな各SGPにシグナリングメッセージが送信されるブロードキャストモデルも可能です。 SGPを介したMTP3ユーザーメッセージの配布は、SS7ユーザーパーツで必要とされるメッセージのミスシーケンスを最小限に抑えるような方法で行う必要があります。
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は、SGの少なくとも1つのSGPとのSCTPアソシエーションが確立された場合、プロビジョニングされたSS7宛先Xにトラフィックを転送できます。SGPは確認応答をASPに返しました。 ASPがその宛先Xのトラフィックをアクティブに処理していることを示し、SGPは宛先Xにアクセスできないことを示しておらず、SGPはMTP再起動を示していません。トラフィックをSS7ネットワークに転送するために複数のSGPを使用するようにASPが構成されている場合、ASPは、対象の宛先へのトラフィックを処理するSGPの現在の機能の知識を維持する必要があります。この情報は、障害や回復および保守活動が発生した場合の、アクティブ/バックアップ、ロードシェアリング、およびブロードキャストモデルのサービスの全体的な信頼性にとって重要です。 ASP M3UAは、輻輳回避の目的でこの情報を使用する場合もあります。 SGPを介したMTP3ユーザーメッセージの配信は、SS7ユーザーパーツで必要とされるメッセージのシーケンスミスを最小限に抑えるような方法で行う必要があります。
Editors' Addresses
編集者のアドレス
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA, USA 20171
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon、VA、USA 20171
EMail: kmorneau@cisco.com
Javier Pastor-Balbas Ericsson Espana S.A. C/ Retama 1 28045 Madrid - Spain
ハビエル牧師-バルバスエリクソンエスパーニャS.A. C /レタマ1 28045マドリード-スペイン
EMail: j.javier.pastor@ericsson.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（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.
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.
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事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンライン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は、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。