[要約] 要約： RFC 3332は、SS7のMTP3とM3UAのユーザ適応層に関する仕様を定義しています。目的： このRFCの目的は、SS7ネットワークでのメッセージ転送を効率的かつ信頼性の高い方法で実現するためのプロトコルを提供することです。
Network Working Group G. Sidebottom
Request for Comments: 3332 Signatus Technologies
Category: Standards Track K. Morneault
Cisco
J. Pastor-Balbas
Ericsson
Editors
September 2002
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
シグナリングシステム7（SS7）メッセージ転送パート3（MTP3） - ユーザー適応レイヤー（M3UA）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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.
このメモは、ストリーム制御伝送プロトコルのサービスを使用して、IPよりもSS7 MTP3ユーザーシグナル伝達（ISUPおよびSCCPメッセージなど）の輸送をサポートするためのプロトコルを定義します。また、SS7およびIPドメインのMTP3ユーザーピアのシームレスな操作を可能にするプロトコル要素のプロビジョニングが作成されます。このプロトコルは、シグナリングゲートウェイ（SG）とメディアゲートウェイコントローラー（MGC）またはIP居住者のデータベースの間、または2つのIPベースのアプリケーション間で使用されます。SGは、SS7メッセージ転送パーツ（MTP）を使用して標準のSS7インターフェイスを介してSS7シグナル伝達を受信して輸送を提供すると想定されています。
Table of Contents
目次
1. Introduction..................................................3
1.1 Scope.........................................................3
1.2 Terminology...................................................4
1.3 M3UA Overview.................................................6
1.4 Functional Areas.............................................10
1.5 Sample Configurations........................................18
1.6 Definition of M3UA Boundaries................................21
2. Conventions..................................................25
3. M3UA Protocol Elements.......................................25
3.1 Common Message Header........................................26
3.2 Variable Length Parameter....................................29
3.3 Transfer Messages............................................31
3.4 SS7 Signalling Network Management (SSNM) Messages............35
3.5 ASP State Maintenance (ASPSM) Messages.......................45
3.6 Routing Key Management (RKM) Messages........................48
3.7 ASP Traffic Maintenance (ASPTM) Messages.....................59
3.8 Management (MGMT) Messages...................................63
4. Procedures...................................................69
4.1 Procedures to Support the M3UA-User .........................69
4.2 Procedures to Support the Management of SCTP Associations ...70
4.3 AS and ASP State Maintenance.................................72
4.4 Routing Key Management Procedures............................87
4.5 Procedures to Support the Availability or Congestion Status
of SS7 Destination...........................................89
4.6 MTP3 Restart.................................................92
5. Examples of M3UA Procedures..................................93
5.1 Establishment of Association and Traffic
Between SGs and ASPs.........................................93
5.2 ASP traffic Failover Examples................................99
5.3 Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association..............................100
5.4 M3UA/MTP3-User Boundary Examples............................101
5.5 Examples of IPSP communication..............................105
6. Security Considerations.....................................108
6.1 Introduction................................................108
6.2 Threats.....................................................108
6.3 Protecting Confidentiality..................................108
7. IANA Considerations.........................................109
7.1 SCTP Payload Protocol Identifier............................109
7.2 M3UA Port Number............................................109
7.3 M3UA Protocol Extensions....................................109
8. References...................................................111
8.1 Normative References........................................111
8.2 Informative References......................................111
9. Acknowledgements.............................................113
10. Document Contributors.......................................113
Appendix A......................................................114
A.1 Signalling Network Architecture.............................114
A.2 Redundancy Models...........................................117
Editors' Addresses..............................................119
Full Copyright Statement........................................120
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 [17]. 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 Gaway Controller (MGC) or IP-resident Database [11], or between two IP-based applications.
このメモは、ストリーム制御伝送プロトコルのサービスを使用して、IPよりもSS7 MTP3ユーザーシグナル伝達（ISUPおよびSCCPメッセージなど）の輸送をサポートするためのプロトコルを定義します[17]。また、SS7およびIPドメインのMTP3ユーザーピアのシームレスな操作を可能にするプロトコル要素のプロビジョニングが作成されます。このプロトコルは、シグナリングゲートウェイ（SG）とメディアゲーイコントローラー（MGC）またはIP居住者データベース[11]の間、または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 [11]. The delivery mechanism should meet the following criteria:
SS7シグナリングゲートウェイ（SG）からメディアゲートウェイコントローラー（MGC）またはSignal Cransportのフレームワークアーキテクチャで説明されているように、メディアゲートウェイコントローラー（MGC）またはIP居住者データベースへのスイッチング回路ネットワーク（SCN）シグナリングプロトコルの配信が必要です[11]。送達メカニズムは、次の基準を満たす必要があります。
* Support for the transfer of all SS7 MTP3-User Part messages (e.g., ISUP [1,2,3], SCCP [4,5,6], TUP [12], etc.)
* Support for the seamless operation of MTP3-User protocol peers
* Support for the management of SCTP transport associations and traffic between an SG and one or more MGCs or IP-resident Databases
* Support for MGC or IP-resident Database process failover and load sharing
* Support for the asynchronous reporting of status changes to management
*すべてのSS7 MTP3ユーザーパーツメッセージの転送のサポート（例：ISUP [1,2,3]、SCCP [4,5,6]、TUP [12]など）
* MTP3ユーザープロトコルピアのシームレスな操作のサポート
* SCTP輸送協会の管理とSGと1つ以上のMGCまたはIP居住者のデータベース間のトラフィックのサポート
* MGCまたはIP-Residentデータベースプロセスフェールオーバーとロード共有のサポート
*管理へのステータスの変更の非同期報告のサポート
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]、ISUP、SCCPおよび/またはその他のMTP3ユーザープロトコルメッセージ、およびSCTP輸送を介して特定の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 unique range of PSTN trunks, identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a virtual database element, handling all HLR transactions for a particular SS7 DPC/OPC/SCCP_SSN 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.
Application Server（AS） - 特定のルーティングキーを提供する論理エンティティ。アプリケーションサーバーの例は、SS7 SIO/DPC/OPC/CIC_RANGEによって識別される一意の範囲のPSTNトランクのすべてのコール処理を処理する仮想スイッチ要素です。別の例は、仮想データベース要素であり、特定のSS7 DPC/OPC/SCCP_SSNの組み合わせのすべての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ユーザープロトコルデータユニットと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は、M3UAをポイントツーポイントで使用することを除いて、ASPと本質的に同じです。概念的には、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.
Linkset-モジュールとして使用される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 it belongs to. 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.
ネットワークバイトの順序：最も重要なバイト最初、別名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 either configured using a configuration management interface, or by using the routing key management procedures defined in this document.
ルーティングコンテキスト - ルーティングキーを一意に識別する値。ルーティングコンテキスト値は、構成管理インターフェイスを使用して構成されるか、このドキュメントで定義されているルーティングキー管理手順を使用して構成されます。
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 - An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network [11]. 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は、IPネットワークの端でSCNネイティブシグナル伝達を受信/送信するシグナル伝達剤です[11]。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の可用性 /混雑 /ユーザー_PARTステータスも考慮する必要があります。
Stream - A stream refers to an SCTP stream; a unidirectional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the unordered delivery service.
ストリーム - ストリームはSCTPストリームを指します。あるSCTPエンドポイントから別の関連するSCTPエンドポイントに確立された単方向論理チャネル。内部では、すべてのユーザーメッセージが順序付けられていない配信サービスに提出されたものを除き、シーケンスで配信されます。
The framework architecture that has been defined for SCN signalling transport over IP [11] 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シグナル伝達輸送用に定義されているフレームワークアーキテクチャ[11]は、一般的なシグナル伝達輸送プロトコルと適応モジュールを含む複数のコンポーネントを使用して、基礎となるプロトコル層から特定の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) [12]. TCAP [13,14,15] or RANAP [16] messages are transferred transparently by the M3UA protocol as SCCP payload, as they are SCCP-User protocols.
フレームワークアーキテクチャ内で、このドキュメントは、MTPユーザーとしてMTPレベル3に識別されるプロトコルレイヤーのメッセージの転送をサポートするのに適したMTP3ユーザー適応モジュールを定義します。これらのプロトコルレイヤーのリストには、ISDNユーザーパーツ（ISUP）[1,2,3]、シグナリング接続制御パーツ（SCCP）[4,5,6]および電話ユーザーパーツ（TUP）[]が含まれますが、これらに限定されません。12]。TCAP [13,14,15]またはラナップ[16]メッセージは、SCCPユーザープロトコルであるため、SCCPペイロードとしてM3UAプロトコルによって透過的に転送されます。
It is recommended that M3UA use the services of the Stream Control Transmission Protocol (SCTP) [17] as the underlying reliable common signalling transport protocol. This is to take advantage of various SCTP features such as:
M3UAは、基礎となる信頼できる共通シグナル伝達輸送プロトコルとして、Stream Control Transmission Protocol（SCTP）[17]のサービスを使用することをお勧めします。これは、次のようなさまざまな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, and - 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 SS7のMTP3ユーザーに提供されるように、MTP3ユーザーに上層のプリミティブの同等のプリミティブセットを提供します。このようにして、ASPまたはIPSPでのISUPおよび/またはSCCP層は、予想されるMTP3サービスが、ローカルMTP3層ではなく、SGPのMTP3層からリモートで提供されていることを知りません。SGPのMTP3レイヤーは、ローカルユーザーが実際にM3UAを超えるリモートユーザーパーツであることを知らない場合があります。実際、M3UAはMTP3レイヤーサービスへのアクセスをリモートIPベースのアプリケーションに拡張します。M3UAレイヤー自体はMTP3サービスを提供していません。ただし、ASPが複数のSGに接続されている場合、ASPのM3UAレイヤーは、各SGを介してこれらの宛先へのルートの可用性と輻輳状態に従って、構成されたSS7宛先とルートメッセージのステータスを維持する必要があります。
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転送プリミティブの輸送を提供します。
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, minimizing missequencing.
ASPでは、宛先が複数のSGPを介して到達可能な場合、M3UAレイヤーは、SGPがルーティングまたは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 [21]) may permit larger block sizes.
M3UA層は、SS7 MTPレベル2プロトコル[7,8,9]で指定されているように、272-OCTETシグナリング情報フィールド（SIF）の長さ制限を課しません。最近のSCCPまたはISUPバージョンで指定されているように、上層のセグメンテーション/再組み立て手順を必要とせずに、より大きな情報ブロックをM3UA/SCTPによって直接収容できます。ただし、SGのコンテキストでは、最終目的地へのより大きな情報ブロックの転送をサポートしないSS7ネットワークにインターワーキングする場合、最大272-OCTETブロックサイズに従う必要があります。これにより、SGPでの潜在的なISUPまたはSCCP断片化要件が回避されます。SS7ネットワークのプロビジョニングと構成により、最大ブロックサイズに配置された制限が決まります。一部の構成（ブロードバンドMTP [21]など）は、より大きなブロックサイズを可能にする場合があります。
The M3UA layer provides the capability to indicate errors associated with received M3UA messages and to notify, as appropriate, local management and/or the peer M3UA.
M3UAレイヤーは、受信したM3UAメッセージに関連付けられたエラーを示し、必要に応じてローカル管理および/またはピアM3UAに通知する機能を提供します。
At the SGP, the M3UA layer provides interworking with MTP3 management functions to support seamless operation of the user SCN signalling applications in the SS7 and IP domains. This includes:
SGPでは、M3UAレイヤーはMTP3管理機能とのインターワーキングを提供し、SS7およびIPドメインでのユーザーSCNシグナリングアプリケーションのシームレスな操作をサポートします。これも：
- Providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is not reachable.
- ASPでMTP3ユーザーにSS7ネットワークの目的地に到達できないことを示しています。
- Providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is now reachable.
- ASPでMTP3ユーザーにSS7ネットワークの目的地に到達可能になったことを示しています。
- Providing an indication to MTP3-Users at an ASP that messages to a destination in the SS7 network are experiencing SS7 congestion.
- ASPでMTP3ユーザーにSS7ネットワークの目的地にメッセージを送信していることを示す兆候を提供しているのは、SS7の輻輳が発生していることを示しています。
- Providing an indication to the M3UA layer at an ASP that the routes to a destination in the SS7 network are restricted.
- ASPでM3UA層に兆候を提供すると、SS7ネットワークの宛先へのルートが制限されていることを示します。
- Providing an indication to MTP3-Users at an ASP that a MTP3-User peer is unavailable.
- ASPでMTP3ユーザーにMTP3ユーザーのピアが利用できないことを示しています。
The M3UA layer at an ASP keeps the state of the routes to remote SS7 destinations and may initiate an audit of the availability, the restricted or the congested state of remote SS7 destinations. This information is requested from the M3UA layer at the SGP.
ASPのM3UAレイヤーは、ルートの状態をリモートSS7の目的地への状態に保ち、可用性、制限または混雑したSS7宛先の監査を開始する場合があります。この情報は、SGPのM3UAレイヤーから要求されます。
The M3UA layer at an ASP may also indicate to the SG that the M3UA layer itself or the ASP or the ASP's Host is congested.
ASPのM3UA層は、SGにM3UA層自体またはASPまたはASPのホストが混雑していることを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. As well, the active/inactive and congestion state of remote ASPs is maintained.
SGPのM3UA層は、SCTP関連とM3UAピア間のトラフィックを管理するために、構成されたすべてのリモートASPの可用性状態を維持します。同様に、リモート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層は、PEER 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.
ローカルマネジメントは、M3UAレイヤーからM-SCTP_STATUSリクエストを使用して基礎となるSCTP関連のステータスを要求し、プリミティブを確認できます。また、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のステータスの変化をローカル管理に通知する場合があります。これは、M-ASP_STATUSリクエストまたはM-AS_STATUSリクエストPrimitivesを使用して達成できます。
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ネットワーク内では、シグナリングゲートウェイがルーティング目的でSS7ネットワークにIPドメイン内の一連のノードを表すことで充電される場合があります。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 represents a set of nodes in the IP domain into each SS7 network. Alias Point Codes [8] may also be used within an SG network appearance.
SGは、複数のSS7ネットワークの外観で動作するように論理的に分割される場合があります。このような場合、SGは各ネットワークの外観のポイントコードでアドレス指定でき、各SS7ネットワークのIPドメイン内の一連のノードを表します。エイリアスポイントコード[8]は、SGネットワークの外観内でも使用できます。
Where an SG contains more than one SGP, the MTP3 routeset, SPMC and remote AS/ASP states of each SGP SHOULD be coordinated across all the SGPs. Rerouting of traffic between the SGPs MAY also be supported.
SGに複数のSGPが含まれている場合、各SGPのMTP3ルートセット、SPMC、およびリモートAS/ASP状態をすべてのSGPで調整する必要があります。SGP間のトラフィックの再ルーティングもサポートされる場合があります。
Application Servers can be represented under the same Point Code of the SG, 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ネットワークから「STPS」と見なすことができ、それぞれが同じASPへの「継続的な「ルート」があります。ASPがSGSの1つから利用できない障害条件下では、このアプローチにより、SGとSS7ネットワーク間のMTP3ルート管理メッセージが可能になり、宛先ポイントコードアドレスを変更せずに代替SGを介して簡単なSS7を再ルーティングできます。SS7 ASPへのトラフィック。
Where a particular AS can be reached via more than one SGP, the corresponding Routing Keys in the SGPs should be identical. (Note: It is possible for the SGP Routing Key configuration data to be temporarily out-of-sync during configuration updates).
複数のSGPを介して特定のAsに到達できる場合、SGPの対応するルーティングキーは同一である必要があります。（注：SGPルーティングキー構成データが、構成の更新中に一時的にシンク外になる可能性があります）。
+--------+
| |
+------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ----
| SEP +---+ +--------+ +---/ \
| or | |* | ASPs |
| STP +---+ +--------+ +---\ /
+-------+ | | | | ----
+------------+ SG 2 +--------------+
| "STP" |
+--------+
Figure 1 Example with mated SGs
図1交配されたSGSの例
* Note:. SG-to-SG communication (i.e., "C-links") is recommended for carrier grade networks, using an MTP3 linkset or an 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.
* 注記：。SG-to-SG通信（つまり、「C-Links」）は、経路障害が発生した場合にSGS間の再ルーティングを可能にするために、MTP3リンクセットまたは同等物を使用して、キャリアグレードネットワークに推奨されます。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-byte 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, SIO found in the MTP3 routing label, or MTP3-User specific fields (such as the ISUP CIC, SCCP subsystem number). Some example Routing Keys are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the DPC/SSN 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、またはMTP3ユーザー固有のフィールド（ISUP CIC、SCCPサブシステム番号など）に含まれています。ルーティングキーの例のいくつかは、DPC単独、DPC/OPCの組み合わせ、DPC/OPC/CICの組み合わせ、またはDPC/SSNの組み合わせです。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. It is not necessary for the parameter range values within a particular Routing Key to be contiguous. For example, an AS could be configured to support call processing for multiple ranges of PSTN trunks that are not represented by contiguous CIC values.
ルーティングキーは、SS7シグナル伝達メッセージを受信したそれぞれが単一のルーティング結果に完全または部分的に一致する必要があるという意味で一意である必要があります。特定のルーティングキー内のパラメーター範囲値が隣接する必要はありません。たとえば、隣接するCIC値では表されないPSTNトランクの複数の範囲のコール処理をサポートするように構成できるAを構成できます。
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ユーザーメッセージからの情報を使用してメッセージ分布関数を実行する必要があります。
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への可用性、トラフィックハンドリング機能、および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.
ANの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 ASP(s), or to drop the message and provide a notification to layer management. The treatment of unallocated traffic is implementation dependent.
着信SS7メッセージに一致するルーティングキーエントリがない場合、デフォルトの処理が指定される場合があります。考えられるソリューションは、SGPでデフォルトのアプリケーションサーバーを提供し、すべての未割り当てされたトラフィックを（SETの）デフォルトASP（s）に向けるか、メッセージをドロップし、管理に通知を提供することです。未成年のトラフィックの処理は実装に依存しています。
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は、SS7ネットワークにメッセージを向けるためにSGPを選択する必要があります。これは、宛先ポイントコード（およびおそらく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（S）から受け取ったうっ血ステータス、個々のSGPの可用性ステータス、構成の変更とフェールオーバーメカニズム。ただし、SGPのステータスを管理するM3UAメッセージングはありません（たとえば、SGP-Up/Down/Active/非アクティブメッセージ）。
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) to and from the PSTN over a standard SS7 network interface, using the SS7 Message Transfer Part (MTP) [7,8,9] to provide reliable transport of the messages.
SS7の観点から、SS7メッセージ転送パーツ（MTP）[7,8,9]を使用して、シグナリングゲートウェイはSS7メッセージシグナリングユニット（MSUS）を標準SS7ネットワークインターフェイスを介してPSTNに送信および受信することが予想されます。メッセージの信頼できる輸送を提供します。
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) [18,19].
標準のSS7ネットワークインターフェイスとして、MTPレベル2シグナリングリンクの使用は唯一の可能性ではありません。ATMベースの高速リンクは、シグナリングATM適応層（SAAL）[18,19]のサービスでも使用できます。
Note: It is also possible for IP-based interfaces to be present, using the services of the MTP2-User Adaptation Layer (M2UA) [27] or M2PA [28].
注：MTP2ユーザー適応層（M2UA）[27]またはM2PA [28]のサービスを使用して、IPベースのインターフェイスが存在する可能性もあります。
These could be terminated at a Signalling Transfer Point (STP) or Signalling End Point (SEP). Using the services of MTP3, the SG could be capable of communicating with remote SS7 SEPs in a quasi-associated fashion, where STPs may be present in the SS7 path between the SEP and the SG.
これらは、シグナル伝達点（STP）またはシグナル伝達エンドポイント（SEP）で終了できます。MTP3のサービスを使用すると、SGは、SEPとSGの間のSS7パスにSTPが存在する場合がある準関連ファッションで、リモートSS7 SEPと通信することができます。
The SGP provides a functional interworking of transport functions between the SS7 network and the IP network by also supporting the M3UA adaptation layer. It allows the transfer of MTP3-User signalling messages to and from an IP-based Application Server Process where the peer MTP3-User protocol layer exists.
SGPは、M3UA適応層もサポートすることにより、SS7ネットワークとIPネットワーク間の輸送機能の機能的な相互作用を提供します。これにより、ピアMTP3ユーザープロトコルレイヤーが存在するIPベースのアプリケーションサーバープロセスとの間のMTP3ユーザーシグナル伝達メッセージを転送できます。
For SS7 user part management, it is required that the MTP3-User protocols at ASPs receive indications of SS7 signalling point availability, SS7 network congestion, and remote User Part unavailability as would be expected in an SS7 SEP node. To accomplish this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives received at the MTP3 upper layer interface at the SG need to be propagated to the remote MTP3-User lower layer interface at the ASP.
SS7ユーザーパーツ管理の場合、ASPのMTP3ユーザープロトコルは、SS7 SEPノードで予想されるように、SS7シグナリングポイントの可用性、SS7ネットワーク輻輳、およびリモートユーザー部品の利用不能の適応を受信することが必要です。これを達成するには、SGのMTP3上層インターフェイスで受け取ったMTP-Pause、MTP-Resume、およびMTP-Status Indixication Primitiveを、ASPのリモートMTP3ユーザー下層インターフェイスに伝播する必要があります。
MTP3 management messages (such as TFPs or TFAs received from the SS7 network) MUST NOT be encapsulated as Data message Payload Data and sent either from SG to ASP or from ASP to SG. The SG MUST terminate these messages and generate M3UA messages as appropriate.
MTP3管理メッセージ（SS7ネットワークから受信したTFPやTFAなど）は、データメッセージのペイロードデータとしてカプセル化され、SGからASPに、またはASPからSGに送信されてはなりません。SGはこれらのメッセージを終了し、必要に応じてM3UAメッセージを生成する必要があります。
A cluster of application servers is responsible for providing the overall support for one or more SS7 upper layers. From an SS7 standpoint, a Signalling Point Management Cluster (SPMC) provides complete support for the upper layer service for a given point code. 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.
アプリケーションサーバーのクラスターは、1つ以上のSS7上層の全体的なサポートを提供する責任があります。SS7の観点から、シグナリングポイント管理クラスター（SPMC）は、特定のポイントコードの上層サービスを完全にサポートします。例として、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 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.
IPSはM3UAをポイントツーポイントで使用するため、リモートエンドを超えてメッセージのルーティングの概念はありません。したがって、このモデルにはSS7およびM3UAインターワーキングは必要ありません。
All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned Routing Key at an SGP are mapped to an Application Server.
SGPでプロビジョニングされたルーティングキーに一致するすべてのMTP3ユーザーメッセージ（ISUP、SCCPなど）は、アプリケーションサーバーにマッピングされます。
The Application Server is the set of all ASPs associated with a specific Routing Key. Each ASP in this set may be active, inactive or unavailable. Active ASPs handle traffic; inactive ASPs might be used when active ASPs become unavailable.
アプリケーションサーバーは、特定のルーティングキーに関連付けられたすべてのASPのセットです。このセットの各ASPは、アクティブ、非アクティブ、または利用できない場合があります。アクティブなASPはトラフィックを処理します。アクティブなASPが利用できなくなると、非アクティブなASPが使用される場合があります。
The failover model supports an "n+k" redundancy model, where "n" ASPs is the minimum number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP. 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.
フェイルオーバーモデルは「n k」冗長モデルをサポートします。ここで、「n」ASPはトラフィックを処理するために必要な冗長ASPの最小数であり、「k」ASPは失敗または利用できないASPのために引き継ぐことができます。「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 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ユーザーへの混雑を示します。
When an SG determines that the transport of SS7 messages to a Signalling Point Management Cluster (SPMC) is encountering congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled management messages to originating SS7 nodes, per the congestion procedures of the relevant MTP3 standard. The triggering of SS7 MTP3 Management messages from an SG is an implementation-dependent function.
SGがSS7メッセージの信号ポイント管理クラスター（SPMC）への輸送が混雑に遭遇していると判断した場合、SGは、関連するMTP3標準の輻輳手順に従って、SS7 MTP3 MTP3 MTP3がSS7ノードを発信したSS7ノードに転送する可能性があると判断すると、SGがSS7 MTP3を転送することができます。SGからのSS7 MTP3管理メッセージのトリガーは、実装依存関数です。
The M3UA layer at an ASP or IPSP MAY indicate local congestion to an M3UA peer with an SCON message. When an SG receives a congestion message (SCON) from an ASP, and the SG determines that an SPMC is now encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled management messages to concerned SS7 destinations according to congestion procedures of the relevant MTP3 standard.
ASPまたはIPSPでのM3UA層は、Sconメッセージを持つM3UAピアへの局所的な混雑を示している可能性があります。SGがASPから混雑メッセージ（SCON）を受信し、SGがSPMCが混雑に遭遇していると判断した場合、関連するMTP3標準の輻輳手順に従ってSS7 MTP3の転送管理メッセージを関係SS7目的地にトリガーする可能性があります。
1.4.7 SCTP Stream Mapping.
1.4.7 SCTPストリームマッピング。
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 or the ISUP CIC assignment, subject of course to the maximum number of streams supported by the underlying SCTP association.
SGPとASPの両方のM3UA層は、SCTP協会内のストリームへのシグナリングトラフィックの割り当てもサポートしています。シーケンスを必要とするトラフィックは、同じストリームに割り当てる必要があります。これを達成するために、MTP3ユーザートラフィックは、たとえば、MTP3ルーティングラベルまたはISUP CIC割り当てのSLS値に基づいて個々のストリームに割り当てられます。もちろん、基礎となるSCTP協会がサポートする最大数のストリームに対応します。
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を使用したピアエンドポイントを構成して、1つが常にクライアントの役割を引き受け、もう1つはSCTP関連を開始するためのサーバーの役割を引き受ける必要があります。デフォルトのオリエンテーションは、ASPがクライアントである間、SGPがサーバーの役割を引き受けることです。この場合、ASPはSCTP協会をSGPに開始する必要があります。
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を使用したピアエンドポイントを構成して、一方が常にクライアントの役割を引き受けるように設定する必要があります。
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は、MGCがSS7ベースのSEPとSS7シグナリングメッセージを交換できるようにする実装依存性ノードインターワーキング関数（NIF）を提供します。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転送指示プリミティブとして受信され、MTP転移要求プリミティブに翻訳され、ローカルに送信されます。最終的なIP宛先への継続的なルーティングのためのM3UA居住メッセージ配布関数。MTP転換プリミティブとしてのローカルM3UAネットワークアドレスの翻訳およびマッピング機能から受信されたメッセージは、MTP転送がSS7 SEPへの進行中のMTPレベル3ルーティングのプリミティブを要求するため、MTPレベル3上層インターフェイスに送信されます。SS7ネットワークステータス情報を提供する目的で、NIFはMTP-RESUME、MTP-STATUS表示プリミティブをMTPレベル3上層インターフェイスからローカル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ユーザープロトコルインスタンスを使用して、2つのIP居住者のIPSP間で直接交換されます。SS7ネットワークインターワーキングは必要ありません。したがって、考慮すべきSCCPおよびSCCPユーザープロトコルの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には、たとえば、SG SCCPに論理的にアドレス指定されたメッセージのSCCPグローバルタイトル翻訳（GTT）関数を実行する可能性のあるSS7 SCCPプロトコル層のインスタンスが含まれています。SCCPメッセージのGTTの結果がIPドメインにあるSCCPピアのSS7 DPCまたはDPC/SSNアドレスを生成する場合、結果のMTP転移要求プリミティブがローカル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転送指示プリミティブは、GTTのSCCPにローカルM3UA居住ネットワークアドレスの翻訳とマッピング機能から送信されます。GTTの結果がSS7ネットワーク内のSCCPピアのアドレスを生成する場合、結果のMTPトランスファー要求は、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 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移動要求プリミティブが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/SSN address information. This nodal interworking function has no visible peer protocol with either the ASP or SEP.
内部SGPモデリングのために、これは、SCCPの下に効果的に位置し、MTP転送要求/表示メッセージをMTP3とM3UA層の両方にルーティングするSGP内の実装依存性ノードインターワーキング関数を使用することで実現できます。SS7 DPCまたはDPC/SSNアドレス情報に基づいています。この節点インターワーキング関数には、ASPまたはSEPのいずれかを備えた目に見えるピアプロトコルはありません。
Note that the services and interface provided by the M3UA layer are the same as in Example 1 and 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プロトコルでは再現されていません。
1.6.1 Definition of the Boundary between M3UA and an MTP3-User.
1.6.1 M3UAとMTP3ユーザーの境界の定義。
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転換指示MTP-RESINACTION INSICOLDICATION MTP-RESUME表示MTP-STATUS表示
An example of the upper layer primitives provided by the SCTP are provided in Reference [17] Section 10.
SCTPによって提供される上層のプリミティブの例は、参照[17]セクション10に記載されています。
M-SCTP_ESTABLISH request Direction: LM -> M3UA Purpose: LM requests ASP to establish an SCTP association with its peer.
M -SCTP_ESTABLISHリクエストの方向：LM-> M3UA目的：LMは、ASPに同業者とSCTP関連を確立するよう要求します。
M-STCP_ESTABLISH confirm Direction: M3UA -> LM Purpose: ASP confirms to LM that it has established an SCTP association with its peer.
MSTCP_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 ASP to 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 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はLMにSCTPの再起動指示が受信されたことを通知します。
M-SCTP_STATUS request Direction: LM -> M3UA Purpose: LM requests M3UA to 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 M3UA to 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 status of local or remote ASP.
M -ASP_STATUS確認方向：M3UA-> LM目的：M3UAはローカルまたはリモートASPのステータスを報告します。
M-AS_STATUS request Direction: LM -> M3UA Purpose: LM requests M3UA to 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 ASP to start its operation and send an ASP Up message to its peer.
M -ASP_UP要求方向：LM-> M3UA目的：LMは、ASPにその操作を開始し、ASPアップメッセージをピアに送信するよう要求します。
M-ASP_UP confirm Direction: M3UA -> LM Purpose: ASP reports that is 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 it has successfully processed an incoming ASP Up message from its peer.
M -ASP_UP表示方向：M3UA-> LM目的：M3UAは、同ピアからの受信ASPメッセージの処理に正常に処理されたと報告しています。
M-ASP_DOWN request Direction: LM -> M3UA Purpose: LM requests ASP to 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 is has received an ASP Down Ack message from its peer.
m -asp_down方向の確認：M3UA-> lm目的：ASPレポートは、ピアからASPダウンACKメッセージを受け取っています。
M-ASP_DOWN indication Direction: M3UA -> LM Purpose: M3UA reports 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ダウンメッセージを正常に処理したと報告するか、SCTP協会が失われ/リセットされました。
M-ASP_ACTIVE request Direction: LM -> M3UA Purpose: LM requests ASP to send an ASP Active message to its peer.
m -asp_active要求方向：lm-> m3ua目的：lmは、ASPにASPアクティブなメッセージをピアに送信するよう要求します。
M-ASP_ACTIVE confirm Direction: M3UA -> LM Purpose: ASP reports that is has received an ASP Active Ack message from its peer.
m -asp_activeの確認方向：M3UA-> lm目的：ASPレポートは、ピアからASPアクティブACKメッセージを受信しました。
M-ASP_ACTIVE indication Direction: M3UA -> LM Purpose: M3UA reports it has successfully processed an incoming ASP Active message from its peer.
M -ASP_active表示方向：M3UA-> LM目的：M3UAは、同ピアからの着信ASPアクティブメッセージの処理に成功したと報告しています。
M-ASP_INACTIVE request Direction: LM -> M3UA Purpose: LM requests ASP to send an ASP Inactive message to its peer.
M -ASP_INACTIVEリクエストの方向：LM-> M3UA目的：LMは、ASPにASPの非アクティブメッセージを同業者に送信するよう要求します。
M-ASP_INACTIVE confirm Direction: LM -> M3UA Purpose: ASP reports that is 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 it has successfully processed an incoming ASP Inactive message from its peer.
M -ASP_INACTIVE IDACITION方向：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がアクティブ状態に移動したと報告しています。
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が非アクティブ状態に移動したと報告しています。
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がダウン状態に移動したと報告しています。
If dynamic registration of RK is supported by the M3UA layer, the layer MAY support the following additional primitives:
RKの動的登録がM3UA層によってサポートされている場合、レイヤーは次の追加のプリミティブをサポートする場合があります。
M-RK_REG request Direction: LM -> M3UA Purpose: LM requests ASP to register RK(s) with its peer by sending REG REQ message M-RK_REG confirm Direction: M3UA -> LM Purpose: ASP reports that it has received REG RSP message with registration status as successful from its peer.
m -rk_reg要求方向：lm-> m3ua目的：lmは、reg reqメッセージを送信することにより、rk（s）をピアに登録することを要求しますm -rk_regは指示を確認します。登録ステータスは、ピアから成功しました。
M-RK_REG indication Direction: M3UA -> LM Purpose: M3UA informs LM that it has successfully processed an incoming REG REQ message.
M -RK_REGの表示方向：M3UA-> LM目的：M3UAはLMに、着信Reg Reqメッセージを正常に処理したことを通知します。
M-RK_DEREG request Direction: LM -> M3UA Purpose: LM requests ASP to deregister RK(s) with its peer by sending DEREG REQ message.
M -RK_DEREGリクエスト方向：LM-> M3UA目的：LMは、Dereg Reqメッセージを送信することにより、ASPを同業者にリクエストします。
M-RK_DEREG confirm Direction: M3UA -> LM Purpose: ASP reports that it has received DEREG REQ message with deregistration status as successful from its peer.
M -RK_DEREGの確認指示：M3UA-> lm目的：ASPは、同ピアから成功したために、dereg -strationステータスでdereg reqメッセージを受信したと報告しています。
M-RK_DEREG indication Direction: M3UA -> LM Purpose: M3UA informs LM that it has successfully processed an incoming DEREG REQ from its peer.
M -RK_DEREG表示方向：M3UA-> LM目的：M3UAはLMに、ピアからの入っているDereg Reqを正常に処理したことを通知します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [20].
キーワードは、このドキュメントに登場する場合、[20]で説明されているように解釈される場合は、キーワードが必要であってはなりません。
The general M3UA message format includes a Common Message Header followed by zero or more parameters as defined by the Message Type. For forward compatibility, all Message Types may have attached parameters even if none are specified in this version.
一般的なM3UAメッセージ形式には、メッセージタイプで定義されているゼロ以上のパラメーターが続く共通のメッセージヘッダーが含まれます。順方向の互換性のために、すべてのメッセージタイプに、このバージョンで指定されていない場合でも、パラメーターが添付されている場合があります。
The protocol messages for MTP3-User Adaptation require a message header which contains the adaptation layer version, the message type, and message length.
MTP3ユーザー適応のプロトコルメッセージには、適応レイヤーバージョン、メッセージタイプ、メッセージの長さを含むメッセージヘッダーが必要です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
All fields in an M3UA message MUST be transmitted in the network byte order, unless otherwise stated.
M3UAメッセージ内のすべてのフィールドは、特に明記しない限り、ネットワークバイト順序で送信する必要があります。
The version field contains the version of the M3UA adaptation layer.
バージョンフィールドには、M3UA適応レイヤーのバージョンが含まれています。
The supported versions are the following:
サポートされているバージョンは次のとおりです。
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 Message Type: 8 bits (unsigned integer)
0管理（MGMT）メッセージ1メッセージの転送2 SS7シグナリングネットワーク管理（SSNM）メッセージ3 ASP状態メンテナンス（ASPSM）メッセージ4 ASPトラフィックメンテナンス（ASPTM）メッセージ他のシグトラン適応レイヤーの場合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 notify（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ペイロードデータ（データ）2〜127 IETF 128から255によって予約されていますIETF定義の転送拡張機能
SS7 Signalling Network Management (SSNM) Messages (See Section 3.4)
SS7シグナリングネットワーク管理（SSNM）メッセージ（セクション3.4を参照）
0 Reserved 1 Destination Unavailable (DUNA) 2 Destination Available (DAVA) 3 Destination State Audit (DAUD) 4 Signalling Congestion (SCON) 5 Destination User Part Unavailable (DUPU) 6 Destination Restricted (DRST) 7 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined SSNM extensions
0予約済みの1つの宛先（DUNA）2宛先利用可能（DAVA）3宛先ステート監査（DAUD）4シグナル輻輳（SCON）5宛先ユーザー部品が利用できない（DUPU）6宛先制限（DRST）7〜127 IETF 128が予約します。255 IETF定義のSSNM拡張機能用に予約されています
ASP State Maintenance (ASPSM) Messages (See Section 3.5)
ASP状態メンテナンス（ASPSM）メッセージ（セクション3.5を参照）
0 Reserved 1 ASP Up (ASPUP) 2 ASP Down (ASPDN) 3 Heartbeat (BEAT) 4 ASP Up Acknowledgement (ASPUP ACK) 5 ASP Down Acknowledgement (ASPDN ACK) 6 Heartbeat Acknowledgement (BEAT ACK) 7 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined ASPSM extensions
0予約済み1 ASP UP（ASPUP）2 ASPダウン（ASPDN）3ハートビート（BEAT）4 ASP UP ASPONCEMAGE（ASPUP ACK）5 ASPダウン承認（ASPDN ACK）6ハートビート謝辞（Beat ACK）7〜127 IETF 128が予約します128IETF定義のASPSMエクステンション用に予約されている255へ
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 regeg-restration Response（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 bytes, if any.
メッセージの長さは、一般的なヘッダーを含むオクテットのメッセージの長さを定義します。メッセージの長さには、パラメーターパディングバイトが含まれている必要があります。
Note: A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length.
注：レシーバーは、最終的なパラメーターパディングがメッセージの長さに含まれているかどうかにかかわらず、メッセージを受け入れる必要があります。
M3UA messages consist of a Common Header followed by zero or more variable length parameters, as defined by the message type. All the parameters contained in a message are defined in a Tag Length-Value format as shown below.
M3UAメッセージは、メッセージタイプで定義されているように、共通のヘッダーとそれに続くゼロ以上の可変長さパラメーターで構成されています。メッセージに含まれるすべてのパラメーターは、以下に示すように、タグの長さ価値形式で定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
メッセージに複数のパラメーターが含まれている場合、明示的に義務付けられている場合を除き、パラメーターは任意の順序である場合があります。受信者は、任意の順序でパラメーターを受け入れる必要があります。
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
Circuit Range 0x020f
Protocol Data 0x0210
Reserved 0x0211
Registration Status 0x0212
Deregistration Status 0x0213
Reserved by the IETF 0x0214 to 0xffff
IETF 0x0214から0xffffによって予約されています
The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific parameter description are reserved for use by the IETF.
65535の値は、IETF定義の拡張機能に予約されています。特定のパラメーター説明で定義されている値以外の値は、IETFが使用するために予約されています。
Parameter Length: 16 bits (unsigned integer)
パラメーターの長さ：16ビット（符号なし整数）
The Parameter Length field contains the size of the parameter in bytes, 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 bytes.
パラメーター長いフィールドには、パラメータータグ、パラメーター長、パラメーター値フィールドなど、バイト内のパラメーターのサイズが含まれています。したがって、ゼロの長さのパラメーター値フィールドを持つパラメーターの長さフィールドは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 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is NOT included in the parameter length field. A sender SHOULD NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
パラメーターの総長さ（タグ、パラメーターの長さ、値フィールドを含む）は、4バイトの倍数でなければなりません。パラメーターの長さが4バイトの倍数でない場合、送信者は、すべてのゼロバイトを持つ最後のパラメーター（つまり、パラメーター値フィールドの後）にパッドをパッドします。パディングの長さは、パラメーターの長さフィールドに含まれていません。送信者は、3バイト以上のパッドではありません。受信機は、パディングバイトを無視する必要があります。
The following section describes the Transfer messages and parameter contents.
次のセクションでは、転送メッセージとパラメーターの内容について説明します。
The DATA message contains the SS7 MTP3-User protocol data, which is an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The DATA message contains the following variable length parameters:
データメッセージには、完全なMTP3ルーティングラベルを含むMTP転送プリミティブであるSS7 MTP3ユーザープロトコルデータが含まれています。データメッセージには、次の変数長パラメーターが含まれています。
Network Appearance Optional
Routing Context Optional
Protocol Data Mandatory
Correlation Id Optional
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 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.
ネットワークの外観パラメーターは、メッセージのSS7ネットワークコンテキストを識別し、使用したSS7ポイントコード形式、SS7ネットワークインジケーター値、MTP3および特定のSS7ネットワーク内で使用されるMTP3ユーザープロトコルタイプ/バリアント/バージョンを暗黙的に識別します。SGが単一のSS7ネットワークのコンテキストで動作する場合、または個々のSCTP関連は各SS7ネットワークコンテキストに専用である場合、ネットワークの外観パラメーターは必要ありません。他の場合には、受信機の使用のために存在するようにパラメーターを構成することができます。
The Network Appearance parameter value is of local significance only, coordinated between the SGP and ASP. Therefore, in the case where an ASP is connected to more than one SGP, the same SS7 network context may be identified by different Network Appearance values depending over which SGP a message is being transmitted/received.
ネットワークの外観パラメーター値は、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.
ルーティングコンテキストパラメーターには、データメッセージに関連付けられたルーティングコンテキスト値が含まれています。SGPとASPの間でルーティングキーが調整されていない場合、ルーティングコンテキストの送信は必要ありません。共通の関連付けで複数のルーティングキーとルーティングコンテキストが使用されている場合、トラフィックフローを識別するためにルーティングコンテキストを送信する必要があり、データメッセージの内部分布を支援する必要があります。
Protocol Data: variable length
プロトコルデータ：変数長
The Protocol Data parameter contains the original SS7 MTP3 message, including the Service Information Octet and Routing Label.
プロトコルデータパラメーターには、サービス情報Octetやルーティングラベルなど、元のSS7 MTP3メッセージが含まれています。
The Protocol Data parameter contains the following fields:
プロトコルデータパラメーターには、次のフィールドが含まれています。
Service Indicator, Network Indicator, Message Priority.
サービスインジケーター、ネットワークインジケーター、メッセージの優先順位。
Destination Point Code, Originating Point Code,
宛先ポイントコード、発信ポイントコード、
Signalling Link Selection Code (SLS).
シグナリングリンク選択コード（SLS）。
User Protocol Data. Includes:
ユーザープロトコルデータ。含まれる：
MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP parameters).
MTP3ユーザープロトコル要素（ISUP、SCCP、またはTUPパラメーターなど）。
The Protocol Data parameter is encoded as follows:
プロトコルデータパラメーターは次のようにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI | NI | MP | SLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Originating Point Code: 32 bits (unsigned integer) Destination Point Code: 32 bits (unsigned integer)
元のポイントコード：32ビット（符号なし整数）目的地ポイントコード：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が、ネットワークバイトの順序で正当化され、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 [29] message priority bits. The MP bits are aligned to the least significant bit. Unused bits are coded `0'.
メッセージの優先順位フィールドには、ANSIスタイルとTTCスタイル[29]メッセージの優先順位ビットの両方で、元のSS7メッセージからMPビット（もしあれば）が含まれています。MPビットは、最も重要なビットに整列しています。未使用のビットは「0」とコード化されています。
Signalling Link Selection: 8 bits (unsigned integer)
シグナリングリンクの選択：8ビット（署名されていない整数）
The Signalling Link Selection field contains the SLS bits from the routing label of the original SS7 message justified to the least significant bit and in Network Byte Order. Unused bits are coded `0'.
信号リンクの選択フィールドには、元のSS7メッセージのルーティングラベルからのSLSビットが含まれています。未使用のビットは「0」とコード化されています。
User Protocol Data: (byte string)
ユーザープロトコルデータ：（バイト文字列）
The User Protocol Data field contains a byte string of MTP-User information from the original SS7 message starting with the first byte of the original SS7 message following the Routing Label.
ユーザープロトコルデータフィールドには、ルーティングラベルに続く元の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.
相関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メッセージは、SGPからSGPからすべてのASPに送信され、SGが1つ以上のSS7宛先が到達不可能であると判断したことを示しています。また、ASPから到達不可能なSS7宛先へのメッセージに応じてSGPによって送信されます。実装オプションとして、SGは、リモートサイドが反応する時間を与えるために、特定の到達不可能なSS7宛先に関する後続の「応答」DUNAメッセージの送信を抑制する場合があります。別のSGを介して代替ルートがない場合、ASPのMTP3ユーザーは、定義されたMTP3ユーザー手順に従って、SGを介して影響を受ける目的地へのトラフィックを停止すると予想されます。
The DUNA message contains the following parameters:
DUNAメッセージには、次のパラメーターが含まれています。
Network Appearance Optional Routing Context Optional Affected Point Code Mandatory INFO String Optional
ネットワークの外観オプションルーティングコンテキストオプションの影響を受けるポイントコード必須情報文字列オプション
The format for DUNA Message parameters is as follows:
DUNAメッセージパラメーターの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bit unsigned integer
ネットワークの外観：32ビットの符号なし整数
See Section 3.3.1
セクション3.3.1を参照してください
Routing Context: n x 32-bits (unsigned integer)
ルーティングコンテキスト：n x 32ビット（符号なし整数）
The optional Routing Context parameter contains the Routing Context values associated with the DUNA message. Where a Routing Key has not been coordinated between the SGP and ASP, sending of Routing Context is not required. Where multiple Routing Keys and Routing Contexts are used across a common association, the Routing Context(s) MUST be sent to identify the concerned traffic flows for which the DUNA message applies, assisting in outgoing traffic management and internal distribution of MTP-PAUSE indications to MTP3-Users at the receiver.
オプションのルーティングコンテキストパラメーターには、DUNAメッセージに関連付けられたルーティングコンテキスト値が含まれます。SGPとASPの間でルーティングキーが調整されていない場合、ルーティングコンテキストの送信は必要ありません。共通の関連付けで複数のルーティングキーとルーティングコンテキストが使用されている場合、DUNAメッセージが適用される関係するトラフィックフローを特定するためにルーティングコンテキストを送信する必要があります。受信機のMTP3ユーザー。
Affected Point Code: n x 32-bits
影響を受けるポイントコード：n x 32ビット
The Affected Point Code parameter contains a list of Affected Destination Point Code fields, each a three-octet parameter to allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected Point Codes that are less than 24-bits, are padded on the left to the 24-bit boundary. The encoding is shown below for ANSI and ITU Point Code examples.
影響を受けるポイントコードパラメーターには、影響を受ける宛先ポイントコードフィールドのリストが含まれており、それぞれが14、16、および24ビットのバイナリ形式のSS7ポイントコードを可能にする3オクテットのパラメーターです。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 reception of an MTP3 management message or a linkset event simultaneously affects the availability status of a list of destinations at an SG.
影響を受けるPOTコードパラメーターを複数の影響を受ける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 reception of an MTP3 management message or a linkset event simultaneously affects the availability status of a series of destinations at an SG.
マスクフィールドを使用して、隣接する範囲の影響を受ける宛先ポイントコードを識別できます。隣接する範囲の影響を受けるDPCを特定することは、MTP3管理メッセージまたはリンクセットイベントの受信またはSGの一連の目的地の可用性ステータスに同時に影響する場合に役立ちます。
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 is "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 is "wildcarded". For a 14-bit ITU Affected PC, this is equivalent to signaling that an ITU
マスクパラメーターは、関連する影響を受けるPCフィールドに適用できるビットマスクを表す整数です。ビットマスクは、影響を受けるPCフィールドのビット数が重要であり、効果的に「ワイルドカード」されているものを識別します。たとえば、「8」のマスクは、PCの最後の8ビットが「ワイルドカード」であることを示しています。ANSI 24ビットの影響を受けるPCの場合、これはANSIクラスター内のすべてのPCが利用できないことを示すことと同等です。「3」のマスクは、PCの最後の3ビットが「ワイルドカード」であることを示しています。14ビットのITUに影響を受けるPCの場合、これはITUの信号と同等です
Region is unavailable. A mask value equal (or greater than) the number of bits in the PC indicates that the entire network appearance is affected - this is used to indicate network isolation to the ASP.
地域は利用できません。PCのビット数に等しい（またはそれ以上）マスク値は、ネットワークの外観全体が影響を受けていることを示しています。これは、ASPのネットワーク分離を示すために使用されます。
INFO String: variable length
情報文字列：可変長
The optional INFO String parameter can carry any meaningful UTF-8 [10] character string along with the message. Length of the INFO String parameter is from 0 to 255 octets. No procedures are presently identified for its use but the INFO String MAY be used for debugging purposes.
オプションの情報文字列パラメーターは、意味のあるUTF-8 [10]文字文字列をメッセージとともに運ぶことができます。情報文字列パラメーターの長さは0〜255オクテットです。現在、その使用に関する手順は特定されていませんが、情報文字列はデバッグの目的で使用される場合があります。
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ユーザープロトコルに通知され、影響を受ける目的地へのトラフィックを再開する可能性があります。ASP M3UAレイヤーは、DAVAメッセージを開始するSGを介してMTP3ユーザートラフィックをルーティングします。
The DAVA message contains the following parameters:
DAVAメッセージには、次のパラメーターが含まれています。
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String Optional
The format and description of the Network Appearance, Routing Context, Affected Point Code and INFO String parameters is the same as for the DUNA message (See Section 3.4.1).
ネットワークの外観、ルーティングコンテキスト、影響を受けるポイントコード、情報文字列パラメーターの形式と説明は、DUNAメッセージと同じです（セクション3.4.1を参照）。
The DAUD message MAY be sent from the ASP to the SGP to audit the availability/congestion state of SS7 routes from the SG to one or more affected destinations.
Daudメッセージは、SGPからSGPの可用性/輻輳状態をSGから1つ以上の影響を受ける宛先に監査するために、ASPからSGPに送信できます。
The DAUD message contains the following parameters:
Daudメッセージには、次のパラメーターが含まれています。
Network Appearance Optional Routing Context Optional Affected Point Code Mandatory INFO String Optional
ネットワークの外観オプションルーティングコンテキストオプションの影響を受けるポイントコード必須情報文字列オプション
The format and description of DAUD Message parameters is the same as for the DUNA message (See Section 3.4.1).
Daudメッセージパラメーターの形式と説明は、Dunaメッセージの場合と同じです（セクション3.4.1を参照）。
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 M3UA layer or the ASP is congested.
SCONメッセージは、SGPから関係するすべてのASPに送信することができ、SGがSS7ネットワークに1つ以上の宛先に混雑があることを判断したことを示しています。一部のMTPプロトコルバリエーション（ANSI MTPなど）の場合、SS7の混雑レベルが変化すると、Sconメッセージが送信される場合があります。Sconメッセージは、M3UA層またはASPが混雑していることを示すM3UAピアへのASPのM3UA層からも送信される場合があります。
The SCON message contains the following parameters:
Sconメッセージには、次のパラメーターが含まれています。
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
Concerned Destination Optional
Congestion Indications Optional
INFO String Optional
The format for SCON Message parameters is as follows:
Sconメッセージパラメーターの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the Network Appearance, Routing Context, Affected Point Code, and INFO String parameters is the same as for the DUNA message (See Section 3.4.1).
ネットワークの外観、ルーティングコンテキスト、影響を受けるポイントコード、および情報文字列パラメーターの形式と説明は、DUNAメッセージと同じです（セクション3.4.1を参照）。
The Affected Point Code parameter can be used to indicate congestion of multiple destinations or ranges of destinations.
影響を受けるポイントコードパラメーターを使用して、複数の目的地または宛先の範囲の輻輳を示すことができます。
Concerned Destination: 32-bits
関係する目的地：32ビット
The optional Concerned Destination parameter is only used if the SCON message is sent from an ASP to the SGP. It contains the point code of the originator of the message that triggered the SCON message. The Concerned Destination parameter contains one Concerned Destination Point Code field, a three-octet parameter to allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. A Concerned Point Code that is less than 24-bits is padded on the left to the 24-bit boundary. Any resulting Transfer Controlled (TFC) message from the SG is sent to the Concerned Point Code using the single Affected DPC contained in the SCON message to populate the (affected) Destination field of the TFC message
オプションの関係する宛先パラメーターは、SCONメッセージがASPからSGPに送信される場合にのみ使用されます。これには、Sconメッセージをトリガーしたメッセージのオリジネーターのポイントコードが含まれています。関係する宛先パラメーターには、1つの関係する宛先ポイントコードフィールド、14、16ビット、および24ビットのバイナリ形式のSS7ポイントコードを可能にする3つのオクセットパラメーターが含まれています。24ビット未満の関係ポイントコードは、左側に24ビットの境界にパッドで埋められます。SGからの結果の転送制御（TFC）メッセージは、TFCメッセージの（影響を受ける）宛先フィールドに入力するためにSconメッセージに含まれる単一の影響を受けるDPCを使用して、関係ポイントコードに送信されます。
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.
オプションのうっ血指示パラメーターには、うっ血レベルフィールドが含まれています。このオプションのパラメーターは、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:
影響を受ける宛先パラメーターのすべての影響を受けるDPC（S）に関連付けられた輻輳レベルフィールドには、次の値のいずれかが含まれています。
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など）が利用できないことを懸念ASPSに通知します。
The DUPU message contains the following parameters:
DUPUメッセージには、次のパラメーターが含まれています。
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
User/Cause Mandatory
INFO String Optional
The format for DUPU message parameters is as follows:
DUPUメッセージパラメーターの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User/Cause: 32-bits
ユーザー/原因：32ビット
The Unavailability Cause and MTP3-User Identity fields, associated with the Affected PC in the Affected Point Code parameter, are encoded as follows:
影響を受けるポイントコードパラメーターの影響を受けたPCに関連付けられている利用不可の原因とMTP3ユーザーIDフィールドは、次のようにエンコードされます。
Unavailability Cause field: 16-bits (unsigned integer)
利用不能の原因フィールド：16ビット（署名されていない整数）
The Unavailability Cause parameter provides the reason for the unavailability of the MTP3-User. The valid values for the Unavailability Cause parameter are shown in the following table. The values agree with those provided in the SS7 MTP3 User Part Unavailable message. Depending on the MTP3 protocol used in the Network Appearance, additional values may be used - the specification of the relevant MTP3 protocol variant/version recommendation is definitive.
利用できない原因パラメーターは、MTP3ユーザーが利用できない理由を提供します。利用不可能な原因パラメーターの有効な値を次の表に示します。値は、SS7 MTP3ユーザーパーツで提供されていないメッセージに提供されているものと一致します。ネットワークの外観で使用されるMTP3プロトコルに応じて、追加の値を使用できます。関連するMTP3プロトコルバリアント/バージョンの推奨の仕様は決定的です。
0 Unknown 1 Unequipped Remote User 2 Inaccessible Remote User
0不明1装備されていないリモートユーザー2アクセスできないリモートユーザー
MTP3-User Identity field: 16-bits (unsigned integer)
MTP3ユーザーIDフィールド：16ビット（符号なし整数）
The MTP3-User Identity describes the specific MTP3-User that is unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for the MTP3-User Identity are shown below. The values align with those provided in the SS7 MTP3 User Part Unavailable message and Service Indicator. Depending on the MTP3 protocol variant/version used in the network appearance, additional values may be used. The relevant MTP3 protocol variant/version recommendation is definitive.
MTP3ユーザーのアイデンティティは、利用できない特定のMTP3ユーザー（ISUP、SCCPなど）を説明しています。MTP3ユーザーIDの有効な値の一部を以下に示します。値は、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 12 AALタイプ2シグナル伝達13ベアラー独立コールコントロール（BICC）14ゲートウェイコントロールプロトコル15予約済み
The format and description of the Affected Point Code parameter is 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のみが含まれていないことを除いて、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。影響を受けるDPCの範囲とリストは、DUPUメッセージではシグナルを受けることはできませんが、これはSS7ネットワークでのUPU操作と一致しています。SS7ネットワークからSGPが受信したMTP3ユーザーパーツの影響を受けた宛先パラメーターには、1つの宛先のみが含まれています。
The format and description of the Network Appearance, Routing Context, and INFO String parameters is the same as for the DUNA message (See Section 3.4.1).
ネットワークの外観、ルーティングコンテキスト、および情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The DRST message is optionally sent from the SGP to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are now restricted from the point of view of the SG, or in response to a DAUD message if appropriate. The M3UA layer at the ASP is expected to send traffic to the affected destination via an alternate SG with route(s) 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がSGの観点から1つ以上のSS7宛先が制限されていることを決定したことを示していることを示しています。ASPのM3UAレイヤーは、同等の優先度のあるルートを備えた代替SGを介して影響を受ける目的地にトラフィックを送信することが期待されますが、そのような代替ルートが存在し、利用可能な場合のみです。現在、影響を受ける目的地がASPが利用できないと見なされている場合、MTP3ユーザーには、影響を受ける目的地への交通が再開できることを通知する必要があります。この場合、M3UA層は、DRSTメッセージを開始するSGを介してトラフィックをルーティングする必要があります。
This message is optional for the SG to send and it is optional for the ASP to act on any information received in the message. It is for use in the "STP" case described in Section 1.4.1.
このメッセージは、SGが送信するためのオプションであり、ASPがメッセージで受信した情報に基づいて行動するためのオプションです。セクション1.4.1で説明されている「STP」ケースで使用するためです。
The DRST message contains the following parameters:
DRSTメッセージには、次のパラメーターが含まれています。
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String Optional
The format and description of the Network Appearance, Routing Context, Affected Point Code and INFO String parameters is the same as for the DUNA message (See Section 3.4.1).
ネットワークの外観、ルーティングコンテキスト、影響を受けるポイントコード、情報文字列パラメーターの形式と説明は、DUNAメッセージと同じです（セクション3.4.1を参照）。
The ASP Up message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any ASPSM/ASPTM messages for all Routing Keys that the ASP is configured to serve.
ASPアップメッセージは、ASPが提供するように構成されているすべてのルーティングキーのASPSM/ASPTMメッセージを受信する準備ができていることをリモートM3UAピアに示すために使用されます。
The ASP Up message contains the following parameters:
ASPアップメッセージには、次のパラメーターが含まれています。
ASP Identifier Optional
INFO String Optional
The format for ASP Up 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 = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASP Identifier: 32-bit unsigned integer
ASP識別子：32ビットの符号なし整数
The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SGP should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.8.2).
オプションのASP識別子パラメーターには、ASをサポートするASPの間で局所的に重要な一意の値が含まれています。SGPは、必要に応じて、通知メッセージを使用して使用するASP識別子を保存する必要があります（セクション3.8.2を参照）。
The format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1).
オプションの情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The ASP UP Ack message is used to acknowledge an ASP Up message received from a remote M3UA peer.
ASP Up ACKメッセージは、リモートM3UAピアから受信したASPアップメッセージを確認するために使用されます。
The ASP Up Ack message contains the following parameters:
ASP Up ACKメッセージには、次のパラメーターが含まれています。
INFO String (optional)
情報文字列（オプション）
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 =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1). The INFO String in an ASP Up Ack message is independent from the INFO String in the ASP Up message (i.e., it does not have to echo back the INFO String received).
オプションの情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。ASP Up ACKメッセージの情報文字列は、ASPアップメッセージの情報文字列から独立しています（つまり、受信した情報文字列をエコーする必要はありません）。
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ダウンメッセージは、適応層がデータ、SSNM、RKM、またはASPTMメッセージを受信する準備ができていないことをリモートM3UAピアに示すために使用されます。
The ASP Down message contains the following parameters:
ASPダウンメッセージには、次のパラメーターが含まれています。
INFO String Optional 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 is the same as for the DUNA message (See Section 3.4.1).
オプションの情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M3UA peer.
ASPダウンACKメッセージは、リモートM3UAピアから受け取ったASPダウンメッセージを確認するために使用されます。
The ASP Down Ack message contains the following parameters:
ASPダウンACKメッセージには、次のパラメーターが含まれています。
INFO String Optional
情報文字列オプション
The format for the ASP Down Ack message parameters is as follows:
ASPダウン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 is the same as for the DUNA message (See Section 3.4.1).
オプションの情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The INFO String in an ASP Down Ack message is independent from the INFO String in the ASP Down message (i.e., it does not have to echo back the INFO String received).
ASPダウンACKメッセージの情報文字列は、ASPダウンメッセージの情報文字列から独立しています（つまり、受信した情報文字列をエコーする必要はありません）。
The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. It is recommended for use when the M3UA runs over a transport layer other than the SCTP, which has its own heartbeat.
ビートメッセージは、M3UAピアが互いに利用できるようにするためにオプションで使用されます。M3UAがSCTP以外の輸送層を介して実行される場合は、使用することをお勧めします。
The BEAT message contains the following parameters:
ビートメッセージには、次のパラメーターが含まれています。
Heartbeat Data Optional
ハートビートデータオプション
The format for the BEAT message is as follows:
ビートメッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ハートビートデータパラメーターの内容は、送信ノードによって定義されます。ハートビートデータには、たとえば、ハートビートシーケンス番号やタイムスタンプを含めることができます。ビートメッセージの受信者は、送信者にとって重要なだけであるため、このフィールドを処理しません。レシーバーは、ビート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.
ビートACKメッセージは、受信したビートメッセージに応じて送信されます。これには、変更されていない、受信したビートメッセージのすべてのパラメーターが含まれています。
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 expects to receive a REG RSP message in return with an associated Routing Context value.
Reg Reqメッセージは、ASPによって送信され、リモートピアに1つ以上の指定されたルーティングキーを登録したいことをリモートM3UAピアに示すように送信されます。通常、ASPはこのメッセージをSGPに送信し、関連するルーティングコンテキスト値と見返りにREG RSPメッセージを受信することを期待しています。
The REG REQ message contains the following parameters:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The Destination Point Code, Service Indicators, Originating Point Code List and Circuit Range 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
Local-RK-Identifier：32ビットの符号なし整数
The mandatory Local-RK-Identifier field is used to uniquely identify the registration request. The Identifier value is assigned by the ASP, and is used to correlate the response in an REG RSP message with the original registration request. The Identifier value must remain unique until the REG RSP message is received.
必須のローカルRK-Identifierフィールドを使用して、登録リクエストを一意に識別します。識別子値は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 LoadShare 3ブロードキャスト
Destination Point Code:
宛先ポイントコード：
The Destination Point Code parameter is mandatory, and identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. 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トラフィックの宛先ポイントコードを識別します。この形式は、DUNAメッセージの影響を受ける宛先パラメーターの説明と同じです（セクション3.4.1を参照）。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance:
ネットワークの外観：
The optional Network Appearance parameter field identifies the SS7 network context for the Routing Key, and has the same format as in the DATA message (See Section 3.3.1). The absence of the Network Appearance parameter in the Routing Key indicates the use of any Network Appearance value. Its format is:
オプションのネットワーク外観パラメーターフィールドは、ルーティングキーのSS7ネットワークコンテキストを識別し、データメッセージと同じ形式を持っています（セクション3.3.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 as 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ユーザーIDフィールドに記載されているように、値から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 the Destination Point Code parameter. The absence of the OPC List parameter in the Routing Key indicates the use of any OPC value,
元のポイントコードリストパラメーターには1つ以上のSS7 OPCエントリが含まれており、その形式は宛先ポイントコードパラメーターと同じです。ルーティングキーにOPCリストパラメーターがないことは、OPC値の使用を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Circuit Range:
回路範囲：
An ISUP controlled circuit is uniquely identified by the SS7 OPC, DPC and CIC value. For the purposes of identifying Circuit Ranges in an M3UA Routing Key, the optional Circuit Range parameter includes one or more circuit ranges, each identified by an OPC and Upper/Lower CIC value. The DPC is implicit as it is mandatory and already included in the DPC parameter of the Routing Key. The absence of the Circuit Range parameter in the Routing Key indicates the use of any Circuit Range values, in the case of ISUP/TUP traffic. The Origination Point Code is encoded the same as the Destination Point Code parameter, while the CIC values are 16-bit integers.
ISUP制御回路は、SS7 OPC、DPC、CIC値によって一意に識別されます。M3UAルーティングキーで回路範囲を識別する目的で、オプションの回路範囲パラメーターには1つ以上の回路範囲が含まれ、それぞれがOPCと上/下のCIC値によって識別されます。DPCは必須であり、ルーティングキーのDPCパラメーターに既に含まれているため、暗黙的です。ルーティングキーに回路範囲パラメーターがないことは、ISUP/TUPトラフィックの場合、回路範囲値の使用を示しています。Origination Pointコードは、宛先ポイントコードパラメーターと同じでエンコードされ、CIC値は16ビット整数です。
The Circuit Range format 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 = 0x020f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #1 | Upper CIC Value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #2 | Upper CIC Value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #n | Upper CIC Value #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 parameters:
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:
登録結果パラメーターには、reg reqメッセージの単一のルーティングキーの登録結果が含まれます。単一のREG RSPメッセージの結果の数は、対応するreg Reqメッセージにあるルーティングキーパラメーターの総数から1つまでの範囲でなければなりません。複数のREG RSPメッセージがReg Reqメッセージへの返信で使用される場合、特定の結果は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
Local-RK-Identifier：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.
登録結果ステータスフィールドは、登録要求の成功または失敗の理由を示します。
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
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メッセージは、特定のルーティングキーを登録したいことをリモートM3UAピアに示すためにASPによって送信されます。通常、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が現在登録されているアプリケーションサーバーのトラフィックをインデックス作成する整数（リストのリスト）が含まれていますが、今では登録を希望しています。
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 parameters:
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メッセージの結果の数は、対応するDereg REQメッセージで見つかったルーティングコンテキスト値の総数から1から1までの範囲である場合があります。
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メッセージのみである必要があります。各結果の形式は次のとおりです。
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メッセージに見られるように、一致するルーティングキーのルーティングコンテキスト値がDeregisterへのルーティングコンテキスト値を含んでいます。
Deregistration Status: 32-bit integer
登録ステータス：32ビット整数
The Deregistration Result Status field indicates the success or the reason for failure of the deregistration.
縮小結果ステータスフィールドは、解雇の成功または失敗の理由を示します。
Its values may be:
その値は次のとおりです。
0 Successfully Deregistered
1 Error - Unknown
2 Error - Invalid Routing Context
3 Error - Permission Denied
4 Error - Not Registered
5 Error - ASP Currently Active for Routing Context
The ASP Active message is sent by an ASP to indicate to a remote M3UA peer that it is ready to process signalling traffic for a particular Application Server. The ASP Active message affects only the ASP state for the Routing Keys identified by the Routing Contexts, if present.
ASPアクティブメッセージは、ASPによって送信され、特定のアプリケーションサーバーのシグナリングトラフィックを処理する準備ができていることをリモートM3UAピアに示すことができます。ASPアクティブメッセージは、存在する場合、ルーティングコンテキストによって識別されるルーティングキーのASP状態のみに影響します。
The ASP Active message contains the following parameters:
ASPアクティブメッセージには、次のパラメーターが含まれています。
Traffic Mode Type Optional Routing Context Optional INFO String Optional
トラフィックモードタイプオプションルーティングコンテキストオプション情報文字列オプション
The format for the ASP Active message is as follows:
ASPアクティブメッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 LoadShare 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, and 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をオーバーライドします。LoadShareモードでは、ASPは、現在アクティブな他のASPと交通量の配布を共有します。ブロードキャストモードでは、ASPは現在アクティブな他のASPと同じメッセージを受け取ります。
Routing Context: n X 32-bit integers
ルーティングコンテキスト：n x 32ビット整数
The optional Routing Context parameter contains (a list of) integers indexing the Application Server traffic that the sending ASP is configured/registered to receive.
オプションのルーティングコンテキストパラメーターには、送信ASPが受信するように構成/登録されているアプリケーションサーバーのトラフィックをインデックス作成する整数（リストのリスト）が含まれます。
There is 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ルーティングキーまたは名前として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 call processing for multiple ranges of PSTN trunks and therefore receive related signalling traffic, identified by separate SS7 DPC/OPC/CIC ranges.
アプリケーションサーバープロセスは、複数の論理アプリケーションサーバーのトラフィックを処理するように構成できます。ASPの観点から見ると、ルーティングコンテキストは、ASPが現在SGPから受け取るように構成されているさまざまなシグナルトラフィックを定義します。たとえば、PSTNトランクの複数の範囲のコール処理をサポートするようにASPを構成することができ、したがって、個別のSS7 DPC/OPC/CIC範囲によって識別される関連シグナルトラフィックを受信できます。
The format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1).
オプションの情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The ASP Active Ack message is used to acknowledge an ASP Active message received from a remote M3UA peer.
ASP Active ACKメッセージは、リモートM3UAピアから受信したASPアクティブメッセージを確認するために使用されます。
The ASP Active Ack message contains the following parameters:
ASP Active ACKメッセージには、次のパラメーターが含まれています。
Traffic Mode Type Optional Routing Context Optional INFO String Optional
トラフィックモードタイプオプションルーティングコンテキストオプション情報文字列オプション
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 is the same as for the DUNA message (See Section 3.4.1).
オプションの情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The INFO String in an ASP Active Ack message is independent from the INFO String in the ASP Active message (i.e., it does not have to echo back the INFO String received).
ASP Active ACKメッセージの情報文字列は、ASP Activeメッセージの情報文字列から独立しています（つまり、受信した情報文字列をエコーする必要はありません）。
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のリスト内から使用されるアクティブなASPではなくなったことをリモートM3UAピアに示すことができます。ASPの非アクティブメッセージは、存在する場合、ルーティングコンテキストによって識別されるルーティングキーのASP状態のみに影響します。
The ASP Inactive message contains the following parameters:
ASPの非アクティブメッセージには、次のパラメーターが含まれています。
Routing Context Optional INFO String Optional
ルーティングコンテキストオプションの情報文字列オプション
The format for the ASP Inactive message parameters is as follows:
ASPの非アクティブメッセージパラメーターの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Routing Context and INFO String parameters is the same as for the ASP Active message (See Section 3.5.5.)
オプションのルーティングコンテキストと情報文字列パラメーターの形式と説明は、ASPアクティブメッセージと同じです（セクション3.5.5を参照）
The ASP Inactive Ack message is used to acknowledge an ASP Inactive message received from a remote M3UA peer.
ASPの非アクティブACKメッセージは、リモートM3UAピアから受信したASP非アクティブメッセージを確認するために使用されます。
The ASP Inactive Ack message contains the following parameters:
ASPの非アクティブACKメッセージには、次のパラメーターが含まれています。
Routing Context Optional INFO String Optional
ルーティングコンテキストオプションの情報文字列オプション
The format for the ASP Inactive Ack message is as follows:
ASP不活性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 is the same as for the DUNA message (See Section 3.4.1.)
オプションの情報文字列パラメーターの形式と説明は、DUNAメッセージの場合と同じです（セクション3.4.1を参照）。
The INFO String in an ASP Inactive Ack message is independent from the INFO String in the ASP Inactive message (i.e., it does not have to echo back the INFO String received).
ASP不活性ACKメッセージの情報文字列は、ASPの不活性メッセージの情報文字列から独立しています（つまり、受信した情報文字列をエコーする必要はありません）。
The format of the Routing Context parameter is the same as for the ASP Inactive message. (See Section 3.7.3).
ルーティングコンテキストパラメーターの形式は、ASPの非アクティブメッセージと同じです。（セクション3.7.3を参照）。
The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid.
エラーメッセージは、着信メッセージに関連付けられたエラーイベントをピアに通知するために使用されます。たとえば、現在の状態を考慮して、メッセージタイプが予想外になるか、パラメーター値が無効である場合があります。
The Error message contains the following parameters:
エラーメッセージには、次のパラメーターが含まれています。
Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Optional
(*) 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:
エラーコードパラメーターは、エラーメッセージの理由を示します。エラーパラメーター値は、次の値のいずれかになります。
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で使用されていませんM3UA 0x0D拒否 - 管理ブロック0x0E ASP識別子識別子0x0f無効なASP識別子0x10 M3UA 0x11で使用されていない0x12パラメーターフィールドエラー0x13予期しないパラメーター0x14宛先ステータス未知の0x15無効なネットワーク外観0x17M3UA 0x19無効なルーティングコンテキスト0x1a ASPのように構成されていない
The "Invalid Stream Identifier" error is sent if a message is received on an unexpected SCTP stream (e.g., a MGMT message was received on a stream other than "0"). Error messages MUST NOT be generated in response to other Error messages.
「無効なストリーム識別子」エラーは、予期しないSCTPストリームでメッセージが受信された場合に送信されます（たとえば、「0」以外のストリームでMGMTメッセージが受信されました）。他のエラーメッセージに応じてエラーメッセージを生成してはなりません。
The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received.
「サポートされていないメッセージクラス」エラーは、予期しないまたはサポートされていないメッセージクラスを含むメッセージが受信された場合に送信されます。
The "Unsupported Message Type" error is sent if a message with an unexpected or unsupported Message Type is received.
「サポートされていないメッセージタイプ」エラーは、予期しないまたはサポートされていないメッセージタイプを持つメッセージが受信された場合に送信されます。
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 Context(s), the Routing Context(s) SHOULD be included in the Error message.
「予期しないメッセージ」エラーは、現在の状態では予想されない定義および認識されたメッセージが受信された場合に送信される場合があります（場合によっては、ASPはオプションでメッセージを静かに破棄し、エラーメッセージを送信しない場合があります）。たとえば、サイレント廃棄は、ASPがASP不活性状態にある間にSGPからデータメッセージを受信した場合、ASPによって使用されます。予期しないメッセージにルーティングコンテキストが含まれている場合、ルーティングコンテキストをエラーメッセージに含める必要があります。
The "Protocol Error" error is sent for any protocol anomaly (i.e., reception 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アップアップまたはASPアクティブメッセージが受信され、管理上の理由でリクエストが拒否されたときに送信されます（たとえば、管理ロックアウト "）。ASPアクティブメッセージのコンテキストは、エラーメッセージに含める必要があります。
The "ASP Identifier Required" is sent by a SGP in response to an ASP Up message which 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識別子が必要」は、SGPが必要な場合にASP識別子パラメーターを含まないASPアップメッセージに応じてSGPによって送信されます。ASPは、ASP識別子を使用してASPアップメッセージを再送信する必要があります。
The "Invalid ASP Identifier" is sent by an SGP in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
「無効なASP識別子」は、無効な（つまり、非統一）ASP識別子を含むASPアップメッセージに応じて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".
「無効なパラメーター値」エラーは、無効なパラメーター値でメッセージが受信された場合に送信されます（たとえば、「0」以外のマスク値でDUPUメッセージが受信されました。
The "Parameter Field Error" would be sent if a message is received with a parameter having a wrong length field.
「パラメーターフィールドエラー」は、間違った長さフィールドを持つパラメーターでメッセージが受信されると送信されます。
The "Unexpected Parameter" error would be sent if a message contains an invalid parameter.
メッセージに無効なパラメーターが含まれている場合、「予期しないパラメーター」エラーが送信されます。
The "Destination Status Unknown" Error MAY be sent if a DAUD is received at an SG enquiring of the availability/congestion status of a destination, and the SG does not wish to provide the status (e.g., the sender is not authorized to know the status). For this error, the invalid or unauthorized Point Code(s) MUST be included along with the Network Appearance and/or Routing Context associated with the Point Code(s).
「宛先ステータス不明」エラーは、宛先の可用性/輻輳ステータスを調査するSGでDaudを受信した場合、SGがステータスを提供することを望まない場合に送信される場合があります（たとえば、送信者は、状態）。このエラーのために、ポイントコードに関連付けられたネットワークの外観および/またはルーティングコンテキストとともに、無効または不正なポイントコードを含める必要があります。
The "Invalid Network Appearance" error is sent by a 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.
必須パラメーターがメッセージに含まれていない場合、「欠落パラメーター」エラーが送信されます。
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のように構成されていない」エラーは、ルーティングコンテキストパラメーターなしでピアからメッセージが受信され、アプリケーションサーバーが参照される構成データでは知られていない場合に送信されます。
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.
含まれる場合、オプションの診断情報は、エラー条件の識別を支援するために、エラー条件に互換性のある情報になる可能性があります。診断情報には、問題のメッセージが含まれている必要があります。
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:
Notifyメッセージには、次のパラメーターが含まれています。
Status Mandatory
ASP Identifier Optional
Routing Context Optional
INFO String Optional
The format for the Notify message is as follows:
Notifyメッセージの形式は次のとおりです。
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:
ステータスタイプパラメーターは、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:
ステータス情報パラメーターには、ステータスタイプの値に基づいて、通知の詳細情報が含まれています。ステータスタイプがState_changeの場合、次のステータス情報値が使用されます。
1 reserved 2 Application Server Inactive (AS-INACTIVE) 3 Application Server Active (AS-ACTIVE) 4 Application Server Pending (AS-PENDING)
1予約済み2アプリケーションサーバー不活性（無作法）3アプリケーションサーバーActive（As-active）4アプリケーションサーバー保留（保留）
These notifications are sent from an SGP to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the Application Server.
これらの通知は、特定のアプリケーションサーバーのステータスの変更により、SGPからASPに送信されます。値は、アプリケーションサーバーの新しい状態を反映しています。
If the Status Type is Other, then the following Status Information values are defined:
ステータスタイプが他の場合、次のステータス情報値が定義されています。
1 Insufficient ASP Resources Active in AS 2 Alternate ASP Active 3 ASP Failure
1 ASPの不十分な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 ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP MUST be placed in the message.
これらの通知は、ASPまたはASの状態の変更を報告するSGPに基づいていません。不十分なASPリソースの場合、SGPは、ASのロードを処理するために別のASPが必要なASのASP_INACTIVE ASPを示しています（ロードシェアリングモードまたはブロードキャストモード）。代替ASPアクティブケースの場合、ASPがオーバーライドモードでASP活性状態に移行する場合にASPが通知されます。代替ASPのASP識別子（利用可能な場合）をメッセージに配置する必要があります。ASP障害の場合、SGPはASPの1つがASPダウンに移行したASのASPを示しています。故障したASPのASP識別子（利用可能な場合）をメッセージに配置する必要があります。
The format and description of the optional 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 is the same as for the ASP Active message (See Section 3.7.1)
オプションのASP識別子の形式と説明は、ASPアップメッセージと同じです（セクション3.5.1を参照）。ルーティングコンテキストと情報文字列パラメーターの形式と説明は、ASPアクティブメッセージと同じです（セクション3.7.1を参照）
The M3UA layer needs to respond to various local primitives it receives from other layers as well as the messages that it receives from the peer M3UA layer. This section describes the M3UA procedures in response to these events.
M3UAレイヤーは、他のレイヤーから受け取るさまざまなローカルプリミティブや、ピアM3UAレイヤーから受信するメッセージに応答する必要があります。このセクションでは、これらのイベントに応じたM3UA手順について説明します。
On receiving an MTP-TRANSFER request primitive from an upper layer at an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA layer sends a corresponding DATA message (see Section 3) to its M3UA peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER indication primitive to the upper layer.
ASP/IPSPの上層からのMTP転移要求のプリミティブを受信すると、SGPでの節点インターワーキング関数からM3UA層は、対応するデータメッセージ（セクション3を参照）をM3UAピアに送信します。データメッセージを受信するM3UAピアは、上層にプリミティブなMTP移動兆候を送信します。
The M3UA message distribution function (see Section 1.4.2.1) determines the Application Server (AS) based on 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 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活性状態のASPが選択され、対応するSCTP協会でデータメッセージが構築および発行されます。ASP活性状態に複数のASPがいる場合（つまり、トラフィックは複数のASPにわたって負荷をかけます）、ASP活性状態のASPの1つがリストから選択されます。ASPがブロードキャストモードの場合、すべてのアクティブなASPが選択され、メッセージが各アクティブASPに送信されます。選択アルゴリズムは実装に依存しますが、たとえば、ロビンの周りであるか、SLSまたはISUP CICに基づいている可能性があります。適切な選択アルゴリズムは、ASのASP活性ASP間の状態調整の程度のアプリケーションの仮定と理解に依存するため、慎重に選択する必要があります。
In addition, the message needs to be sent on the appropriate SCTP stream, again taking care to meet the message sequencing needs of the signalling application. DATA messages MUST be sent on an SCTP stream other than stream '0'.
さらに、メッセージを適切なSCTPストリームに送信する必要があり、再び信号アプリケーションのメッセージシーケンスニーズを満たすように注意してください。データメッセージは、ストリーム「0」以外のSCTPストリームで送信する必要があります。
When there is no Routing Key match, or only a partial match, for an incoming SS7 message, a default treatment MAY be specified. Possible solutions are to provide a default Application Server at the SGP that directs all unallocated traffic to a (set of) default ASP(s), or to drop the message and provide a notification to Layer Management in an M-ERROR indication primitive. The treatment of unallocated traffic is implementation dependent.
SS7メッセージを着信する場合、ルーティングキーの一致、または部分的な一致のみがない場合、デフォルトの治療を指定することができます。可能なソリューションは、SGPでデフォルトのアプリケーションサーバーを提供し、すべての未割り当てトラフィックを（Set of）default ASP（s）に向けるか、メッセージをドロップし、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関連原始をローカル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レイヤーは、Associationのセットアップが完了したときにM-SCTP_ESTABLISHのプリミティブをレイヤー管理に送信します。ピアM3UAレイヤーでは、M-SCTP_ESTABLISH INDICONACITIONプリミティブが、着信SCTPアソシエーションのセットアップが正常に完了すると、レイヤー管理に送信されます。
An M-SCTP_RELEASE request primitive from Layer Management initiates the teardown of an SCTP association. The M3UA layer accomplishes a graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN primitive to the SCTP layer.
レイヤー管理からのM-SCTP_RELEASE要求プリミティブは、SCTP協会の分解を開始します。M3UA層は、SCTP層にSCTP-Shutdownプリミティブを送信することにより、SCTP関連の優雅なシャットダウンを達成します。
When the graceful shutdown of the SCTP association has been accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE notification primitive to the local M3UA layer. At the M3UA Layer that initiated the request, the M3UA layer will send an M-SCTP_RELEASE confirm primitive to Layer Management when the association shutdown is complete. At the peer M3UA Layer, an M-SCTP_RELEASE indication primitive is sent to Layer Management upon abort or successful shutdown of an SCTP association.
SCTP協会の優雅なシャットダウンが達成されると、SCTPレイヤーは、sctp-shutdown_complete通知をローカルM3UAレイヤーの原始的な通知を返します。リクエストを開始したM3UAレイヤーでは、M3UAレイヤーがM-SCTP_RELEESEを送信し、Associationのシャットダウンが完了したときに層管理にプリミティブを確認します。ピアM3UAレイヤーでは、M-SCTP_RELEESE表示プリミティブが、SCTP協会の中止または成功したシャットダウン時に層管理に送信されます。
An M-SCTP_STATUS request primitive supports a Layer Management query of the local status of a particular SCTP association. The M3UA layer simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS primitive to the SCTP layer. When the SCTP responds, the M3UA layer maps the association status information to an M-SCTP_STATUS confirm primitive. No peer protocol is invoked.
M-SCTP_STATUSリクエストPrimitiveは、特定のSCTP協会のローカルステータスのレイヤー管理クエリをサポートします。M3UAレイヤーは、単にM-SCTP_STATUS要求をSCTP層の原始的に原始的にマッピングします。SCTPが応答すると、M3UAレイヤーはAssociationステータス情報を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 [17] 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-M3UA-to-SCTPおよび/またはSCTP-to-M3UA-to-LMプリミティブマッピングは、RFC2960の他のさまざまなSCTP上層プリミティブについて説明できます[17]。ハートビートをリクエストし、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 request, M-ASP_DOWN request, M-ASP_ACTIVE request 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リクエスト、およびM-ASP_INACTIVEリクエストPrimitivesにより、ASPでレイヤー管理が状態の変更を開始できます。正常に完了すると、M3UA層によって対応する確認原始が層管理に提供されます。呼び出しが失敗した場合、プリミティブでエラー表示プリミティブが提供されます。これらの要求により、SGPまたはIPSPでのリモートM3UAピアに対するASPダウン、ASPダウン、ASPアクティブおよびASPの非アクティブなメッセージが発信されます。
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 and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication primitives to the local Layer Management.
ピアM3UAからのASP、ASPダウン、ASPのアクティブ、ASPの非アクティブなメッセージの受容に起因する状態の変化が成功すると、M3UA層は、対応するM-ASP_UP、M-ASP_DOWN、M-ASP_ACTIVE、M-ASP_INACTIVE、M-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.
すべての非輸送および非SSNM、メッセージ、beatおよびbeat ackを除くメッセージは、注文を確実にするためにシーケンスされた配信で送信する必要があります。ASPTMメッセージは、可能なメッセージの損失を最小限に抑えるために、ルーティングコンテキストに関連するデータトラフィックを運ぶために使用されるストリームの1つに送信される場合があります。beat and 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. For the purposes of the following procedures, only the SGP/ASP case is described but the SGP side of the procedures also apply to an IPSP sending traffic to an AS consisting of a set of remote IPSPs.
SGP上のM3UAレイヤーは、各アプリケーションサーバーの各リモートASPの状態を維持します。ASPは、M3UAメッセージ配布関数への入力としてトラフィックを受信するようにASPが構成されています。同様に、IPSPがポイントツーポイントでM3UAを使用する場合、IPSPのM3UA層はリモートIPSPの状態を維持します。次の手順の目的のために、SGP/ASPケースのみが説明されていますが、手順のSGP側は、リモートIPSPのセットで構成されるASにトラフィックを送信するIPSPにも適用されます。
The state of each remote ASP, in each AS that it is configured to operate, is maintained in the M3UA layer in the SGP. The state of a particular ASP in a particular AS changes due to events. The events include:
各リモートASPの状態は、それぞれが動作するように構成されているように、SGPのM3UA層で維持されます。イベントによる変化として特定のASPの特定のASPの状態。イベントには以下が含まれます：
* Reception of messages from the peer M3UA layer at the ASP; * Reception of some messages from the peer M3UA layer at other ASPs in the AS (e.g., ASP Active message indicating "Override"); * Reception of indications from the SCTP layer; or * Local Management intervention.
* ASPでのピアM3UAレイヤーからのメッセージの受信。* ASの他のASPでのピアM3UAレイヤーからのいくつかのメッセージの受信（たとえば、「オーバーライド」を示すASPアクティブメッセージ）;* SCTP層からの適応症の受信。または *ローカル管理介入。
The ASP state transition diagram is shown in Figure 3. The possible states of an ASP are:
ASP状態遷移図を図3に示します。ASPの可能な状態は次のとおりです。
ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the related SCTP association is down. Initially all ASPs will be in this state. An ASP in this state SHOULD NOT be sent any M3UA messages, with the exception of Heartbeat, ASP Down Ack and Error messages.
ASPダウン：ASPのリモートM3UAピアは利用できず、関連するSCTP協会がダウンしています。当初、すべてのASPがこの状態になります。この状態のASPは、ハートビート、ASPダウンACK、エラーメッセージを除き、M3UAメッセージを送信しないでください。
ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the related SCTP association is up) but application traffic is stopped. In this state the ASP SHOULD NOT be sent any DATA or SSNM messages for the AS for which the ASP is inactive.
ASP-Inactive：ASPのリモートM3UAピアが利用可能です（および関連するSCTP協会は増加しています）が、アプリケーショントラフィックは停止します。この状態では、ASPは、ASPが非アクティブであるASのデータまたはSSNMメッセージを送信しないでください。
ASP-ACTIVE: The remote M3UA peer at the ASP is available and application traffic is active (for a particular Routing Context or set of Routing Contexts).
ASP-Active：ASPのリモート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 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 ASP's peer SCTP layer.
SCTP RI：SGの上層層プロトコル（M3UA）に対するローカルSCTP層の再起動指示。ローカルSCTPは、ASPのピアSCTPレイヤーから再起動を検出すると、この表示を送信します。
Figure 3: ASP State Transition Diagram, per AS
図3：ASP状態遷移図、ASごと
+--------------+
| |
+----------------------| ASP-ACTIVE |
| Other +-------| |
| ASP in AS | +--------------+
| Overrides | ^ |
| | ASP | | ASP
| | Active | | Inactive
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI/
SCTP RI | | v SCTP RI
| +--------------+
| | |
+--------------------->| ASP-DOWN |
| |
+--------------+
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 the 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ダウン状態にあることを意味します。最初はこの状態になります。アプリケーションサーバーは、構成から削除されると、廃止状態になります。
AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP-INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired.
不活性：アプリケーションサーバーは利用可能ですが、アプリケーショントラフィックはアクティブではありません（つまり、1つ以上の関連ASPがASP不活性状態にありますが、ASP活性状態にはありません）。回復タイマーT（R）が実行されていないか、期限切れになっています。
AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that at least one ASP is in the ASP-ACTIVE state.
AS-Active：アプリケーションサーバーが利用可能で、アプリケーショントラフィックがアクティブです。この状態は、少なくとも1つのASPがASP活性状態にあることを意味します。
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.
保留中：アクティブなASPはASP不活性またはASPダウンに移行し、ASの最後の残りのアクティブASPでした。回復タイマーT（R）を開始する必要があり、すべての着信シグナリングメッセージはSGPがキューに掲載する必要があります。t（r）が有効になる前にASPがASP活性になると、ASがアクティブな状態に移動され、すべてのキューに囲まれたメッセージがASPに送信されます。
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no alternative, the SGP may stops queuing messages and discards all previously queued messages. The AS will move to the AS-INACTIVE state.
ASPがASPアクティブになる前にT（R）が期限切れになり、SGPには選択肢がない場合、SGPはメッセージのキューイングを停止し、以前にキューに入ったすべてのメッセージを破棄する場合があります。ASは非アクティブな状態に移動します。
If at least one ASP is in ASP-INACTIVE state, otherwise it will move to AS-DOWN state.
少なくとも1つのASPがASP不活性状態にある場合、それ以外の場合、それはダウン状態に移動します。
Figure 4 shows an example AS state machine for the case where the AS/ASP data is preconfigured. For 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データが事前に設定されている場合の状態マシンとしての例を示しています。AS/ASP構成データが動的に作成される他のケースでは、特にASの作成時に状態マシンに違いがあります。
Figure 4: AS State Transition Diagram
図4：状態遷移図として
+----------+ one ASP trans to ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queuing) |
| |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state)
Tr = Recovery Timer
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 first successful REG REQ from an ASP. Another example is where the AS/ASP configuration data is not created until the first ASP successfully enters the ASP-ACTIVE state. In this case the AS-ACTIVE state is entered directly.
たとえば、AS/ASP構成データが最初のASPの登録まで作成されない場合、AS ASPからの最初の成功したRec Reqに直接入力されます。別の例は、AS/ASP構成データがASP活性状態に正常に入るまで作成されない場合です。この場合、アクティブな状態が直接入力されます。
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状態が州にあると想定されています。
Once the SCTP association is established (see Section 4.2) and 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ユーザーの準備ができていると仮定して、ASP UP/ASPダウン/ASPアクティブ/ASPの不活性を使用して、ローカルM3UA ASPメンテナンス（ASPM）関数が関連する手順を開始します。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-Communication_DownまたはSCTP-Restartの指示原始を基礎となるSCTP層から受信した場合、M-SCTP_STATUS INDICATION PRIMITITITを呼び出すことにより、レイヤー管理を通知します。ASPの状態はASPダウンに移動されます。ASPでは、MTP3ユーザーは、MTP-Pause Insidication Primitivesを使用して、影響を受けるSS7の目的地の利用不能性を通知されます。
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-establish the SCTP Association. This MAY be done by the M3UA layer automatically, or Layer Management MAY re-establish using the M-SCTP_ESTABLISH request primitive.
SCTP-Communication_Downの場合、SCTPクライアントはSCTP協会を再確立しようとする場合があります。これは、M3UAレイヤーによって自動的に行われる場合があります。または、レイヤー管理は、M-SCTP_ESTABLISHリクエストPrimitiveを使用して再確立する場合があります。
In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered by its M3UA peer to be in the ASP-DOWN state. The ASP, if it is to recover, must begin any recovery with the ASP-Up procedure.
ASPでのSCTP-Restartの表示の場合、ASPは現在、M3UAピアによってASPダウン状態にあると見なされています。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アップメッセージを送信するのを待ち、ASP M3UAピアが利用可能であることを示します。ASPは常にASPアップメッセージのイニシエーターです。このアクションは、レイヤー管理からの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 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.
ASPアップメッセージがSGPで受信され、内部的にリモートASPがASPダウン状態にある場合、ローカル管理上の理由でロックアウトされているとは見なされない場合、SGPは州のASP不活性のリモートASPをマークし、レイヤー管理に通知します。M-ASP_UP表示プリミティブ。SGPが現在の構成データを介して認識している場合、ASPが動作するように構成されているアプリケーションサーバーを介して、SGPはそれがメンバーであるように、それぞれのASP状態をそれぞれにASP不活性に更新します。
Alternatively, the SGP may move the ASP into a pool of Inactive ASPs available for future configuration within Application Server(s), 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識別子を保存する必要があります。SGPは、ASPがSGPでASP不活性として既にマークされている場合でも、受信したASPアップメッセージに応じて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 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アップメッセージを送信すると、タイマーT（ACK）が開始されます。ASPがT（ACK）内のASPアップメッセージへの応答を受け取らない場合、ASPはT（ACK）を再起動し、ASP Up ACKメッセージを受信するまでASPを再送信できます。T（ACK）は、デフォルトの2秒で提供可能です。あるいは、ASPアップメッセージの再送信は、レイヤー管理の制御下に置かれる場合があります。この方法では、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メッセージを待つ必要があります。SGPがASPアップメッセージを受信する前に他のM3UAメッセージを受信した場合（ASPダウン以外 - セクション4.3.4.2を参照）、SGPはそれらを破棄する場合があります。
If an ASP Up message is received and internally the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message), and the remote ASP state is changed to ASP-INACTIVE in all relevant Application Servers.
ASPアップメッセージが受信され、内部的にリモートASPがASPアクティブ状態にある場合、ASP Up ACKメッセージが返され、エラーメッセージが返され（「予期しないメッセージ）、リモートASP状態がASPに変更されます。関連するすべてのアプリケーションサーバーで非アクティブ。
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アップメッセージが受信され、内部的にリモートASPがすでにASP不活性状態にある場合、ASP Up ACKメッセージが返され、それ以上のアクションは実行されません。
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.
サポートされていないバージョンを含むASPアップメッセージが受信された場合、受信側はエラーメッセージで応答し、受信ノードがサポートし、レイヤー管理に通知するバージョンを示します。
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 assumed that the Error message would normally come from the SGP.
これは、プロトコルバージョンのアップグレードがネットワークで実行されている場合に役立ちます。新しいバージョンにアップグレードされたノードは、通信している他のノードで使用される古いバージョンをサポートする必要があります。ASPSはASPアップ手順を開始するため、エラーメッセージは通常SGPから得られると想定されています。
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アップアップまたはASP Up ACKが受信された後、ASP不活性状態で考慮される場合があります。IPSPは、ASPダウンまたはASPダウンACKを受け取った後、ASPダウン状態で考慮することができます。IPSPは、M-ASP_UPまたはM-ASP_DN表示または確認プリミティブを使用して、リモートIPSPの状態の変化を層管理に通知する場合があります。
Alternatively, an interchange of ASP Up messages from each end can be performed. This option follows the ASP state transition diagram. It would need four messages for completion.
または、両端からのASPアップメッセージの交換を実行することができます。このオプションは、ASP状態遷移図に従います。完了には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 reason "Refused Management Blocking" and leaves the remote IPSP in the ASP-DOWN state.
現地の理由（例：管理ロックアウト）がIPSPがASP Up ACKメッセージを使用してASPアップメッセージに応答できない場合、理由「拒否された管理ブロッキング」でエラーメッセージを使用してASPアップメッセージに応答し、リモートIPSPを残しますASPダウン状態。
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がメンバーであり、データ、SSNM、またはASPTMメッセージを受け取らないというすべてのアプリケーションサーバーでサービスから削除されることを希望する場合、SGPにASPダウンメッセージを送信します。このアクションは、レイヤー管理からの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 as 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ダウンとしてマークし、M-ASP_DOWN IDINCATION PRIMITITITを使用してレイヤー管理に通知し、ASPダウンACKメッセージをASPに返します。
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.
SGPは、ASPがSGPでASPダウンとして既にマークされている場合でも、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 as in the ASP-DOWN state.
ASPでは、受信したASPダウンACKメッセージは認められていません。レイヤー管理には、M-ASP_DOWNのプリミティブ確認が付いています。ASPがASPダウンメッセージを送信せずにASPダウンACKを受け取った場合、ASPはASPダウン状態のように自分自身を考慮する必要があります。
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活性またはASP不活性状態にあった場合、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ダウンメッセージを送信すると、タイマーT（ACK）が開始されます。ASPがT（ACK）内のASPダウンメッセージへの応答を受け取らない場合、ASPはASPダウンACKメッセージを受信するまでT（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. In the case where an ASP Active message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Server(s) the ASP is a member.
ASPがSGPまたはIPSPからASP Up ACKメッセージを受け取った後、ASPはASPアクティブなメッセージをSGPに送信して、ASPがトラフィックの処理を開始する準備ができていることを示す場合があります。このアクションは、レイヤー管理からのM-ASP_activeリクエストの原始的な要求によってASPで開始されるか、M3UA管理機能によって自動的に開始される場合があります。ASPが共通のSCTPアソシエーション全体で複数のアプリケーションサーバーのトラフィックを処理することを希望する場合、ASPアクティブメッセージには、ASPアクティブメッセージをサーバーするアプリケーションを示すために、1つ以上のルーティングコンテキストのリストを含める必要があります適用されます。ASPが単一のASPアクティブメッセージに関心のあるすべてのルーティングコンテキストを含める必要はないため、すべてのルーティングコンテキストで同時にアクティブになることを要求します。複数のASPアクティブメッセージを使用して、アプリケーションサーバー内で個別に、またはセット内でアクティブ化できます。ASP Activeメッセージにルーティングコンテキストパラメーターが含まれていない場合、受信者は構成データを介して、ASPがメンバーであるアプリケーションサーバーを介して知る必要があります。
For the Application Servers that 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 Active ACKメッセージに含める必要があります。ASPアクティブメッセージのトラフィックモードタイプ要求、またはリクエストがない場合はローカル構成データに応じて、SGPはASPを関連するアプリケーションサーバー内の正しいASPトラフィック状態に移動します。レイヤー管理には、M-ASP_ACTIVE表示が付いています。ASPアクティブメッセージを受信する前にSGPまたはIPSPがデータメッセージを受信した場合、SGPまたはIPSPがそれらを破棄する場合があります。ASPアクティブACKメッセージを送信することにより、SGPまたはIPSPは、関連するルーティングコンテキストのトラフィックを受信して送信する準備ができました。ASPは、ASPアクティブなACKメッセージを受信する前に、関連するルーティングコンテキストのデータまたはSSNMメッセージを送信しないでください。そうしないと、メッセージの損失が危険にさらされます。
Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge the ASP Active message for different (sets of) Routing Contexts. The SGP or IPSP MUST send an Error message ("Invalid Routing Context") for each Routing Context value that the ASP cannot be successfully activated .
複数のASPアクティブなACKメッセージを使用して、複数のルーティングコンテキストを含むASPアクティブメッセージに応じて使用できます。これにより、SGPまたはIPSPが異なる（セットの）ルーティングコンテキストのASPアクティブメッセージを個別に確認できます。SGPまたはIPSPは、ASPを正常にアクティブ化できないルーティングコンテキスト値ごとにエラーメッセージ（「無効なルーティングコンテキスト」）を送信する必要があります。
In the case where an "out-of-the-blue" ASP Active message is received (i.e., the ASP has not registered with the SG or the SG has no static configuration data for the ASP), the message MAY be silently discarded.
「青い」ASPアクティブメッセージが受信された場合（つまり、ASPがSGに登録していないか、SGにASPの静的な構成データがない場合）、メッセージは静かに廃棄される場合があります。
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 ASP-ACTIVE state at the SGP.
SGPは、ASPがSGPのASP活性状態ですでにマークされている場合、ASPからの受信ASPアクティブメッセージに応じてASPアクティブ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 message(s) 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 reception of the ASP Active Ack message.
ASPでは、受信したASPアクティブACKメッセージは認められていません。レイヤー管理には、M-ASP_ACTIVEの原始的な確認が付いています。ASPアクティブACKメッセージの前にASPがデータメッセージを受信する可能性があり、SGまたはIPSPからのデータメッセージは異なるSCTPストリームで送信される可能性があります。ASPがASPアクティブACKメッセージを受信するまで、ASPはASPアクティブ状態では自分自身を考慮していないため、メッセージの損失が可能です。
When the ASP sends an ASP Active message it starts timer T(ack). If the ASP does not receive a response to an ASP Active message within T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until it receives an ASP Active Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Active messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying a negative indication.
ASPがASPアクティブメッセージを送信すると、タイマーT（ACK）が開始されます。ASPがT（ACK）内のASPアクティブメッセージへの応答を受け取らない場合、ASPはASPアクティブACKメッセージを受信するまでT（ACK）を再起動し、ASPアクティブメッセージを再送信できます。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.
SGP M3UAレイヤーには、オーバーライド、ロードシェア、ブロードキャストの3つのアプリケーションサーバートラフィックの取り扱いがあります。含まれる場合、ASPアクティブメッセージのトラフィックモードタイプパラメーターは、特定のアプリケーションサーバーで使用されるトラフィックハンドリングモードを示します。SGPがASPアクティブメッセージに示されているモードが、AS用に現在構成されているモードとサポートされていないか、互換性がないことを決定した場合、SGPはエラーメッセージ（「サポートされていない /無効なトラフィックハンドリングモード」）で応答します。アプリケーションサーバーのトラフィックハンドリングモードが構成データを介してまだわかっていない場合、アプリケーションサーバーの状態をアクティブに遷移する原因となる最初のASPアクティブメッセージに示されたトラフィックハンドリングモードを使用してモードを設定することができます。
In the case of an Override mode AS, reception 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 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.
オーバーライドモードの場合、SGPでのASPアクティブメッセージの受信により、ASPアクティブメッセージを送信したASPのすべてのトラフィックの（再）方向が発生します。ASの以前にアクティブなASPは現在、ASP不活性であると考えられており、AS内のSGPからトラフィックを受け取ることはできません。SGPまたはIPSPは、ASの以前にアクティブなASPに通知メッセージ（「代替ASP_ACTIVE」）を送信する必要があり、そのASPへの通信を停止する必要があります。この通知を受け取っているASPは、ASPがASP間通信を介してこれをまだ認識していない場合、ASP不活性状態で自分自身を考慮する必要があります。
In the case of a Loadshare mode AS, reception of an ASP Active message at an SGP or IPSP causes the 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, ISUP CIC value).
ASロードシェアモードの場合、SGPまたはIPSPでのASPアクティブメッセージの受信により、ASPアクティブメッセージの送信のトラフィックの方向が、ASで現在アクティブな他のすべてのASPに加えて、ASPアクティブメッセージを送信します。すべてのアクティブなASPに関する積極的なトラフィックのためのSGPのアルゴリズムは、実装に依存しています。たとえば、アルゴリズムは、ラウンドロビンであるか、データメッセージの情報に基づいている可能性があります（例：SLS、SCCP SSN、ISUP CIC値）。
An SGP or IPSP, upon reception 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.
SGPまたはIPSPは、ロードシェアの最初のASPに対するASPアクティブメッセージを受信すると、予想される負荷を処理するのに十分なリソースがあると判断するまで、新しくアクティブなASPにトラフィックを向けないことを選択できます（たとえば、そこからそこになるまでASのASPアクティブの「N」ASPS）。この場合、SGPまたはIPSPは、十分なリソースが発生するまで通知（AS-Active）を差し控える必要があります。
For the n+k redundancy case, ASPs which 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のASのアクティブなASPの数を調整するというASPSのASPは、N ASPがアクティブになってからのみトラフィックを送信し始める必要があります。
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.
ロード共有モード内のすべてのzipは、提供された負荷の潜在的なフェールオーバーまたはリバランスに対応するために、ASに対して受信したデータメッセージを処理できる必要があります。
In the case of a Broadcast mode AS, reception of an ASP Active message at an SGP or IPSP causes the 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内の放送トラフィックのためのSGPのアルゴリズムは、すべてのメッセージが各アクティブASPに送信される単純なブロードキャストアルゴリズムです。
An SGP or IPSP, upon reception of an ASP Active message for the first ASP in a Broadcast AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources.
SGPまたはIPSPは、放送中の最初のASPのASPアクティブメッセージを受信すると、予想される負荷を処理するのに十分なリソースがあると判断するまで、新しくアクティブなASPにトラフィックを向けないことを選択できます（たとえば、そこからそこになるまでASのASPアクティブの「N」ASPS）。この場合、SGPまたはIPSPは、十分なリソースが発生するまで通知（AS-Active）を差し控える必要があります。
For the n+k redundancy case, ASPs which 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のASのアクティブなASPの数を調整するというASPSの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
ASP-ActiveになるようにブロードキャストモードのASPがASPがASP活性になるときはいつでも、SGPは各トラフィックフローで最初のデータメッセージブロードキャストにタグを付けなければなりません
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.
一意の相関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アクティブを受信した場合、ピアをASPアクティブとしてマークし、ASPアクティブACKメッセージを返す必要があります。ASPアクティブなACKメッセージを受け取るASPは、ASP活性状態にまだない場合、ピアをASP活性としてマークする場合があります。
Alternatively, an interchange of ASP Active messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be activated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion.
または、両端からASPアクティブメッセージの交換を実行することができます。このオプションは、ASP状態遷移図に従い、各端からアクティブ化されるように特定の選択を選択するという追加の利点を示します。IPSPが複数のASを提供している場合に特に便利です。完了には4つのメッセージが必要です。
When an ASP wishes to withdraw from receiving traffic within an AS, the ASP sends an ASP Inactive message to the SGP or IPSP. This action 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. 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 and move the ASP to the ASP-INACTIVE state in all Application Servers. 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 by the SGP to be in state ASP-INACTIVE. An ASP Inactive Ack message is sent to the ASP, after ensuring that all traffic is stopped to the ASP.
ASPがAS内のトラフィックの受信から撤退したい場合、ASPはASPの非アクティブなメッセージをSGPまたはIPSPに送信します。このアクションは、レイヤー管理からのM-ASP_INACTIVEリクエストの原始的な要求によってASPで開始されるか、M3UA管理機能によって自動的に開始される場合があります。ASPが共通のSCTPアソシエーション全体で複数のアプリケーションサーバーのトラフィックを処理している場合、ASPの非アクティブメッセージには、ASPの非アクティブメッセージが適用されるアプリケーションサーバーを示すために、1つ以上のルーティングコンテキストが含まれています。ASPの非アクティブメッセージにルーティングコンテキストパラメーターが含まれていない場合、受信者は構成データを介して知る必要があります。アプリケーションサーバーはASPがメンバーであり、ASPをすべてのアプリケーションサーバーのASP不活性状態に移動します。オーバーライドモードASの場合、ASPアクティブ（「オーバーライド」）メッセージを使用してASのAS内のトラフィックを既に引き継いでいる場合、ASPの非アクティブメッセージを送信するASPは、SGPが既に状態にあると見なしています。ASP不活性。すべてのトラフィックがASPに停止することを保証した後、ASPの非アクティブACKメッセージがASPに送信されます。
In the case of a Loadshare mode AS, the SGP moves the ASP to the ASP-INACTIVE state and the AS traffic is reallocated across the remaining ASPs in the state ASP-ACTIVE, as per the loadsharing algorithm currently used within the AS. A Notify message ("Insufficient ASP resources active in AS") MAY be sent to all inactive ASPs, if required. An ASP Inactive Ack message is sent to the ASP after all traffic is halted and Layer Management is informed with an M-ASP_INACTIVE indication primitive.
ASのロードシェアモードの場合、SGPはASP不活性状態にASPを移動し、ASはAS内で現在使用されている負荷シェアリングアルゴリズムに従って、ASP-Activeの残りのASPにトラフィックが再割り当てされます。必要に応じて、通知メッセージ（ "ASP不十分なASPリソースAS AS]）は、すべての非アクティブASPに送信される場合があります。ASPの非アクティブ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.
放送モードの場合、SGPはASPをASP不活性状態に移動し、ASトラフィックはASP-Activeの残りのASPにのみ放送されます。必要に応じて、通知メッセージ（ "ASP不十分なASPリソースAS AS]）は、すべての非アクティブASPに送信される場合があります。ASPの非アクティブACKメッセージがASPに送信され、すべてのトラフィックが停止し、M-ASP_INACTIVE表示プリミティブでレイヤー管理が通知されます。
Multiple ASP Inactive Ack messages MAY be used in response to an ASP Inactive message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge for different (sets of) Routing Contexts. The SGP or IPSP sends an Error message ("Invalid Routing Context") message for each invalid or unconfigured Routing Context value in a received ASP Inactive message.
複数のASP不活性ACKメッセージは、複数のルーティングコンテキストを含むASPの非アクティブメッセージに応じて使用でき、SGPまたはIPSPが異なる（セットの）ルーティングコンテキストを独立して確認できるようにします。SGPまたはIPSPは、受信したASPの非アクティブメッセージで、無効または固定されていないルーティングコンテキスト値ごとにエラーメッセージ（「無効なルーティングコンテキスト」）メッセージを送信します。
The SGP MUST send an ASP Inactive Ack message in response to a received ASP Inactive message from the ASP and the ASP is already marked as ASP-INACTIVE at the SGP.
SGPは、ASPからの受け取ったASPの非アクティブメッセージに応じてASPの非アクティブACKメッセージを送信する必要があり、ASPはすでにSGPでASP不活性としてマークされています。
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 as 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の非アクティブACKメッセージは認められていません。レイヤー管理には、M-ASP_INACTIVE ADMING PRIMITITITが付いています。ASPがASPの非アクティブメッセージを送信せずにASPの非アクティブACKを受け取った場合、ASPはASP不活性状態のように自分自身を考慮する必要があります。ASPが以前にASP活性状態にあった場合、ASPは以前の状態に戻る手順を開始する必要があります。
When the ASP sends an ASP Inactive message it starts 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 a M-ASP_Inactive confirm primitive carrying a negative indication.
ASPがASPの非アクティブメッセージを送信すると、タイマーT（ACK）が開始されます。ASPがT（ACK）内のASP非アクティブメッセージへの応答を受け取らない場合、ASPはASPの非アクティブACKメッセージを受信するまでT（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 of the ASPs in the AS which 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アクティブにない場合、SGPは州のASP不活性にあるASのすべてのASPに通知メッセージ（「As-Pending」）を送信する必要があります。SGPは、T（R）秒間の受信メッセージのバッファリングを開始する必要があります。その後、メッセージが破棄される可能性があります。T（r）は、ネットワーク演算子が構成できます。SGPがT（R）の前に有効期限が切れる前にASPからASPアクティブメッセージを受信した場合、バッファリングされたトラフィックがそのASPに向けられ、タイマーがキャンセルされます。t（r）が有効になると、ASは不活性状態に移動されます。
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不活性状態で考慮される場合があります。
Alternatively, an interchange of ASP Inactive messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be deactivated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion.
あるいは、両端からのASP不活性なメッセージの交換を実行することができます。このオプションは、ASP状態遷移図に従い、各端から非アクティブ化されるように特定の選択を選択するという追加の利点を示します。IPSPが複数のASを提供している場合に特に便利です。完了には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 reception of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack).
AS状態の変更を反映した通知メッセージは、ASPダウン状態のASのすべてを除き、適切なステータス情報とASPのASPの失敗の識別子を除き、ASのすべてのASPに送信する必要があります。ASPでは、レイヤー管理はM-notify表示プリミティブで通知されます。AS AS状態の変更がASPの失敗またはASP州管理（ASPSM） / ASPトラフィック管理（ASPTM）メッセージの受容の結果であるかどうかにかかわらず、通知メッセージを送信する必要があります。2番目のケースでは、Notifyメッセージは、関連する確認メッセージの後に送信する必要があります（たとえば、ASP Up ACK、ASP Down ACK、ASP Active ACK、またはASP Inactive ACK）。
In the case where a Notify message ("AS-PENDING") message is sent by an SGP that now has no ASPs active to service the traffic, or where a Notify ("Insufficient ASP resources active in AS") message is sent in the Loadshare or Broadcast mode, the Notify message does not explicitly compel the ASP(s) receiving the message to become active. The ASPs remain in control of what (and when) traffic action is taken.
通知メッセージ（「As-Pending」）メッセージがSGPによって送信される場合、現在トラフィックにサービスを提供するためにASPがアクティブになっていない場合、または通知（「ASP不十分なASPリソースがアクティブ」）メッセージが送信されます。LoadShareまたはブロードキャストモードでは、Notifyメッセージは、メッセージを受信するASPをアクティブにすることを明示的に強制しません。ASPは、トラフィックアクションがどのような（およびいつ）実行されるかを制御し続けています。
In the case where a Notify message does not contain a Routing Context parameter, the receiver must know, via configuration data, of which Application Servers the ASP is a member and take the appropriate action in each AS.
Notifyメッセージにルーティングコンテキストパラメーターが含まれていない場合、受信者は構成データを介して、ASPがメンバーであり、それぞれのASで適切なアクションを実行する場合を知っておく必要があります。
Notify works in the same manner as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state.
SG-ASの場合と同じ方法で作業を通知します。IPSPSの1つは、このメッセージをASPダウン状態にないリモート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).
オプションのハートビート手順は、輸送協会の損失を検出するための独自のハートビートメカニズム（つまり、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.
M3UA Peerは、配置可能なタイマーT（ビート）の対象となる、オプションでハートビートメッセージを定期的に送信する場合があります。ハートビートメッセージを受信すると、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.
Heartbeat ACKメッセージ（または他のM3UAメッセージ）が2*t（beat）内のM3UAピアから受信されない場合、リモートM3UAピアは利用できないと見なされます。ハートビートメッセージの送信が停止し、シグナリングプロセスが、切断されたM3UAピアのクライアントとして構成されている場合、通信を再確立しようとするはずです。
The Heartbeat message may optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Heartbeat Ack message. The sender, upon examining the contents of the returned Heartbeat Ack message, MAY choose to consider the remote M3UA peer as unavailable. The contents/format of the Heartbeat Data parameter is implementation-dependent and only of local interest to the original sender. The contents may be used, for example, to support a Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a timestamp mechanism (to evaluate delays).
ハートビートメッセージには、オプションで、関連するハートビートACKメッセージに変更されていない背中に反映する必要がある不透明なハートビートデータパラメーターが含まれている場合があります。送信者は、返されたハートビートACKメッセージの内容を調べると、リモートM3UAピアを利用できないと考えることを選択できます。ハートビートデータパラメーターの内容/形式は、実装依存であり、元の送信者にとって現地の関心のみです。内容は、たとえば、ハートビートシーケンスアルゴリズム（欠落しているハートビートを検出するため）および/またはタイムスタンプメカニズム（遅延を評価する）をサポートするために使用できます。
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はASにASに追加されることを許可する場合があります。または、ルーティングキーが現在存在せず、受信したルーティングキーデータが有効かつ一意である場合、SGPサポートダイナミック構成は、新しいルーティングキーと関連するアプリケーションサーバーの作成を承認し、ASPを新しいASに追加する場合があります。どちらの場合でも、SGPはASPへの登録応答メッセージを返し、最初のリクエストで提供されているのと同じローカルRK-Identifierを含み、登録結果は「正常に登録」されます。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 Type".
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", "Error - Invalid Network Appearance" as appropriate.
SGPが、受信したルーティングキーデータが無効であるか、無効なパラメーター値を含んでいると判断した場合、SGPはASPへの登録応答メッセージを返します。 - 必要に応じて、ネットワークの外観が無効です。
If the SGP determines that a unique Routing Key cannot be created, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - "Cannot Support Unique Routing" An incoming signalling message received at an SGP should not match against more than one Routing Key.
SGPが一意のルーティングキーを作成できないと判断した場合、SGPはASPへの登録応答メッセージを返し、「エラー」の登録ステータスが一意のルーティングをサポートできません。複数のルーティングキー。
If the SGP does not authorize an otherwise valid registration request, the SGP returns a REG RSP message to the ASP containing the Registration Result "Error - Permission Denied".
SGPがそれ以外の有効な登録リクエストを承認しない場合、SGPは登録結果「エラー - 許可拒否」を含むASPにREG RSPメッセージを返します。
If an SGP determines that a received Routing Key does not currently exist and 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 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 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". This result MAY be used if, for example, the SGP does not support RK Circuit Range Lists in a Routing Key because the SGP does not support ISUP traffic, or does not provide CIC range granularity.
SGPが、新しいルーティングキーエントリを作成する目的で、1つ以上のルーティングキーパラメーターがサポートされていないと判断した場合、SGPは登録結果「エラー - サポートされていないRKパラメーターフィールド」を含むASPに登録応答メッセージを返します。この結果は、たとえば、SGPがISUPトラフィックをサポートせず、CIC範囲の粒度を提供しないため、SGPがルーティングキーのRK回路範囲リストをサポートしていない場合に使用できます。
A Registration Response "Error - Unsupported Traffic Handling Mode" is returned if the Routing Key in the REG REQ contains an Traffic Handling Mode that is inconsistent with the presently configured mode for the matching Application Server.
登録応答「エラー - サポートされていないトラフィックハンドリングモード」が返されます。REGREQのルーティングキーに、マッチングアプリケーションサーバーの現在構成されたモードと矛盾するトラフィックハンドリングモードが含まれている場合。
An ASP MAY register multiple Routing Keys at once by including a number of Routing Key parameters in a single REG REQ message. The SGP MAY respond to each registration request in a single REG RSP message, indicating the success or failure result for each Routing Key in a separate Registration Result parameter. Alternatively the SGP MAY respond with multiple REG RSP messages, each with one or more Registration Result parameters. The ASP uses the Local-RK-Identifier parameter to correlate the requests with the responses.
ASPは、単一のReg Reqメッセージにいくつかのルーティングキーパラメーターを含めることにより、複数のルーティングキーを一度に登録することができます。SGPは、各登録リクエストに単一のREG RSPメッセージで応答し、個別の登録結果パラメーターの各ルーティングキーの成功または障害の結果を示します。あるいは、SGPは複数のREG RSPメッセージで応答する場合があり、それぞれが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
ASでのASPの登録が成功したとき、SGPは、ASPの非アクティブへの移行を以前に開始しなかった場合、関連する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 that it is a member before attempting to move to the ASP-Down state.
ASPは、dereg reqメッセージを使用して、アプリケーションサーバー内のASPとしてSGPを使用して動的に登録することができます。DEREG REQメッセージのルーティングコンテキストパラメーターは、登録キーを登録するためのルーティングキーを指定します。ASPは、ルーティングキー（つまり、ASPの非アクティブACKを受け取った後の登録者）を登録しようとする前に、アプリケーションサーバーのASP不活性状態に移動する必要があります。また、ASPは、すべてのアプリケーションサーバーから、ASPダウン状態に移動しようとする前にメンバーであることを控除する必要があります。
The SGP examines the contents of the received Routing Context parameter and validates that the ASP is currently registered in the Application Server(s) related to the included Routing Context(s). If validated, the ASP is deregistered as an ASP in the related Application Server.
SGPは、受信したルーティングコンテキストパラメーターの内容を調べ、ASPが現在含まれているルーティングコンテキストに関連するアプリケーションサーバーに登録されていることを検証します。検証された場合、ASPは関連するアプリケーションサーバーのASPとして登録されます。
The deregistration procedure does not necessarily imply the deletion of Routing Key and Application Server configuration data at the SG. 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.
登録手順は、SGでのルーティングキーおよびアプリケーションサーバー構成データの削除を必ずしも意味するものではありません。他のASPは引き続きアプリケーションサーバーに関連付けられている可能性があります。その場合、ルーティングキーデータを削除してはなりません。登録がアプリケーションサーバーにASPがなくなった場合、SGはルーティングキーデータを削除する場合があります。
The SGP acknowledges the deregistration request by returning a DEREG RSP message to the requesting ASP. The result of the deregistration is found in the Deregistration Result parameter, indicating success or failure with cause.
SGPは、要求のASPにDereg RSPメッセージを返すことにより、登録要求を認めます。登録の結果は、登録結果パラメーターに見られ、原因による成功または失敗を示しています。
An ASP MAY deregister multiple Routing Contexts at once by including a number of Routing Contexts in a single DEREG REQ message. The SGP MAY respond to each deregistration request in a single DEREG RSP message, indicating the success or failure result for each Routing Context in a separate Deregistration Result parameter.
ASPは、単一のDereg Reqメッセージに多くのルーティングコンテキストを含めることにより、複数のルーティングコンテキストを一度に阻止できます。SGPは、単一のDereg RSPメッセージの各登録要求に応答する場合があり、各ルーティングコンテキストの成功または失敗の結果が別の登録結果パラメーターで成功または障害の結果を示します。
The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered.
登録/登録手順は、AS-SGの場合と同じ方法でIPSPの場合に機能します。IPSPは、リモートIPSPにRKを登録する場合があります。IPSPは、登録したRKSを登録する責任があります。
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-ResumeまたはMTP-STATUSのプリミティブを受信すると、SGP M3UA層は、対応するSS7シグナル伝達ネットワーク管理（SSNM）DUNA、DAVA、SCON、またはDUPUメッセージを送信します（セクション3.4）を参照してください。M3UAレイヤーは、SSNMメッセージのさまざまなフィールドをプリミティブで受け取った情報と一貫して埋める必要があります。
The SGP M3UA layer determines the set of concerned ASPs to be informed based on the specific SS7 network for which the primitive indication is relevant. In this way, all ASPs configured to send/receive traffic within a particular network appearance are informed. If the SGP operates within a single SS7 network appearance, then all ASPs are informed.
SGP M3UA層は、原始的な適応症が関連する特定のSS7ネットワークに基づいて通知される関係するASPのセットを決定します。このようにして、特定のネットワークの外観内でトラフィックを送信/受信するように構成されたすべてのASPに通知されます。SGPが単一のSS7ネットワークの外観内で動作する場合、すべてのASPが通知されます。
DUNA, DAVA, SCON, and DRST messages may be sent sequentially and processed at the receiver in the order sent.
Duna、Dava、Scon、およびDRSTメッセージは、送信された順序で受信機で順次送信され、処理される場合があります。
Sequencing is not required for the DUPU or DAUD messages, which MAY be sent unsequenced.
DUPUまたはDaudメッセージにはシーケンスは必要ありません。
At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) message from the remote M3UA Peer, the M3UA layer invokes the appropriate primitive indications to the resident M3UA-Users. Local management is informed.
ASPで、リモートM3UAピアからSS7シグナリングネットワーク管理（SSNM）メッセージを受信すると、M3UAレイヤーは常駐M3UAユーザーに適切な原始的な適応症を呼び出します。ローカル管理に通知されます。
In the case where a local event has caused the unavailability or congestion status of SS7 destinations, the M3UA layer at the ASP SHOULD pass up appropriate indications in the primitives to the M3UA User, as though equivalent SSNM messages were received. For example, the loss of an SCTP association to an SGP may cause the unavailability of a set of SS7 destinations. MTP-PAUSE indication primitives to the M3UA User are appropriate.
ローカルイベントがSS7宛先の利用不可または輻輳状態を引き起こした場合、ASPのM3UAレイヤーは、同等のSSNMメッセージが受信されたかのように、M3UAユーザーにプリミティブの適切な適応症を渡す必要があります。たとえば、SCTP関連のSGPを失うと、一連の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 effected 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ユーザーに適切な原始的な適応症を呼び出します。ローカル管理に通知されます。
Implementation Note: To accomplish this, the M3UA layer at an ASP maintains the status of routes via the SG, much like an MTP3 layer maintains route-set status.
実装注：これを達成するために、ASPのM3UAレイヤーは、MTP3レイヤーがルートセットステータスを維持するのと同じように、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 reception 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は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活性であるか、長期間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"). This is because the value indicates either congestion abatement or that the ITU MTP3 international congestion method is being used. In the international congestion method, the MTP3 layer at the SGP does not maintain the congestion status of any destinations and therefore the SGP cannot provide any congestion information in response to the DAUD. For the same reason, in the second of the cases above a DAUD message cannot reveal any congested destination(s).
実装注：上記の最初のケースでは、「混雑なし」または未定義」の輻輳レベル値を含む受信されたsconメッセージの場合、監査手順を呼び出さないでください（つまり、うっ血レベル= "0"）。これは、値が混雑の軽減またはITU MTP3国際渋滞法のいずれかを示しているためです。国際渋滞法では、SGPのMTP3層は目的地の輻輳状態を維持せず、したがってSGPは混雑を提供できません。Daudに応じた情報。同じ理由で、Daudメッセージの上記の2番目の場合、混雑した目的地を明らかにすることはできません。
The SGP SHOULD respond to a DAUD message with the MTP3 availability/congested status of the routeset associated with each Destination Point Code(s) 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). Where the SGP maintains the congestion status of the SS7 destination, and the SS7 destination is congested, the SGP MUST additionally respond with an SCON message before the DAVA or DRST message. If the SS7 destination is available and congested, the SGP MUST respond with an SCON message and then a DAVA message. If the SS7 destination is restricted and congested, the SGP MUST respond with an SCON message immediately followed by a DRST message. If the SGP has no information on the availability status of the SS7 destination, the SGP responds with a DUNA message, as it has no routing information to allow it to route traffic to this destination.
SGPは、Daudメッセージの各宛先ポイントコードに関連付けられているルートセットのMTP3の可用性/雑誌ステータスを使用して、Daudメッセージに応答する必要があります。要求された各SS7宛先のステータスは、DUNAメッセージ（利用できない場合）、DAVAメッセージ（利用可能な場合）、またはDRST（制限されている場合、SGPがこの機能をサポートしている場合）に示されています。SGPがSS7宛先の輻輳状態を維持し、SS7宛先が混雑している場合、SGPはDAVAまたはDRSTメッセージの前にSconメッセージでさらに応答する必要があります。SS7の宛先が利用可能で混雑している場合、SGPはSconメッセージ、次にDavaメッセージで応答する必要があります。SS7の宛先が制限され、混雑している場合、SGPはSconメッセージですぐにDRSTメッセージを送信する必要があります。SGPにSS7宛先の可用性ステータスに関する情報がない場合、SGPはDUNAメッセージで応答します。これは、この宛先へのトラフィックをルーティングできるルーティング情報がないためです。
Any DUNA or DAVA message in response to a DAUD message MAY contain a list of Affected Point Codes.
DAUDメッセージに応じたDUNAまたはDAVAメッセージには、影響を受けるポイントコードのリストが含まれている場合があります。
An SG MAY refuse to provide the availability or congestion status of a destination if, for example, the ASP is not authorized to know the status of the destination. The SG MAY respond with an Error Message (Error Code = "Destination Status Unknown")
たとえば、ASPが目的地のステータスを知ることを許可されていない場合、SGは目的地の可用性または輻輳状態の提供を拒否する場合があります。SGはエラーメッセージで応答する場合があります（エラーコード= "宛先ステータス不明"）
In the case where the MTP3 in the SG undergoes an MTP restart, event communication SHOULD be handled as follows:
SGのMTP3がMTP再起動を受ける場合、イベント通信は次のように処理する必要があります。
When the SG discovers SS7 network isolation, the SGPs send an indication to all concerned available ASPs (i.e., ASPs in the ASP-ACTIVE state) using DUNA messages for the concerned destinations.
SGがSS7ネットワークの分離を発見すると、SGPSは、関係するすべてのASP（つまり、ASP活性状態のASP）に兆候を送信します。
When the SG has completed the MTP Restart procedure, the M3UA layers at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any available/restricted SS7 destinations using the DAVA/DRST messages. No message is necessary for those destinations still unavailable after the restart procedure.
SGがMTP再起動手順を完了した場合、SGPのM3UA層は、DAVA/DRSTメッセージを使用して利用可能な/制限されたSS7宛先をASP活性状態において、関係するすべてのASPに通知します。再起動手続き後も利用できないこれらの宛先にはメッセージは必要ありません。
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 the ASP is in the ASP-ACTIVE state towards this SGP.
ASPのM3UAレイヤーがSGでSS7の宛先が利用できないことを示すDUNAメッセージを受信すると、MTPユーザーはMTP-Pauseの表示を受け取り、この宛先への影響を受けたトラフィックを停止します。M3UAがDAVA/DRSTメッセージを受信すると、MTPユーザーはMTPレスーム表示を受け取り、ASPがこのSGPに対してASP活性状態にある場合、新しく利用可能なSS7宛先へのトラフィックを再開できます。
The ASP MAY choose to audit the availability of unavailable destinations by sending DAUD messages. This would be for example the case when an AS becomes active at an ASP and does not have current destination statuses. If MTP restart is in progress at the SG, the SGP returns a DUNA message for that destination, even if it received an indication that the destination became available or restricted.
ASPは、Daudメッセージを送信して、利用できない目的地の可用性を監査することを選択できます。これは、たとえば、ASがASPでアクティブになり、現在の宛先ステータスがない場合です。SGでMTP再起動が進行中の場合、SGPは、目的地が利用可能になったか制限されたことを示したとしても、その目的地のDUNAメッセージを返します。
In the IPSP case, MTP restart could be considered if the IPSP also has connection to an SS7 network. In that case, the same behavior as described above for the SGP would apply to the restarting IPSP. This would also be the case if the IPSPs were perceived as exchanging MTP Peer PDUs, instead of MTP primitives between MTP User and MTP Provider. In other words, M3UA does not provide the equivalent to Traffic Restart Allowed messages indicating the end of the restart procedure between peer IPSPs that would also be connected to an SS7 network.
IPSPの場合、IPSPがSS7ネットワークにも接続している場合、MTP RestARTを考慮することができます。その場合、SGPの上記と同じ動作がIPSPの再起動に適用されます。これは、MTPユーザーとMTPプロバイダーの間のMTPプリミティブの代わりに、IPSPがMTPピアPDUを交換すると認識された場合にも当てはまります。言い換えれば、M3UAは、SS7ネットワークにも接続されているピアIPSP間の再起動手順の終了を示すトラフィックの再起動許可メッセージに相当するものを提供しません。
NOTE: Not all the Notify messages that are appropriate per the Notify procedures are shown in these examples.
注：これらの例には、通知手順に応じて適切なすべての通知メッセージが示されているわけではありません。
These scenarios show the example 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),
5.1.1 アプリケーションサーバーの単一ASP（ "1 0" Sparing）、
These scenarios show the example 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メッセージの例を示しています。
SGP ASP1
| |
|<-------------ASP Up-----------|
|-----------ASP Up Ack--------->|
| |
|<------- 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 Activeメッセージにオプションのルーティングコンテキストパラメーターが含まれている場合、ASP Activeメッセージは指定されたRC値にのみ適用されます。未知のRC値の場合、SGPはエラーメッセージで応答します。
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
| | Context
|----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g., invalid RKn), the Register Response message will contain an unsuccessful indication and the ASP will not subsequently send an ASP Active message.
注：登録が失敗した場合（たとえば、無効なRKN）、レジスタ応答メッセージには失敗した表示が含まれ、ASPはその後ASPアクティブメッセージを送信しません。
5.1.1.3 Single ASP in Multiple Application Servers (each with "1+0" sparing), Dynamic Registration (Case 1 - Multiple Registration Requests)
5.1.1.3 複数のアプリケーションサーバーの単一ASP（それぞれ「1 0」の散布）、動的登録（ケース1-複数の登録リクエスト）
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing
| | Context
|----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
| |
|<----REGISTER REQ(LRCn,RKn)----|
| |
|----REGISTER RESP(LRCn,RCn)--->|
| |
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g., invalid RKn), the Register Response message will contain an unsuccessful indication and the ASP will not subsequently send an ASP Active message. Each LRC/RK pair registration is considered independently.
注：登録が失敗した場合（たとえば、無効なRKN）、レジスタ応答メッセージには失敗した表示が含まれ、ASPはその後ASPアクティブメッセージを送信しません。各LRC/RKペアの登録は、独立して考慮されます。
It is not necessary to follow a Registration Request/Response message pair with an ASP Active message before sending the next Registration Request. The ASP Active message can be sent at any time after the related successful registration.
次の登録リクエストを送信する前に、ASPアクティブメッセージを使用して登録リクエスト/応答メッセージペアに従う必要はありません。ASPアクティブメッセージは、関連する登録が成功した後、いつでも送信できます。
5.1.1.4 Single ASP in Multiple Application Servers (each with "1+0" sparing), Dynamic Registration (Case 2 - Single Registration Request)
5.1.1.4 複数のアプリケーションサーバーの単一ASP（それぞれ「1 0」の散布）、動的登録（ケース2-単一登録リクエスト）
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<---REGISTER REQ({LRC1,RK1},---|
| ..., |
| {LRCn,RKn}),--|
| |
|---REGISTER RESP({LRC1,RC1},-->|
| ..., |
| (LRCn,RCn}) |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
: :
: :
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g., Invalid RKn), the Register Response message will contain an unsuccessful indication and the ASP will not subsequently send an ASP Active message. Each LRC/RK pair registration is considered independently.
注：登録が失敗した場合（たとえば、無効なRKN）、レジスタ応答メッセージには失敗した表示が含まれ、ASPはその後ASPアクティブメッセージを送信しません。各LRC/RKペアの登録は、独立して考慮されます。
The ASP Active message can be sent at any time after the related successful registration, and may have more than one RC.
ASPアクティブメッセージは、関連する登録の成功後いつでも送信でき、複数のRCがある場合があります。
This scenario shows the 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はASP活性状態で構成され、ASP2は「バックアップ」になるようになります。通信の失敗またはASP1のサービスからの撤退。ASP2は、ASP1とASP2がコール/トランザクション状態を共有する程度に応じて、ホット、ウォーム、またはコールドバックアップとして機能するか、障害/引き出しイベントの下でコール状態を通信できる場合があります。メッセージフローの例は、ASPアクティブメッセージが「オーバーライド」、「LoadShare」、または「ブロードキャスト」モードを示すかどうかに同じですが、通常、この例はオーバーライドモードを使用します。
SGP ASP1 ASP2
| | |
|<--------ASP Up---------| |
|-------ASP Up Ack------>| |
| | |
|<----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------>|
| | |
| | |
|<-------ASP Active------| |
|------ASP Active Ack--->| |
| | |
This scenario shows a similar case to Section 5.1.2 but where the two ASPs are brought to the state ASP-ACTIVE and subsequently loadshare the traffic. In this case, one ASP is sufficient to handle the total traffic load.
このシナリオは、セクション5.1.2と同様のケースを示していますが、2つのASPが州のASP活性に持ち込まれ、その後トラフィックをロードシェアします。この場合、1つのASPでは、総トラフィック負荷を処理するのに十分です。
SGP ASP1 ASP2
| | |
|<---------ASP Up--------| |
|--------ASP Up Ack----->| |
| | |
|<-----------------------------ASP Up---------------|
|----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)---| |
|-----ASP-Active Ack---->| |
| | |
|---NOTIFY (AS-ACTIVE)-->| |
|---------------------------NOTIFY (AS-ACTIVE------>|
| | |
|<---------------------------ASP Active (Ldshr)-----|
|------------------------------ASP Active Ack------>|
| | |
This scenario shows the 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活性に持ち込まれ、その後負荷を共有します。この場合、総トラフィック負荷（2 1スパーリング）を処理するには、最低2つのASPが必要です。
SGP ASP1 ASP2 ASP3
| | | |
|<------ASP Up------| | |
|-----ASP Up Ack--->| | |
| | | |
|<-------------------------ASP Up-------| |
|------------------------ASP Up Ack---->| |
| | | |
|<--------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack---->|
| | | |
| | | |
|<--ASP Act (Ldshr)-| | |
|----ASP Act Ack--->| | |
| | | |
| | | |
|<-------------------ASP Act. (Ldshr)---| |
|----------------------ASP Act Ack----->| |
| | | |
|---------Notify (AS-ACTIVE)----------->| |
|----------------------Notify (AS-ACTIVE)------------------>|
Following on from the example in Section 5.1.2, and 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不活性なメッセージ交換（つまり、ASP1からSGP）は発生しません。
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 on from the example in Section 5.1.4, and ASP1 withdraws from service:
セクション5.1.4の例に続き、ASP1はサービスから撤退します。
SGP ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.----| | |
|---ASP Inact Ack-->| | |
| | | |
|--------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->|
| | | |
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").
Notifyメッセージを送信すると、SGは必要な最小ASPリソースの知識を維持します（たとえば、SGがLoadShare ASの「n k」= "2 1"を知っている場合、「n」は現在等しく "1"です）。
Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP-ASP1) would not occur.
注：SGPがASP1 M3UAピアの損失を検出した場合（たとえば、M3UAハートビート損失またはSCTP障害の検出）、最初のASP不活性なメッセージ交換（つまり、SGP-ASP1）は発生しません。
An ASP which 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 on from Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" state:
現在、州のASP不活性で確認されているASP（つまり、ASPがASPの非アクティブACKメッセージを受け取った）は、サービスから削除される場合、ASPダウン状態に進むことができます。セクション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が以前にアプリケーションサーバー内の構成に登録手順を使用した場合、通常、縮小手順が使用されます。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不活性状態にあるはずであり、ASPダウン状態に移動しようとする前に、すべてのルーティングコンテキストで登録を行う必要があります。
This section describes the primitive mapping between the MTP3 User and the M3UA layer at an ASP.
このセクションでは、ASPでのMTP3ユーザーとM3UAレイヤー間のプリミティブマッピングについて説明します。
When the MTP3-User on the ASP has data to send to a remote MTP3-User, it uses the MTP-TRANSFER request primitive. The M3UA layer at the ASP will do the following when it receives an MTP-TRANSFER request primitive from the M3UA user:
ASPのMTP3ユーザーがリモートMTP3ユーザーに送信するデータを持っている場合、MTP-TransferリクエストのPrimitiveを使用します。ASPのM3UAレイヤーは、M3UAユーザーからPrimitiveをMTP転送要求を受信すると、次のことを行います。
- Determine the correct SGP;
- 正しいSGPを決定します。
- Determine the correct association to the chosen SGP;
- 選択したSGPの正しい関連性を決定します。
- Determine the correct stream in the association (e.g., based on SLS);
- 協会の正しいストリームを決定します（例えば、SLSに基づいて）。
- Determine whether to complete the optional fields of the DATA message;
- データメッセージのオプションフィールドを完了するかどうかを判断します。
- Map the MTP-TRANSFER request primitive into the Protocol Data field of a DATA message;
- MTP-Transferリクエストをマッププリミティブデータメッセージのプロトコルデータフィールドにマップします。
- Send the DATA message to the remote M3UA peer at the SGP, over the SCTP association.
- SCTP協会を介して、SGPのリモートM3UAピアにデータメッセージを送信します。
SGP ASP
| |
|<-----DATA Message-------|<--MTP-TRANSFER req.
| |
When the M3UA layer on the ASP receives a DATA message from the M3UA peer at the remote SGP, it will do the following:
ASP上のM3UA層がリモートSGPでM3UAピアからデータメッセージを受信すると、次のことが行われます。
- Evaluate the optional fields of the DATA message, if present;
- 存在する場合は、データメッセージのオプションフィールドを評価します。
- Map the Protocol Data field of a DATA message into the MTP-TRANSFER indication primitive;
- データメッセージのプロトコルデータフィールドをMTP転移表示プリミティブにマップします。
- Pass the MTP-TRANSFER indication primitive to the user part. In case of multiple user parts, the optional fields of the Data message are used to determine the concerned user part.
- ユーザーパーツにプリミティブなMTP転移表示を渡します。複数のユーザーパーツの場合、データメッセージのオプションフィールドを使用して、関係するユーザーパーツを決定します。
SGP ASP
| |
|------Data Message------>|-->MTP-Transfer ind.
| |
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監査SS7の宛先の可用性/輻輳状態でM3UA層を引き起こす可能性のある状況があります。注：内部M3UA管理機能によって開始されるため、MTP3ユーザーがM3UAレイヤーからこの監査をリクエストする原始はありません。
SGP ASP
| |
|<----------DAUD-----------|
|<----------DAUD-----------|
|<----------DAUD-----------|
| |
| |
This section describes the primitive mapping between the MTP3-User and the M3UA layer at an SGP.
このセクションでは、SGPでのMTP3ユーザーとM3UA層の間のプリミティブマッピングについて説明します。
When the M3UA layer at the SGP has received DATA messages from its peer destined to the SS7 network it will do the following:
SGPのM3UAレイヤーがSS7ネットワークに運命づけられているピアからデータメッセージを受信した場合、次のことが行われます。
- Evaluate the optional fields of the DATA message, if present, to determine the Network Appearance;
- 存在する場合は、データメッセージのオプションフィールドを評価して、ネットワークの外観を決定します。
- Map the Protocol data field of the DATA message into an MTP-TRANSFER request primitive;
- データメッセージのプロトコルデータフィールドをMTP-Transferリクエストプリミティブにマップします。
- Pass the MTP-TRANSFER request primitive to the MTP3 of the concerned Network Appearance.
- 関係するネットワークの外観のMTP3に原始的なMTP転移要求を渡します。
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転移表示プリミティブを使用します。SGPのM3UA層は、MTP転移指標プリミティブを受信すると、以下を実行します。
- Determine the correct AS using the distribution function;
- 分布関数を使用して正しいものを決定します。
- Select an ASP in the ASP-ACTIVE state
- ASPアクティブ状態でASPを選択します
- Determine the correct association to the chosen ASP;
- 選択したASPの正しい関連性を決定します。
- Determine the correct stream in the SCTP association (e.g., based on SLS);
- SCTP協会の正しいストリームを決定します（例：SLSに基づく）。
- Determine whether to complete the optional fields of the DATA message;
- データメッセージのオプションフィールドを完了するかどうかを判断します。
- Map the MTP-TRANSFER indication primitive into the Protocol Data field of a DATA message;
- MTP転送指示のプリミティブをデータメッセージのプロトコルデータフィールドにマッピングします。
- Send the DATA message to the remote M3UA peer in the ASP, over the SCTP association
- SCTP協会を介して、ASPのリモートM3UAピアにデータメッセージを送信する
SGP ASP
| |
--MTP-TRANSFER ind.->|-----------DATA --------->|
| |
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 Indidication Primitiveを、関連する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.-->
| |
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レスメの指示原始を生成します。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ステータスの指標プリミティブを生成します。M3UAレイヤーは、この原始的なスコンメッセージにマッピングされます。意図したアプリケーションサーバーに基づいて、どのASPがSconメッセージを送信するかを決定します。
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 based on the intended Application Server.
SGPのMTP3レイヤーは、SS7ネットワークからUPUメッセージを受信するとMTPステータス表示プリミティブを生成します。M3UAレイヤーは、このプリミティブをDUPUメッセージにマッピングします。意図したアプリケーションサーバーに基づいて、DUPUを送信するASP（s）が決定されます。
SGP ASP
| |
--MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
| |
5.5 Examples for IPSP communication.
5.5 IPSP通信の例。
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協会はすでに設定されていると想定されています。単一の交換と二重交換の両方の動作は、説明のために含まれています。
5.5.1 Single exchange:
5.5.1 単一交換：
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 are previously agreed to be the same in both directions.
ルーティングコンテキストは、以前は両方向で同じであることが合意されています。
5.5.2 Double exchange:
5.5.2 二重交換：
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 as enough since the response by the other peer can be considered as a notice that it is in ASP_UP state.
このアプローチでは、他のピアによる応答がASP_UP状態にあるという通知と見なすことができるため、ASPアップメッセージの1つの交換のみが十分であると考えることができます。
For the same reason, only one ASP Down message is needed since once that an IPSP receives ASP_Down ack message it is itself considered as being in the ASP_Down state and not allowed to receive ASPSM messages.
同じ理由で、IPSPがASP_DOWN ACKメッセージを受信すると、それ自体がASP_DOWN状態であると見なされ、ASPSMメッセージの受信が許可されていないため、ASPダウンメッセージは1つだけです。
M3UA is designed to carry signalling messages for telephony services. As such, M3UA must involve the security needs of several parties: the end users of the services; the network providers and the applications involved. Additional requirements may come from local regulation. While having some overlapping security needs, any security solution should fulfill all of the different parties' needs.
M3UAは、テレフォニーサービスのシグナリングメッセージを携帯するように設計されています。そのため、M3UAには、いくつかの当事者のセキュリティニーズが必要です。サービスのエンドユーザー。ネットワークプロバイダーと関連するアプリケーション。追加の要件は、現地の規制から生じる場合があります。重複するセキュリティニーズがありますが、セキュリティソリューションはすべてのさまざまな当事者のニーズを満たす必要があります。
There is no quick fix, one-size-fits-all solution for security. As a transport protocol, M3UA has the following security objectives:
セキュリティのためのクイックフィックス、ワンサイズのすべてのソリューションはありません。輸送プロトコルとして、M3UAには次のセキュリティ目標があります。
* Availability of reliable and timely user data transport. * Integrity of user data transport. * Confidentiality of user data.
* 信頼できるタイムリーなユーザーデータトランスポートの可用性。*ユーザーデータトランスポートの整合性。*ユーザーデータの機密性。
M3UA is recommended to be transported on SCTP. SCTP [17] provides certain transport related security features, such as some protection against:
M3UAはSCTPで輸送することをお勧めします。SCTP [17]は、次のような保護など、特定の輸送関連のセキュリティ機能を提供します。
* Blind Denial of Service Attacks * Flooding * Masquerade * Improper Monopolization of Services
* 盲目のサービス拒否攻撃 *洪水 *仮面舞踏会 *サービスの不適切な独占
When M3UA is running in professionally managed corporate or service provider network, it is reasonable to expect that this network includes an appropriate security policy framework. The "Site Security Handbook" [22] should be consulted for guidance.
M3UAが専門的に管理されているコーポレートまたはサービスプロバイダーネットワークで実行されている場合、このネットワークに適切なセキュリティポリシーフレームワークが含まれることを期待することは合理的です。「サイトセキュリティハンドブック」[22]は、ガイダンスについて参照する必要があります。
When the network in which M3UA runs in involves more than one party, it may not be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [23] for more information on configuring IPSEC services.
M3UAが実行されるネットワークに複数の当事者が関与する場合、すべての当事者が十分な方法でセキュリティを実装していることを期待することは合理的ではないかもしれません。そのような場合、ユーザーペイロードの機密性を確保するためにIPSECを使用することをお勧めします。IPSECサービスの構成の詳細については、[23]に相談してください。
Particularly for mobile users, the requirement for confidentiality may include the masking of IP addresses and ports. In this case application level encryption is not sufficient; IPSEC ESP [24] SHOULD be used instead. Regardless of which level performs the encryption, the IPSEC ISAKMP [25] service SHOULD be used for key management.
特にモバイルユーザーにとって、機密性の要件には、IPアドレスとポートのマスキングが含まれる場合があります。この場合、アプリケーションレベルの暗号化は十分ではありません。代わりにIPSEC ESP [24]を使用する必要があります。どのレベルが暗号化を実行するかに関係なく、IPSEC ISAKMP [25]サービスをキー管理に使用する必要があります。
IANA has assigned an M3UA value for the Payload Protocol Identifier in the SCTP DATA chunk. The following SCTP Payload Protocol Identifier is registered:
IANAは、SCTPデータチャンクのペイロードプロトコル識別子にM3UA値を割り当てました。次のSCTPペイロードプロトコル識別子が登録されています。
M3UA "3"
M3UA "3"
The SCTP Payload Protocol Identifier value "3" SHOULD be included in each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA protocol. The value "0" (unspecified) is also allowed but any other values MUST not be used. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a DATA chunk.
SCTPペイロードプロトコル識別子値「3」は、SCTPがM3UAプロトコルを運んでいることを示すために、各SCTPデータチャンクに含める必要があります。値「0」（不特定）も許可されていますが、他の値は使用してはなりません。このペイロードプロトコル識別子は、SCTPでは直接使用されませんが、特定のネットワークエンティティで使用されて、データチャンクで運ばれる情報の種類を識別することができます。
The User Adaptation peer MAY use the Payload Protocol Identifier as a way of determining additional information about the data being presented to it by SCTP.
ユーザー適応ピアは、SCTPによって提示されているデータに関する追加情報を決定する方法として、ペイロードプロトコル識別子を使用する場合があります。
IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It is recommended that SGPs use this SCTP port number for listening for new connections. SGPs MAY also use statically configured SCTP port numbers instead.
IANAは、M3UAにSCTP（およびUDP/TCP）ポート番号2905を登録しています。SGPは、新しい接続をリスニングするためにこのSCTPポート番号を使用することをお勧めします。SGPSは、代わりに静的に構成されたSCTPポート番号を使用する場合もあります。
This protocol may also be extended through IANA in three ways:
このプロトコルは、3つの方法でIANAを介して拡張することもできます。
-- through definition of additional message classes,
-- through definition of additional message types, and
-- 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 (25]
新しいメッセージクラス、タイプ、パラメーターの定義と使用は、シグトラン適応レイヤーの不可欠な部分です。したがって、これらの拡張機能は、IETFコンセンサスアクションを通じてIANAによって割り当てられます。IANAの考慮事項セクションをRFCSに記述するためのガイドラインで定義されています（25]
The proposed extension must in no way adversely affect the general working of the protocol.
提案された拡張は、プロトコルの一般的な作業に決して悪影響を及ぼさないでください。
The documentation for a new message class MUST include the following information:
新しいメッセージクラスのドキュメントには、次の情報を含める必要があります。
(a) A long and short name for the new message class; (b) A detailed description of the purpose of the message class.
(a) 新しいメッセージクラスの長くて短い名前。（b）メッセージクラスの目的の詳細な説明。
The documentation for a new message type MUST include the following information:
新しいメッセージタイプのドキュメントには、次の情報を含める必要があります。
(a) A long and short name for the new message type;
(b) A detailed description of the structure of the message;.
(c) A detailed definition and description of intended use for each
field within the message;
(d) A detailed procedural description of the use of the new
message type within the operation of the protocol;
(e) A detailed description of error conditions when receiving this
message type.
When an implementation receives a message type which 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.
[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、「Signaling System No.7（SS7）-ISDNユーザーパーツ（ISUP）」
[2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[2] ANSI T1.113-「シグナリングシステム番号7-ISDNユーザーパーツ」
[3] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services"
[3] ETSI ETS 300 356-1 "統合サービスデジタルネットワーク（ISDN）;シグナリングシステムNo.7; ISDNユーザーパーツ（ISUP）バージョン2のバージョン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、「シグナリングシステムNo. 7（SS7） - シグナリング接続制御パーツ（SCCP）」
[5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection Control Part"
[5] ANSI T1.112「シグナリングシステム番号7-シグナリング接続制御部品」
[6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Signalling Connection Control Part (SCCP) (connectionless and connection-oriented class 2) to support international interconnection; Part 1: Protocol specification"
[6] ETSI ETS 300 009-1、「統合サービスデジタルネットワーク（ISDN）;シグナリングシステムNo.7;シグナリング接続制御パーツ（SCCP）（Connectionless and Connection-Connectioneded Class 2）は、国際的な相互接続をサポートしています。パート1：プロトコル仕様」
[7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7 (SS7) - Message Transfer Part (MTP)"
[7] ITU -Tの推奨事項Q.701からQ.705、「シグナリングシステムNo. 7（SS7） - メッセージ転送パーツ（MTP）」
[8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
[8] ANSI T1.111「シグナリングシステム番号7-メッセージ転送パーツ」
[9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer Part (MTP) to support international interconnection; Part 1: Protocol specification"
[9] ETSI ETS 300 008-1、「Integrated Services Digital Network（ISDN）; Signaling System No.7; Message Transfer Part（MTP）国際的な相互接続をサポートする;パート1：プロトコル仕様」
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[10] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[11] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H., Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[11] Ong、L.、Rytina、M.、Garcia、H.、Schwarzbauer、L.、Coene、H.、Lin、I.、Juhasz、M。and C. Holdrege、「シグナリング輸送のためのフレームワークアーキテクチャ」、RFC 2719、1999年10月。
[12] ITU-T Recommendation Q.720, "Telephone User Part"
[12] ITU-Tの推奨事項Q.720、「電話ユーザーパーツ」
[13] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7) - Transaction Capabilities (TCAP)"
[13] ITU -Tの推奨事項Q.771からQ.775「シグナリングシステムNo. 7（SS7） - トランザクション機能（TCAP）」
[14] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities Application Part"
[14] ANSI T1.114「シグナリングシステム番号7-トランザクション機能アプリケーションパーツ」
[15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification"
[15] ETSI ETS 300 287-1、「Integrated Services Digital Network（ISDN）; Signaling System No.7;トランザクション機能（TC）バージョン2;パート1：プロトコル仕様」
[16] 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"
[16] 3G TS 25.410 V4.0.0（2001-04）「技術仕様 - 第3世代パートナーシッププロジェクト、技術仕様グループラジオアクセスネットワーク、UTRAN IUインターフェイス：一般的な側面と原則」
[17] Stewart, R., Xie, Q., Mornmeault, K., Sharp, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transport Protocol", RFC 2960, October 2000.
[17] Stewart、R.、Xie、Q.、Mornmeault、K.、Sharp、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。and V. Paxson、「Stream Control Transport Protocol」、RFC 2960、2000年10月。
[18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - Service Specific Coordination Function for signalling at the Network Node Interface (SSCF at NNI)"
[18] ITU-Tの推奨Q.2140「B-ISDN ATM適応レイヤー - ネットワークノードインターフェイス（NNIのSSCF）でのシグナリングのためのサービス固有の調整関数」
[19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP)"
[19] ITU-T推奨Q.2110「B-ISDN ATM適応レイヤー - サービス固有の接続指向プロトコル（SSCOP）」」
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[20] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[21] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 functions and messages using the services of ITU Recommendation Q.2140"
[21] ITU-Tの推奨事項Q.2210 "ITU推奨のサービスを使用したメッセージパーツレベル3の機能とメッセージQ.2140」
[22] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[22] Fraser、B。、「サイトセキュリティハンドブック」、FYI 8、RFC 2196、1997年9月。
[23] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture for the Internet Protocol", RFC 3168, November 1998.
[23] Ramakrishnan、S.、Floyd、S。and D. Black、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 3168、1998年11月。
[24] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[24] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[25] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[25] Maughan、D.、Schertler、M.、Schneider、M. and J. Turner、「Internet Security Association and Key Management Protocol」、RFC 2408、1998年11月。
[26] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[26] Narten、T。およびH. Alverstrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[27] 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, August 2002.
[27] Morneault、K.、Dantu、R.、Sidebottom、G.、Bidulock、B。and J. Heitz、「Signaling System 7（SS7）メッセージ転送パート2（MTP2） - ユーザー適応レイヤー」、RFC 3331、2002年8月。
[28] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work in Progress.
[28] ジョージ、T。、他al。、「SS7 MTP2-USER PEER-to-Peer適応層」、進行中の作業。
[29] Telecommunication Technology Committee (TTC) Standard JT-Q704, "Message Transfer Part Signaling Network Functions", April 28, 1992.
[29] 1992年4月28日、電気通信技術委員会（TTC）標準JT-Q704
The authors would like to thank Antonio Roque Alvarez, Joyce Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Antonio Caete, 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.
著者は、アントニオ・ロケ・アルバレス、ジョイス・アーチボルド、トルガ・アスヴェレン、マリア・クルス・バルトローム・ロドリゴ、ダン・ブレンデス、アントニオ・ケーテ、ニキル・ジャイン、ロランド・ジェスケ、ジョー・ケラー、カート・カイト、ミン・リン、スティーブ・ロルスソ、ナト・マキナイ、ハワード・メイ、フランソワ・ミューイラウド、バリー・ナゲルバーグ、ニール・オルソン、ハインツ・プラントナー、シャマル・プラサド、ムケシュ・パンハーニ、セルヴァム・レンガサミ、ジョン・シャンツ、レイ・シン、マイケル・トゥクセン、ニティン・トマール、ジェリー・ヴェルヴィンプ、ティム・ベトター、カズオワ・ワタナベ、彼らの貴重なコメントと提案のために。
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
Ian Rytina -Ericsson Guy Mousseau -Nortel Networks Lyndon Ong -Ciena Hanns Juergen Schwarzbauer -Siemens Klaus Gradischnig -Detecon Inc. Mallesh Kalla -Telcordia Normand Glaude -Performance Technolocies
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ネットワークから複数の分散ASP（MGCやIPデータベースなど）に受け取ったMTP3ユーザーシグナリングトラフィックの輸送をサポートするために使用されます。明らかに、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ベースのアプリケーションの間のエンドツーエンドネットワークアーキテクチャに単一の障害ポイントが存在しないことを要求する場合があります。これは通常、冗長SGPSまたはSGPS、冗長ホスト、および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 5 below:
IPネットワークドメインでのSS7キャリアグレードの操作に関連する物理ネットワークアーキテクチャの1つの例を以下の図5に示します。
SGs MGCs
SGS MGCS
Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * =
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
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 5 - Physical Model
図5-物理モデル
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つ以上のシグナリングゲートウェイプロセスでは、単一のシグナリングゲートウェイが構成されています。
This example model can also be applied to IPSP-IPSP signalling. In this case, each IPSP may have its services distributed across 2 hosts or more, 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.
キャリアグレードのネットワークの場合、特定のシグナル伝達プロセスの障害または分離は、安定した呼び出しやトランザクションが失われることはありません。これは、シグナリングプロセスでは、場合によっては、コール/トランザクション状態を共有するか、互いにコール状態情報を渡すことができることを意味します。ASPがコール処理を実行する場合、特定のトランク終了のためにMGCコントロールを転送するために、関連するメディアゲートウェイの調整も必要になる場合があります。ただし、このコール/トランザクション状態情報の共有または通信は、このドキュメントの範囲外です。
This model serves as an example. M3UA imposes no restrictions as to the exact layout of the network elements, the message distribution algorithms and the distribution of the signalling processes. Instead, it provides a framework and a set of messages that allow for a flexible and scalable signalling network architecture, aiming to provide reliability and performance.
このモデルは例として機能します。M3UAは、ネットワーク要素の正確なレイアウト、メッセージ分布アルゴリズム、およびシグナル伝達プロセスの分布に関して制限を課しません。代わりに、信頼性とパフォーマンスを提供することを目的とした柔軟でスケーラブルなシグナリングネットワークアーキテクチャを可能にするフレームワークと一連のメッセージを提供します。
At the SGP, an Application Server list contains active and inactive ASPs to support ASP broadcast, loadsharing and failover procedures. The list of ASPs within a logical Application Server is kept updated in the SGP to reflect the active Application Server Process(es).
SGPでは、アプリケーションサーバーリストには、ASPブロードキャスト、ロードシェアリング、フェールオーバー手順をサポートするためのアクティブおよび非アクティブなASPが含まれています。論理アプリケーションサーバー内のASPのリストは、Active Application Serverプロセス（ES）を反映するために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またはHost4のASP1の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で着信メッセージが送信されます。HOST1のASP1は、通常、ASP1/HOST1に障害または接続の喪失時に「アクティブ」な状態に持ち込まれます。
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
HOST1のSGP1のASリストは、LoadShareモードでも設定される場合があります。
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のルーティングキーとして使用するルーティング情報の選択において、ネットワークオペレーターが注意する必要がある場合があります。
For example, where Application Servers are defined using ranges of ISUP CIC values, the Operator is implicitly splitting up control of the related circuit groups. Some CIC value range assignments may interfere with ISUP circuit group management procedures.
たとえば、ISUP CIC値の範囲を使用してアプリケーションサーバーが定義されている場合、オペレーターは関連する回路グループの制御を暗黙的に分割しています。一部のCIC値範囲の割り当ては、ISUP回路グループ管理手順を妨げる可能性があります。
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. For example, the two ASPs may share call state via shared memory, or may use an ASP to ASP protocol to pass call state information. Any ASP-to-ASP protocol to support this function is outside the scope of this document.
フェールオーバーの過程で、ASPがコール処理をサポートする場合、安定した呼び出しが失敗しないことをお勧めします。「遷移」への呼び出しは失敗する可能性がありますが、関係するASP間の通信の測定を使用してこれを緩和することができます。たとえば、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モデルと同様に、SGSは1つ以上のSGプロセス（SGP）で構成され、アクティブ/バックアップまたはロードシェアリングモデルを使用して、1つまたは複数のホストに分布します。SGPがすべてまたは部分的なSS7接続を失い、その他のSGPが存在する場合、SGPはSCTP関連を関係するASPに終了する場合があります。
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がSS7ネットワークに向けられているSS7ネットワークに向かって、複数のSGPを使用してルーティングするメッセージをルーティングする可能性があります。このモデルでは、シグナリングゲートウェイが単一のSGとして機能するホストのクラスターとして展開されます。プライマリ/バックアップ冗長性モデルが可能であり、SCTP AssociationがプライマリSGPに利用できないことを使用して、影響を受けたトラフィックを代替SGPに再ルーティングできるようになります。信号メッセージが複数のSGP間で負荷がかかっているロードシェアリングモデルが可能です。SGの各アクティブSGPにシグナリングメッセージが送信されるブロードキャストモデルも可能です。SGPS上の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
ASPのM3UA層の観点から見ると、特定のSGは、SGの少なくとも1つのSGPとSCTP関連が確立されている場合、SGPがASPへの承認を返した場合、プロビジョニング付きSS7宛先Xにトラフィックを転送できます。ASPがその宛先Xのトラフィックを積極的に処理していることを示します。SGPは、宛先Xがアクセスできないことを示しておらず、SGPがMTPの再起動を示していないことを示しています。ASPがSS7ネットワークにトラフィックを転送するために複数のSGPを使用するように構成されている場合、ASPはSGPの現在の能力に関する知識を維持する必要があります
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, 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 to minimize message missequencing, as required by the SS7 User Parts.
関心のある目的地へのトラフィックを処理します。この情報は、障害、回復、メンテナンス活動が発生した場合、アクティブ/バックアップ、ロードシェアリングモデル、放送モデルのために、サービスの全体的な信頼性にとって重要です。ASP M3UAは、この情報を混雑回避のために使用する場合もあります。SGPS上のMTP3ユーザーメッセージの分布は、SS7ユーザーパーツで要求されるように、メッセージの誤解を最小限に抑えるために行う必要があります。
Editors' Addresses
編集者のアドレス
Greg Sidebottom Signatus Technologies Kanata, Ontario, Canada
カナダ、オンタリオ州カナタのグレッグサイドボトムシグナタステクノロジーズ
EMail: greg@signatustechnologies.com
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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。