RFC3331 日本語訳
3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - UserAdaptation Layer. K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock,J. Heitz. September 2002. (Format: TXT=210807 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Morneault
Request for Comments: 3331 Cisco Systems
Category: Standards Track R. Dantu
NetRake
G. Sidebottom
Signatus Technologies
B. Bidulock
OpenSS7
J. Heitz
Lucent
September 2002
Morneaultがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3331年のシスコシステムズカテゴリ: 2002年9月のB.Bidulock OpenSS7J.ハイツLucentの標準化過程R.Dantu NetRake G.Sidebottom Signatus技術
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -
User Adaptation Layer
シグナリングシステム7(SS7)メッセージ転送第2部(MTP2)--ユーザ適合層
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document defines a protocol for the backhauling of Signaling System 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signalling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. The Signalling Gateway would act as a Signalling Link Terminal.
このドキュメントは、Signaling System7Message Transfer Part2(SS7 MTP2)ユーザ合図メッセージのbackhaulingのためにIPの上でStream Control Transmissionプロトコル(SCTP)を使用することでプロトコルを定義します。 このプロトコルはSignallingゲートウェイ(SG)とメディアゲートウェイController(MGC)の間で使用されるでしょう。 SGがSS7 Message Transfer Part(MTP)を使用する標準のSS7インタフェースの上で輸送を提供すると合図するSS7を受けると思われます。 SignallingゲートウェイはSignalling Link Terminalとして機能するでしょう。
Morneault, et. al. Standards Track [Page 1] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[1ページ]。
Table of Contents
目次
1. Introduction.............................................. 2
1.1 Scope.................................................. 3
1.2 Terminology............................................ 3
1.3 M2UA Overview.......................................... 5
1.4 Services Provided by the M2UA Adaptation Layer......... 7
1.5 Functions Provided by the M2UA Layer................... 9
1.6 Definition of the M2UA Boundaries..................... 12
2. Conventions.............................................. 16
3. Protocol Elements........................................ 16
3.1 Common Message Header................................. 16
3.2 M2UA Message Header................................... 22
3.3 M2UA Messages......................................... 23
4. Procedures............................................... 58
4.1 Procedures to Support the M2UA-User Layer............. 58
4.2 Receipt of Primitives from the Layer Management....... 59
4.3 AS and ASP State Maintenance.......................... 61
4.4 Link Key Management Procedures........................ 73
5. Examples of MTP2 User Adaptation (M2UA) Procedures....... 75
5.1 Establishment of associations between SGP and MGC..... 75
examples
5.2 ASP Traffic Fail-over Examples........................ 77
5.3 SGP to MGC, MTP Level 2 to MTP Level 3 Boundary
Procedures............................................ 78
6. Timer Values............................................. 85
7. Security Considerations.................................. 85
7.1 Threats................................................ 85
7.2 Protecting Confidentiality............................. 86
8. IANA Considerations...................................... 86
8.1 SCTP Payload Protocol Identifier....................... 86
8.2 M2UA Protocol Extensions............................... 86
9. Acknowledgements......................................... 87
10. References............................................... 88
Appendix A: Signalling Network Architecture.................. 90
Authors' Addresses........................................... 92
Full Copyright Statement..................................... 94
1. 序論… 2 1.1範囲… 3 1.2用語… 3 1.3M2UA概要… 5 M2UA適合で提供された1.4のサービスが層にされます… 7 M2UAによって提供された1.5の機能が層にされます… 9 1.6 M2UA境界の定義… 12 2. コンベンション… 16 3. Elementsについて議定書の中で述べてください… 16 3.1の一般的なメッセージヘッダー… 16 3.2M2UAメッセージヘッダー… 22 3.3 M2UAメッセージ… 23 4. 手順… 58 M2UA-ユーザをサポートする4.1の手順が層にされます… 58 4.2 層の管理からの基関数の領収書… 59、4.3、ASPはメインテナンスを述べます… 同じくらいそして、… 61 4.4 Key Management手順をリンクしてください… 73 5. MTP2ユーザ適合(M2UA)手順に関する例… 75 5.1 SGPとMGCとの協会の設立… 75の例5.2のASPオーバーTraffic Fail Examples… 77 5.3 MGC、MTPへのMTPの平らな2へのSGPは3つの境界手順を平らにします… 78 6. タイマ値… 85 7. セキュリティ問題… 85 7.1の脅威… 85 7.2 秘密性を保護します… 86 8. IANA問題… 86 8.1 SCTP有効搭載量プロトコル識別子… 86 8.2 M2UAは拡大について議定書の中で述べます… 86 9. 承認… 87 10. 参照… 88 付録A: ネットワークアーキテクチャに合図します… 90人の作者のアドレス… 92 完全な著作権宣言文… 94
1. Introduction
1. 序論
This document defines a protocol for the backhauling of SS7 [1] MTP2 User [2] [3] [4] (i.e. MTP3) signalling messages over IP using the Stream Control Transmission Protocol (SCTP) [8]. This protocol would be used between a Signalling Gateway (SG) and Media Gateway Controller (MGC).
このドキュメントは、SS7[1]MTP2 User[2][3][4](すなわち、MTP3)のbackhaulingのためにStream Control Transmissionプロトコル(SCTP)[8]を使用することでIPの上でメッセージに合図しながら、プロトコルを定義します。 このプロトコルはSignallingゲートウェイ(SG)とメディアゲートウェイController(MGC)の間で使用されるでしょう。
Morneault, et. al. Standards Track [Page 2] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[2ページ]。
1.1 Scope
1.1 範囲
There is a need for Switched Circuit Network (SCN) signalling protocol delivery from a Signalling Gateway (SG) to a Media Gateway Controller (MGC) [9]. The delivery mechanism addresses the following objectives:
Signallingゲートウェイ(SG)からメディアゲートウェイController(MGC)[9]までのSwitched Circuit Network(SCN)合図プロトコル配送の必要があります。 排紙機構は以下の目的を扱います:
* Support for MTP Level 2 / MTP Level 3 interface boundary
* Support for communication between Layer Management modules on SG
and MGC
* Support for management of SCTP active associations between the SG
and MGC
* MTP Levelには、SGとMGCとのSCTPの活動的な協会の経営のSGとMGC*サポートのときに2 / MTP Level3がLayer Managementモジュールのコミュニケーションのインタフェース境界*サポートであるとサポートしてください。
The SG will terminate up to MTP Level 2 and the MGC will terminate MTP Level 3 and above. In other words, the SG will transport MTP Level 3 messages over an IP network to a MGC.
SGはMTP Level2まで終わるでしょう、そして、MGCはより多くのMTP Level3を終えるでしょう。 言い換えれば、SGはIPネットワークの上でMTP Level3メッセージをMGCに輸送するでしょう。
1.2 Terminology
1.2 用語
Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the MTP Level 3 and call processing for SS7 links terminated by the Signalling Gateways. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary, ...).
アプリケーションServer(AS)--特定のアプリケーションインスタンスに役立つ論理的な実体。 Application Serverに関する例はSS7リンクのためのMTP Level3と呼び出し処理がSignalling Gatewaysで終えたMGC取り扱いです。 実際に話すなら、1以上の規則正しいリストがApplication Server Processes(例えば、プライマリの、そして、セカンダリの第三、…)を関係づけたので、ASはSGでモデル化されます。
Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are active or standby MGC instances.
アプリケーションServer Process(ASP)--Application Server Application Server Processesに関する例のプロセスインスタンスはアクティブであるか予備MGCインスタンスです。
Association - An association refers to a SCTP association. The association will provide the transport for the delivery of protocol data units for one or more interfaces.
協会--協会はSCTP協会について言及します。 協会はプロトコルデータ単位の配送のための輸送を1つ以上のインタフェースに提供するでしょう。
Backhaul - Refers to the transport of signalling from the point of interface for the associated data stream (i.e., SG function in the MGU) back to the point of call processing (i.e., the MGCU), if this is not local [9].
逆送--これが地方の[9]でないなら関連データストリーム(すなわち、SGはMGUで機能する)のためにインタフェースのポイントから呼び出し処理(すなわち、MGCU)まで合図する輸送について言及します。
Fail-over - The capability to reroute signalling traffic as required to an alternate Application Server Process within an Application Server in the event of failure or unavailability of a currently used Application Server Process. Fail-back MAY apply upon the return to service of a previously unavailable Application Server Process.
フェイルオーバー--現在中古のApplication Server Processの失敗か使用不能の場合、必要に応じてApplication Serverの中の代替のApplication Server Processに合図トラフィックを別ルートで送る能力。 フェールバックはリターンのときに以前に入手できないApplication Server Processのサービスに適用されるかもしれません。
Host - The computing platform that the ASP process is running on.
ホスト--ASPプロセスが走っているコンピューティングプラットホーム。
Morneault, et. al. Standards Track [Page 3] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[3ページ]。
Interface - For the purposes of this document, an interface is a SS7 signalling link.
インタフェース--このドキュメントの目的のために、インタフェースはSS7合図リンクです。
Interface Identifier - The Interface Identifier identifies the physical interface at the SG for which the signalling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP.
インタフェースIdentifier--Interface Identifierは合図メッセージが送るか、または受信されているSGで物理インターフェースを特定します。 Interface Identifierパラメタの形式は、テキストか整数であるかもしれません。ネットワーク・オペレータ方針によると、それの値は割り当てられます。 使用される値はSGとASPの間で唯一の、そして、連携しているローカルの意味のものです。
Layer Management - Layer Management is a nodal function in an SG or ASP that handles the inputs and outputs between the M2UA layer and a local management entity.
層のManagement--層のManagementはM2UA層と現地管理職者実体の間の入力と出力を扱うSGかASPでこぶのような機能です。
Link Key - The link key is a locally unique (between ASP and SG) value that identifies a registration request for a particular Signalling Data Link and Signalling Terminal pair.
Keyをリンクしてください--リンクキーは特定のSignalling Data LinkとSignalling Terminal組を求める登録要求を特定する局所的にユニークな(ASPとSGの間の)値です。
MTP - The Message Transfer Part of the SS7 protocol
MTP--SS7プロトコルのMessage Transfer Part
MTP2 - MTP Level 2, the signalling data link layer of SS7
MTP2--MTP Level2、SS7の合図データ・リンク層
MTP3 - MTP Level 3, the signalling network layer of SS7
MTP3--MTP Level3、SS7の合図ネットワーク層
MTP2-User - A protocol that uses the services of MTP Level 2 (i.e. MTP3).
MTP2-ユーザ--MTP Level2(すなわち、MTP3)のサービスを利用するプロトコル。
Network Byte Order: Most significant byte first, a.k.a Big Endian.
バイトオーダーをネットワークでつないでください: 大部分の重要なバイト最初に、a.k.a Big Endian。
Signalling Data Link - An SDL refers to a specific communications facility that connects two Signalling Link Terminals.
合図Data Link--SDLは2Signalling Link Terminalsを接続する特定のコミュニケーション施設について言及します。
Signalling Gateway (SG) - An SG is a signalling agent at the edge of the IP network. An SG appears to the SS7 as one or more Signalling Link Terminals that are connected to one or more Signalling Data Links in the SS7 network. An SG contains a set of one or more unique Signalling Gateway Processes, on which one or more is normally actively processing traffic. Where an SG contains more than one SGP, the SG is a logical entity.
合図ゲートウェイ(SG)--SGはIPネットワークの縁の合図エージェントです。 SGはSS7ネットワークで1Signalling Dataのリンクスに接続される1Signalling Link TerminalsとしてSS7において現れます。 SGは1ユニークなSignallingゲートウェイProcessesの1セットを含んでいます。(そこでは、通常、1つ以上が活発に処理しているトラフィックです)。 SGが1SGPを含んでいるところでは、SGは論理的な実体です。
Signalling Gateway Process (SGP) - A process instance that uses M2UA to communicate to and from a Signalling Link Terminal. It serves as an active, backup or load-sharing process of a Signalling Gateway.
合図ゲートウェイProcess(SGP)--Signalling Link TerminalとSignalling Link Terminalから交信するのにM2UAを使用するプロセスインスタンス。 それはSignallingゲートウェイの活発なバックアップか負荷分割法プロセスとして機能します。
Signalling Link Terminal (SLT) - Refers to the means of performing all of the functions defined at MTP level 2 regardless of their implementation [2,3].
合図Link Terminal(SLT)--それらの実装[2、3]にかかわらずMTPレベル2で定義された機能のすべてを実行する手段を示します。
Morneault, et. al. Standards Track [Page 4] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[4ページ]。
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ストリームについて言及します。 1つのSCTP終点から別の終点まで確立された単方向の論理チャネルはSCTP終点を関連づけました。そこでは、連続して順不同のデリバリ・サービスに提出されたものを除いて、すべてのユーザメッセージが提供されます。
1.3 M2UA Overview
1.3 M2UA概要
The framework architecture that has been defined for SCN signalling transport over IP [9] uses two components: a signalling common transport protocol and an adaptation module to support the services expected by a particular SCN signalling protocol from its underlying protocol layer.
IP[9]の上のSCN合図輸送のために定義されたフレームワークアーキテクチャは2つのコンポーネントを使用します: 特定のSCN合図で予想されたサービスをサポートする合図の一般的なトランスポート・プロトコルと適合モジュールは基本的なプロトコル層より議定書を作ります。
Within this framework architecture, this document defines a SCN adaptation module that is suitable for the transport of SS7 MTP2 User messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services of the Stream Control Transmission Protocol [8] as the underlying reliable signalling common transport protocol.
このフレームワークアーキテクチャの中では、このドキュメントはSS7 MTP2 Userメッセージの輸送に適したSCN適合モジュールを定義します。 唯一のSS7 MTP2 UserがMTP3です。 M2UAは基本的な信頼できる合図一般的なトランスポート・プロトコルとしてStream Control Transmissionプロトコル[8]のサービスを利用します。
In a Signalling Gateway, it is expected that the SS7 MTP2-User signalling is transmitted and received from the PSTN over a standard SS7 network interface, using the SS7 Message Transfer Part Level 1 and Level 2 [2,3,4] to provide reliable transport of the MTP3-User signalling messages to and from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP). The SG then provides an interworking of transport functions with the IP transport, in order to transfer the MTP2-User signalling messages to and from an Application Server Process where the peer MTP2-User protocol layer exists.
Signallingゲートウェイでは、SS7 MTP2-ユーザ合図が標準のSS7ネットワーク・インターフェースの上のPSTNから送信されて、受け取られると予想されます、Signalling Transfer PointとSS7 Signalling End Point(9月)かSignalling Transfer Point(STP)からのメッセージに合図しながらMTP3-ユーザの信頼できる輸送を提供するのに、SS7 Message Transfer Part Level1とLevel2[2、3、4]を使用して。 次に、SGは輸送機能を織り込むのにIP輸送を提供します、Application Server Processと、そして、同輩MTP2-ユーザプロトコル層が存在するApplication Server Processからのメッセージに合図しながらMTP2-ユーザを移すために。
Morneault, et. al. Standards Track [Page 5] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[5ページ]。
1.3.1 Example - SG to MGC
1.3.1 例--MGCへのSG
In a Signalling Gateway, it is expected that the SS7 signalling is received over a standard SS7 network termination, using the SS7 Message Transfer Part (MTP) to provide transport of SS7 signalling messages to and from an SS7 Signalling End Point (SEP) or SS7 Signalling Transfer Point (STP). In other words, the SG acts as a Signalling Link Terminal (SLT) [2,3]. The SG then provides an interworking of transport functions with IP Signalling Transport, in order to transport the MTP3 signalling messages to the MGC where the peer MTP3 protocol layer exists, as shown below:
Signallingゲートウェイでは、SS7合図が標準のSS7ネットワーク終了の上に受け取られると予想されます、SS7 Signalling Transfer PointとSS7 Signalling End Point(9月)かSS7 Signalling Transfer Point(STP)からSS7合図メッセージの輸送を提供するのに、SS7 Message Transfer Part(MTP)を使用して。 言い換えれば、SGはSignalling Link Terminal(SLT)[2、3]として機能します。 次に、SGは輸送機能を織り込むのにIP Signalling Transportを提供します、同輩MTP3プロトコル層が存在するMGCにMTP3合図メッセージを輸送するために、以下に示すように:
****** SS7 ****** IP *******
*SEP *-----------* SG *-------------* MGC *
****** ****** *******
****** SS7******IP********9月*-----------* SG*-------------* MGC********************
+----+ +----+
|S7UP| |S7UP|
+----+ +----+
|MTP + |MTP |
| L3 | (NIF) |L3 |
+----+ +----+----+ +----+
|MTP | |MTP |M2UA| |M2UA|
| | | +----+ +----+
|L2 | |L2 |SCTP| |SCTP|
|L1 | |L1 +----+ +----+
| | | |IP | |IP |
+----+ +---------+ +----+
+----+ +----+ |S7UP| |S7UP| +----+ +----+ |MTP+|MTP| | L3| (NIF) |L3| +----+ +----+----+ +----+ |MTP| |MTP|M2UA| |M2UA| | | | +----+ +----+ |L2| |L2|SCTP| |SCTP| |L1| |L1+----+ +----+ | | | |IP| |IP| +----+ +---------+ +----+
NIF - Nodal Interworking Function
SEP - SS7 Signalling Endpoint
IP - Internet Protocol
SCTP - Stream Control Transmission Protocol (Reference [8])
NIF--9月--SS7合図終点IP(こぶのような織り込む機能インターネットプロトコルSCTP)は制御伝動プロトコルを流します。(参照[8])
Figure 1 M2UA in the SG to MGC Application
図1 MGCアプリケーションへのSGのM2UA
Note: STPs MAY be present in the SS7 path between the SEP and the SG.
以下に注意してください。 STPsは9月、SGの間のSS7経路に存在しているかもしれません。
It is recommended that the M2UA use the services of the Stream Control Transmission Protocol (SCTP) [8] as the underlying reliable common signalling transport protocol. The use of SCTP provides the following features:
M2UAが基本的な信頼できる一般的な合図トランスポート・プロトコルとしてStream Control Transmissionプロトコル(SCTP)[8]のサービスを利用するのは、お勧めです。 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,
- 明白なパケット指向の配送(ストリーム指向でない)--個々のユーザメッセージの到着の注文配送のためのオプションによる複数のストリームの中のユーザメッセージの配列された配送--SCTPデータグラムへのユーザメッセージの任意のマルチプレクシング
Morneault, et. al. Standards Track [Page 6] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[6ページ]。
- network-level fault tolerance through the 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
- そして、どちらかのマルチホーミングのサポートか協会の両端を通るネットワークレベル耐障害性--氾濫と仮面舞踏会への抵抗が攻撃される、--従うデータ分割が経路MTUサイズを発見した
There are scenarios without redundancy requirements and scenarios in which redundancy is supported below the transport layer. In these cases, the SCTP functions above MAY NOT be a requirement and TCP can be used as the underlying common transport protocol.
シナリオが冗長がトランスポート層の下でサポートされる冗長要件とシナリオなしであります。 これらのケース、上の機能がそうしないSCTPでは要件になってください、そして、基本的な一般的なトランスポート・プロトコルとしてTCPは使用できます。
1.3.2 ASP Fail-over Model and Terminology
1.3.2 ASPフェイルオーバーモデルと用語
The M2UA layer supports ASP fail-over functions in order to support a high availability of call and transaction processing capability. All MTP2-User messages incoming to a SGP from the SS7 network are assigned to the unique Application Server, based on the Interface Identifier of the message.
M2UA層は、呼び出しとトランザクション処理能力の高可用性をサポートするためにASPフェイルオーバーが機能であるとサポートします。 SS7ネットワークからのSGPへのすべてのMTP2-ユーザメッセージ入来がユニークなApplication Serverに割り当てられます、メッセージのInterface Identifierに基づいて。
The M2UA layer supports a n+k redundancy model (active-standby, load sharing, broadcast) where n 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. Note that 1+1 active/standby redundancy is a subset of this model. A simplex 1+0 model is also supported as a subset, with no ASP redundancy.
M2UA層はnがトラフィックを扱わなければならなかった余分なASPの最小の数であり、k ASPが失敗したか入手できないASPのために持って行くために入手できるところでn+k冗長モデルをサポートします(活発な予備(負荷分割法)は放送されました)。 1つの+1アクティブな/予備冗長がこのモデルの部分集合であることに注意してください。 また、シンプレクス1+0モデルは部分集合としてASP冗長なしでサポートされます。
1.3.3 Client/Server Model
1.3.3 クライアント/サーバモデル
It is recommended that the SGP and ASP be able to support both client and server operation. The peer endpoints using M2UA 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がクライアントとサーバ操作の両方をサポートすることができるのは、お勧めです。 ものがクライアントともう片方の役割でいつもSCTP協会を開始するのにサーバの役割を果たすように構成されていて、M2UA SHOULDを使用する同輩終点。 ASPはクライアントですが、デフォルトオリエンテーションはSGPがサーバの役割を引き受けるだろうことです。 この場合、ASP SHOULDはSCTP協会をSGPに開始します。
The SCTP and TCP Registered User Port Number Assignment for M2UA is 2904.
M2UAのためのSCTPとTCP Registered User Port Number Assignmentは2904です。
1.4 Services Provided by the M2UA Adaptation Layer
M2UA適合で提供された1.4のサービスが層にされます。
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination point in the IP network, so that the M2UA protocol layer is required to provide the equivalent set of services to its users as provided by the MTP Level 2 to MTP Level 3.
SS7 MTP3/MTP2(MTP2-ユーザ)インタフェースは終了ポイントでIPネットワークで保有されます、MTP Level2によってMTP Level3に供給されるようにM2UAプロトコル層がユーザに対する同等なサービスを提供しなければならないように。
Morneault, et. al. Standards Track [Page 7] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[7ページ]。
1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary
1.4.1 MTP Level2 / MTP Level3インタフェース境界のサポート
M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables a seamless, or as seamless as possible, operation of the MTP2-User peers in the SS7 and IP domains. An example of the primitives that need to be supported can be found in [10].
M2UAは、MTP Levelがaを可能にする2 / MTP Level3インタフェース境界であるとサポートします。シームレスである、またはできるだけシームレスであり、MTP2-ユーザの操作はSS7とIPドメインをじっと見ます。 [10]でサポートされる必要がある基関数に関する例を見つけることができます。
1.4.2 Support for communication between Layer Management modules on SG
and MGC
1.4.2 SGとMGCの上のLayer Managementモジュールのコミュニケーションのサポート
The M2UA layer needs to provide some messages that will facilitate communication between Layer Management modules on the SG and MGC. To facilitate reporting of errors that arise because of the backhauling MTP Level 3 scenario, the following primitive is defined:
M2UA層は、SGとMGCでLayer Managementモジュールのコミュニケーションを容易にするいくつかのメッセージを提供する必要があります。 backhauling MTP Level3シナリオで起こる誤りについて報告するのを容易にするために、以下の基関数は定義されます:
M-ERROR
M誤り
The M-ERROR message is used to indicate an error with a received M2UA message (e.g., an interface identifier value is not known to the SG).
M-ERRORメッセージは、受信されたM2UAメッセージで誤りを示すのに使用されます(例えばインタフェース識別子価値はSGにおいて知られていません)。
1.4.3 Support for management of active associations between SG and MGC
1.4.3 SGとMGCとの活動的な協会の経営のサポート
The M2UA layer on the SG keeps the state of the configured ASPs. A set of primitives between M2UA layer and the Layer Management are defined below to help the Layer Management manage the association(s) between the SG and the MGC. The M2UA layer can be instructed by the Layer Management to establish a SCTP association to a peer M2UA node. This procedure can be achieved using the M-SCTP ESTABLISH primitive.
SGの上のM2UA層は構成されたASPの状態を維持します。 M2UA層とLayer Managementの間の1セットの基関数は、Layer ManagementがSGとMGCとの協会を経営するのを助けるために以下で定義されます。 Layer Managementは、M2UA層が同輩M2UAノードにSCTP協会を設立するよう命令できます。 原始的にM-SCTP ESTABLISHを使用することでこの手順を達成できます。
M-SCTP_ESTABLISH
M、-、SCTP_は設立します。
The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm the establishment of a SCTP association to a peer M2UA node.
_ESTABLISH基関数が使用されているM-SCTPは同輩M2UAノードにSCTP協会の設立を要求して、示して、確認します。
M-SCTP_RELEASE
M SCTP_リリース
The M-SCTP_RELEASE primitives are used to request, indicate, and confirm the release of a SCTP association to a peer M2UA node.
_RELEASE基関数が使用されているM-SCTPは同輩M2UAノードにSCTP協会のリリースを要求して、示して、確認します。
The M2UA layer MAY also need to inform the status of the SCTP association(s) to the Layer Management. This can be achieved using the following primitive.
また、M2UA層は、SCTP協会の状態をLayer Managementに知らせる必要があるかもしれません。 原始的に以下を使用することでこれを達成できます。
M-SCTP_STATUS
M SCTP_状態
The M-SCTP_STATUS primitive is used to request and indicate the status of underlying SCTP association(s).
_STATUS基関数が使用されているM-SCTPは基本的なSCTP協会の状態を要求して、示します。
Morneault, et. al. Standards Track [Page 8] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[8ページ]。
The Layer Management MAY need to inform the M2UA layer of an AS/ASP status (i.e., failure, active, etc.), so that messages can be exchanged between M2UA layer peers to stop traffic to the local M2UA user. This can be achieved using the following primitive.
Layer Managementは、AS/ASP状態(すなわち、失敗、能動態など)のM2UA層を知らせる必要があるかもしれません、地元のM2UAユーザに通行を止めるためにM2UA層の同輩の間でメッセージを交換できるように。 原始的に以下を使用することでこれを達成できます。
M-ASP_STATUS
M ASP_状態
The ASP status is stored inside the M2UA layer on both the SG and MGC sides. The M-ASP_STATUS primitive can be used by Layer Management to request the status of the Application Server Process from the M2UA layer. This primitive can also be used to indicate the status of the Application Server Process.
ASP状態はSGとMGC側の両方にM2UA層の中に保存されます。 M ASP_STATUS原始的であるのは、使用されて、M2UAからApplication Server Processの状態を要求するLayer Managementが層にするということであるかもしれません。 また、Application Server Processの状態を示すのにこの基関数を使用できます。
M-ASP_MODIFY
_が変更するM ASP
The M-ASP_MODIFY primitive can be used by Layer Management to modify the status of the Application Server Process. In other words, the Layer Management on the ASP side uses this primitive to initiate the ASPM procedures.
M、-Layer Managementは、Application Server Processの状態を変更するのにASP_MODIFY基関数を使用できます。 言い換えれば、ASP側の上のLayer ManagementはASPM手順に着手するために原始的にこれを使用します。
M-AS_STATUS
M、-、_状態
The M-AS_STATUS primitive can be used by Layer Management to request the status of the Application Server. This primitive can also be used to indicate the status of the Application Server.
M AS_STATUS原始的であるのは、Application Serverの状態を要求するのにLayer Managementによって使用されて、また、Application Serverの状態を示すのに. この基関数を使用できるということであるかもしれません。
1.5 Functions Provided by the M2UA Layer
M2UAによって提供された1.5の機能が層にされます。
1.5.1 Mapping
1.5.1 マッピング
The M2UA layer MUST maintain a map of an Interface ID to a physical interface on the Signalling Gateway. A physical interface would be a V.35 line, T1 line/time slot, E1 line/time slot, etc. The M2UA layer MUST also maintain a map of the Interface Identifier to SCTP association and to the related stream within the association.
M2UA層はSignallingゲートウェイでInterface IDの地図を物理インターフェースに維持しなければなりません。 物理インターフェースはV.35系列、T1の系列/時間帯、1Eの系列/時間帯でしょうなど。 また、M2UA層は協会の中でSCTP協会と、そして、関連するストリームにInterface Identifierの地図を維持しなければなりません。
The SGP maps an Interface Identifier to an SCTP association/stream only when an ASP sends an ASP Active message for a particular Interface Identifier. It must be noted, however, that this mapping is dynamic and could change at any time due to a change of ASP state. This mapping could even temporarily be invalid, for example during fail-over of one ASP to another. Therefore, the SGP MUST maintain the states of AS/ASP and reference them during the routing of any messages to an AS/ASP.
ASPが特定のInterface IdentifierへのASP Activeメッセージを送るときだけ、SGPはSCTP協会/ストリームにInterface Identifierを写像します。 しかしながら、このマッピングがダイナミックであり、いつでもASP状態の変化のため変化できたことに注意しなければなりません。 このマッピングは例えば、別のものの1つのASPのフェイルオーバーの間、一時無効でさえあるかもしれません。 したがって、SGP MUSTはAS/ASPの州を維持して、AS/ASPへのどんなメッセージのルーティングの間も、彼らに参照をつけます。
Note that only one SGP SHOULD provide Signalling Link Terminal services to an SS7 link. Therefore, within an SG, an Application Server SHOULD be active for only one SGP at any given point in time.
1SGP SHOULDだけがSS7リンクに対するサービスをSignalling Link Terminalに供給することに注意してください。 したがって、SGの中でApplication Server SHOULD、いずれの1SGPだけにおいて、時間内にのポイントを考えて、アクティブであってください。
Morneault, et. al. Standards Track [Page 9] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[9ページ]。
An example of the logical view of the relationship between an SS7 link, Interface Identifier, AS and ASP in an SGP is shown below:
SGPのSS7リンクと、Interface Identifierと、ASとASPとの関係の論理的な視点に関する例は以下に示されます:
/-------------------------------------------------+
/ /----------------------------------------------|--+
/ / v |
/ / +----+ act+-----+ +-------+ -+--+|-+-
SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+-
/ +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+
SS7 link2-------->|IID |-+ | ASP |
+----+ +-----+
/-------------------------------------------------+ / /----------------------------------------------|--+ //v| / / +----+ 行為+-----+ +-------+ -+--+|-+ SS7 link1-------->|IID|-+ +-->| ASP| -->、| Assoc| v/+----+ | +----+ | +-----+ +-------+ -+--+--+- / +->| as|--+ ストリーム/+----+ | +----+ stb+-----+ SS7 link2-------->|IID|-+ | ASP| +----+ +-----+
where IID = Interface Identifier
IIDがインタフェースIdentifierと等しいところ
A SGP MAY support more than one AS. An AS MAY support more than one Interface Identifier.
SGP MAYサポート1以上AS。 AS MAYサポート1以上Interface Identifier。
1.5.2 Support for the management of SCTP associations between the SGPs
and ASPs
1.5.2 SGPsとASPとのSCTP協会の経営のサポート
The M2UA layer at the SG maintains the availability state of all configured ASPs, in order to manage the SCTP associations and the traffic between the SG and ASPs. As well, the active/inactive state of remote ASP(s) are also maintained. The Active ASP(s) are the one(s) currently receiving traffic from the SG.
SGのM2UA層はすべての構成されたASPの有用性状態を維持します、SGとASPの間のSCTP協会とトラフィックを経営するために。 また、井戸、リモートASPのアクティブであるか不活発な状態が維持されるように。 Active ASPは現在SGからトラフィックを受けるもの(s)です。
The M2UA layer MAY be instructed by local management to establish an SCTP association to a peer M2UA node. This can be achieved using the M-SCTP_ESTABLISH primitive to request, indicate and confirm the establishment of an SCTP association with a peer M2UA node.
M2UA層が同輩M2UAノードにSCTP協会を設立するよう現地管理職者によって命令されるかもしれません。 要求するためには原始のM SCTP_ESTABLISHを使用することでこれを達成できます、と同輩M2UAノードとのSCTP協会の設立は示して、確認します。
The M2UA layer MAY also need to inform local management of the status of the underlying SCTP associations using the M-SCTP_STATUS request and the indication primitive. For example, the M2UA MAY inform local management of the reason for the release of an SCTP association, determined either locally within the M2UA layer or by a primitive from the SCTP.
また、_STATUSが要求するM-SCTPと指示プリミティブを使用して、M2UA層は、基本的なSCTP協会の状態について現地管理職者に知らせる必要があるかもしれません。 例えば、M2UA MAYはM2UA層以内かSCTPからの基関数で局所的に決定するSCTP協会のリリースの理由について現地管理職者に知らせます。
Also the M2UA layer may need to 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.
また、M2UA層は、ASPかASの状態の変化について現地管理職者に知らせる必要があるかもしれません。 これがASP STATUSが要求するMを使用することで達成されるかもしれませんか、またはM AS_STATUSは基関数を要求します。
Morneault, et. al. Standards Track [Page 10] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[10ページ]。
1.5.3 Status of ASPs
1.5.3 ASPの状態
The M2UA layer on the SG MUST maintain the state of the ASPs it is supporting. The state of an ASP changes because of the reception of peer-to-peer messages (ASPM messages as described in Section 3.3.2) or the reception of indications from the local SCTP association. The ASP state transition procedures are described in Section 4.3.1.
SG MUSTの上のM2UA層はそれがサポートしているASPの状態を維持します。 ASPの状態はピアツーピアメッセージ(セクション3.3.2で説明されるASPMメッセージ)のレセプションか指摘のレセプションのために地方のSCTP協会から変化します。 ASP状態遷移手順はセクション4.3.1で説明されます。
At a SGP, an Application Server list MAY contain active and inactive ASPs to support ASP fail-over procedures. When, for example, both a primary and a backup ASP are available, the M2UA peer protocol is required to control which ASP is currently active. The ordered list of ASPs within a logical Application Server is kept updated in the SGP to reflect the active Application Server Process.
SGPでは、Application ServerリストはサポートASPフェイルオーバー手順にアクティブで不活発なASPを含むかもしれません。 例えば、予備選挙とバックアップASPの両方が利用可能であるときに、M2UA同輩プロトコルが、どのASPが現在活動的であるかを制御するのに必要です。 論理的なApplication Serverの中のASPの規則正しいリストはSGPでアップデートして、アクティブなApplication Server Processを反映してください続けられます。
Also the M2UA layer MAY need to inform the local management of the change in status of an ASP or AS. This can be achieved using the M- ASP_STATUS or M-AS_STATUS primitives.
また、M2UA層は、ASPかASの状態の変化について現地管理職者に知らせる必要があるかもしれません。 M ASP_STATUSかM AS_STATUS基関数を使用することでこれを達成できます。
1.5.4 SCTP Specifics
1.5.4 SCTP詳細
1.5.4.1 SCTP Stream Management
1.5.4.1 SCTPストリーム管理
SCTP allows a user specified number of streams to be opened during initialization of the association. It is the responsibility of the M2UA layer to ensure proper management of these streams. Because of the unidirectional nature of streams, a M2UA layer is not aware of the stream information from its peer M2UA layer. For this reason, the Interface Identifier is in the M2UA message header.
SCTPは協会の初期化の間、ユーザの指定された番号のストリームを開かせます。 これらのストリームの適切な管理を確実にするのは、M2UA層の責任です。ストリームの単方向の本質のために、M2UA層は同輩M2UA層からのストリーム情報を意識していません。 この理由で、Interface IdentifierがM2UAメッセージヘッダーにあります。
The use of SCTP streams within M2UA is recommended in order to minimize transmission and buffering delay, thereby, improving the overall performance and reliability of the signalling elements. A separate SCTP stream can be used for each SS7 link. Or, an implementation may choose to split the SS7 link across several streams based on SLS. This method may be of particular interest for high speed SS7 links (MTP3b) since high speed links have a 24-bit sequence number and the stream sequence number is 16-bits.
M2UAの中のSCTPストリームの使用は、合図要素のトランスミッション、その結果、総合的な性能を向上させながら遅れをバッファリングして、および信頼性を最小にするためにお勧めです。 それぞれのSS7リンクに別々のSCTPストリームを使用できます。 または、実装は、SLSに基づくいくつかの小川の向こう側にSS7リンクを分けるのを選ぶかもしれません。 高速リンクには24ビットの一連番号があって、ストリーム一連番号が16ビットであるので、このメソッドは高速SS7リンク(MTP3b)に関して特別におもしろいかもしれません。
SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) messages (see Section 3) since stream '0' SHOULD only be used for ASP Management (ASPM) messages (see Section 4.3.3).
SCTP Stream'0'SHOULD NOT、ストリーム'0'SHOULD以来のMTP2 User Adaptationに、中古(MAUP)のメッセージ(セクション3を見る)が唯一であったなら、ASP Management(ASPM)メッセージには、使用されてください(セクション4.3.3を見てください)。
Morneault, et. al. Standards Track [Page 11] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 11] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
1.5.5 Seamless SS7 Network Management Interworking
1.5.5 Seamless SS7 Network Management Interworking
The M2UA layer on the SGP SHOULD pass an indication of unavailability of the M2UA-User (MTP3) to the local Layer Management, if the currently active ASP moves from the ACTIVE state. The actions taken by M2UA on the SGP with regards to MTP Level 2 should be in accordance with the appropriate MTP specifications.
The M2UA layer on the SGP SHOULD pass an indication of unavailability of the M2UA-User (MTP3) to the local Layer Management, if the currently active ASP moves from the ACTIVE state. The actions taken by M2UA on the SGP with regards to MTP Level 2 should be in accordance with the appropriate MTP specifications.
1.5.6 Flow Control / Congestion
1.5.6 Flow Control / Congestion
It is possible for the M2UA layer to be informed of the IP network congestion onset and abatement by means of an implementation dependent function (i.e. an indication from the SCTP). The handling of this congestion indication by M2UA is implementation dependent. However, the actions taken by the SG should be in accordance with the appropriate MTP specification and should enable SS7 functionality (e.g. flow control) to be correctly maintained.
It is possible for the M2UA layer to be informed of the IP network congestion onset and abatement by means of an implementation dependent function (i.e. an indication from the SCTP). The handling of this congestion indication by M2UA is implementation dependent. However, the actions taken by the SG should be in accordance with the appropriate MTP specification and should enable SS7 functionality (e.g. flow control) to be correctly maintained.
1.5.7 Audit of SS7 Link State
1.5.7 Audit of SS7 Link State
After a fail-over of one ASP to another ASP, it may be necessary for the M2UA on the ASP to audit the current SS7 link state to ensure consistency. The M2UA on the SGP would respond to the audit request with information regarding the current state of the SS7 link (i.e. in-service, out-of-service, congestion state, LPO/RPO state).
After a fail-over of one ASP to another ASP, it may be necessary for the M2UA on the ASP to audit the current SS7 link state to ensure consistency. The M2UA on the SGP would respond to the audit request with information regarding the current state of the SS7 link (i.e. in-service, out-of-service, congestion state, LPO/RPO state).
1.6 Definition of the M2UA Boundaries
1.6 Definition of the M2UA Boundaries
1.6.1 Definition of the M2UA / MTP Level 3 boundary
1.6.1 Definition of the M2UA / MTP Level 3 boundary
DATA ESTABLISH RELEASE STATE DATA RETRIEVAL DATA RETRIEVAL COMPLETE
DATA ESTABLISH RELEASE STATE DATA RETRIEVAL DATA RETRIEVAL COMPLETE
1.6.2 Definition of the M2UA / MTP Level 2 boundary
1.6.2 Definition of the M2UA / MTP Level 2 boundary
DATA ESTABLISH RELEASE STATE DATA RETRIEVAL DATA RETRIEVAL COMPLETE
DATA ESTABLISH RELEASE STATE DATA RETRIEVAL DATA RETRIEVAL COMPLETE
Morneault, et. al. Standards Track [Page 12] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 12] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP
1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP
The upper layer and layer management primitives provided by SCTP are provided in Reference [8] Section 10.
The upper layer and layer management primitives provided by SCTP are provided in Reference [8] Section 10.
1.6.4 Definition of Layer Management / M2UA Boundary
1.6.4 Definition of Layer Management / M2UA Boundary
M-SCTP_ESTABLISH request
Direction: LM -> M2UA
Purpose: LM requests ASP to establish an SCTP association with an
SGP.
M-SCTP_ESTABLISH request Direction: LM -> M2UA Purpose: LM requests ASP to establish an SCTP association with an SGP.
M-SCTP_ESTABLISH confirm
Direction: M2UA -> LM
Purpose: ASP confirms to LM that it has established an
SCTP association with an SGP.
M-SCTP_ESTABLISH confirm Direction: M2UA -> LM Purpose: ASP confirms to LM that it has established an SCTP association with an SGP.
M-SCTP_ESTABLISH indication
Direction: M2UA -> LM
Purpose: SGP informs LM that an ASP has established an SCTP
association.
M-SCTP_ESTABLISH indication Direction: M2UA -> LM Purpose: SGP informs LM that an ASP has established an SCTP association.
M-SCTP_RELEASE request Direction: LM -> M2UA Purpose: LM requests ASP to release an SCTP association with SGP.
M-SCTP_RELEASE request Direction: LM -> M2UA Purpose: LM requests ASP to release an SCTP association with SGP.
M-SCTP_RELEASE confirm
Direction: M2UA -> LM
Purpose: ASP confirms to LM that it has released SCTP association
with SGP.
M-SCTP_RELEASE confirm Direction: M2UA -> LM Purpose: ASP confirms to LM that it has released SCTP association with SGP.
M-SCTP_RELEASE indication Direction: M2UA -> LM Purpose: SGP informs LM that ASP has released an SCTP association.
M-SCTP_RELEASE indication Direction: M2UA -> LM Purpose: SGP informs LM that ASP has released an SCTP association.
M-SCTP_RESTART indication
Direction: M2UA -> LM
Purpose: M2UA informs LM that a SCTP Restart indication has
been received.
M-SCTP_RESTART indication Direction: M2UA -> LM Purpose: M2UA informs LM that a SCTP Restart indication has been received.
M-SCTP_STATUS request Direction: LM -> M2UA Purpose: LM requests M2UA to report status of SCTP association.
M-SCTP_STATUS request Direction: LM -> M2UA Purpose: LM requests M2UA to report status of SCTP association.
M-SCTP_STATUS indication Direction: M2UA -> LM Purpose: M2UA reports status of SCTP association.
M-SCTP_STATUS indication Direction: M2UA -> LM Purpose: M2UA reports status of SCTP association.
Morneault, et. al. Standards Track [Page 13] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 13] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
M-ASP_STATUS request Direction: LM -> M2UA Purpose: LM requests SGP to report status of remote ASP.
M-ASP_STATUS request Direction: LM -> M2UA Purpose: LM requests SGP to report status of remote ASP.
M-ASP_STATUS indication Direction: M2UA -> LM Purpose: SGP reports status of remote ASP.
M-ASP_STATUS indication Direction: M2UA -> LM Purpose: SGP reports status of remote ASP.
M-AS_STATUS request Direction: LM -> M2UA Purpose: LM requests SG to report status of AS.
M-AS_STATUS request Direction: LM -> M2UA Purpose: LM requests SG to report status of AS.
M-AS_STATUS indication Direction: M2UA -> LM Purpose: SG reports status of AS.
M-AS_STATUS indication Direction: M2UA -> LM Purpose: SG reports status of AS.
M-NOTIFY indication
Direction: M2UA -> LM
Purpose: ASP reports that it has received a NOTIFY message
from its peer.
M-NOTIFY indication Direction: M2UA -> LM Purpose: ASP reports that it has received a NOTIFY message from its peer.
M-ERROR indication
Direction: M2UA -> LM
Purpose: ASP or SGP reports that it has received an ERROR
message from its peer.
M-ERROR indication Direction: M2UA -> LM Purpose: ASP or SGP reports that it has received an ERROR message from its peer.
M-ASP_UP request
Direction: LM -> M2UA
Purpose: LM requests ASP to start its operation and send an ASP UP
message to the SGP.
M-ASP_UP request Direction: LM -> M2UA Purpose: LM requests ASP to start its operation and send an ASP UP message to the SGP.
M-ASP_UP confirm
Direction: M2UA -> LM
Purpose: ASP reports that it has received an ASP UP Acknowledgment
message from the SGP.
M-ASP_UP confirm Direction: M2UA -> LM Purpose: ASP reports that it has received an ASP UP Acknowledgment message from the SGP.
M-ASP_DOWN request
Direction: LM -> M2UA
Purpose: LM requests ASP to stop its operation and send an ASP DOWN
message to the SGP.
M-ASP_DOWN request Direction: LM -> M2UA Purpose: LM requests ASP to stop its operation and send an ASP DOWN message to the SGP.
M-ASP_DOWN confirm
Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP DOWN Acknowledgment
message from the SGP.
M-ASP_DOWN confirm Direction: M2UA -> LM Purpose: ASP reports that is has received an ASP DOWN Acknowledgment message from the SGP.
Morneault, et. al. Standards Track [Page 14] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 14] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
M-ASP_ACTIVE request Direction: LM -> M2UA Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP.
M-ASP_ACTIVE request Direction: LM -> M2UA Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP.
M-ASP_ACTIVE confirm
Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP ACTIVE
Acknowledgment message from the SGP.
M-ASP_ACTIVE confirm Direction: M2UA -> LM Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgment message from the SGP.
M-ASP_INACTIVE request Direction: LM -> M2UA Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP.
M-ASP_INACTIVE request Direction: LM -> M2UA Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP.
M-ASP_INACTIVE confirm
Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP INACTIVE
Acknowledgment message from the SGP.
M-ASP_INACTIVE confirm Direction: M2UA -> LM Purpose: ASP reports that is has received an ASP INACTIVE Acknowledgment message from the SGP.
M-LINK_KEY_REG Request
Direction: LM -> M2UA
Purpose: LM requests ASP to register Link Key with SG by sending REG
REQ message.
M-LINK_KEY_REG Request Direction: LM -> M2UA Purpose: LM requests ASP to register Link Key with SG by sending REG REQ message.
M-LINK_KEY_REG Confirm
Direction: M2UA -> LM
Purpose: ASP reports to LM that it has successfully received a REG
RSP message from SG.
M-LINK_KEY_REG Confirm Direction: M2UA -> LM Purpose: ASP reports to LM that it has successfully received a REG RSP message from SG.
M-LINK_KEY_REG Indication
Direction: M2UA -> LM
Purpose: SG reports to LM that it has successfully processed an
incoming REG REQ message from ASP.
M-LINK_KEY_REG Indication Direction: M2UA -> LM Purpose: SG reports to LM that it has successfully processed an incoming REG REQ message from ASP.
M-LINK_KEY_DEREG Request
Direction: LM -> M2UA
Purpose: LM requests ASP to de-register Link Key with SG by sending
DEREG REQ message.
M-LINK_KEY_DEREG Request Direction: LM -> M2UA Purpose: LM requests ASP to de-register Link Key with SG by sending DEREG REQ message.
M-LINK_KEY_DEREG Confirm
Direction: M2UA -> LM
Purpose: ASP reports to LM that it has successfully received a
DEREG RSP message from SG.
M-LINK_KEY_DEREG Confirm Direction: M2UA -> LM Purpose: ASP reports to LM that it has successfully received a DEREG RSP message from SG.
M-LINK_KEY_DEREG Indication
Direction: M2UA -> LM
Purpose: SG reports to LM that it has successfully processed an
incoming DEREG REQ message from ASP.
M-LINK_KEY_DEREG Indication Direction: M2UA -> LM Purpose: SG reports to LM that it has successfully processed an incoming DEREG REQ message from ASP.
Morneault, et. al. Standards Track [Page 15] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 15] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
2.0 Conventions
2.0 Conventions
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 [RFC2119].
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 [RFC2119].
3.0 Protocol Elements
3.0 Protocol Elements
This section describes the format of various messages used in this protocol.
This section describes the format of various messages used in this protocol.
3.1 Common Message Header
3.1 Common Message Header
The protocol messages for MTP2-User Adaptation require a message structure that contains a version, message class, message type, message length, and message contents. This message header is common among all signalling protocol adaptation layers:
The protocol messages for MTP2-User Adaptation require a message structure that contains a version, message class, message type, message length, and message contents. This message header is common among all signalling protocol adaptation layers:
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 | Spare | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Spare | Message Class | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Common Message Header
Figure 2 Common Message Header
All fields in an M2UA message MUST be transmitted in the network byte order, unless otherwise stated.
All fields in an M2UA message MUST be transmitted in the network byte order, unless otherwise stated.
3.1.1 Version
3.1.1 Version
The version field contains the version of the M2UA adaptation layer. The supported versions are:
The version field contains the version of the M2UA adaptation layer. The supported versions are:
Value Version
----- -------
1 Release 1.0
Value Version ----- ------- 1 Release 1.0
3.1.2 Spare
3.1.2 Spare
The Spare field is 8-bits. It SHOULD be set to all '0's by the sender and ignored by the receiver.
The Spare field is 8-bits. It SHOULD be set to all '0's by the sender and ignored by the receiver.
Morneault, et. al. Standards Track [Page 16] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 16] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
3.1.3 Message Class
3.1.3 Message Class
The following List contains the valid Message Classes:
The following List contains the valid Message Classes:
Message Class: 8 bits (unsigned integer)
Message Class: 8 bits (unsigned integer)
0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
1 Transfer Messages [M3UA]
2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
5 Q.921/Q.931 Boundary Primitives Transport (QPTM)
Messages [IUA]
6 MTP2 User Adaptation (MAUP) Messages [M2UA]
7 Connectionless Messages [SUA]
8 Connection-Oriented Messages [SUA]
9 Routing Key Management (RKM) Messages (M3UA)
10 Interface Identifier Management (IIM) Messages (M2UA)
11 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensions
0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 1 Transfer Messages [M3UA] 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages [IUA] 6 MTP2 User Adaptation (MAUP) Messages [M2UA] 7 Connectionless Messages [SUA] 8 Connection-Oriented Messages [SUA] 9 Routing Key Management (RKM) Messages (M3UA) 10 Interface Identifier Management (IIM) Messages (M2UA) 11 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined Message Class extensions
3.1.4 Message Type
3.1.4 Message Type
The following List contains the Message Types for the valid Message Classes:
The following List contains the Message Types for the valid Message Classes:
MTP2 User Adaptation (MAUP) Messages
MTP2 User Adaptation (MAUP) Messages
0 Reserved
1 Data
2 Establish Request
3 Establish Confirm
4 Release Request
5 Release Confirm
6 Release Indication
7 State Request
8 State Confirm
9 State Indication
10 Data Retrieval Request
11 Data Retrieval Confirm
12 Data Retrieval Indication
13 Data Retrieval Complete Indication
14 Congestion Indication
15 Data Acknowledge
16 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MAUP extensions
0 Reserved 1 Data 2 Establish Request 3 Establish Confirm 4 Release Request 5 Release Confirm 6 Release Indication 7 State Request 8 State Confirm 9 State Indication 10 Data Retrieval Request 11 Data Retrieval Confirm 12 Data Retrieval Indication 13 Data Retrieval Complete Indication 14 Congestion Indication 15 Data Acknowledge 16 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined MAUP extensions
Morneault, et. al. Standards Track [Page 17] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 17] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Application Server Process State Maintenance (ASPSM) messages
Application Server Process State Maintenance (ASPSM) messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heartbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
0 Reserved 1 ASP Up (UP) 2 ASP Down (DOWN) 3 Heartbeat (BEAT) 4 ASP Up Ack (UP ACK) 5 ASP Down Ack (DOWN ACK) 6 Heartbeat Ack (BEAT ACK) 7 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined ASPSM extensions
Application Server Process Traffic Maintenance (ASPTM) messages
Application Server Process Traffic Maintenance (ASPTM) messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions
0 Reserved 1 ASP Active (ACTIVE) 2 ASP Inactive (INACTIVE) 3 ASP Active Ack (ACTIVE ACK) 4 ASP Inactive Ack (INACTIVE ACK) 5 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined ASPTM extensions
Management (MGMT) Messages
Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions
0 Error (ERR) 1 Notify (NTFY) 2 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined MGMT extensions
Interface Identifier Management (IIM) Messages
Interface Identifier Management (IIM) Messages
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 IIM extensions
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 IIM extensions
3.1.5 Message Length
3.1.5 Message Length
The Message Length defines the length of the message in octets, including the header. The Message Length MUST include parameter padding bytes, if any. The Message Length MUST NOT be longer than a MTP3 message [2,3,4,5] plus the length of the common and M2UA message headers.
The Message Length defines the length of the message in octets, including the header. The Message Length MUST include parameter padding bytes, if any. The Message Length MUST NOT be longer than a MTP3 message [2,3,4,5] plus the length of the common and M2UA message headers.
Morneault, et. al. Standards Track [Page 18] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 18] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
3.1.6 Variable-Length Parameter Format
3.1.6 Variable-Length Parameter Format
M2UA messages consist of a Common Header followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameters contained in a message are defined in a Tag-Length-Value format as shown below.
M2UA messages consist of a Common Header followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameters contained in a message are defined in a Tag-Length-Value format as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Tag | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory parameters MUST be placed before optional parameters in a message.
Mandatory parameters MUST be placed before optional parameters in a message.
Parameter Tag: 16 bits (unsigned integer)
Parameter Tag: 16 bits (unsigned integer)
The Type field is a 16 bit identifier of the type of parameter. It takes a value of 0 to 65534. The common parameters used by the adaptation layers are in the range of 0x00 to 0xff. The M2UA specific parameters have Tags in the range 0x300 to 0x3ff.
The Type field is a 16 bit identifier of the type of parameter. It takes a value of 0 to 65534. The common parameters used by the adaptation layers are in the range of 0x00 to 0xff. The M2UA specific parameters have Tags in the range 0x300 to 0x3ff.
Morneault, et. al. Standards Track [Page 19] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 19] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The common parameter tags (used by all User Adaptation layers) that M2UA uses are defined below:
The common parameter tags (used by all User Adaptation layers) that M2UA uses are defined below:
Parameter Value Parameter Name
--------------- --------------
0 (0x00) Reserved
1 (0x01) Interface Identifier (Integer)
2 (0x02) Unused
3 (0x03) Interface Identifier (Text)
4 (0x04) Info String
5 (0x05) Unused
6 (0x06) Unused
7 (0x07) Diagnostic Information
8 (0x08) Interface Identifier (Integer Range)
9 (0x09) Heartbeat Data
10 (0x0a) Unused
11 (0x0b) Traffic Mode Type
12 (0x0c) Error Code
13 (0x0d) Status Type/Information
14 (0x0e) Unused
15 (0x0f) Unused
16 (0x10) Unused
17 (0x11) ASP Identifier
18 (0x12) Unused
19 (0x13) Correlation Id
18-255 Reserved
Parameter Value Parameter Name --------------- -------------- 0 (0x00) Reserved 1 (0x01) Interface Identifier (Integer) 2 (0x02) Unused 3 (0x03) Interface Identifier (Text) 4 (0x04) Info String 5 (0x05) Unused 6 (0x06) Unused 7 (0x07) Diagnostic Information 8 (0x08) Interface Identifier (Integer Range) 9 (0x09) Heartbeat Data 10 (0x0a) Unused 11 (0x0b) Traffic Mode Type 12 (0x0c) Error Code 13 (0x0d) Status Type/Information 14 (0x0e) Unused 15 (0x0f) Unused 16 (0x10) Unused 17 (0x11) ASP Identifier 18 (0x12) Unused 19 (0x13) Correlation Id 18-255 Reserved
Morneault, et. al. Standards Track [Page 20] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 20] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The M2UA specific parameter Tags defined are as follows:
The M2UA specific parameter Tags defined are as follows:
Parameter Value Parameter Name
--------------- --------------
768 (0x0300) Protocol Data 1
769 (0x0301) Protocol Data 2 (TTC)
770 (0x0302) State Request
771 (0x0303) State Event
772 (0x0304) Congestion Status
773 (0x0305) Discard Status
774 (0x0306) Action
775 (0x0307) Sequence Number
776 (0x0308) Retrieval Result
777 (0x0309) Link Key
778 (0x030a) Local-LK-Identifier
779 (0x030b) Signalling Data Terminal (SDT) Identifier
780 (0x030c) Signalling Data Link (SDL) Identifier
781 (0x030d) Registration Result
782 (0x030e) Registration Status
783 (0x030f) De-Registration Result
784 (0x0310) De-Registration Status
Parameter Value Parameter Name --------------- -------------- 768 (0x0300) Protocol Data 1 769 (0x0301) Protocol Data 2 (TTC) 770 (0x0302) State Request 771 (0x0303) State Event 772 (0x0304) Congestion Status 773 (0x0305) Discard Status 774 (0x0306) Action 775 (0x0307) Sequence Number 776 (0x0308) Retrieval Result 777 (0x0309) Link Key 778 (0x030a) Local-LK-Identifier 779 (0x030b) Signalling Data Terminal (SDT) Identifier 780 (0x030c) Signalling Data Link (SDL) Identifier 781 (0x030d) Registration Result 782 (0x030e) Registration Status 783 (0x030f) De-Registration Result 784 (0x0310) De-Registration Status
Parameter Length: 16 bits (unsigned integer)
Parameter Length: 16 bits (unsigned integer)
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.
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.
Parameter Value: variable-length.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be transferred in the parameter.
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 MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
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 MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
Morneault, et. al. Standards Track [Page 21] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 21] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
3.2 M2UA Message Header
3.2 M2UA Message Header
In addition to the common message header, there will be a M2UA specific message header. The M2UA specific message header will immediately follow the common message header, but will only be used with MAUP messages.
In addition to the common message header, there will be a M2UA specific message header. The M2UA specific message header will immediately follow the common message header, but will only be used with MAUP messages.
This message header will contain the Interface Identifier. The Interface Identifier identifies the physical interface at the SG for which the signalling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP.
This message header will contain the Interface Identifier. The Interface Identifier identifies the physical interface at the SG for which the signalling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP.
The integer formatted Interface Identifier MUST be supported. The text formatted Interface Identifier MAY optionally be supported.
The integer formatted Interface Identifier MUST be supported. The text formatted Interface Identifier MAY optionally be supported.
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 (0x1) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (0x1) | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 M2UA Message Header (Integer-based Interface Identifier)
Figure 3 M2UA Message Header (Integer-based Interface Identifier)
The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8.
The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier (text) /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (0x3) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifier (text) / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 M2UA Message Header (Text-based Interface Identifier)
Figure 4 M2UA Message Header (Text-based Interface Identifier)
The Tag value for the Text-based Interface Identifier is 0x3. The encoding of the Identifier is ANSI X3.4-1986 [7]. The maximum string length of the text-based Interface Identifier is 255 octets. The tag length is equal to the string length of the Interface Identifier name plus four bytes for the Tag and Length fields.
The Tag value for the Text-based Interface Identifier is 0x3. The encoding of the Identifier is ANSI X3.4-1986 [7]. The maximum string length of the text-based Interface Identifier is 255 octets. The tag length is equal to the string length of the Interface Identifier name plus four bytes for the Tag and Length fields.
Morneault, et. al. Standards Track [Page 22] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 22] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
3.3 M2UA Messages
3.3 M2UA Messages
The following section defines the messages and parameter contents. The M2UA messages will use the common message header (Figure 2) and the M2UA message header (Figure 3 and Figure 4).
The following section defines the messages and parameter contents. The M2UA messages will use the common message header (Figure 2) and the M2UA message header (Figure 3 and Figure 4).
3.3.1 MTP2 User Adaptation Messages
3.3.1 MTP2 User Adaptation Messages
3.3.1.1 Data
3.3.1.1 Data
The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The Data message contains the following parameter:
The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The Data message contains the following parameter:
Protocol Data (mandatory)
Correlation Id (optional)
Protocol Data (mandatory) Correlation Id (optional)
The format for the Data Message parameters is as follows:
The format for the Data Message parameters 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 (0x300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x13) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Protocol Data / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x13) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in network byte order starting with the Signalling Information Octet (SIO). 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 M2UA. The purpose of the Correlation Id is to permit the newly active ASP to synchronize its processing of the traffic in each ordered stream with other ASPs in the broadcast group.
The Protocol Data field contains the MTP2-User application message in network byte order starting with the Signalling Information Octet (SIO). 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 M2UA. The purpose of the Correlation Id is to permit the newly active ASP to synchronize its processing of the traffic in each ordered stream with other ASPs in the broadcast group.
Morneault, et. al. Standards Track [Page 23] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 23] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for a Data Message with TTC PDU parameters is as follows:
The format for a Data Message with TTC PDU parameters 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 (0x301) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ TTC Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x13) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x301) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ TTC Protocol Data / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x13) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in network byte order starting with the Length Indicator (LI) octet. The Japanese TTC variant uses the spare bits of the LI octet for priority.
The Protocol Data field contains the MTP2-User application message in network byte order starting with the Length Indicator (LI) octet. The Japanese TTC variant uses the spare bits of the LI octet for priority.
The length of the Protocol Data and TTC Protocol Data MUST NOT exceed the length of a MTP2-User application message [2,3,5].
The length of the Protocol Data and TTC Protocol Data MUST NOT exceed the length of a MTP2-User application message [2,3,5].
3.3.1.2 Data Acknowledge Message
3.3.1.2 Data Acknowledge Message
The Data Acknowledge message contains the Correlation Id of the Data message that the sending M2UA is acknowledging as successfully processed to the peer M2UA.
The Data Acknowledge message contains the Correlation Id of the Data message that the sending M2UA is acknowledging as successfully processed to the peer M2UA.
The Data Acknowledge message contains the following parameter:
The Data Acknowledge message contains the following parameter:
Correlation Id Mandatory
Correlation Id Mandatory
The following format MUST be used for the Data Ack Message:
The following format MUST be used for the Data Ack 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 (0x13) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x13) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Correlation Id parameter of the Data message and the Data Ack message provide a mechanism, for those SG implementations capable of taking advantage of them, to obtain an acknowledgment that the MSU has been transferred to the M2UA peer before acknowledging the MSU to
The Correlation Id parameter of the Data message and the Data Ack message provide a mechanism, for those SG implementations capable of taking advantage of them, to obtain an acknowledgment that the MSU has been transferred to the M2UA peer before acknowledging the MSU to
Morneault, et. al. Standards Track [Page 24] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 24] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
the SS7 peer, removing the risk of losing messages due to association failure or SCTP congestion.
the SS7 peer, removing the risk of losing messages due to association failure or SCTP congestion.
The Data Ack message MUST be sent if a Correlation Id parameter is received from the peer. Otherwise, the Data Ack message MUST NOT be sent.
The Data Ack message MUST be sent if a Correlation Id parameter is received from the peer. Otherwise, the Data Ack message MUST NOT be sent.
If the Data Acknowledge is not sent for Correlation Id(s) or is sent with Invalid Correlation Id(s), the SS7 link will eventually fail due to lack of MTP Level 2 acknowledgments of the SS7 peer's MSUs.
If the Data Acknowledge is not sent for Correlation Id(s) or is sent with Invalid Correlation Id(s), the SS7 link will eventually fail due to lack of MTP Level 2 acknowledgments of the SS7 peer's MSUs.
3.3.1.3 Establish (Request, Confirmation)
3.3.1.3 Establish (Request, Confirmation)
The Establish Request message is used to establish the SS7 link or to indicate that the channel has been established. The MGC controls the state of the SS7 link. When the MGC desires the SS7 link to be in- service, it will send the Establish Request message. Note that the SGP MAY already have the SS7 link established at its layer. If so, upon receipt of an Establish Request, the SGP takes no action except to send an Establish Confirm.
Establish Requestメッセージは、SS7リンクを証明するか、またはチャンネルが確立されたのを示すのに使用されます。 MGCはSS7リンクの状態を制御します。 MGCが、SS7リンクがコネサービスであることを望んでいるとき、それはEstablish Requestメッセージを送るでしょう。 SGP MAYが層にSS7リンクを既に設立させることに注意してください。 そうだとすれば、Establish Requestを受け取り次第、Establish Confirmを送る以外に、SGPは行動を全く取りません。
When the MGC sends an M2UA Establish Request message, the MGC MAY start a timer. This timer would be stopped upon receipt of an M2UA Establish Confirm. If the timer expires, the MGC would resend the M2UA Establish Request message and restart the timer. In other words, the MGC MAY continue to request the establishment of the data link on a periodic basis until the desired state is achieved or some other action is taken (notify the Management Layer).
MGCがM2UA Establish Requestメッセージを送るとき、MGC MAYはタイマを始動します。 このタイマはM2UA Establish Confirmを受け取り次第止められるでしょう。 タイマが期限が切れるなら、MGCはM2UA Establish Requestメッセージを再送して、タイマを再開するでしょう。 言い換えれば、MGC MAYは、必要な状態を獲得するか、またはある他の行動を取るまで(Management Layerに通知してください)周期的ベースにおけるデータ・リンクの設立を要求し続けています。
The mode (Normal or Emergency) for bringing the SS7 link in service is defaulted to Normal. The State Request (described in Section 3.3.1.5 below) can be used to change the mode to Emergency.
使用中の状態でSS7リンクを持って来るのがあるので、モード(標準かEmergency)はNormalをデフォルトとしました。 モードをEmergencyに変えるのに、州Request(セクション3.3.1では、.5未満について説明する)を使用できます。
3.3.1.4 Release (Request, Indication, Confirmation)
3.3.1.4 リリース(要求、指示、確認)
This Release Request message is used to release the channel. The Release Confirm and Indication messages are used to indicate that the channel has been released.
このRelease Requestメッセージは、チャンネルを釈放するのに使用されます。 Release ConfirmとIndicationメッセージは、チャンネルが釈放されたのを示すのに使用されます。
3.3.1.5 State Request
3.3.1.5 州の要求
The State Request message can be sent from a MGC to cause an action on a particular SS7 link supported by the Signalling Gateway Process. The SGP sends a State Confirm to the MGC if the action has been successfully completed. The State Confirm reflects that state value received in the State Request message.
SignallingゲートウェイProcessによって支えられた特定のSS7リンクへの動作を引き起こすためにMGCから州Requestメッセージを送ることができます。 操作が首尾よく完了したなら、SGPは州ConfirmをMGCに送ります。 州Confirmはその州の対価領収を州Requestメッセージに反映します。
Morneault, et. al. Standards Track [Page 25] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[25ページ]。
The State Request message contains the following parameter:
州Requestメッセージは以下のパラメタを含んでいます:
State (mandatory)
状態(義務的)です。
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 (0x302) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×302)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table.
州のための有効値は以下のテーブルに示されます。
Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered
STATUS_EMER_SET 0x2 Request emergency alignment
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency)
STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit
and retransmit queues
STATUS_CONTINUE 0x5 Continue or Resume
STATUS_CLEAR_RTB 0x6 Clear the retransmit queue
STATUS_AUDIT 0x7 Audit state of link
STATUS_CONG_CLEAR 0x8 Congestion cleared
STATUS_CONG_ACCEPT 0x9 Congestion accept
STATUS_CONG_DISCARD 0xa Congestion discard
EMER_CLEAR0x3のRequestの通常の整列(キャンセル非常時)STATUS_FLUSH_BUFFERS0x4Flushか明確な状態で地方の地方のValue記述STATUS_LPO_SET0x0の回復している_STATUS_EMER SET0x2Request非常時整列STATUS Requestプロセッサ供給停止STATUS_LPO_CLEAR0x1Requestプロセッサ供給停止_を定義してください、受信してください; 伝わってください。そうすれば、再送キューのSTATUS_CONTINUE0x5ContinueかResume STATUS_CLEAR_RTB0x6Clear再送キューSTATUS_AUDIT0x7Auditは、CLEAR0x8CongestionがきれいにしたリンクSTATUS_CONG_では、STATUS_CONG_ACCEPT0×9CongestionがSTATUS_CONG_DISCARD 0xa Congestion破棄を受け入れると述べます。
3.3.1.6 State Confirm
3.3.1.6 州は確認します。
The State Confirm message will be sent by the SGP in response to a State Request from the MGC. The State Confirm reflects that state value received in the State Request message.
州ConfirmメッセージはMGCからの州Requestに対応してSGPによって送られるでしょう。 州Confirmはその州の対価領収を州Requestメッセージに反映します。
The State Confirm message contains the following parameter:
州Confirmメッセージは以下のパラメタを含んでいます:
State (mandatory)
状態(義務的)です。
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 (0x302) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×302)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et. al. Standards Track [Page 26] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[26ページ]。
The valid values for State are shown in the following table. The value of the State field SHOULD reflect the value received in the State Request message.
州のための有効値は以下のテーブルに示されます。 州分野SHOULDの値は州Requestメッセージに対価領収を反映します。
Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered
STATUS_EMER_SET 0x2 Request emergency alignment
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency)
STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit
and retransmit queues
STATUS_CONTINUE 0x5 Continue or Resume
STATUS_CLEAR_RTB 0x6 Clear the retransmit queue
STATUS_AUDIT 0x7 Audit state of link
STATUS_CONG_CLEAR 0x8 Congestion cleared
STATUS_CONG_ACCEPT 0x9 Congestion accept
STATUS_CONG_DISCARD 0xa Congestion discard
EMER_CLEAR0x3のRequestの通常の整列(キャンセル非常時)STATUS_FLUSH_BUFFERS0x4Flushか明確な状態で地方の地方のValue記述STATUS_LPO_SET0x0の回復している_STATUS_EMER SET0x2Request非常時整列STATUS Requestプロセッサ供給停止STATUS_LPO_CLEAR0x1Requestプロセッサ供給停止_を定義してください、受信してください; 伝わってください。そうすれば、再送キューのSTATUS_CONTINUE0x5ContinueかResume STATUS_CLEAR_RTB0x6Clear再送キューSTATUS_AUDIT0x7Auditは、CLEAR0x8CongestionがきれいにしたリンクSTATUS_CONG_では、STATUS_CONG_ACCEPT0×9CongestionがSTATUS_CONG_DISCARD 0xa Congestion破棄を受け入れると述べます。
3.3.1.7 State Indication
3.3.1.7 州の指示
The MTP2 State Indication message can be sent from a SGP to an ASP to indicate a condition on a SS7 link.
SS7リンクに関する状態を示すためにMTP2州IndicationメッセージをSGPからASPに送ることができます。
The State Indication message contains the following parameter:
州Indicationメッセージは以下のパラメタを含んでいます:
Event (mandatory)
出来事(義務的)です。
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 (0x303) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×303)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Event are shown in the following table.
Eventのための有効値は以下のテーブルに示されます。
Define Value Description
EVENT_RPO_ENTER 0x1 Remote entered processor outage
EVENT_RPO_EXIT 0x2 Remote exited processor outage
EVENT_LPO_ENTER 0x3 Link entered processor outage
EVENT_LPO_EXIT 0x4 Link exited processor outage
定義、Value記述EVENT_RPO_ENTER0x1RemoteがRPO_EXIT0x2Remoteが出たプロセッサ供給停止EVENT_に入った、プロセッサ供給停止、EVENT_LPO_ENTER0x3LinkがLPO_EXIT0x4Linkが出たプロセッサ供給停止EVENT_に入った、プロセッサ供給停止
Morneault, et. al. Standards Track [Page 27] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[27ページ]。
3.3.1.8 Congestion Indication
3.3.1.8 混雑指示
The Congestion Indication message can be sent from a Signalling Gateway Process to an ASP to indicate the congestion status and discard status of a SS7 link. When the MSU buffer fill increases above an Onset threshold or decreases below an Abatement threshold or crosses a Discard threshold in either direction, the SGP SHALL send a congestion indication message when it supports SS7 MTP2 variants that support multiple congestion levels.
SS7リンクについて混雑状態を示して、状態を捨てるためにSignallingゲートウェイProcessからASPにCongestion Indicationメッセージを送ることができます。 MSUバッファ中詰めがOnset敷居より上まで増加するか、Abatement敷居より下であるまで減少するか、またはDiscard敷居にどちらの方向とも交差するとき、それが複数の混雑レベルを支持するSS7 MTP2異形を支持すると、SGP SHALLは混雑指示メッセージを送ります。
The SGP SHALL send the message only when there is actually a change in either the discard level or the congestion level to report, meaning it is different from the previously sent message. In addition, the SGP SHALL use an implementation dependent algorithm to limit the frequency of congestion indication messages.
SGP SHALLはいつだけ、破棄における平らな変化が実際にあるか、そして、報告する混雑レベルをメッセージに送ります、それが以前に送られたメッセージと異なっていることを意味して。 さらに、SGP SHALLは、混雑指示メッセージの頻度を制限するのに実現に依存するアルゴリズムを使用します。
An implementation may optionally send Congestion Indication messages on a "high priority" stream in order to potentially reduce delay.
実現は、「高い優先度」の流れのときに潜在的に遅れを縮めるために任意にメッセージをCongestion Indicationに送るかもしれません。
The Congestion Indication message contains the following parameters:
Congestion Indicationメッセージは以下のパラメタを含んでいます:
Congestion Status (mandatory)
Discard Status (optional)
混雑状態(義務的な)は状態を捨てます。(任意)です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x304) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x305) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×304)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 混雑状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×305)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態を捨ててください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Congestion Status and Discard Status are shown in the following table.
Congestion StatusとDiscard Statusのための有効値は以下のテーブルに示されます。
Define Value Description
LEVEL_NONE 0x0 No congestion
LEVEL_1 0x1 Congestion Level 1
LEVEL_2 0x2 Congestion Level 2
LEVEL_3 0x3 Congestion Level 3
Value記述LEVEL_NONE0x0いいえ混雑LEVEL_1 0×1Congestion Level1LEVEL_2 0×2Congestion Level2LEVEL_3 0×3Congestion Level3を定義してください。
Morneault, et. al. Standards Track [Page 28] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[28ページ]。
For SS7 networks that do not support multiple levels of congestion, only the LEVEL_NONE and LEVEL_3 values will be used. For SS7 networks that support multiple levels of congestion, it is possible for all values to be used. Refer to [2], [3] and [12] for more details on the Congestion and Discard Status of SS7 signalling links.
複数のレベルの混雑を支持しないSS7ネットワークのために、LEVEL_NONEとLEVEL_3つの値だけが使用されるでしょう。 複数のレベルの混雑を支持するSS7ネットワークに、すべての値が使用されるのは、可能です。 SS7合図リンクのCongestionとDiscard Statusに関するその他の詳細のための[2]、[3]、および[12]を参照してください。
3.3.1.9 Retrieval Request
3.3.1.9 検索要求
The MTP2 Retrieval Request message is used during the MTP Level 3 changeover procedure to request the BSN, to retrieve PDUs from the transmit and retransmit queues or to flush PDUs from the retransmit queue. Examples of the use of Retrieval Request for SS7 Link Changeover are provided in Section 5.3.6.
MTP2 Retrieval RequestメッセージがPDUsを検索するのにBSNを要求するMTP Level3転換手順の間、使用される、伝えてください、そして、再送キューから待ち行列か豊富なPDUsに再送してください。 Retrieval RequestのSS7 Link Changeoverの使用に関する例をセクション5.3.6に提供します。
The Retrieval Request message contains the following parameters:
Retrieval Requestメッセージは以下のパラメタを含んでいます:
Action (mandatory)
Sequence Number (optional)
動作の(義務的)の一連番号(任意)です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x306) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x307) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×306)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 動作| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×307)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are shown in the following table.
Actionのための有効値は以下のテーブルに示されます。
Define Value Description
ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number
ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit
and retransmit queues
Value記述ACTION_RTRV_BSN0x1Retrieve後方の一連番号ACTION_RTRV_MSGS0x2Retrieve PDUsを定義する、待ち行列を伝えて、再送してください。
In the Retrieval Request message, the Sequence Number field SHOULD NOT be present if the Action field is ACTION_RTRV_BSN. The Sequence Number field contains the Forward Sequence Number (FSN) of the far end if the Action is ACTION_RTRV_MSGS.
Retrieval Requestメッセージでは、Sequence NumberはSHOULD NOTをさばきます。Action分野がACTION_RTRV_BSNであるなら、存在してください。 Sequence Number分野はActionがACTION_RTRV_MSGSであるなら遠端のForward Sequence Number(FSN)を含んでいます。
Morneault, et. al. Standards Track [Page 29] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[29ページ]。
3.3.1.10 Retrieval Confirm
3.3.1.10 検索は確認します。
The MTP2 Retrieval Confirm message is sent by the Signalling Gateway in response to a Retrieval Request message. Examples of the use of the Retrieval Confirm for SS7 Link Changeover are provided in Section 5.3.6.
MTP2 Retrieval ConfirmメッセージはRetrieval Requestメッセージに対応してSignallingゲートウェイによって送られます。 Retrieval ConfirmのSS7 Link Changeoverの使用に関する例をセクション5.3.6に提供します。
The Retrieval Confirm message contains the following parameters:
Retrieval Confirmメッセージは以下のパラメタを含んでいます:
Action (mandatory)
Result (mandatory)
Sequence Number (optional)
動作の(義務的)の結果(義務的)の一連番号(任意)です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x306) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x308) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x307) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×306)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 動作| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×308)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 結果| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×307)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are the same as in Retrieval Request.
Actionのための有効値はRetrieval Requestと同じです。
The values for Result are shown below:
Resultのための値は以下に示されます:
Define Value Description
RESULT_SUCCESS 0x0 Action successful
RESULT_FAILURE 0x1 Action failed
ActionのうまくいっているRESULT_FAILURE0x1Actionが失敗したValue記述RESULT_SUCCESS0x0を定義してください。
When the Signalling Gateway Process sends a Retrieval Confirm to a Retrieval Request, it echos the Action field. If the Action was ACTION_RTRV_BSN and the SGP successfully retrieved the BSN, the SGP will put the Backward Sequence Number (BSN) in the Sequence Number field and will indicate a success in the Result field. If the BSN could not be retrieved, the Sequence Number field will not be included and the Result field will indicate failure.
SignallingゲートウェイProcessがRetrieval ConfirmをRetrieval Requestに送るとき、それはこだまします。Action分野。 RTRV_BSNとSGPがActionがACTION_であったなら首尾よくBSNを検索して、SGPはBackward Sequence Number(BSN)をSequence Number分野に置いて、Result分野の成功を示すでしょう。 BSNを検索できないと、Sequence Number分野は含まれないでしょう、そして、Result分野は失敗を示すでしょう。
Morneault, et. al. Standards Track [Page 30] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[30ページ]。
For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of the Result field will indicate success or failure. A failure means that the buffers could not be retrieved. The Sequence Number field is not used with ACTION_RTRV_MSGS.
ACTION_RTRV_MSGSのActionとRetrieval Confirmに関しては、Result分野の値は成否を示すでしょう。 失敗は、バッファを検索できなかったことを意味します。 Sequence Number分野はACTION_RTRV_MSGSと共に使用されません。
3.3.1.11 Retrieval Indication
3.3.1.11 検索指示
The Retrieval Indication message is sent by the Signalling Gateway with a PDU from the transmit or retransmit queue. The Retrieval Indication message does not contain the Action or Sequence Number fields, just a MTP3 Protocol Data Unit (PDU) from the transmit or retransmit queue. Examples of the use of the Retrieval Indication for SS7 Link Changeover are provided in Section 5.3.6.
Retrieval IndicationメッセージがPDUがあるSignallingゲートウェイによって送られる、待ち行列を伝えるか、または再送してください。 Retrieval IndicationメッセージがActionかSequence Number分野、まさしくMTP3プロトコルData Unit(PDU)を含んでいない、待ち行列を伝えるか、または再送してください。 Retrieval IndicationのSS7 Link Changeoverの使用に関する例をセクション5.3.6に提供します。
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 (0x300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×300)| 長さ| プロトコル..データ
For TTC Data messages, the following parameter will be used to indicate a TTC PDU which starts at LI.
TTC Dataメッセージに関しては、以下のパラメタは、LIで始まるTTC PDUを示すのに使用されるでしょう。
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 (0x301) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ TTC Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×301)| 長さ| 議定書の中で述べる..データ
The M2UA implementation MAY consider the use of the bundling feature of SCTP for Retrieval Indication messages.
M2UA実現はSCTPのバンドリング機能のRetrieval Indicationメッセージの使用を考えるかもしれません。
3.3.1.12 Retrieval Complete Indication
3.3.1.12 検索の完全な指示
The MTP2 Retrieval Complete Indication message is exactly the same as the MTP2 Retrieval Indication message except that it also indicates that retrieval is complete. In addition, it MAY contain a PDU (which MUST be the last PDU) from the transmit or retransmit queue.
MTP2 Retrieval Complete Indicationメッセージはまさにまた、その検索を示すのを除いて、MTP2 Retrieval Indicationメッセージが完全であるのと同じです。 さらに、PDU(最後のPDUであるに違いない)を含むかもしれない、待ち行列を伝えるか、または再送してください。
Morneault, et. al. Standards Track [Page 31] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[31ページ]。
3.3.2 Application Server Process Maintenance (ASPM) Messages
3.3.2 アプリケーション・サーバー過程維持(ASPM)メッセージ
The ASPM messages will only use the common message header.
ASPMメッセージは一般的なメッセージヘッダーを使用するだけでしょう。
3.3.2.1 ASP Up (ASPUP)
3.3.2.1 ASP上(ASPUP)
The ASP Up (ASPUP) message is used to indicate to a remote M2UA peer that the Adaptation layer is ready to receive traffic or maintenance messages.
ASP Up(ASPUP)メッセージは、Adaptation層が交通か維持メッセージを受け取る準備ができているのをリモートM2UA同輩に示すのに使用されます。
The ASPUP message contains the following parameters
ASPUPメッセージは以下のパラメタを含んでいます。
ASP Identifier (optional)
Info String (optional)
ASPの識別子の(任意)のインフォメーションストリング(任意)です。
Note: The ASP Identifier MUST be used where the SGP cannot
identify the ASP by pre-configured address/port number
information (e.g., where an ASP is resident on a Host using
dynamic address/port number assignment).
以下に注意してください。 SGPがあらかじめ設定されたアドレス/ポートナンバー情報でASPを特定できない(例えば、どこで、ASPはHostでダイナミックなアドレス/ポートナンバー課題を使用することで居住していますか)ところでASP Identifierを使用しなければなりません。
The format for ASPUP Message parameters is as follows:
ASPUP 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 (0x11) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×11)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP識別子*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| インフォメーション..ストリング
The optional ASP Identifier parameter would contain 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.3.3.2).
任意のASP IdentifierパラメタはASを支持するASPの中で局所的に重要なユニークな値を含んでいるでしょう。 セクション3.3を見てください。SGPが必要なら、Notifyメッセージと共に使用されるためにASP Identifierを取っておくはずである、(.3 .2)。
The optional INFO String parameter can carry any meaningful UTF-8 [6] 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.
任意のINFO Stringパラメタはメッセージに伴うどんな重要なUTF-8[6]文字列も運ぶことができます。 INFO Stringパラメタの長さは0〜255の八重奏です。 手順は全く現在、使用のために特定されませんが、INFO Stringはデバッグ目的に使用されるかもしれません。
Morneault, et. al. Standards Track [Page 32] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[32ページ]。
3.3.2.2 ASP Up Ack
3.3.2.2 AckへのASP
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote M2UA peer.
ASP Up Ackメッセージは、リモートM2UA同輩から受け取られたASP Upメッセージを承認するのに使用されます。
The ASPUP Ack message contains the following parameters:
ASPUP Ackメッセージは以下のパラメタを含んでいます:
INFO String (optional)
インフォメーションストリング(任意)です。
The format for ASPUP Ack Message parameters is as follows:
ASPUP Ack 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 (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| インフォメーション..ストリング
The format and description of the optional Info String parameter is the same as for the ASP UP message (See Section 3.3.2.1).
セクション3.3を見てください。任意のInfo Stringパラメタの形式と記述がASP UPメッセージのように同じである、(.2 .1)。
3.3.2.3 ASP Down (ASPDN)
3.3.2.3 ASP下(ASPDN)
The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer that the adaptation layer is not ready to receive traffic or maintenance messages.
ASP Down(ASPDN)メッセージは、適合層が交通か維持メッセージを受け取る準備ができていないのをリモートM2UA同輩に示すのに使用されます。
The ASPDN message contains the following parameters
ASPDNメッセージは以下のパラメタを含んでいます。
INFO String (optional)
インフォメーションストリング(任意)です。
The format for the ASPDN message parameters is as follows:
ASPDNメッセージパラメタのための形式は以下の通りです:
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 (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| インフォメーション..ストリング
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
セクション3.3を見てください。任意のInfo Stringパラメタの形式と記述がASP Upメッセージのように同じである、(.2 .1)。
Morneault, et. al. Standards Track [Page 33] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[33ページ]。
3.3.2.4 ASP Down Ack
3.3.2.4 ASP下のAck
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M2UA peer.
ASP Down Ackメッセージは、リモートM2UA同輩から受け取られたASP Downメッセージを承認するのに使用されます。
The ASP Down Ack message contains the following parameters:
ASP Down Ackメッセージは以下のパラメタを含んでいます:
INFO String (optional)
インフォメーションストリング(任意)です。
The format for the ASPDN Ack message parameters is as follows:
ASPDN 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 (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| インフォメーション..ストリング
The format and description of the optional Info String parameter is the same as for the ASP UP message (See Section 3.3.2.1).
セクション3.3を見てください。任意のInfo Stringパラメタの形式と記述がASP UPメッセージのように同じである、(.2 .1)。
3.3.2.5 Heartbeat (BEAT)
3.3.2.5 鼓動(ビート)
The Heartbeat message is optionally used to ensure that the M2UA peers are still available to each other.
Heartbeatメッセージは、互いにおいて、M2UA同輩がまだ手があいているのを保証するのに任意に使用されます。
The BEAT message contains the following parameter:
BEATメッセージは以下のパラメタを含んでいます:
Heartbeat Data Optional
鼓動データ任意です。
The format for the BEAT message is as follows:
BEATメッセージのための形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0009| 長さ| 鼓動..データ
The sending node defines the Heartbeat Data field contents. It may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details.
送付ノードはHeartbeat Data分野コンテンツを定義します。 それはHeartbeat Sequence Number、そして/または、タイムスタンプ、または他の実現の特定の詳細を含むかもしれません。
Morneault, et. al. Standards Track [Page 34] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[34ページ]。
The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver echoes the content of the Heartbeat Data in a BEAT ACK message.
それが送付者への意味だけのものであって、Heartbeatメッセージの受信機はこの分野を処理しません。 受信機はBEAT ACKメッセージでHeartbeat Dataの内容を反映します。
3.3.2.6 Heartbeat Ack (BEAT ACK)
3.3.2.6 鼓動Ack(ビートACK)
The Heartbeat ACK message is sent in response to a BEAT message. A peer MUST send a BEAT ACK in response to a BEAT message. It includes all the parameters of the received Heartbeat message, without any change.
BEATメッセージに対応してHeartbeat ACKメッセージを送ります。 同輩はBEATメッセージに対応してBEAT ACKを送らなければなりません。 それは少しも変化なしで受信されたHeartbeatメッセージのすべてのパラメタを含んでいます。
The BEAT ACK message contains the following parameter:
BEAT ACKメッセージは以下のパラメタを含んでいます:
Heartbeat Data Optional
鼓動データ任意です。
The format for the BEAT ACK message is as follows:
BEAT 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 = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0009| 長さ| 鼓動..データ
The sending node defines the Heartbeat Data field contents. It may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details.
送付ノードはHeartbeat Data分野コンテンツを定義します。 それはHeartbeat Sequence Number、そして/または、タイムスタンプ、または他の実現の特定の詳細を含むかもしれません。
The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver echoes the content of the Heartbeat Data in a BEAT ACK message.
それが送付者への意味だけのものであって、Heartbeatメッセージの受信機はこの分野を処理しません。 受信機はBEAT ACKメッセージでHeartbeat Dataの内容を反映します。
3.3.2.7 ASP Active (ASPAC)
3.3.2.7 ASPアクティブです。(ASPAC)
The ASPAC message is sent by an ASP to indicate to an SGP that it is Active and ready to be used.
ASPACメッセージは、それがActiveであることをSGPに示すためにASPによって送られて、使用される準備ができています。
The ASPAC message contains the following parameters:
ASPACメッセージは以下のパラメタを含んでいます:
Traffic Mode Type (optional)
Interface Identifier (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (optional)
Traffic Mode Type (optional) Interface Identifier (optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (optional)
Morneault, et. al. Standards Track [Page 35] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 35] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ASPAC message using integer formatted Interface Identifiers is as follows:
The format for the ASPAC message using integer formatted Interface Identifiers 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 (0xb) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x8=integer range) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StartN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StopN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x1 or 0x8 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et. al. Standards Track [Page 36] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 36] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ASPAC message using text formatted (string) Interface Identifiers is as follows:
The format for the ASPAC message using text formatted (string) Interface Identifiers 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3=string) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifier* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x3 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table:
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table:
Value Description
0x1 Override
0x2 Load-share
0x3 Broadcast
Value Description 0x1 Override 0x2 Load-share 0x3 Broadcast
Within a particular AS, only one Traffic Mode Type can be used. The Override value indicates that the ASP is operating in Override mode, where the ASP takes over all traffic in an Application Server (i.e., primary/backup operation), over-riding any currently active ASPs in the AS. In Load-share mode, the ASP will share in the traffic distribution with any other currently active ASPs. In Broadcast mode, all of the Active ASPs receive all message traffic in the Application Server.
Within a particular AS, only one Traffic Mode Type can be used. The Override value indicates that the ASP is operating in Override mode, where the ASP takes over all traffic in an Application Server (i.e., primary/backup operation), over-riding any currently active ASPs in the AS. In Load-share mode, the ASP will share in the traffic distribution with any other currently active ASPs. In Broadcast mode, all of the Active ASPs receive all message traffic in the Application Server.
Morneault, et. al. Standards Track [Page 37] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 37] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The optional Interface Identifiers parameter contains a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3)indexing the Application Server traffic that the sending ASP is configured/registered to receive. If integer formatted Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers (Type 0x8). Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. Text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types.
The optional Interface Identifiers parameter contains a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3)indexing the Application Server traffic that the sending ASP is configured/registered to receive. If integer formatted Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers (Type 0x8). Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. Text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types.
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned. If only a subset of Interface Identifiers for an AS are included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned. If only a subset of Interface Identifiers for an AS are included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
Note: If the optional Interface Identifier parameter is present, the
integer formatted Interface Identifier MUST be supported, while
the text formatted Interface Identifier MAY be supported.
Note: If the optional Interface Identifier parameter is present, the integer formatted Interface Identifier MUST be supported, while the text formatted Interface Identifier MAY be supported.
An SGP that receives an ASPAC with an incorrect or unsupported Traffic Mode Type for a particular Interface Identifier will respond with an Error Message (Cause: Unsupported Traffic Handling Mode).
An SGP that receives an ASPAC with an incorrect or unsupported Traffic Mode Type for a particular Interface Identifier will respond with an Error Message (Cause: Unsupported Traffic Handling Mode).
The format and description of the optional Info String parameter is the same as for the ASP UP message (See Section 3.3.2.1).
The format and description of the optional Info String parameter is the same as for the ASP UP message (See Section 3.3.2.1).
3.3.2.8 ASP Active Ack
3.3.2.8 ASP Active Ack
The ASP Active (ASPAC) Ack message is used to acknowledge an ASP Active message received from a remote M2UA peer.
The ASP Active (ASPAC) Ack message is used to acknowledge an ASP Active message received from a remote M2UA peer.
The ASPAC Ack message contains the following parameters:
The ASPAC Ack message contains the following parameters:
Traffic Mode Type (optional)
Interface Identifier (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (optional)
Traffic Mode Type (optional) Interface Identifier (optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (optional)
Morneault, et. al. Standards Track [Page 38] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 38] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ASPAC Ack message with Integer-formatted Interface Identifiers is as follows:
The format for the ASPAC Ack message with Integer-formatted Interface Identifiers 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 (0xb) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x8=integer range) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StartN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StopN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x1 or 0x8 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et. al. Standards Track [Page 39] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 39] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ASP Active Ack message using text formatted (string) Interface Identifiers is as follows:
The format for the ASP Active Ack message using text formatted (string) Interface Identifiers 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xb) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3=string) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifier* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x3 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
The format of the optional Interface Identifier parameter is the same as for the ASP Active message (See Section 3.3.2.7).
The format of the optional Interface Identifier parameter is the same as for the ASP Active message (See Section 3.3.2.7).
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
3.3.2.9 ASP Inactive (ASPIA)
3.3.2.9 ASP Inactive (ASPIA)
The ASP Inactive (ASPIA) message is sent by an ASP to indicate to an SGP that it is no longer an active ASP to be used from within a list of ASPs. The SGP will respond with an ASPIA Ack message and either discard incoming messages or buffer for a timed period and then discard.
The ASP Inactive (ASPIA) message is sent by an ASP to indicate to an SGP that it is no longer an active ASP to be used from within a list of ASPs. The SGP will respond with an ASPIA Ack message and either discard incoming messages or buffer for a timed period and then discard.
Morneault, et. al. Standards Track [Page 40] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 40] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The ASPIA message contains the following parameters:
The ASPIA message contains the following parameters:
Interface Identifiers (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (optional)
Interface Identifiers (optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (optional)
The format for the ASP Inactive message parameters using Integer formatted Interface Identifiers is as follows:
The format for the ASP Inactive message parameters using Integer formatted Interface Identifiers 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 (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x8=integer range) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StartN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StopN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x1 or 0x8 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et. al. Standards Track [Page 41] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 41] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ASP Inactive message using text formatted (string) Interface Identifiers is as follows:
The format for the ASP Inactive message using text formatted (string) Interface Identifiers 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 (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3=string) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifier* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x3 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the optional Interface Identifier parameter is the same as for the ASP Active message (See Section 3.3.2.7).
The format of the optional Interface Identifier parameter is the same as for the ASP Active message (See Section 3.3.2.7).
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
The optional Interface Identifiers parameter contains a list of Interface Identifier integers indexing the Application Server traffic that the sending ASP is configured/registered to receive, but does not want to receive at this time.
The optional Interface Identifiers parameter contains a list of Interface Identifier integers indexing the Application Server traffic that the sending ASP is configured/registered to receive, but does not want to receive at this time.
3.3.2.10 ASP Inactive Ack
3.3.2.10 ASP Inactive Ack
The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP Inactive message received from a remote M2UA peer.
The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP Inactive message received from a remote M2UA peer.
The ASPIA Ack message contains the following parameters:
The ASPIA Ack message contains the following parameters:
Interface Identifiers (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (optional)
Interface Identifiers (optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (optional)
Morneault, et. al. Standards Track [Page 42] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 42] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ASPIA Ack message is as follows:
The format for the ASPIA Ack 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 (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifiers* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x8=integer range) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StartN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StopN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x1 or 0x8 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et. al. Standards Track [Page 43] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 43] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ASP Inactive Ack message using text formatted (string) Interface Identifiers is as follows:
The format for the ASP Inactive Ack message using text formatted (string) Interface Identifiers 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 (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3=string) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifier* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Additional Interface Identifiers / / of Tag Type 0x3 \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the optional Interface Identifier parameter is the same as for the ASP Active message (See Section 3.3.2.7).
The format of the optional Interface Identifier parameter is the same as for the ASP Active message (See Section 3.3.2.7).
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
3.3.3 Layer Management (MGMT) Messages
3.3.3 Layer Management (MGMT) Messages
3.3.3.1 Error (ERR)
3.3.3.1 Error (ERR)
The Error (ERR) 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 (ERR) 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.
An Error message MUST not be generated in response to other Error messages.
An Error message MUST not be generated in response to other Error messages.
The ERR message contains the following parameters:
The ERR message contains the following parameters:
Error Code (mandatory)
Interface Identifier (optional)
Diagnostic Information (optional)
Error Code (mandatory) Interface Identifier (optional) Diagnostic Information (optional)
Morneault, et. al. Standards Track [Page 44] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
Morneault, et. al. Standards Track [Page 44] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
The format for the ERR message is as follows:
ERRメッセージのための形式は以下の通りです:
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 (0xc) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1, 0x3, or 0x8) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier(s)* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x7) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Diagnostic Information* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xc)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×1、0×3、または0×8)| 長さ| インタフェース..識別子| タグ(0×7)| 長さ| 診断..情報
The Error Code parameter indicates the reason for the Error Message. The Error parameter value can be one of the following values:
Error CodeパラメタはError Messageの理由を示します。 Errorパラメタ価値は以下の値の1つであるかもしれません:
Invalid Version 0x1
Invalid Interface Identifier 0x2
Unsupported Message Class 0x3
Unsupported Message Type 0x4
Unsupported Traffic Handling Mode 0x5
Unexpected Message 0x6
Protocol Error 0x7
Unsupported Interface Identifier Type 0x8
Invalid Stream Identifier 0x9
Not Used in M2UA 0xa
Not Used in M2UA 0xb
Not Used in M2UA 0xc
Refused - Management Blocking 0xd
ASP Identifier Required 0xe
Invalid ASP Identifier 0xf
ASP Active for Interface Identifier(s) 0x10
Invalid Parameter Value 0x11
Parameter Field Error 0x12
Unexpected Parameter 0x13
Not Used in M2UA 0x14
Not Used in M2UA 0x15
Missing Parameter 0x16
M2UA 0xbで使用されないM2UA 0xaで使用されないサポートされないサポートされない無効のバージョン0x1の無効のインタフェース識別子0x2のサポートされないメッセージのクラス0x3のタイプ0×4サポートされないトラフィック取り扱いメッセージモード0x5の予期していなかったメッセージ0x6プロトコル誤り0x7の識別子タイプ0×8無効のストリームインタフェース識別子0x9; 経営者側がM2UA0x15のなくなったパラメタ0x16で使用されないM2UA0x14で使用されないインタフェース識別子0x10の無効のパラメタ価値0x11のパラメタ分野誤り0x12の予期していなかったパラメタ0x13に、活動的な必要な0xdの0xe無効のASP識別子0xf ASP識別子ASPを妨げて、拒否されたM2UA 0xcでは、使用されません。
Morneault, et. al. Standards Track [Page 45] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[45ページ]。
The "Invalid Version" error would be sent if a message was received with an invalid or unsupported version. The Error message would contain the supported version in the Common header. The Error message could optionally provide the supported version in the Diagnostic Information area.
無効の、または、サポートされないバージョンでメッセージを受け取るなら、「無効のバージョン」誤りを送るでしょうに。 ErrorメッセージはCommonヘッダーにサポートしているバージョンを含んでいるでしょう。 Errorメッセージは任意にDiagnostic情報領域にサポートしているバージョンを提供するかもしれません。
The "Invalid Interface Identifier" error would be sent by a SGP if an ASP sends a message (i.e. an ASP Active message) with an invalid (not configured) Interface Identifier value. One of the optional Interface Identifier parameters (Integer-based, text-based or integer range) MUST be used with this error code to identify the invalid Interface Identifier(s) received.
ASPが無効(構成されない)のインタフェースIdentifier価値があるメッセージ(すなわち、ASP Activeメッセージ)を送るなら、「無効のインタフェース識別子」誤りはSGPによって送られるでしょう。 任意のInterface Identifierパラメタの1つ、(整数ベースである、テキストベースか整数範囲) Interface Identifier(s)が受けた病人を特定するのにこのエラーコードと共に使用しなければなりません。
The "Unsupported Traffic Handling Mode" error would be sent by a SGP if an ASP sends an ASP Active with an unsupported Traffic Handling Mode. An example would be a case in which the SGP did not support load-sharing. One of the optional Interface Identifier parameters (Integer-based, text-based or integer range) MAY be used with this error code to identify the Interface Identifier(s).
ASPがサポートされないTraffic Handling ModeのASP Activeを送るなら、「サポートされないトラフィック取り扱いモード」誤りはSGPによって送られるでしょう。 例はSGPが負荷分割法をサポートしなかった場合でしょう。 任意のInterface Identifierパラメタの1つ、(整数ベースである、テキストベースか整数範囲) Interface Identifier(s)を特定するのにこのエラーコードと共に使用されるかもしれません。
The "Unexpected Message" error would be sent by an ASP if it received a MAUP message from an SGP while it was in the Inactive state.
それがInactive状態にあった間、SGPからMAUPメッセージを受け取るなら、「予期していなかったメッセージ」誤りはASPによって送られるでしょうに。
The "Protocol Error" error would be sent for any protocol anomaly (i.e. a bogus message).
どんなプロトコル例外(すなわち、にせのメッセージ)によっても「プロトコル誤り」誤りを送るでしょう。
The "Invalid Stream Identifier" error would be sent if a message was received on an unexpected SCTP stream (i.e. a MGMT message was received on a stream other than "0").
予期していなかったSCTPストリームにメッセージを受け取るなら「無効のストリーム識別子」誤りを送る、(ストリームにすなわち、MGMTメッセージを受け取った、「0インチ)」
The "Unsupported Interface Identifier Type" error would be sent by a SGP if an ASP sends a Text formatted Interface Identifier and the SGP only supports Integer formatted Interface Identifiers. When the ASP receives this error, it will need to resend its message with an Integer formatted Interface Identifier.
ASPがフォーマットされたInterface IdentifierをTextに送って、サポートだけをSGPに送るなら誤りがSGPによって送られる「サポートされないインタフェース識別子タイプ」IntegerはInterface Identifiersをフォーマットしました。 ASPがこの誤りを受けるとき、それは、IntegerがフォーマットされているメッセージにInterface Identifierを再送する必要があるでしょう。
The "Unsupported Message Class" error would be sent if a message with an unexpected or unsupported Message Class is received.
予期していなかったかサポートされないMessage Classがあるメッセージが受信されているなら、「サポートされないメッセージのクラス」誤りを送るでしょう。
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 lock-out").
「ASP UpかASP Activeメッセージが受信されているとき、「拒否されました--管理ブロッキング」という誤りを送って、管理理由で要求を拒否する、(例えば、管理ロックアウト、」、)
The "ASP Identifier Required" is sent by a SGP in response to an ASPUP message which does not contain an ASP Identifier parameter when the SGP requires one. The ASP SHOULD resend the ASPUP message with an ASP Identifier.
「必要であるASP識別子」はSGPが1を必要とするときASP Identifierパラメタを含まないASPUPメッセージに対応してSGPによって送られます。 ASP SHOULDはASP IdentifierがあるASPUPメッセージを再送します。
Morneault, et. al. Standards Track [Page 46] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[46ページ]。
The "Invalid ASP Identifier" is sent by a SGP in response to an ASPUP message with an invalid (i.e. non-unique) ASP Identifier.
「無効のASP識別子」は無効(すなわち、非ユニークな)のASP IdentifierがあるASPUPメッセージに対応してSGPによって送られます。
The "ASP Currently Active for Interface Identifier(s)" error is sent by a SGP when a Deregistration request is received from an ASP that is active for Interface Identifier(s) specified in the Deregistration request. One of the optional Interface Identifier parameters (Integer-based, text-based or integer range) MAY be used with this error code to identify the Interface Identifier(s).
Deregistration要求で指定されたInterface Identifier(s)に、活動的なASPからDeregistration要求を受け取るとき、SGPは「インタフェース識別子に、現在活動的なASP」誤りを送ります。 任意のInterface Identifierパラメタの1つ、(整数ベースである、テキストベースか整数範囲) Interface Identifier(s)を特定するのにこのエラーコードと共に使用されるかもしれません。
The "Invalid Parameter Value " error is sent if a message is received with an invalid parameter value (e.g., a State Request with an an undefined State).
無効のパラメタ値でメッセージを受け取るなら「無効のParameter Value」誤りを送る、(例えば、州Request、未定義の州)
The "Parameter Field Error" would be sent if a message with a parameter has a wrong length field.
パラメタがあるメッセージに間違った長さの分野があるなら、「パラメタ分野誤り」を送るでしょう。
The "Unexpected Parameter" error would be sent if a message contains an invalid parameter.
メッセージが無効のパラメタを含んでいるなら、「予期していなかったパラメタ」誤りを送るでしょう。
The "Missing Parameter" error would be sent if a mandatory parameter was not included in a message.
メッセージに義務的なパラメタを含んでいないなら、「なくなったパラメタ」誤りを送るでしょうに。
The optional Diagnostic information can be any information germane to the error condition, to assist in the identification of the error condition. In the case of an Invalid Version Error Code the Diagnostic information includes the supported Version parameter. In the other cases, the Diagnostic information SHOULD be the first 40 bytes of the offending message.
任意のDiagnostic情報は、エラー条件の識別を助けるためにはエラー条件に適切などんな情報であるかもしれません。 InvalidバージョンError Codeの場合では、Diagnostic情報はサポートしているバージョンパラメタを含んでいます。 他のケース、Diagnostic情報SHOULD、腹立たしいメッセージの最初の40バイトになってください。
3.3.3.2 Notify (NTFY)
3.3.3.2 通知してください。(NTFY)
The Notify message is used to provide an autonomous indication of M2UA events to an M2UA peer.
Notifyメッセージは、M2UAイベントの自動しるしをM2UA同輩に供給するのに使用されます。
The NTFY message contains the following parameters:
NTFYメッセージは以下のパラメタを含んでいます:
Status Type (mandatory)
Status Information (mandatory)
ASP Identifier (optional)
Interface Identifiers (optional)
INFO String (optional)
(義務的)の状態の(義務的)のASP識別子(任意)のインタフェースタイプ状態情報識別子(任意の)インフォメーションストリング(任意)です。
The format for the Notify message with Integer-formatted Interface Identifiers is as follows:
IntegerによってフォーマットされたInterface IdentifiersがあるNotifyメッセージのための形式は以下の通りです:
Morneault, et. al. Standards Track [Page 47] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[47ページ]。
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 (0xd) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xd)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態タイプ| 状態情報| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×11)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP識別子*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×1=整数)にタグ付けをしてください。| 長さ| インタフェース..識別子| (0×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| 追加..インタフェース..識別子..タグ..タイプ..0×1..0×8| タグ(0×4)| 長さ| インフォメーション..ストリング
Morneault, et. al. Standards Track [Page 48] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[48ページ]。
The format for the Notify message with Text-formatted Interface Identifiers is as follows:
TextによってフォーマットされたInterface Identifiersがある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 (0xd) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xd)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態タイプ| 状態情報| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×11)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP識別子*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×3=ストリング)にタグ付けをしてください。| 長さ| インタフェース..識別子..追加..インタフェース..識別子..タグ..タイプ..0×3| タグ(0×4)| 長さ| インフォメーション..ストリング
The Status Type parameter identifies the type of the Notify message. The following are the valid Status Type values:
Status TypeパラメタはNotifyメッセージのタイプを特定します。 ↓これは有効なStatus Type値です:
Value Description
0x1 Application Server state change (AS_State_Change)
0x2 Other
値の記述0x1Application Server州の変化(_AS_州Change)0×2Other
Morneault, et. al. Standards Track [Page 49] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[49ページ]。
The Status Information parameter contains more detailed information for the notification, based on the value of the Status Type. If the Status Type is AS_State_Change the following Status Information values are used:
Status情報パラメタはStatus Typeの値に基づいて通知のための、より詳細な情報を含んでいます。 Status TypeがAS_州_Changeであるなら、以下のStatus情報値は使用されています:
Value Description
1 reserved
2 Application Server Inactive (AS_Inactive)
3 Application Server Active (AS_Active)
4 Application Server Pending (AS_Pending)
値の記述1は2Application Server Inactive(AS_Inactive)3Application Server Active(AS_Active)4Application Server Pendingを予約しました。(未定の_としての)
These notifications are sent from an SGP to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the Application Server. The Interface Identifiers of the AS MAY be placed in the message if desired.
特定のApplication Serverの状態の変化でこれらの通知をSGPからASPに送ります。値は置かれたコネがメッセージであったなら望まれているなら. AS MAYのApplication Server Interface Identifiersの新しい州を反映します。
If the Status Type is Other, then the following Status Information values are defined:
Status TypeがOtherであるなら、以下のStatus情報値は定義されます:
Value Description
1 Insufficient ASP resources active in AS
2 Alternate ASP Active
3 ASP Failure
AS2Alternate ASP Active3ASP Failureでアクティブな値の記述1Insufficient ASPリソース
In the Insufficient ASP Resources case, the SGP is indicating to an ASP-INACTIVE ASP(s) in the AS that another ASP is required in order to handle the load of the AS (Load-sharing mode). For the Alternate ASP Active case, the formerly Active 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.
Insufficient ASP Resources場合では、SGPは、ASで別のASPがAS(負荷分割法モード)の荷重を扱うのに必要であることをASP-INACTIVE ASPに示しています。 Alternate ASP Activeケースのために以前Active ASP、代替のASPがいつOverrideモードでASP Active状態に移行するかを知らされます。 Alternate ASPのASP Identifier(利用可能であるなら)をメッセージに置かなければなりません。 ASP Failureケースのために、SGPは、ASでASPの1つがASP-DOWNに移行したのをASPに示しています。 失敗したASPのASP Identifier(利用可能であるなら)をメッセージに置かなければなりません。
For each of the Status Information values in Status Type Other, the Interface Identifiers of the affected AS MAY be placed in the message if desired.
情報がStatus Type Other、Interface Identifiersで評価するそれぞれの影響を受けるAS MAYのStatusに関しては、望まれているなら、メッセージに置かれてください。
The format of the optional Interface Identifier parameter is the same as for the ASP Active message (See Section 3.3.2.7).
セクション3.3を見てください。任意のInterface Identifierパラメタの形式がASP Activeメッセージのように同じである、(.2 .7)。
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
セクション3.3を見てください。任意のInfo Stringパラメタの形式と記述がASP Upメッセージのように同じである、(.2 .1)。
Morneault, et. al. Standards Track [Page 50] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[50ページ]。
3.3.4 Interface Identifier Management (IIM) Messages
3.3.4 インタフェース識別子管理(IIM)メッセージ
The Interface Identifier Management messages are optional. They are used to support the automatic allocation of Signalling Terminals or Signalling Data Links [2][3].
Interface Identifier Managementメッセージは任意です。 それらは、Signalling TerminalsかSignalling Dataリンクス[2][3]の自動配分をサポートするのに使用されます。
3.3.4.1 Registration Request (REG REQ)
3.3.4.1 登録要求(レッジREQ)
The REG REQ message is sent by an ASP to indicate to a remote M2UA peer that it wishes to register one or more given Link Keys with the remote peer. Typically, an ASP would send this message to an SGP, and expect to receive a REG RSP in return with an associated Interface Identifier value.
REG REQメッセージは、ASPが1つを登録したがっているのをリモートM2UA同輩に示すために送るか、またはリモート同輩がいるLinkキーズをもう少し与えます。 ASPは、通常、このメッセージをSGPに送って、代わりに関連Interface Identifier値でREG RSPを受け取ると予想するでしょう。
The REG REQ message contains the following parameter:
REG REQメッセージは以下のパラメタを含んでいます:
Link Key (mandatory)
リンクキー(義務的)です。
The format for the REG REQ message is as follows
REG REQメッセージのための形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0309 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Link Key 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0309 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Link Key n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0309| 長さ| リンク..主要 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0309| 長さ| リンク
Link Key: fixed length
キーをリンクしてください: 固定長
The Link Key parameter is mandatory. The sender of this message
expects that the receiver of this message will create a Link Key
entry and assign a unique Interface Identifier value to it, if the
Link Key entry does not yet exist.
Link Keyパラメタは義務的です。 このメッセージの送付者は、このメッセージの受信機がLink Keyエントリーを作成して、ユニークなInterface Identifier値をそれに割り当てると予想します、Link Keyエントリーがまだ存在していないなら。
Morneault, et. al. Standards Track [Page 51] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[51ページ]。
The Link Key parameter may be present multiple times in the same
message. This is used to allow the registration of multiple Link
Keys in a single message.
Link Keyパラメタは同じメッセージのプレゼント複数の回であるかもしれません。 これは、ただ一つのメッセージにおける、複数のLinkキーズの登録を許すのに使用されます。
The format of the Link Key parameter is as follows:
Link Keyパラメタの形式は以下の通りです:
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-LK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signalling Data Terminal Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signalling Data Link 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのLK識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 合図データ端末識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 合図データ・リンク識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-LK-Identifier: 32-bit integer
ローカルのLK識別子: 32ビットの整数
The mandatory Local-LK-Identifier field is used to uniquely
(between ASP and SGP) identify the registration request. The
Identifier value is assigned by the ASP, and is used to correlate
the response in a REG RSP message with the original registration
request. The Identifier value MUST remain unique until the REG
RSP is received.
義務的なLocal-LK-識別子分野は、唯一登録要求を特定すること(ASPとSGPの間で)に使用されます。 Identifier値は、ASPによって割り当てられて、REG RSPメッセージにおけるオリジナルの登録要求による応答を関連させるのに使用されます。 REG RSPが受け取られているまで、Identifier値はユニークなままでなければなりません。
The format of the Local-LK-Identifier field is as follows:
Local-LK-識別子分野の形式は以下の通りです:
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 = 0x030a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-LK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030a| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのLK識別子値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et. al. Standards Track [Page 52] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[52ページ]。
Signalling Data Terminal Identifier
合図データ端末識別子
The Signalling Data Terminal Identifier parameter is mandatory.
It identifies the Signalling Data Terminal associated with the SS7
link for which the ASP is registering. The format is as follows:
Signalling Data Terminal Identifierパラメタは義務的です。 それはASPが登録しているSS7リンクに関連しているSignalling Data Terminalを特定します。 形式は以下の通りです:
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 = 0x030b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SDT 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030b| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| SDT識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SDT Identifier is a 32-bit unsigned value which may only be
significant to 12 or 14 bits depending on the SS7 variant which is
supported by the MTP Level 3 at the ASP. Insignificant SDT
Identifier bits are coded 0.
SDT Identifierは12ビットかASPのMTP Level3によってサポートされるSS7異形に依存する14ビットにしか重要でないかもしれない未署名の32ビットの値です。 わずかなSDT Identifierビットは0にコード化されます。
Signalling Data Link Identifier
合図データ・リンク識別子
The Signalling Data Link Identifier parameter is mandatory. It
identifies the Signalling Data Link Identifier associated with the
SS7 link for which the ASP is registering. The format is as
follows:
Signalling Data Link Identifierパラメタは義務的です。 それはASPが登録しているSS7リンクに関連しているSignalling Data Link 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 = 0x030c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SDL 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030c| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| SDL識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SDL Identifier is a 32-bit unsigned value which may only be
significant to 12 or 14 bits depending on the SS7 variant which
is supported by the MTP Level 3 at the ASP. Insignificant SDLI
bits are coded 0.
SDL Identifierは12ビットかASPのMTP Level3によってサポートされるSS7異形に依存する14ビットにしか重要でないかもしれない未署名の32ビットの値です。 わずかなSDLIビットは0にコード化されます。
3.3.4.2 Registration Response (REG RSP)
3.3.4.2 登録応答(レッジRSP)
The REG RSP message is used as a response to the REG REQ message from a remote M2UA peer. It contains indications of success/failure for registration requests and returns a unique Interface Identifier value for successful registration requests, to be used in subsequent M2UA Traffic Management protocol.
REG RSPメッセージはリモートM2UA同輩からのREG REQメッセージへの応答として使用されます。 それは、登録要求のために成功/失敗のしるしを含んでいて、その後のM2UA Traffic Managementプロトコルに使用されるためにうまくいっている登録要求のためのユニークなInterface Identifier値を返します。
Morneault, et. al. Standards Track [Page 53] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[53ページ]。
The REG RSP message contains the following parameter:
REG RSPメッセージは以下のパラメタを含んでいます:
Registration Results (mandatory)
登録結果(義務的)です。
The format for the REG RSP message is as follows:
REG RSPメッセージのための形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x030d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Registration Result 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x030d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Registration Result n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030d| 長さ| 登録..結果 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030d| 長さ| 登録
Registration Results: fixed length
登録は結果として生じます: 固定長
The Registration Results parameter contains one or more results,
each containing the registration status for a single Link Key in
the REG REQ message. The number of results in a single REG RSP
message MAY match the number of Link Key parameters found in the
corresponding REG REQ message. The format of each result is as
follows:
Registration Resultsパラメタは1つ以上の結果を含んでいます、REG REQメッセージにそれぞれ独身のLink Keyのための登録状態を含んでいて。 ただ一つのREG RSPメッセージの結果の数は対応するREG REQメッセージで見つけられたLink Keyパラメタの数に合うかもしれません。 それぞれの結果の形式は以下の通りです:
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-LK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのLK識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 登録状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et. al. Standards Track [Page 54] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[54ページ]。
Local-LK-Identifier: 32-bit integer
ローカルのLK識別子: 32ビットの整数
The Local-LK-Identifier contains the same value as found in the
matching Link Key parameter found in the REG REQ message. The
format of the Local-LK-Identifier is shown in Section 3.3.4.1.
Local-LK-識別子はREG REQメッセージで見つけられた合っているLink Keyパラメタで見つけられるのと同じ値を含んでいます。 Local-LK-識別子の書式はセクション3.3.4で.1に示されます。
Registration Status: 32-bit integer
登録状態: 32ビットの整数
The Registration Result Status field indicates the success or the
reason for failure of a registration request.
Registration Result Status分野は登録要求の失敗の成功か理由を示します。
Its values may be one of the following:
値は以下の1つであるかもしれません:
0 Successfully Registered
1 Error - Unknown
2 Error - Invalid SDLI
3 Error - Invalid SDTI
4 Error - Invalid Link Key
5 Error - Permission Denied
6 Error - Overlapping (Non-unique) Link Key
7 Error - Link Key not Provisioned
8 Error - Insufficient Resources
0 1つの首尾よく登録された誤り--未知の2誤り--無効のSDLI3誤り--無効のSDTI4誤り--(非ユニーク)のリンク主要な7誤り--リンクの主要な食糧を供給されなかった8誤り--不十分なリソースを重ね合わせる無効のリンク主要な5誤り(6誤りが否定された許可)
The format of the Registration Status field is as follows:
Registration Status分野の形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x030e | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030e| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 登録状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface Identifier: 32-bit integer
識別子を連結してください: 32ビットの整数
The Interface Identifier field contains the Interface Identifier
for the associated Link Key if the registration is successful. It
is set to "0" if the registration was not successful. The format
of integer-based and text-based Interface Identifier parameters
are shown in Section 3.2.
登録がうまくいくなら、Interface Identifier分野は関連Link KeyのためのInterface Identifierを含んでいます。 それは「0インチは登録であるならうまくいかなかったこと」に設定されません。 パラメタがセクション3.2に示される整数ベースの、そして、テキストベースのInterface Identifierの形式。
3.3.4.3 De-Registration Request (DEREG REQ)
3.3.4.3 反-登録要求(DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote M2UA peer that it wishes to de-register a given Interface Identifier. Typically, an ASP would send this message to an SGP, and expects to receive a DEREG RSP in return reflecting the Interface Identifier and containing a de-registration status.
DEREG REQメッセージは、反-与えられたInterface Identifierを登録したがっているのをリモートM2UA同輩に示すためにASPによって送られます。 ASPは、通常、このメッセージをSGPに送って、Interface Identifierを反映して、反-登録状態を含んでいて、代わりにDEREG RSPを受け取ると予想します。
Morneault, et. al. Standards Track [Page 55] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[55ページ]。
The DEREG REQ message contains the following parameter:
DEREG REQメッセージは以下のパラメタを含んでいます:
Interface Identifier (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 = 0x1 or 0x3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifier 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x1 or 0x3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifier n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0×1か0x3| 長さ| インタフェース..識別子 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0×1か0x3| 長さ| インタフェース
Interface Identifier
インタフェース識別子
The Interface Identifier parameter contains a Interface Identifier
indexing the Application Server traffic that the sending ASP is
currently registered to receive from the SGP but now wishes to
de-register. The format of integer-based and text-based Interface
Identifier parameters are shown in Section 3.2.
Interface Identifierパラメタは、送付ASPが現在SGPから受けるために登録されるApplication Server交通に索引をつけるInterface Identifierを含んでいますが、現在、反-登録したがっています。 パラメタがセクション3.2に示される整数ベースの、そして、テキストベースのInterface Identifierの形式。
3.3.4.4 De-Registration Response (DEREG RSP)
3.3.4.4 反-登録応答(DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message from a remote M2UA peer.
DEREG RSPメッセージはリモートM2UA同輩からのDEREG REQメッセージへの応答として使用されます。
The DEREG RSP message contains the following parameter:
DEREG RSPメッセージは以下のパラメタを含んでいます:
De-Registration Results (mandatory)
反-登録結果(義務的)です。
Morneault, et. al. Standards Track [Page 56] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[56ページ]。
The format for the DEREG RSP message is as follows:
DEREG RSPメッセージのための形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x030f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ De-Registration Result 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x030f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ De-Registration Result n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030f| 長さ| 登録..結果 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x030f| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / De-Registration Result n / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
De-Registration Results: fixed length
反-登録は結果として生じます: 固定長
The De-Registration Results parameter contains one or more
results, each containing the de-registration status for a single
Interface Identifier in the DEREG REQ message. The number of
results in a single DEREG RSP message MAY match the number of
Interface Identifier parameters found in the corresponding DEREG
REQ message. The format of each result is as follows:
De-登録Resultsパラメタは1つ以上の結果を含んでいます、DEREG REQメッセージにそれぞれ独身のInterface Identifierのための反-登録状態を含んでいて。 ただ一つのDEREG RSPメッセージの結果の数は対応するDEREG REQメッセージで見つけられたInterface 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 反-登録状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface Identifier: 32-bit integer
識別子を連結してください: 32ビットの整数
The Interface Identifier field contains the Interface Identifier
value of the matching Link Key to de-register, as found in the
DEREG REQ. The format of integer-based and text-based Interface
Identifier parameters are shown in Section 3.2.
Interface Identifier分野は反-示す合っているLink KeyのInterface Identifier値を含んでいます、DEREG REQで見つけられるように。 パラメタがセクション3.2に示される整数ベースの、そして、テキストベースのInterface Identifierの形式。
Morneault, et. al. Standards Track [Page 57] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[57ページ]。
De-Registration Status: 32-bit integer
反-登録状態: 32ビットの整数
The De-Registration Result Status field indicates the success or
the reason for failure of the de-registration.
De-登録Result Status分野は反-登録の失敗の成功か理由を示します。
Its values may be one of the following:
値は以下の1つであるかもしれません:
0 Successfully De-registered
1 Error - Unknown
2 Error - Invalid Interface Identifier
3 Error - Permission Denied
4 Error - Not Registered
0 1つの首尾よく反-登録された誤り--未知の2誤り--無効のインタフェース識別子3誤り(4誤りが否定された許可)は示されませんでした。
The format of the De-Registration Status field is as follows:
De-登録Status分野の形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0310 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0310| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 反-登録状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.0 Procedures
4.0の手順
The M2UA layer needs to respond to various primitives it receives from other layers as well as messages it receives from the peer-to- peer messages. This section describes various procedures involved in response to these events.
M2UA層は、それがそれが同輩から同輩へのメッセージから受け取るメッセージと同様に他の層から受け取る様々な基関数に応じる必要があります。 このセクションはこれらの出来事に対応してかかわる様々な手順について説明します。
4.1 Procedures to Support the M2UA-User Layer
M2UA-ユーザ層を支える4.1の手順
These procedures achieve the M2UA layer "Transport of MTP Level 2 / MTP Level 3 boundary" service.
これらの手順はM2UA層「MTP Level2 / MTP Level3境界の輸送」サービスを実現します。
4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures
4.1.1 MTPは2 / MTPレベル3 境界手順を平らにします。
On receiving a primitive from the local upper layer, the M2UA layer will send the corresponding MAUP message (see Section 3) to its peer. The M2UA layer MUST fill in various fields of the common and specific headers correctly. In addition the message SHOULD be sent on the SCTP stream that corresponds to the SS7 link.
地方の上側の層から基関数を受け取ると、M2UA層は対応するMAUPメッセージ(セクション3を見る)を同輩に送るでしょう。 M2UA層は正しく一般的で特定のヘッダーの多岐に記入しなければなりません。 SHOULDを通信させてください。さらに、SS7リンクに対応するSCTPの流れに送ります。
4.1.2 MAUP Message Procedures
4.1.2 MAUPメッセージ手順
On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an SG or MGC needs to invoke the corresponding layer primitives to the local MTP Level 2 or MTP Level 3 layer.
同輩M2UA層からMAUPメッセージを受け取ると、SGかMGCの上のM2UA層は、地方のMTP Level2かMTP Level3層へ対応する層の基関数を呼び出す必要があります。
Morneault, et. al. Standards Track [Page 58] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[58ページ]。
4.2 Receipt of Primitives from the Layer Management
4.2 層の管理からの基関数の領収書
On receiving primitives from the local Layer Management, the M2UA layer will take the requested action and provide an appropriate response primitive to Layer Management.
地方のLayer Managementから基関数を受け取ると、M2UA層は、要求された行動を取って、Layer Managementへの原始の適切な応答を提供するでしょう。
An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP will initiate the establishment of an SCTP association. The M2UA layer will attempt to establish an SCTP association with the remote M2UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP layer.
M SCTP_ESTABLISHは、ASPのLayer Managementからの基関数がSCTP協会の設立を開始するよう要求します。 M2UA層は、地方のSCTP層への原始のSCTP-ASSOCIATEを送ることによってリモートM2UA同輩とのSCTP仲間を設立するのを試みるでしょう。
When an SCTP association has been successfully established, the SCTP will send an SCTP-COMMUNICATION_UP notification primitive to the local M2UA layer. At the SGP that initiated the request, the M2UA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer Management when the association setup is complete. At the peer M2UA layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer Management upon successful completion of an incoming SCTP association setup.
SCTP協会が首尾よく設立されたとき、SCTPは地方のM2UA層への原始のSCTP-COMMUNICATION_UP通知を送るでしょう。 協会セットアップが完全であるときに、要求を開始したSGPでは、M2UA層は_Layer ManagementへのESTABLISH確認プリミティブをM-SCTPに送るでしょう。 同輩M2UA層、指示プリミティブが送られるM SCTP_ESTABLISHでは、入って来るSCTP協会の無事終了でのLayer Managementにセットアップしてください。
An M-SCTP_RELEASE request primitive from Layer Management initiates the shutdown of an SCTP association. The M2UA layer accomplishes a graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN primitive to the SCTP layer.
M SCTP_RELEASEは、Layer Managementからの基関数がSCTP協会の閉鎖を開始するよう要求します。 M2UA層は、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 M2UA layer. At the M2UA Layer that initiated the request, the M2UA layer will send an M- SCTP_RELEASE confirm primitive to Layer Management when the association shutdown is complete. At the peer M2UA Layer, an M- SCTP_RELEASE indication primitive is sent to Layer Management upon abort or successful shutdown of an SCTP association.
SCTP協会の優雅な閉鎖が実行されたとき、SCTP層は地方のM2UA層への原始のSCTP-SHUTDOWN_COMPLETE通知を返します。 協会閉鎖が完全であるときに、要求を開始したM2UA Layerでは、M2UA層はM SCTP_RELEASE確認プリミティブをLayer Managementに送るでしょう。 同輩M2UA Layerでは、SCTP協会のアボートかうまくいっている閉鎖のときにM SCTP_RELEASE指示プリミティブをLayer Managementに送ります。
An M-SCTP_STATUS request primitive supports a Layer Management query of the local status of a particular SCTP association. The M2UA layer simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS primitive to the SCTP layer. When the SCTP responds, the M2UA layer maps the association status information to an M-SCTP_STATUS confirm primitive. No peer protocol is invoked.
M SCTP_STATUSはLayer Managementが質問する特定のSCTP協会のローカルの状態の原始のサポートを要求します。 M2UAは単にSCTP層への原始のSCTP-STATUSに原始的にM SCTP_STATUSが要求する地図を層にします。 SCTPが応じるとき、M2UAは原始的にM SCTP_STATUSへの協会状態情報が確認する地図を層にします。 同輩プロトコルは全く呼び出されません。
Similar LM-to-M2UA-to-SCTP and/or SCTP-to-M2UA-to-LM primitive mappings can be described for the various other SCTP Upper Layer primitives in RFC 2960 [8] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS CHANGE. Alternatively, these SCTP Upper Layer
RFC2960[8]のINITIALIZEなどの他の様々なSCTP Upper Layer基関数のためにSCTPへのM2UAへの同様のLM、そして/または、LMへのM2UAへのSCTPの原始のマッピングについて説明できます、SET PRIMARY、CHANGE HEARTBEAT、REQUEST HEARTBEAT、GET SRTT REPORT、SET FAILURE THRESHOLD、SET PROTOCOL PARAMETERS、DESTROY SCTP INSTANCE、SEND FAILURE、AND NETWORK STATUS CHANGE。 あるいはまた、これらのSCTP Upper Layer
Morneault, et. al. Standards Track [Page 59] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[59ページ]。
primitives (and Status as well) can be considered for modeling purposes as a Layer Management interaction directly with the SCTP Layer.
モデル目的のために、基関数(そして、また、Status)を直接SCTP LayerとのLayer Management相互作用と考えることができます。
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M2UA Notify or Error message respectively. These indications can also be generated based on local M2UA events.
M-NOTIFY指示とM-ERROR指示プリミティブは容認されたM2UA NotifyかErrorメッセージにそれぞれ含まれた通知かエラー情報をLayer Managementに示します。 また、これらの指摘は地方のM2UA出来事に基づいて発生できます。
An M-ASP_STATUS request primitive supports a Layer Management query of the status of a particular local or remote ASP. The M2UA layer responds with the status in an M-ASP_STATUS confirm primitive. No M2UA peer protocol is invoked.
M ASP_STATUSはLayer Managementが質問する特定の地方の、または、リモートなASPの状態の原始のサポートを要求します。 M2UA層は原始的に中に状態がいる_STATUSが確認するM ASPを反応させます。 M2UA同輩プロトコルは全く呼び出されません。
An M-AS_STATUS request supports a Layer Management query of the status of a particular AS. The M2UA responds with an M-AS_STATUS confirm primitive. No M2UA peer protocol is invoked.
_STATUSが要求するM-ASは特定のASの状態のLayer Management質問を支持します。 M2UAはM-ASと共に_STATUS確認プリミティブを反応させます。 M2UA同輩プロトコルは全く呼び出されません。
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 M2UA 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 M2UA peer at an SGP.
M ASP_DOWNは、M ASP_UPが、M ASP_ACTIVE要求とM ASP_INACTIVEが、ASPのLayer Managementが基関数で州の変化を起こすことができるよう要求するよう要求するよう要求します。 無事終了のときに、M2UA層のそばで対応する確認プリミティブをLayer Managementに提供します。 実施が失敗しているなら、Error指示プリミティブを原始に提供します。 これらの要求はSGPのリモートM2UA同輩への出発しているASP Up、ASP Down、ASP Active、およびASP Inactiveメッセージをもたらします。
4.2.1 Receipt of M2UA Peer Management Messages
4.2.1 M2UA同輩管理メッセージの領収書
Upon successful state changes resulting from reception of ASP Up, ASP Down, ASP Active and ASP Inactive messages from a peer M2UA, the M2UA layer SHOULD 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.
同輩M2UAからのASP Up、ASP Down、ASP Active、およびASP Inactiveメッセージのレセプションから生じるうまくいっている州の変化では、M2UA層のSHOULDは対応するM ASP_UP、M ASP_DOWN、M ASP_ACTIVE、およびM ASP_INACTIVE、M AS_ACTIVE、M AS_INACTIVE、およびM AS_DOWN指示プリミティブを地方のLayer Managementへ呼び出します。
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M2UA Notify or Error message. These indications can also be generated based on local M2UA events.
M-NOTIFY指示とM-ERROR指示プリミティブは容認されたM2UA NotifyかErrorメッセージに含まれた通知かエラー情報をLayer Managementに示します。 また、これらの指摘は地方のM2UA出来事に基づいて発生できます。
All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. All MGMT messages, with the exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on SCTP stream '0'. All ASPTM messages SHOULD be sent on the stream which normally carries the data traffic to which the message applies. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery, and MAY be sent on any stream.
すべてのMGMTが通信して、BEATとBEAT Ack、SHOULDを除いて、配列された配送と共に送って、注文するのを保証してください。 すべてのMGMTが通信して、ASPTMとBEATとBEAT Ackメッセージ、SHOULDを除いて、SCTP流れ'0'に送ってください。 すべてのASPTMがSHOULDを通信させます。通常、メッセージが適用されるデータ通信量を運ぶ流れに送ります。 BEATとBEAT Ackメッセージを不適切な配送を使用させて、どんな流れにも送るかもしれません。
Morneault, et. al. Standards Track [Page 60] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[60ページ]。
4.3 AS and ASP State Maintenance
4.3、同じくらいそして、ASPは維持を述べます。
The M2UA 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 M2UA message distribution function.
SGPの上のM2UA層はそれぞれのリモートASPの状態を維持して、各Application Serverでは、ASPが交通を受けるためにM2UAメッセージの振分けに入力されるように構成されるのは機能します。
4.3.1 ASP States
4.3.1 ASP州
The state of each remote ASP, in each AS that it is configured to operate, is maintained in the M2UA layer in the SGP. The state of a particular ASP in a particular AS changes due to events. The events include:
操作するのが構成されている各ASでは、それぞれのリモートASPの状態はSGPでM2UA層の中で維持されます。 特定のASの特定のASPの状態は出来事のため変化します。 出来事は:
* Reception of messages from the peer M2UA layer at the ASP;
* Reception of some messages from the peer M2UA 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における同輩M2UA層からのメッセージのレセプション。 * AS(例えば、「オーバーライド」を示すASP Activeメッセージ)の他のASPにおける同輩M2UA層からのいくつかのメッセージのレセプション。 * SCTP層からの指摘のレセプション。 または、*地方のManagement介入。
The ASP state transition diagram is shown in Figure 5. The possible states of an ASP are:
ASP状態遷移ダイヤグラムは図5で見せられます。 ASPの可能な州は以下の通りです。
ASP-DOWN: The remote M2UA 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 M2UA messages, with the exception of Heartbeat, ASP Down Ack and Error messages.
ASP下である: ASPのリモートM2UA同輩は入手できません、そして、関連するSCTP協会は下がっています。 初めは、すべてのASPがこの状態にあるでしょう。 これのASPは、どんなM2UAメッセージもSHOULD NOTに送られると述べます、Heartbeat、ASP Down Ack、およびErrorメッセージを除いて。
ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the related SCTP association is up) but application traffic is stopped. In this state the ASP MAY be sent any non-MAUP M2UA messages.
ASP不活発: ASPのリモートM2UA同輩は手があいていますが(関連するSCTP協会は上がっています)、アプリケーション通行は止められます。 この状態では、どんな非MAUP M2UAメッセージもASPに送るかもしれません。
ASP-ACTIVE: The remote M2UA peer at the ASP is available and application traffic is active (for a particular Interface Identifier or set of Interface Identifiers).
ASPアクティブ: ASPのリモートM2UA同輩は手があいています、そして、アプリケーション交通は活発です(Interface Identifiersの特定のInterface Identifierかセットのための)。
Morneault, et. al. Standards Track [Page 61] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[61ページ]。
Figure 5: ASP State Transition Diagram
図5: ASP状態遷移ダイヤグラム
+--------------+
| 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 |
| |
+--------------+
+--------------+ | ASPアクティブです。| +----------------------| | | 他の+-------| | | 中のASP| +--------------+ | オーバーライド| ^ | | | ASP| | ASP| | アクティブ| | 不活発| | | v| | +--------------+ | | | | | +------>| ASP不活発です。| | +--------------+ | ^ | /へのASP| ASP| | / SCTP CDI/の下側へのASP| 上がる| | SCTP CDI/ SCTPロードアイランド| | SCTP RIに対して| +--------------+ | | | +--------------------->| 下にASP| | | +--------------+
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M2UA) 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の上のUpper Layerプロトコル(M2UA)に地方のSCTP層のCommunication Down Indicationを指示します。 それがASPの同輩SCTP層に接続性の損失を検出するとき、地方のSCTP層はこの指示を送るでしょう。 SCTP CDIはSCTP層からのSHUTDOWN_COMPLETE通知かCOMMUNICATION_LOST通知のどちらかとして理解されています。
SCTP RI: The local SCTP layer's Restart indication to the upper layer protocol (M2UA) on an SG. The local SCTP will send this indication when it detects a restart from the ASP's peer SCTP layer.
SCTPロードアイランド: SGの上のプロトコル(M2UA)上側の層への地方のSCTP層のRestart指示。 それがASPの同輩SCTP層から再開を検出するとき、地方のSCTPはこの指示を送るでしょう。
4.3.2 AS States
4.3.2 州として
The state of the AS is maintained in the M2UA layer on the SGP. The state of an AS changes due to events. These events include:
ASの州はSGPでM2UA層の中で維持されます。 ASの州は出来事のため変化します。 これらの出来事は:
* ASP state transitions
* Recovery timer triggers
* ASP状態遷移*回復タイマ引き金
Morneault, et. al. Standards Track [Page 62] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[62ページ]。
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 MUST be in the AS-DOWN state before it can be removed from a configuration.
下にとして: Application Serverは入手できません。 この州は、すべての関連するASPがこのASのためのASP-DOWN状態にあるのを含意します。 初めは、ASがこの状態にあるでしょう。 Application ServerはAS-DOWN状態の構成からそれを取り除くことができる前であるに違いありません。
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.
-、不活発である、: Application Serverは利用可能ですが、どんなアプリケーション交通も活発ではありません(すなわち、1つ以上の関連するASPがしかし、ASP INACTIVE状態、ASP-ACTIVE状態のなにもにあります)。 回復タイマ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.
能動態として: Application Serverは利用可能です、そして、アプリケーション交通は活発です。 この州は、少なくとも1つのASPがASP-ACTIVE状態にあるのを含意します。
AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP- DOWN and it was the last remaining active ASP in the AS. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages will be sent to the ASP.
-、未定である、: 活動的なASPはASP-INACTIVEかASP DOWNに移行しました、そして、それはASの最後の残っている活動的なASPでした。 回復タイマT(r) SHOULD、始められて入って来る合図がメッセージSHOULDであったなら、SGPによって列に並ばせられてください。 T(r)が期限が切れる前にASPがASP-ACTIVEになるなら、ASをAS-ACTIVE状態に動かします、そして、すべての列に並ばせられたメッセージをASPに送るでしょう。
If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing messages and discards all previously queued messages. The AS will move to the AS-INACTIVE state if at least one ASP is in the ASP-INACTIVE state, otherwise it will move to the AS-DOWN state.
ASPがASP-ACTIVEになる前にT(r)が期限が切れるなら、SGPはメッセージを列に並ばせるのを止めて、すべての以前に列に並ばせられたメッセージを捨てます。 少なくとも1つのASPがASP-INACTIVE状態にあるなら、ASはAS-INACTIVE状態に動くでしょう。さもなければ、それはAS-DOWN状態に動くでしょう。
Figure 6 shows an example AS state machine for the case where the AS/ASP data is pre-configured. For other cases where the AS/ASP configuration data is created dynamically, there would be differences in the state machine, especially at the creation of the AS.
図6は、AS/ASPデータがどこであらかじめ設定されるかをケースのための例のAS州のマシンに示します。 AS/ASPコンフィギュレーション・データがダイナミックに作成される他のケースのために、州のマシンの違いがあるでしょう、特にASの創造のときに。
For example, where the AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the 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コンフィギュレーション・データが第1代ASPのRegistrationまで作成されないところでは、AS-INACTIVE状態はASPから直接最初のうまくいっているREG REQに入れられます。 別の例は第1代ASPが首尾よくASP-ACTIVE状態に入るまでAS/ASPコンフィギュレーション・データが作成されないところです。 この場合、AS-ACTIVE状態は直接入られます。
Morneault, et. al. Standards Track [Page 63] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[63ページ]。
Figure 6: AS State Transition Diagram
図6: 状態遷移ダイヤグラムとして
+----------+ 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
+----------+ 1つのASP、移-、ACTIVE+-------------+ | -|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| -| | 不活発| | アクティブ| | | <、-、--、|、| +----------+ \ +-------------+ ^ | \Tr満期、^| | | \、少なくとも1| | | | ASP不活発の\ASP| | | | \ | | | | \ | | | | \ | | 1つのASP| | すべてのASP\1つ、ASP| | 最後のACTIVE、移-| | 移-、\、移-| | ASP、移-| | 下にASP-------\ASP| | ASP不活発なASP| | \アクティブです。| | または、不活発な状態でASPでダウンしてください。| | \ | | (スタートTr) | | \ | | | | \ | | | \に対して| +に対して----------+ \ +-------------+ | | --| | | 下に| | -、未定| | | | (列を作り) | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +----------+ Tr Expiryにもかかわらず、ASPがありません+。-------------+ ASP-INACTIVE状態で
Tr = Recovery Timer
Trは回復タイマと等しいです。
4.3.3 M2UA Management Procedures for Primitives
4.3.3 基関数のためのM2UA管理手順
Before the establishment of an SCTP association the ASP state at both the SGP and ASP is assumed to be in the state ASP-DOWN.
SCTP協会の設立の前に、SGPとASPの両方のASP状態が州のASP-DOWNにあると思われます。
Once the SCTP association is established (see Section 4.2.1) and assuming that the local M2UA-User is ready, the local M2UA 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.1を見てください)地元のM2UA-ユーザが準備ができていると仮定すると、地方のM2UA ASP Maintenance(ASPM)機能は関連手順に着手するでしょう、ASP状態をSGPまで運ぶASP Up/ASP Down/ASP Active/ASP Inactiveメッセージを使用して(セクション4.3.4を見てください)。
If the M2UA 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.
M2UA層が次に基本的なSCTP層からSCTP-COMMUNICATION_DOWNかSCTP-RESTART指示プリミティブを受け取ると、それは、_STATUS指示原始的にM-SCTPを呼び出すことによって、Layer Managementに知らせるでしょう。 ASPの状態はASP DOWNに動かされるでしょう。
Morneault, et. al. Standards Track [Page 64] RFC 3331 SS7 MTP2 User Adaptation Layer September 2002
et Morneault、アル。 規格はSS7 MTP2ユーザ適合層の2002年9月にRFC3331を追跡します[64ページ]。
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-establish the SCTP association. This MAY be done by the M2UA layer automatically, or Layer Management MAY re-establish using the M-SCTP_ESTABLISH request primitive.
SCTP-COMMUNICATION_DOWNの場合では、SCTPクライアントはSCTP協会を復職させようとするかもしれません。 M2UA層で自動的にこれをするかもしれませんか、または原始的に_ESTABLISHが要求するM-SCTPを使用して、Layer Managementは復職するかもしれません。
In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered by its M2UA 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がASP-DOWN状態にあるとM2UA同輩によって考えられます。 回復するつもりであるなら、ASPはASP上がっている手順に従ったどんな回復も始めなければなりません。
4.3.4 ASPM Procedures for Peer-to-Peer Messages
4.3.4 ピアツーピアメッセージのためのASPM手順
4.3.4.1 ASP Up Procedures
4.3.4.1 手順へのASP
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 M2UA 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 M2UA management function.
ASPが首尾よくSCTP協会をSGPに設立した後に、SGPは、ASPがASP Upメッセージを送るのを待っています、ASP M2UA同輩が手があいているのを示して。 いつもASPはASP Upメッセージの創始者です。 この動作は、Layer ManagementからのM ASP_UPによる要求原始のASPで開始されるか、またはM2UA管理機能によって自動的に開始されるかもしれません。
一覧
スポンサーリンク
