RFC 3331
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer
3. Protocol Elements
This section describes the format of various messages used in this protocol.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: 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 All fields in an M2UA message MUST be transmitted in the network byte order, unless otherwise stated.3.1.1 Version
The version field contains the version of the M2UA adaptation layer. The supported versions are: Value Version ----- ------- 1 Release 1.03.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.
3.1.3 Message Class
The following List contains the valid Message Classes: 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 extensions3.1.4 Message Type
The following List contains the Message Types for the valid Message Classes: 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
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
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
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
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
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.
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. 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. 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 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
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 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.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter
at the end (i.e., after the Parameter Value field) with all zero
bytes. The length of the padding is NOT included in the parameter
length field. A sender MUST NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
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. 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. 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) 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) / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.
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).3.3.1 MTP2 User Adaptation Messages
3.3.1.1 Data
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) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
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 following parameter:
Correlation Id Mandatory
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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. 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)
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. 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). 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.3.3.1.4 Release (Request, Indication, Confirmation)
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.3.3.1.5 State Request
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.
The State Request message contains the following parameter:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
3.3.1.6 State Confirm
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.
The State Confirm message contains the following parameter:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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
3.3.1.7 State Indication
The MTP2 State Indication message can be sent from a SGP to an ASP to
indicate a condition on a SS7 link.
The State Indication message contains the following parameter:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Event are shown in the following table.
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
3.3.1.8 Congestion Indication
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. 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. An implementation may optionally send Congestion Indication messages on a "high priority" stream in order to potentially reduce delay. The Congestion Indication message contains the following parameters: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for Congestion Status and Discard Status are shown in the following table. 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
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.3.3.1.9 Retrieval Request
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. The Retrieval Request message contains the following parameters: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for Action are shown in the following table. 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 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.
3.3.1.10 Retrieval Confirm
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. The Retrieval Confirm message contains the following parameters: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for Action are the same as in Retrieval Request. The values for Result are shown below: Define Value Description RESULT_SUCCESS 0x0 Action successful RESULT_FAILURE 0x1 Action failed 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.
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.3.3.1.11 Retrieval Indication
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. 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 / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For TTC Data messages, the following parameter will be used to indicate a TTC PDU which starts at LI. 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 / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The M2UA implementation MAY consider the use of the bundling feature of SCTP for Retrieval Indication messages.3.3.1.12 Retrieval Complete Indication
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.
3.3.2 Application Server Process Maintenance (ASPM) Messages
The ASPM messages will only use the common message header.3.3.2.1 ASP Up (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. The ASPUP message contains the following parameters ASP Identifier (optional) Info String (optional) 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). The format for ASPUP 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 (0x11) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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). 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.
3.3.2.2 ASP Up Ack
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote M2UA peer. The ASPUP Ack message contains the following parameters: INFO String (optional) The format for ASPUP Ack 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 (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).3.3.2.3 ASP Down (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. The ASPDN message contains the following parameters INFO String (optional) The format for the ASPDN 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 (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).
3.3.2.4 ASP Down Ack
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M2UA peer. The ASP Down Ack message contains the following parameters: INFO String (optional) The format for the ASPDN Ack 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 (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).3.3.2.5 Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the M2UA peers are still available to each other. The BEAT message contains the following parameter: Heartbeat Data Optional The format for the BEAT message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0009 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Heartbeat Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.
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.3.3.2.6 Heartbeat Ack (BEAT 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. The BEAT ACK message contains the following parameter: Heartbeat Data Optional The format for the BEAT 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 = 0x0009 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Heartbeat Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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.3.3.2.7 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SGP that it is Active and ready to be used. The ASPAC 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)
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* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
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.
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).
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).
(page 38 continued on part 3)
