RFC 3332
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
3. M3UA Protocol Elements
The general M3UA message format includes a Common Message Header followed by zero or more parameters as defined by the Message Type. For forward compatibility, all Message Types may have attached parameters even if none are specified in this version.
3.1 Common Message Header
The protocol messages for MTP3-User Adaptation require a message header which contains the adaptation layer version, the message type, and message length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Reserved | Message Class | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / / All fields in an M3UA message MUST be transmitted in the network byte order, unless otherwise stated.3.1.1 M3UA Protocol Version: 8 bits (unsigned integer)
The version field contains the version of the M3UA adaptation layer. The supported versions are the following: 1 Release 1.03.1.2 Message Classes and Types
The following list contains the valid Message Classes: Message Class: 8 bits (unsigned integer) The following list contains the valid Message Type Classes: 0 Management (MGMT) Messages 1 Transfer Messages 2 SS7 Signalling Network Management (SSNM) Messages 3 ASP State Maintenance (ASPSM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages 5 Reserved for Other Sigtran Adaptation Layers 6 Reserved for Other Sigtran Adaptation Layers 7 Reserved for Other Sigtran Adaptation Layers 8 Reserved for Other Sigtran Adaptation Layers 9 Routing Key Management (RKM) Messages 10 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined Message Class extensions
Message Type: 8 bits (unsigned integer)
The following list contains the message types for the defined
messages.
Management (MGMT) Messages (See Section 3.8)
0 Error (ERR)
1 Notify (NTFY)
2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions
Transfer Messages (See Section 3.3)
0 Reserved
1 Payload Data (DATA)
2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Transfer extensions
SS7 Signalling Network Management (SSNM) Messages (See Section
3.4)
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 Signalling Congestion (SCON)
5 Destination User Part Unavailable (DUPU)
6 Destination Restricted (DRST)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined SSNM extensions
ASP State Maintenance (ASPSM) Messages (See Section 3.5)
0 Reserved
1 ASP Up (ASPUP)
2 ASP Down (ASPDN)
3 Heartbeat (BEAT)
4 ASP Up Acknowledgement (ASPUP ACK)
5 ASP Down Acknowledgement (ASPDN ACK)
6 Heartbeat Acknowledgement (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
ASP Traffic Maintenance (ASPTM) Messages (See Section 3.7)
0 Reserved
1 ASP Active (ASPAC)
2 ASP Inactive (ASPIA)
3 ASP Active Acknowledgement (ASPAC ACK)
4 ASP Inactive Acknowledgement (ASPIA ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions
Routing Key Management (RKM) Messages (See Section 3.6)
0 Reserved
1 Registration Request (REG REQ)
2 Registration Response (REG RSP)
3 Deregistration Request (DEREG REQ)
4 Deregistration Response (DEREG RSP)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined RKM extensions
3.1.3 Reserved: 8 bits
The Reserved field SHOULD be set to all '0's and ignored by the
receiver.
3.1.4 Message Length: 32-bits (unsigned integer)
The Message Length defines the length of the message in octets,
including the Common Header. The Message Length MUST include
parameter padding bytes, if any.
Note: A receiver SHOULD accept the message whether or not the final
parameter padding is included in the message length.
3.2 Variable Length Parameter Format
M3UA messages consist of a Common Header followed by zero or more variable length parameters, as defined by the message type. All the parameters contained in a message are defined in a Tag Length-Value format as shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Tag | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver SHOULD accept the parameters in any order. Parameter Tag: 16 bits (unsigned integer) The Tag field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534. Common parameters used by adaptation layers are in the range of 0x00 to 0x3f. M3UA-specific parameters have Tags in the range 0x0200 to 0x02ff. The parameter Tags defined are as follows: Common Parameters. These TLV parameters are common across the different adaptation layers: Parameter Name Parameter ID ============== ============ Reserved 0x0000 Not Used in M3UA 0x0001 Not Used in M3UA 0x0002 Not Used in M3UA 0x0003 INFO String 0x0004 Not Used in M3UA 0x0005 Routing Context 0x0006 Diagnostic Information 0x0007 Not Used in M3UA 0x0008 Heartbeat Data 0x0009 Not Used in M3UA 0x000a Traffic Mode Type 0x000b Error Code 0x000c Status 0x000d
Not Used in M3UA 0x000e
Not Used in M3UA 0x000f
Not Used in M3UA 0x0010
ASP Identifier 0x0011
Affected Point Code 0x0012
Correlation ID 0x0013
M3UA-Specific parameters. These TLV parameters are specific to
the M3UA protocol:
Network Appearance 0x0200
Reserved 0x0201
Reserved 0x0202
Reserved 0x0203
User/Cause 0x0204
Congestion Indications 0x0205
Concerned Destination 0x0206
Routing Key 0x0207
Registration Result 0x0208
Deregistration Result 0x0209
Local_Routing Key Identifier 0x020a
Destination Point Code 0x020b
Service Indicators 0x020c
Reserved 0x020d
Originating Point Code List 0x020e
Circuit Range 0x020f
Protocol Data 0x0210
Reserved 0x0211
Registration Status 0x0212
Deregistration Status 0x0213
Reserved by the IETF 0x0214 to 0xffff
The value of 65535 is reserved for IETF-defined extensions.
Values other than those defined in specific parameter description
are reserved for use by the IETF.
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 SHOULD NOT pad with more than 3
bytes. The receiver MUST ignore the padding bytes.
3.3 Transfer Messages
The following section describes the Transfer messages and parameter
contents.
3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is
an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
The DATA message contains the following variable length parameters:
Network Appearance Optional
Routing Context Optional
Protocol Data Mandatory
Correlation Id Optional
The following format MUST be used for the Data Message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0013 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bits (unsigned integer)
The Network Appearance parameter identifies the SS7 network
context for the message and implicitly identifies the SS7 Point
Code format used, the SS7 Network Indicator value, and the MTP3
and possibly the MTP3-User protocol type/variant/version used
within the specific SS7 network. Where an SG operates in the
context of a single SS7 network, or individual SCTP associations
are dedicated to each SS7 network context, the Network Appearance
parameter is not required. In other cases the parameter may be
configured to be present for the use of the receiver.
The Network Appearance parameter value is of local significance
only, coordinated between the SGP and ASP. Therefore, in the case
where an ASP is connected to more than one SGP, the same SS7
network context may be identified by different Network Appearance
values depending over which SGP a message is being
transmitted/received.
Where the optional Network Appearance parameter is present, it
must be the first parameter in the message as it defines the
format of the Protocol Data field.
IMPLEMENTATION NOTE: For simplicity of configuration it may be
desirable to use the same NA value across all nodes sharing a
particular network context.
Routing Context: 32-bits (unsigned integer)
The Routing Context parameter contains the Routing Context value
associated with the DATA message. Where a Routing Key has not
been coordinated between the SGP and ASP, sending of Routing
Context is not required. Where multiple Routing Keys and Routing
Contexts are used across a common association, the Routing Context
MUST be sent to identify the traffic flow, assisting in the
internal distribution of Data messages.
Protocol Data: variable length
The Protocol Data parameter contains the original SS7 MTP3
message, including the Service Information Octet and Routing
Label.
The Protocol Data parameter contains the following fields:
Service Indicator,
Network Indicator,
Message Priority.
Destination Point Code,
Originating Point Code,
Signalling Link Selection Code (SLS).
User Protocol Data. Includes:
MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP
parameters).
The Protocol Data parameter is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI | NI | MP | SLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Originating Point Code: 32 bits (unsigned integer)
Destination Point Code: 32 bits (unsigned integer)
The Originating and Destination Point Code fields contains the OPC
and DPC from the routing label of the original SS7 message in Network
Byte Order, justified to the least significant bit. Unused bits are
coded `0'.
Service Indicator: 8 bits (unsigned integer)
The Service Indicator field contains the SI field from the original
SS7 message justified to the least significant bit. Unused bits are
coded `0'.
Network Indicator: 8-bits (unsigned integer)
The Network Indicator contains the NI field from the original SS7
message justified to the least significant bit. Unused bits are
coded `0'.
Message Priority: 8 bits (unsigned integer)
The Message Priority field contains the MP bits (if any) from the
original SS7 message, both for ANSI-style and TTC-style [29] message
priority bits. The MP bits are aligned to the least significant bit.
Unused bits are coded `0'.
Signalling Link Selection: 8 bits (unsigned integer) The Signalling Link Selection field contains the SLS bits from the routing label of the original SS7 message justified to the least significant bit and in Network Byte Order. Unused bits are coded `0'. User Protocol Data: (byte string) The User Protocol Data field contains a byte string of MTP-User information from the original SS7 message starting with the first byte of the original SS7 message following the Routing Label. Correlation Id: 32-bits (unsigned integer) The Correlation Id parameter uniquely identifies the MSU carried in the Protocol Data within an AS. This Correlation Id parameter is assigned by the sending M3UA.3.4 SS7 Signalling Network Management (SSNM) Messages
3.4.1 Destination Unavailable (DUNA)
The DUNA message is sent from an SGP in an SG to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are unreachable. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. As an implementation option the SG may suppress the sending of subsequent "response" DUNA messages regarding a certain unreachable SS7 destination for a certain period to give the remote side time to react. If there is no alternate route via another SG, the MTP3-User at the ASP is expected to stop traffic to the affected destination via the SG as per the defined MTP3-User procedures.
The DUNA message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String Optional
The format for DUNA 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 = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bit unsigned integer
See Section 3.3.1
Routing Context: n x 32-bits (unsigned integer)
The optional Routing Context parameter contains the Routing
Context values associated with the DUNA message. Where a Routing
Key has not been coordinated between the SGP and ASP, sending of
Routing Context is not required. Where multiple Routing Keys and
Routing Contexts are used across a common association, the Routing
Context(s) MUST be sent to identify the concerned traffic flows
for which the DUNA message applies, assisting in outgoing traffic
management and internal distribution of MTP-PAUSE indications to
MTP3-Users at the receiver.
Affected Point Code: n x 32-bits
The Affected Point Code parameter contains a list of Affected
Destination Point Code fields, each a three-octet parameter to
allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes.
Affected Point Codes that are less than 24-bits, are padded on the
left to the 24-bit boundary. The encoding is shown below for ANSI
and ITU Point Code examples.
ANSI 24-bit Point Code:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Network | Cluster | Member |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB-----------------------------------------LSB|
ITU 14-bit Point Code:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB|
It is optional to send an Affected Point Code parameter with more
than one Affected PC but it is mandatory to receive it. Including
multiple Affected PCs may be useful when reception of an MTP3
management message or a linkset event simultaneously affects the
availability status of a list of destinations at an SG.
Mask: 8-bits (unsigned integer)
The Mask field can be used to identify a contiguous range of
Affected Destination Point Codes. Identifying a contiguous range
of Affected DPCs may be useful when reception of an MTP3
management message or a linkset event simultaneously affects the
availability status of a series of destinations at an SG.
The Mask parameter is an integer representing a bit mask that can
be applied to the related Affected PC field. The bit mask
identifies how many bits of the Affected PC field are significant
and which are effectively "wildcarded". For example, a mask of
"8" indicates that the last eight bits of the PC is "wildcarded".
For an ANSI 24-bit Affected PC, this is equivalent to signalling
that all PCs in an ANSI Cluster are unavailable. A mask of "3"
indicates that the last three bits of the PC is "wildcarded". For
a 14-bit ITU Affected PC, this is equivalent to signaling that an
ITU
Region is unavailable. A mask value equal (or greater than) the
number of bits in the PC indicates that the entire network
appearance is affected - this is used to indicate network
isolation to the ASP.
INFO String: variable length
The optional INFO String parameter can carry any meaningful UTF-8
[10] character string along with the message. Length of the INFO
String parameter is from 0 to 255 octets. No procedures are
presently identified for its use but the INFO String MAY be used
for debugging purposes.
3.4.2 Destination Available (DAVA)
The DAVA message is sent from an SGP to all concerned ASPs to
indicate that the SG has determined that one or more SS7 destinations
are now reachable (and not restricted), or in response to a DAUD
message if appropriate. If the ASP M3UA layer previously had no
routes to the affected destinations the ASP MTP3-User protocol is
informed and may now resume traffic to the affected destination. The
ASP M3UA layer now routes the MTP3-user traffic through the SG
initiating the DAVA message.
The DAVA message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String Optional
The format and description of the Network Appearance, Routing
Context, Affected Point Code and INFO String parameters is the same
as for the DUNA message (See Section 3.4.1).
3.4.3 Destination State Audit (DAUD)
The DAUD message MAY be sent from the ASP to the SGP to audit the
availability/congestion state of SS7 routes from the SG to one or
more affected destinations.
The DAUD message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String Optional
The format and description of DAUD Message parameters is the same as
for the DUNA message (See Section 3.4.1).
3.4.4 Signalling Congestion (SCON)
The SCON message can be sent from an SGP to all concerned ASPs to
indicate that an SG has determined that there is congestion in the
SS7 network to one or more destinations, or to an ASP in response to
a DATA or DAUD message as appropriate. For some MTP protocol
variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
congestion level changes. The SCON message MAY also be sent from the
M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer
or the ASP is congested.
The SCON message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
Concerned Destination Optional
Congestion Indications Optional
INFO String Optional
The format for SCON Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the Network Appearance, Routing
Context, Affected Point Code, and INFO String parameters is the same
as for the DUNA message (See Section 3.4.1).
The Affected Point Code parameter can be used to indicate congestion
of multiple destinations or ranges of destinations.
Concerned Destination: 32-bits
The optional Concerned Destination parameter is only used if the
SCON message is sent from an ASP to the SGP. It contains the point
code of the originator of the message that triggered the SCON
message. The Concerned Destination parameter contains one
Concerned Destination Point Code field, a three-octet parameter to
allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. A
Concerned Point Code that is less than 24-bits is padded on the
left to the 24-bit boundary. Any resulting Transfer Controlled
(TFC) message from the SG is sent to the Concerned Point Code
using the single Affected DPC contained in the SCON message to
populate the (affected) Destination field of the TFC message
Congested Indications: 32-bits
The optional Congestion Indications parameter contains a
Congestion Level field. This optional parameter is used to
communicate congestion levels in national MTP networks with
multiple congestion thresholds, such as in ANSI MTP3. For MTP
congestion methods without multiple congestion levels (e.g., the
ITU international method) the parameter is not included.
Congestion Level field: 8-bits (unsigned integer)
The Congestion Level field, associated with all of the Affected
DPC(s) in the Affected Destinations parameter, contains one of the
following values:
0 No Congestion or Undefined
1 Congestion Level 1
2 Congestion Level 2
3 Congestion Level 3
The congestion levels are defined in the congestion method in the
appropriate national MTP recommendations [7,8].
3.4.5 Destination User Part Unavailable (DUPU)
The DUPU message is used by an SGP to inform concerned ASPs that a
remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is
unavailable.
The DUPU message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
User/Cause Mandatory
INFO String Optional
The format for DUPU message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User/Cause: 32-bits
The Unavailability Cause and MTP3-User Identity fields, associated
with the Affected PC in the Affected Point Code parameter, are
encoded as follows:
Unavailability Cause field: 16-bits (unsigned integer)
The Unavailability Cause parameter provides the reason for the
unavailability of the MTP3-User. The valid values for the
Unavailability Cause parameter are shown in the following table.
The values agree with those provided in the SS7 MTP3 User Part
Unavailable message. Depending on the MTP3 protocol used in the
Network Appearance, additional values may be used - the
specification of the relevant MTP3 protocol variant/version
recommendation is definitive.
0 Unknown
1 Unequipped Remote User
2 Inaccessible Remote User
MTP3-User Identity field: 16-bits (unsigned integer)
The MTP3-User Identity describes the specific MTP3-User that is
unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for
the MTP3-User Identity are shown below. The values align with
those provided in the SS7 MTP3 User Part Unavailable message and
Service Indicator. Depending on the MTP3 protocol variant/version
used in the network appearance, additional values may be used.
The relevant MTP3 protocol variant/version recommendation is
definitive.
0 to 2 Reserved
3 SCCP
4 TUP
5 ISUP
6 to 8 Reserved
9 Broadband ISUP
10 Satellite ISUP
11 Reserved
12 AAL type 2 Signalling
13 Bearer Independent Call Control (BICC)
14 Gateway Control Protocol
15 Reserved
The format and description of the Affected Point Code parameter is
the same as for the DUNA message (See Section 3.4.1.) except that
the Mask field is not used and only a single Affected DPC is
included. Ranges and lists of Affected DPCs cannot be signaled in
a DUPU message, but this is consistent with UPU operation in the
SS7 network. The Affected Destinations parameter in an MTP3 User
Part Unavailable message (UPU) received by an SGP from the SS7
network contains only one destination.
The format and description of the Network Appearance, Routing
Context, and INFO String parameters is the same as for the DUNA
message (See Section 3.4.1).
3.4.6 Destination Restricted (DRST)
The DRST message is optionally sent from the SGP to all concerned
ASPs to indicate that the SG has determined that one or more SS7
destinations are now restricted from the point of view of the SG, or
in response to a DAUD message if appropriate. The M3UA layer at the
ASP is expected to send traffic to the affected destination via an
alternate SG with route(s) of equal priority, but only if such an
alternate route exists and is available. If the affected destination
is currently considered unavailable by the ASP, The MTP3-User should
be informed that traffic to the affected destination can be resumed.
In this case, the M3UA layer should route the traffic through the SG
initiating the DRST message.
This message is optional for the SG to send and it is optional for
the ASP to act on any information received in the message. It is for
use in the "STP" case described in Section 1.4.1.
The DRST message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String Optional
The format and description of the Network Appearance, Routing
Context, Affected Point Code and INFO String parameters is the same
as for the DUNA message (See Section 3.4.1).
3.5 ASP State Maintenance (ASPSM) Messages
3.5.1 ASP Up
The ASP Up message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any ASPSM/ASPTM messages for all Routing Keys that the ASP is configured to serve. The ASP Up message contains the following parameters: ASP Identifier Optional INFO String Optional The format for ASP Up 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 = 0x0011 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASP Identifier: 32-bit unsigned integer The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SGP should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.8.2). The format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1).
3.5.2 ASP Up Acknowledgement (ASP Up Ack)
The ASP UP Ack message is used to acknowledge an ASP Up message received from a remote M3UA peer. The ASP Up Ack message contains the following parameters: INFO String (optional) The format for ASP Up 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 =0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1). The INFO String in an ASP Up Ack message is independent from the INFO String in the ASP Up message (i.e., it does not have to echo back the INFO String received).3.5.3 ASP Down
The ASP Down message is used to indicate to a remote M3UA peer that the adaptation layer is NOT ready to receive DATA, SSNM, RKM or ASPTM messages. The ASP Down message contains the following parameters: INFO String Optional
The format for the ASP Down 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 =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is
the same as for the DUNA message (See Section 3.4.1).
3.5.4 ASP Down Acknowledgement (ASP Down Ack)
The ASP Down Ack message is used to acknowledge an ASP Down message
received from a remote M3UA peer.
The ASP Down Ack message contains the following parameters:
INFO String Optional
The format for the ASP Down 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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is
the same as for the DUNA message (See Section 3.4.1).
The INFO String in an ASP Down Ack message is independent from the
INFO String in the ASP Down message (i.e., it does not have to echo
back the INFO String received).
3.5.5 Heartbeat (BEAT)
The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. It is recommended for use when the M3UA runs over a transport layer other than the SCTP, which has its own heartbeat. The BEAT message contains the following parameters: Heartbeat Data Optional The format for the BEAT message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0009 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Heartbeat Data parameter contents are defined by the sending node. The Heartbeat Data could include, for example, a Heartbeat Sequence Number and/or Timestamp. The receiver of a BEAT message does not process this field as it is only of significance to the sender. The receiver MUST respond with a BEAT Ack message.3.5.6 Heartbeat Acknowledgement (BEAT Ack)
The BEAT Ack message is sent in response to a received BEAT message. It includes all the parameters of the received BEAT message, without any change.3.6 Routing Key Management (RKM) Messages [Optional]
3.6.1 Registration Request (REG REQ)
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to register one or more given Routing Keys with the remote peer. Typically, an ASP would send this message to an SGP, and expects to receive a REG RSP message in return with an associated Routing Context value.
The REG REQ message contains the following parameters:
Routing Key Mandatory
One or more Routing Key parameters MAY be included. The format for
the REG REQ 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 = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Key: variable length
The Routing Key parameter is mandatory. The sender of this message
expects that the receiver of this message will create a Routing
Key entry and assign a unique Routing Context value to it, if the
Routing Key entry does not already exist.
The Routing Key parameter may be present multiple times in the
same message. This is used to allow the registration of multiple
Routing Keys in a single message.
The format of the Routing Key parameter is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The Destination Point Code, Service Indicators, Originating
Point Code List and Circuit Range List parameters MAY be repeated
as a grouping within the Routing Key parameter, in the structure
shown above.
Local-RK-Identifier: 32-bit unsigned integer
The mandatory Local-RK-Identifier field is used to uniquely
identify the registration request. The Identifier value is
assigned by the ASP, and is used to correlate the response in an
REG RSP message with the original registration request. The
Identifier value must remain unique until the REG RSP message is
received.
The format of the Local-RK-Identifier field 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 = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer)
The optional Traffic Mode Type parameter identifies the traffic mode
of operation of the ASP(s) within an Application Server. The format
of the Traffic Mode Type Identifier is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Traffic Mode Type are shown in the following
table:
1 Override
2 Loadshare
3 Broadcast
Destination Point Code:
The Destination Point Code parameter is mandatory, and identifies
the Destination Point Code of incoming SS7 traffic for which the
ASP is registering. The format is the same as described for the
Affected Destination parameter in the DUNA message (See Section
3.4.1). Its format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance:
The optional Network Appearance parameter field identifies the SS7
network context for the Routing Key, and has the same format as in
the DATA message (See Section 3.3.1). The absence of the Network
Appearance parameter in the Routing Key indicates the use of any
Network Appearance value. Its format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Indicators (SI): n X 8-bit integers
The optional SI [7,8] field contains one or more Service
Indicators from the values as described in the MTP3-User Identity
field of the DUPU message. The absence of the SI parameter in the
Routing Key indicates the use of any SI value, excluding of course
MTP management. Where an SI parameter does not contain a multiple
of four SIs, the parameter is padded out to 32-byte alignment.
The SI format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPC List:
The Originating Point Code List parameter contains one or more SS7
OPC entries, and its format is the same as the Destination Point
Code parameter. The absence of the OPC List parameter in the
Routing Key indicates the use of any OPC value,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Circuit Range:
An ISUP controlled circuit is uniquely identified by the SS7 OPC,
DPC and CIC value. For the purposes of identifying Circuit Ranges
in an M3UA Routing Key, the optional Circuit Range parameter
includes one or more circuit ranges, each identified by an OPC and
Upper/Lower CIC value. The DPC is implicit as it is mandatory and
already included in the DPC parameter of the Routing Key. The
absence of the Circuit Range parameter in the Routing Key
indicates the use of any Circuit Range values, in the case of
ISUP/TUP traffic. The Origination Point Code is encoded the same
as the Destination Point Code parameter, while the CIC values are
16-bit integers.
The Circuit Range format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #1 | Upper CIC Value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #2 | Upper CIC Value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #n | Upper CIC Value #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.6.2 Registration Response (REG RSP)
The REG RSP message is used as a response to the REG REQ message from
a remote M3UA peer. It contains indications of success/failure for
registration requests and returns a unique Routing Context value for
successful registration requests, to be used in subsequent M3UA
Traffic Management protocol.
The REG RSP message contains the following parameters:
Registration Result Mandatory
One or more Registration Result parameters MUST be included. The
format for the REG RSP 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 = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Registration Results:
The Registration Result parameter contains the registration result
for a single Routing Key in an REG REQ message. The number of
results in a single REG RSP message MUST be anywhere from one to
the total number of number of Routing Key parameters found in the
corresponding REG REQ message. Where multiple REG RSP messages
are used in reply to REG REQ message, a specific result SHOULD be
in only one REG RSP message. The format of each result is as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0212 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-RK-Identifier: 32-bit integer
The Local-RK-Identifier contains the same value as found in the
matching Routing Key parameter found in the REG REQ message (See
Section 3.6.1).
Registration Status: 32-bit integer
The Registration Result Status field indicates the success or the
reason for failure of a registration request.
Its values may be:
0 Successfully Registered
1 Error - Unknown
2 Error - Invalid DPC
3 Error - Invalid Network Appearance
4 Error - Invalid Routing Key
5 Error - Permission Denied
6 Error - Cannot Support Unique Routing
7 Error - Routing Key not Currently Provisioned
8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field
10 Error - Unsupported/Invalid Traffic Handling Mode
Routing Context: 32-bit integer
The Routing Context field contains the Routing Context value for
the associated Routing Key if the registration was successful. It
is set to "0" if the registration was not successful.
3.6.3 Deregistration Request (DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA
peer that it wishes to deregister a given Routing Key. Typically, an
ASP would send this message to an SGP, and expects to receive a DEREG
RSP message in return with the associated Routing Context value.
The DEREG REQ message contains the following parameters:
Routing Context Mandatory
The format for the DEREG REQ 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: n X 32-bit integers
The Routing Context parameter contains (a list of) integers
indexing the Application Server traffic that the sending ASP is
currently registered to receive from the SGP but now wishes to
deregister.
3.6.4 Deregistration Response (DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message
from a remote M3UA peer.
The DEREG RSP message contains the following parameters:
Deregistration Result Mandatory
One or more Deregistration Result parameters MUST be included. The
format for the DEREG RSP 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 = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deregistration Results:
The Deregistration Result parameter contains the deregistration
status for a single Routing Context in a DEREG REQ message. The
number of results in a single DEREG RSP message MAY be anywhere
from one to the total number of number of Routing Context values
found in the corresponding DEREG REQ message.
Where multiple DEREG RSP messages are used in reply to DEREG REQ
message, a specific result SHOULD be in only one DEREG RSP
message. The format of each result is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0213 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: 32-bit integer
The Routing Context field contains the Routing Context value of
the matching Routing Key to deregister, as found in the DEREG REQ
message.
Deregistration Status: 32-bit integer
The Deregistration Result Status field indicates the success or
the reason for failure of the deregistration.
Its values may be:
0 Successfully Deregistered
1 Error - Unknown
2 Error - Invalid Routing Context
3 Error - Permission Denied
4 Error - Not Registered
5 Error - ASP Currently Active for Routing Context
(next page on part 3)
