RFC 3868
Signalling Connection Control Part User Adaptation Layer (SUA)
Pages: 131
Proposed Standard
Proposed Standard
Part 3 of 5 – Pages 56 to 92
3.7. SUA Management Messages
These messages are used for managing SUA and the representations of the SCCP subsystems in the SUA layer.3.7.1. Error (ERR)
The ERR message is sent between two SUA peers to indicate an error situation. The Diagnostic Information parameter is optional, possibly used for error logging and/or debugging. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x000C | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | Affected PC 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | Affected PC n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x010D | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0007 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Diagnostic Info / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Error Code Mandatory
Routing Context Mandatory *1
Network Appearance Mandatory *1
Affected Point Code Mandatory *1
Diagnostic Information Optional
Note 1: Only mandatory for specific error codes.
3.7.2. Notify (NTFY)
The Notify message used to provide an autonomous indication of SUA
events to an SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTFY message contains the following parameters:
Parameters
Status Mandatory
ASP Identifier Optional *1
Routing Context Optional
Info String Optional
Note 1: ASP Identifier MUST be used where the IPSP/SGP cannot
identify the ASP by provisioned address/port number
information (e.g., where an ASP is resident on a Host
using dynamic address/port number assignment).
3.8. Routing Key Management (RKM) Messages
3.8.1. Registration Request (REG REQ)
The REG REQ message is sent by an ASP to indicate to a remote SUA 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 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 = 0x010E | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Key 1 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x010E | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Key n / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0109 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The REG REQ message contains the following parameters: Parameters Routing Key Mandatory *1 ASP Capabilities Optional Note 1: One or more Routing Key parameters MAY be included in a single REG REQ message.
3.8.2. Registration Response (REG RSP)
The REG RSP message is sent by an SG to an ASP indicate the result of a previous REG REQ from an ASP. 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 SUA Traffic Management protocol messages. 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 = 0x0014 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Result 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0014 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Result n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The REG RSP message contains the following parameters: Parameters Registration Result Mandatory *1 Note 1: One or more Registration Result parameters MAY be included in a single REG RSP message. The number of results in a single REG RSP message can be anywhere from one to the total number of Routing Key parameters found in the corresponding REG REQ message.3.8.3. Deregistration Request (DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote SUA 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 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DEREG REQ message contains the following parameters:
Parameters
Routing Context Mandatory
3.8.4. Deregistration Response (DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message
from a remote SUA peer.
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 = 0x0015 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0015 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DEREG RSP message contains the following parameters:
Parameters
Deregistration Result Mandatory *1
Note 1: One or more Deregistration Result parameters MAY be
included in one DEREG RSP message. The number of results
in a single DEREG RSP message can be anywhere from one to
the total number of Routing Context parameters found in
the corresponding DEREG REQ message.
3.9. Common Parameters
These TLV parameters are common across the different adaptation layers. Parameter Name Parameter ID ============== ============ Reserved 0x0000 Not used in SUA 0x0001 Not used in SUA 0x0002 Not used in SUA 0x0003 Info String 0x0004 Not used in SUA 0x0005 Routing Context 0x0006 Diagnostic Info 0x0007 Not used in SUA 0x0008 Heartbeat Data 0x0009 Not Used in SUA 0x000A Traffic Mode Type 0x000B Error Code 0x000C Status 0x000D Not used in SUA 0x000E Not used in SUA 0x000F Not used in SUA 0x0010 ASP Identifier 0x0011 Affected Point Code 0x0012 Correlation ID 0x0013 Registration Result 0x0014 Deregistration Result 0x0015 Registration Status 0x0016 Deregistration Status 0x0017 Local Routing Key Identifier 0x00183.9.1. Not Used
Use of Parameter ID 0x0001 in SUA messages is not supported.3.9.2. Not Used
Use of Parameter ID 0x0002 in SUA messages is not supported.3.9.3. Not Used
Use of Parameter ID 0x0003 in SUA messages is not supported.
3.9.4. Info String
The optional INFO String parameter can carry any meaningful UTF-8 [3629] 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 service providers may use the INFO String for debugging purposes. 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 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.9.5. Not Used in SUA
Use of Parameter ID 0x0005 in SUA messages is not supported.3.9.6. Routing Context
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 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Routing Context parameter contains (a list of) 4-byte unsigned integers indexing the Application Server traffic that the sending ASP is configured/registered to receive. There is a one-to-one relationship between an index entry and a Routing Key or AS Name. An Application Server Process may be configured to process traffic for more than one logical Application Server. From the perspective of an ASP, a Routing Context defines a range of signalling traffic that the ASP is currently configured to receive from the SG. Additionally, the Routing Context parameter identifies the SS7 network context for the message, for the purposes of logically separating the signalling traffic between the SGP and the Application Server Process over a common SCTP Association, when needed. An example is where an SGP is logically partitioned to appear as an
element in several different national SS7 networks. It implicitly defines the SS7 Point Code format used, the SS7 Network Indicator value and SCCP protocol type/variant/version used within a separate SS7 network. It also defines the network context for the PC and SSN values. Where an SGP operates in the context of a single SS7 network, or individual SCTP associations are dedicated to each SS7 network context, this functionality is not needed. If the Routing Context parameter is present, it SHOULD be the first parameter in the message as it defines the format and/or interpretation of the parameters containing a PC or SSN value.3.9.7. Diagnostic Information
The Diagnostic Information can be used to convey any information relevant to an error condition, to assist in the identification of the error condition. In the case of an Adaptation Layer Identifier or Traffic Handling Mode, the Diagnostic Information includes the received parameter. In the other cases, the Diagnostic information may be the first 40 bytes of the offending 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 = 0x0007 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Diagnostic Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.9.8. Not Used
Parameter ID 0x0008 is not used in SUA.3.9.9. Heartbeat Data
The sending node defines the Heartbeat Data field contents. It may include a Heartbeat Sequence Number and/or Timestamp, 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.
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 data field can be used to store information in the heartbeat
message useful to the sending node (e.g., the data field can contain
a time stamp, a sequence number, etc.).
3.9.10. Not Used
Parameter ID 0x000A is not used in SUA.
3.9.11. Traffic Mode Type
The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS.
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 Type are shown in the following table.
1 Override
2 Loadshare
3 Broadcast
Within a Routing Context, Override, Loadshare Types and Broadcast
cannot be mixed. The Override value indicates that the ASP is
operating in Override mode, and the ASP wishes to take over all
traffic for an Application Server (i.e., primary/backup operation),
overriding any currently active ASP in the AS. In Loadshare mode,
the ASP wishes to share in the traffic distribution with any other
currently active ASPs. In Broadcast mode, the ASP wishes to receive
the same traffic as any other currently active ASPs. When there are
insufficient ASPs, the sender may immediately move the ASP to Active.
3.9.12. Error 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag =0x000C | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Code parameter indicates the reason for the Error Message. The Error parameter value can be one of the following values: 0x01 Invalid Version 0x02 Not Used in SUA 0x03 Unsupported Message Class 0x04 Unsupported Message Type 0x05 Unsupported Traffic Handling Mode 0x06 Unexpected Message 0x07 Protocol Error 0x08 Not used in SUA 0x09 Invalid Stream Identifier 0x0a Not used in SUA 0x0b Not used in SUA 0x0c Not used in SUA 0x0d Refused - Management Blocking 0x0e ASP Identifier Required 0x0f Invalid ASP Identifier 0x10 Not Used in SUA 0x11 Invalid Parameter Value 0x12 Parameter Field Error 0x13 Unexpected Parameter 0x14 Destination Status Unknown 0x15 Invalid Network Appearance 0x16 Missing Parameter 0x17 Not Used in SUA 0x18 Not Used in SUA 0x19 Invalid Routing Context 0x1a No Configured AS for ASP 0x1b Subsystem Status Unknown 0x1c Invalid loadsharing label The "Invalid Version" error is sent if a message was received with an invalid or unsupported version. The Error message contains the supported version in the Common header. The Error message could optionally provide the unsupported version in the Diagnostic information area.
The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received. The "Unsupported Message Type" error is sent if a message with an unexpected or unsupported Message Type is received. The "Unsupported Traffic Handling Mode" error is sent by a SGP if an ASP sends an ASP Active message with an unsupported Traffic Mode Type or a Traffic Mode Type that is inconsistent with the presently configured mode for the Application Server. An example would be a case in which the SGP did not support loadsharing. The "Unexpected Message" error MAY be sent if a defined and recognized message is received that is not expected in the current state (in some cases the ASP may optionally silently discard the message and not send an Error message). For example, silent discard is used by an ASP if it received a DATA message from an SGP while it was in the ASP-INACTIVE state. If the Unexpected message contained Routing Context(s), the Routing Context(s) SHOULD be included in the Error message. The "Protocol Error" error is sent for any protocol anomaly (i.e., reception of a parameter that is syntactically correct but unexpected in the current situation. The "Invalid Stream Identifier" error is sent if a message is received on an unexpected SCTP stream. The "Refused - Management Blocking" error is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons (e.g., management lockout"). If this error is in response to an ASP Active message, the Routing Context(s) in the ASP Active message SHOULD be included in the Error message. The "ASP Identifier Required" is sent by a SGP in response to an ASP Up message that does not contain an ASP Identifier parameter when the SGP requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier. The "Invalid ASP Identifier" is send by a SGP in response to an ASP Up message with an invalid ASP Identifier. The "Invalid Parameter Value" error is sent if a message is received with an invalid parameter value (e.g., a DUPU message was received with a Mask value other than "0". The "Parameter Field Error" would be sent if a message is received with a parameter having a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains an invalid parameter. The "Invalid Network Appearance" error is sent by a SGP if an ASP sends a message with an invalid (not configured) Network Appearance value. For this error, the invalid (not configured) Network Appearance MUST be included in the Network Appearance parameter. The "Missing Parameter" error would be sent if a mandatory parameter were not included in a message. The "Invalid Routing Context" error would be sent by a SG if an ASP sends a message with an invalid (not configured) Routing Context value. For this error, the invalid (not configured) Routing Context(s) MUST be included in the Routing Context parameter. The "No Configured AS for ASP" error is sent if a message is received from a peer without a Routing Context parameter and it is not known by configuration data, which Application Servers are referenced. The "Destination Status Unknown" Error MAY be sent if a DAUD is received at an SG inquiring of the availability or congestion status of a destination, and the SG does not wish to provide the status (e.g., the sender is not authorized to know the status). For this error, the invalid or unauthorized Point Code(s) MUST be included along with the Network Appearance and Routing Context associated with the Point Code(s). The "Subsystem Status Unknown" Error MAY be sent if a DAUD is received at an SG inquiring of the availability or congestion status of a subsystem, and the SG does not wish to provide the status (e.g., the sender is not authorized to know the status). For this error, the invalid or unauthorized Point Code and Subsystem Number MUST be included along with the Network Appearance and Routing Context associated with the Point Code and Subsystem Number.3.9.13. Status
The Status parameter identifies the type of the status that is being notified and the Status 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 = 0x000D | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Type | Status ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Status Type (16 bit unsigned integer) are:
1 Application Server state change (AS_State_Change)
2 Other
The Status ID parameter contains more detailed information for the
notification, based on the value of the Status Type.
If the Status Type is AS_STATE_CHANGE, then the Status ID (16 bit
unsigned integer) values are:
1 reserved
2 Application Server Inactive (AS-Inactive)
3 Application Server Active (AS-Active)
4 Application Server Pending (AS-Pending)
These notifications are sent from an SGP to an ASP upon a change in
status of a particular Application Server. The value reflects the
new state of the Application Server.
If the Status Type is "Other", then the following Status Information
values are defined:
1 Insufficient ASP resources active in AS
2 Alternate ASP Active
3 ASP failure
These notifications are not based on the SGP reporting the state
change of an ASP or AS. In the Insufficient ASP Resources case, the
SGP is indicating to an "Inactive" ASP(s) in the AS that another ASP
is required to handle the load of the AS (Loadsharing mode or
Broadcast mode). For the Alternate ASP Active case, an ASP is
informed when an alternate ASP transitions to the ASP-Active state in
Override mode.
3.9.14. Not Used in SUA
Parameter ID 0x000E is not used in SUA.
3.9.15. Not Used in SUA
Parameter ID 0x000F is not used in SUA.3.9.16. Not Used in SUA
Parameter ID 0x0010 is not used in SUA.3.9.17. ASP 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 = 0x0011 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASP Identifier field: 32-bits (unsigned integer) The ASP Identifier field 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.7.2).3.9.18. Affected Point Code
The Affected Point Code Destinations parameter contains a list of Affected 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. 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 = 0x0012 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | Affected PC 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / . . . / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 for an implementation to generate an Affected Point
Code parameter with more than on Affected PC but the implementation
MUST accept and process an Affected Point Code parameter with more
than one Affected PC.
Mask: 8-bits
The Mask parameter can be used to identify a contiguous range of
Affected Destination Point Codes, independent of the point code
format. Identifying a contiguous range of Affected PCs 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 "wild-carded". For example, a mask of "8" indicates that
the last eight bits of the PC is "wild-carded". 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 "wild-carded". For a 14-bit ITU Affected PC, this
is equivalent to signalling that an ITU Region is unavailable.
3.9.19. 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 = 0x0013 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Correlation ID is a 32-bit identifier that is attached to CLDT messages to indicate to a newly entering ASP in a Broadcast AS where in the traffic flow of CLDT messages the ASP is joining. It is attached to the first CLDT message sent to an ASP by an SG after sending an ASP Active Ack or otherwise starting traffic to an ASP. The Correlation ID is only significant within a Routing Context. Implementation note: Correlation ID parameter can be used for features like Synchronisation of ASPs/SGPs in a Broadcast Mode AS/SG; avoid message duplication and mis-sequencing in case of failover of association from one ASP/SGP to other ASP/SGP etc.3.9.20. Registration Result
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 = 0x0018 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0016 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Routing Key Identifier contains the same TLV formatted parameter value as found in the matching Routing Key parameter in the REG REQ message. Routing Context contains the same TLV formatted Routing Context parameter for the associated Routing Key if the registration was successful. It is set to "0" if the registration was not successful.
3.9.21. Deregistration Result
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0017 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Deregistration Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Routing Context: 32-bit integer Routing Context contains the Routing Context value of the matching Routing key to deregister, as found in the DEREG REQ message. Deregistration Status: 32-bit integer Deregistration Status parameter indicates the success or the reason for failure of the deregistration.3.9.22. 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 = 0x0016 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Registration Status: 32-bits (unsigned integer) The Registration 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 Destination Address 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 Mode Type
11 Error - Routing Key Change Refused
3.9.23. Deregistration 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 = 0x0017 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
3.9.24. Local Routing Key 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 = 0x0018 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Routing Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Local Routing Key Identifier field is a 32-bits unsigned integer.
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
message is received.
3.10. SUA-Specific parameters
These TLV parameters are specific to the SUA protocol. Parameter Name Parameter ID ============== ============ SS7 Hop Counter 0x0101 Source Address 0x0102 Destination Address 0x0103 Source Reference Number 0x0104 Destination Reference Number 0x0105 SCCP Cause 0x0106 Sequence Number 0x0107 Receive Sequence Number 0x0108 ASP Capabilities 0x0109 Credit 0x010A Data 0x010B User/Cause 0x010C Network Appearance 0x010D Routing Key 0x010E DRN Label 0x010F TID Label 0x0110 Address Range 0x0111 SMI 0x0112 Importance 0x0113 Message Priority 0x0114 Protocol Class 0x0115 Sequence Control 0x0116 Segmentation 0x0117 Congestion Level 0x0118 Destination/Source Address Sub-Parameters =========================================== Global Title 0x8001 Point Code 0x8002 Subsystem Number 0x8003 IPv4 Address 0x8004 Hostname 0x8005 IPv6 Addresses 0x8006
3.10.1. SS7 Hop counter
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 = 0x0101 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SS7 Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SS7 Hop Counter (3.18/Q.713) The value of the SS7 Hop Counter is decremented with each global title translation and is in the range 15 to 1.3.10.2. Source Address
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 = 0x0102 | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Indicator | Address Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Address parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following combinations of address parameters are valid: - Global Title (e.g., E.164 number) + optional PC and/or SSN, SSN may be zero, when routing is done on Global Title - SSN (non-zero) + optional PC and/or Global Title, when routing is done on PC + SSN. The PC is mandatory in the source address when sending from SGP to ASP, and in the destination address when sending from ASP to SGP to reach the SS7 SEP. - Hostname + optional SSN, when routing is done by Hostname - SSN (non-zero) and optional IP address (IPv4 or IPv6) when routing is done on IP address + SSN
3.10.2.1. Routing Indicator
The following values are valid for the routing indicator: Reserved 0 Route on Global Title 1 Route on SSN + PC 2 Route on Hostname 3 Route on SSN + IP Address 4 The routing indicator determines which address parameters need to be present in the address parameters field.3.10.2.2. Address Indicator
This parameter is needed for interworking with SS7 networks. The address indicator specifies what address parameters are actually received in the SCCP address from the SS7 network, or are to be populated in the SCCP address when the message is sent into the SS7 network. The value of the routing indicator needs to be taken into account. It is used in the ASP to SG direction. For example, the PC parameter is present in the destination address of the CLDT sent from ASP->SG, but bit 2 is set to "0" meaning "do not populate this in the SCCP called party address". The effect is that the SG only uses the PC to populate the MTP routing label DPC field, but does not include it in the SCCP called party address. In the SG->ASP direction, the source address PC parameter is present (PC of SS7 SEP). However, this may have been populated from the OPC in the received MTP routing label, not from the PC field in the SCCP calling party address. In this case, bit 2 = "0" denotes that. The AI gives further instructions to the SG how and when to populate the SCCP addresses; in the SG->ASP direction, the AI gives information to the ASP as to what was actually present in the received SCCP addresses. The address indicator is coded as follows: Bit 1 is used to indicate inclusion of the SSN 0 Do not include SSN when optional 1 Include SSN Bit 2 is used to indicate inclusion of the PC 0 Do not include PC, regardless of the routing indicator value 1 Include PC
Bit 3 is used to indicate inclusion of the Global Title
0 Do not include GT when optional (routing indicator /= 1)
1 Include GT
The remaining bits are spare and SHOULD be coded zero, and MUST be
ignored by the receiver.
3.10.2.3. Global Title
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 = 0x8001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | GTI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. Digits | Trans. type | Num. Plan | Nature of Add |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Global Title Digits /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Digits:
This is the number of digits contained in the Global Title.
GTI (Global Title Indicator, defined in chapter 3.4.2.3 of Q.713).
0000 Invalid
0001 Nature of Address is taken over. It is implicitly assumed
that the Translation Type = Unknown and Numbering Plan =
E.164 (value 1).
0010 This is most commonly used in North American networks.
The Translation Type implicitly determines Nature of
Address and Numbering Plan. This data can be configured
in the SG. The number of digits is always even and
determined by the SCCP address length.
0011 Numbering Plan and Translation Type are taken over. It is
implicitly assumed that the Nature of Address = Unknown.
0100 This format is used in international networks and most
commonly in networks outside North America. All
information to populate the source address is present in
the SCCP Address.
Translation type:
0 Unknown
1 - 63 International services
64 - 127 Spare
128 - 254 National network specific
255 Reserved
Numbering Plan:
0 unknown
1 ISDN/telephony numbering plan (Recommendations E.163 and
E.164)
2 generic numbering plan
3 data numbering plan (Recommendation X.121)
4 telex numbering plan (Recommendation F.69)
5 maritime mobile numbering plan (Recommendations E.210,
E.211)
6 land mobile numbering plan (Recommendation E.212)
7 ISDN/mobile numbering plan (Recommendation E.214)
8 - 13 spare
14 private network or network-specific numbering plan
15 - 126 spare
127 reserved.
Nature of Address:
0 unknown
1 subscriber number
2 reserved for national use
3 national significant number
4 international number
5 - 255 Spare
Global Title:
Octets contain a number of address signals and possibly filler as
shown:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.|
| sig. | sig. | sig. | sig. | sig. | sig. | sig. | sig. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............. |filler |N addr.| filler |
| |if req | sig. | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All filler bits SHOULD be set to 0.
Address signals to be coded as defined in ITU-T Q.713 Section
3.4.2.3.1.
3.10.2.4. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8002 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See chapter 3.9.18 Affected Point Code for the layout of the Point
Code field.
3.10.2.5. Subsystem 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SSN value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The internationally standardized SSN values are described in chapter
3.4.2.2 of Q.713.
3.10.2.6. IP Addresses
The IP address formats can use different tags. It should be noted that if the source address is in a certain IP version, the destination address should also be in the same IP version. 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 = 0x8004/0x8006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / IPv4 or IPv6 Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The tag value 0x8004 is for an IPv4 address and 0x8006 is for IPv6.3.10.2.7. Hostname
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 = 0x8005 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Name / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Host Name: variable length This field contains a host name in "host name syntax" per RFC 1123 Section 2.1 [1123]. The method for resolving the host name is out of scope for this document. Note: At least one null terminator is included in the Host Name string and must be included in the length.
3.10.3. Destination Address
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 = 0x0103 | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Indicator | Address Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Address Parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of this parameter is identical to the Source Address parameter.3.10.4. Source Reference 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0104 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Reference Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The source reference number is a 4 octet long integer. This is allocated by the source SUA instance.3.10.5. Destination Reference 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0105 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Reference Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The destination reference number is a 4 octet long integer. This is allocated by the destination SUA instance.
3.10.6. SCCP Cause
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 = 0x0106 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Cause Type | Cause Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This parameter bundles the SCCP parameters Release cause, Return cause, Reset cause, Error cause and Refusal cause. Cause Type can have the following values: Return Cause 0x1 Refusal Cause 0x2 Release Cause 0x3 Reset Cause 0x4 Error Cause 0x5 Cause Value contains the specific cause value. Below gives examples for ITU SCCP values. ANSI references can be found in ANSI T1.112.3 Cause value in Correspondence with Reference SUA message SCCP parameter ------------------ ----------------- --------- CLDR Return Cause ITU-T Q.713 Chap 3.12 COREF Refusal Cause ITU-T Q.713 Chap 3.15 RELRE Release Cause ITU-T Q.713 Chap 3.11 RESRE Reset Cause ITU-T Q.713 Chap 3.13 ERR Error Cause ITU-T Q.713 Chap 3.143.10.7. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0107 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Rec Seq Num|M| Sent Seq Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This parameter is used to indicate whether "more" data will follow in subsequent CODT messages, and/or to number each CODT message sequentially for the purpose of flow control. It contains the received as well as the sent sequence number, P(R) and P(S) in Q.713, chapters 3.7 and 3.9.
As such it can also be used to acknowledge the receipt of data
transfers from the peer in case of protocol class 3.
Sent Sequence Number is one octet and is coded as follows:
Bits 2-8 are used to indicate the Send Sequence Number P(S).
Bit 1 (LSB) of octet 1 is spare.
Received Sequence Number is one octet, and is coded as follows:
Bits 2-8 are used to indicate the Received Sequence Number
P(R).
Bit 1 (LSB) is used for the more data indication, as follows:
0 no more data
1 more data
3.10.8. Receive 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0108 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Rec Seq Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is used exclusively for protocol class 3 in the data
acknowledgement message to indicate the lower edge of the receiving
window. See Q.713, chapter 3.9.
It is a 1 octet long integer coded as follows:
Bits 8-2 are used to indicate the Received Sequence Number P(R).
Bit 1 is spare.
3.10.9. ASP Capabilities
This parameter is used so that the ASP can report its capabilities regarding SUA for supporting different protocol classes and interworking scenarios. 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 = 0x0109 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |0 0 0 0|a|b|c|d| Interworking | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags a - Protocol Class 3 b - Protocol Class 2 c - Protocol Class 1 d - Protocol Class 0 It is mandatory to support at least Protocol Class 0. Interworking Values 0x0 indicates no interworking with SS7 Networks. 0x1 indicates IP Signalling Endpoint (ASP), interworking with SS7 networks. 0x2 indicates Signalling Gateway. 0x3 indicates relay node support.3.10.10. Credit
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 = 0x010A | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length of the credit field is one octet. See ITU-T Q.713 Chapter 3.10. The parameter is used for protocol class 3 exclusively.
3.10.11. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x010b | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Data parameter field contains the SS7 SCCP-User application message, for example an INAP/TCAP message.3.10.12. User/Cause
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 = 0x010c | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause | User | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "User" is coded to that SCCP's SI value. There may be several SCCP's at a given point code, each with different SI values, although normally there is only one with SI = 3. Cause may take the following values 0 remote SCCP unavailable, reason unknown; 1 remote SCCP unequipped; 2 remote SCCP inaccessible;
3.10.13. Network Appearance
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 = 0x010D | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Appearance field: 32-bits (unsigned integer) The Network Appearance field identifies the SS7 network context for the Routing Key. The Network Appearance value is of local significance only, coordinated between the SG and ASP. Therefore, in the case where the ASP is connected to more than one SG, the same SS7 Network context may be identified by different Network Appearance values depending upon to which SG the ASP is registering. In the Routing Key, the Network Appearance identifies the SS7 Point Code and Global Title Translation Type format used, and the SCCP and possibly the SCCP-User protocol (type, variant and version) used within the specific SS7 network.3.10.14. Routing 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x010E | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0018 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Routing Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Key parameter(s) \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Local Routing Key Identifier field: 32-bits (unsigned integer) Key field: variable
The Key field contains the following parameters:
Parameter
Traffic Mode Type Optional
Network Appearance Optional *1
Source Address Optional
Destination Address Optional
Address Range Optional
Note 1: The Network Appearance parameter must be included in the
Routing Key when the ASP is able to register in multiple
SS7 Network contexts.
3.10.15. DRN Label
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 = 0x010F | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start | end | label value |
+---------------+---------------+-------------------------------+
The Start parameter is the start position of label, between 0 (LSB)
and 23 (MSB).
The End parameter is the end position of label, between 0 (LSB) and
23 (MSB).
Label value is a 16-bit integer, which is unique across an AS.
3.10.16. TID Label
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 = 0x0110 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start | end | label value |
+---------------+---------------+-------------------------------+
The Start parameter is the start position of label, between 0 (LSB)
and 31 (MSB).
The End parameter is the end position of label, between 0 (LSB) and
31 (MSB).
Label value is a 16-bit integer, which is unique across an AS.3.10.17. Address Range
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 = 0x0111 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Address parameter(s) \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address field: The Address field the following parameters: Parameter Source Address Optional *1 Destination Address Optional *1 Note 1: The Address field must contain pairs of Source Addresses or pairs of Destination Addresses but MUST NOT mix Source Addresses with Destination Addresses in the same Address field.3.10.18. SMI
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 = 0x0112 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SMI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subsystem Multiplicity Indicator (SMI) can have the following values: 0x00 Reserved/Unknown 0x01 Solitary 0x02 Duplicated 0x03 Triplicated 0x04 Quadruplicated 0xff Unspecified
3.10.19. Importance
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 = 0x0113 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Importance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Importance (3.19/Q.713) Possible values of the Importance Parameter are between 0 and 7, where the value of 0 indicates the least important and 7 indicates the most important.3.10.20. Message Priority (or Priority)
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 = 0x0114 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Msg Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Priority Priority value ranges from 0 to 3. If the Priority value has not been specified by the SCCP user, it should be set to 0xFF. The SG MAY take the priority into account for determining the MTP message priority. In the all-IP case, this parameter MAY be used. The Message Priority parameter is optional in the CLDT, CLDR, CORE, COAK and CODT messages. However, for networks, which support Message Priority (e.g., ANSI), this parameter MUST be included but it is not required for those which don't (e.g., International).
3.10.21. Protocol Class
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 = 0x0115 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol Cl. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol class (3.6/Q.713) Bits 1-2 indicate the protocol class. Value Description 0 Class 0 (connectionless service) 1 Class 1 (connectionless service) 2 Class 2 (connection-oriented service) 3 Class 3 (connection-oriented service) Bit 8 indicates the use of the return on error procedure. Value Description 0x0 No special options 0x1 Return message on error Bits 3-7 are spare and SHOULD be coded zero, and MUST be ignored by the receiver.3.10.22. Sequence Control
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 = 0x0116 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Control (6.2.2.2.2/Q.711) The field is coded with the value of the sequence control parameter associated with a group of messages and are chosen so as to ensure proper loadsharing of message groups over SLS values while ensuring that sequence control values within message groups have the sequence control value coded with the same value as the initial message of the message group.
3.10.23. Segmentation
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 = 0x0117 | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | first/remain | Segmentation Reference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first/remaining segments field is formatted as follows: bit 8 (MSB): indicates whether this is the first segment (1) or not (0) bits 1-7: indicate the number of remaining segments, value between 0 and 15 The field would thus be coded 1000 0000 (first, no remaining segments) for a unsegmented CLDT. The segmentation reference field is a 3 byte integer, assigned by the ASP.3.10.24. Congestion Level
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 = 0x0118 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Congestion Level field: 8-bits (unsigned integer) The Congestion Level field contains the level at which congestion has occurred. When the Congestion Level parameter is included in a SCON message that corresponds to an N-PCSTATE primitive, the Congestion Level field indicates the MTP congestion level experienced by the local or affected signalling point as indicated by the Affected Point Code(s) also in the SCON message. In this case, valid values for the Congestion Level field are as follows: 0 No Congestion or Undefined 1 Congestion Level 1 2 Congestion Level 2 3 Congestion Level 3
When the Congestion Level parameter is included in a SCON message that corresponds to an N-STATE primitive, the Congestion Level field indicates the SCCP restricted importance level experienced by the local or affected subsystem as indicated by the Affected Point Code and Subsystem Number also in the SCON message. In this case, valid values for the Congestion Level field range from 0 to 7, where 0 indicates the least congested and 7 indicates the most congested subsystem.
(page 92 continued on part 4)