In effect, it duplicates SCCP's services by providing support for the reliable transfer of SCCP user messages, including support for both connectionless Class 0 and 1 and connection-orie
Trang 1SCCP User Adaptation (SUA)
SUA provides for the transport of SCCP user signaling (TCAP and RANAP) over
IP using SCTP In effect, it duplicates SCCP's services by providing support for the reliable transfer of SCCP user messages, including support for both connectionless (Class 0 and 1) and connection-oriented (Class 2 and 3) services SUA also
provides SCCP management services to manage the status of remote destinations and SCCP subsystems In addition, in some configurations, SUA also provides address mapping and routing functionality SUA is currently defined by an Internet Draft (ID) [139] and is in the process of becoming an RFC
SUA can be used between an SG and an IP-based SEP or between two IP
Signaling Points (IPSP) Figure 14-16 shows an example of SUA transporting signaling information between an SG and an IP-based SEP SUAP refers to any SCCP user, such as MAP over TCAP
Figure 14-16 Use of SUA Between a SG and an IP-Based SEP
With SUA, an SG can act as an endpoint or a relay node For the endpoint
configuration, the point code and SSN of the SCCP user on the IP-based SEP are considered to be on the SG Therefore, from the SS7 point of view, the SCCP user
on the IP-based Signaling Point is on the SG When the SG receives an incoming message from the SS7 network, it might have to perform Global Title Translation (GTT) on the message to determine its destination
When the SG acts as a relay node, the SG must perform an address translation before it can determine the destination of incoming messages This translation can
be modeled on an SCCP GTT or based on hostname, IP address, or other
information in the Called Party Address (CdPA) Thus, the determination of the IP-based SEP is IP-based on the global title or other CdPA information in the SUA
message A hop counter is used to avoid looping (refer to Chapter 9, "Signaling Connection Control Part (SCCP)," for more information)
The SUA layer on the ASP must also make decisions about the distribution of outgoing messages To make this decision, the SUA layer considers the following information:
Trang 2• Provisioning information
• Information in the outgoing message (such as destination and SCCP
subsystem)
• Availability of SGP
• Source local reference or sequence parameter
• Other, such as Routing Context information
The ASP sends responses to the SGP from which it received the message
The SUA layer at the SGP and ASP must maintain the state of each SCTP
association SUA uses a client-server model with the ASP defaulting to the client and SG as the server However, both SG and ASP should be able to be provisioned
as the client or server The client side of the relationship is responsible for
establishing the association
Several inbound and outbound streams are negotiated during the association
establishment The assignment of data traffic to streams depends on the protocol class There is no restriction on Class 0 traffic For Class 1 traffic, SUA must
ensure ordered delivery by basing the stream selection on the sequence number The source local reference is used to select the stream number for Classes 2 and 3
SUA has an IANA registered port number of 14001 It also has an IANA registered SCTP payload protocol identifier value of 4
Messages and Formats
The common message header and TLV format for parameters, defined previously for M3UA, apply equally for SUA
Table 14-2 lists the message classes and message types for SUA
Table 14-2 SUA Message Classes and Types
Msg Class
Value Message Class and Type Names
Msg Type Value
Trang 32 SS7 Signaling Network Management (SSNM)
messages
Destination Available (DAVA) 2 Destination State Audit (DAUD) 3 Signaling Congestion (SCON) 4 Destination User Part Unavailable (DUPU) 5
3 ASP State Maintenance (ASPSM) messages
Heartbeat 3
4 ASP Traffic Maintenance (ASPTM) messages
Connectionless Data Transfer (CLDT) 1
Connectionless Data Response (CLDR) 2
Trang 4Connection Acknowledge (COAK) 2 Connection Refused (COREF) 3
Connection-oriented Data Transfer (CODT) 8 Connection-oriented Data Acknowledge
(CODA)
9
Connection-oriented Error (COERR) 10
9 Routing Key Management (RKM) messages
Connectionless Messages
The Connectionless messages are used for protocol Class 0 and Class 1 traffic There are two connectionless messages: CLDT and CLDR
The Connectionless Data Transfer message corresponds to the SCCP unitdata (UDT), extended unitdata (XUDT), and long unitdata (LUDT) messages It is used
to transfer data between SUA peers for Class 0 and Class 1 traffic
The Connectionless Data Response message corresponds to the SCCP unitdata service (UDTS), extended unitdata service (XUDTS), and long unitdata service (LUDTS) messages It is sent in response to the CLDT, to report errors in the CLDT message if the return option was set
Trang 5Connection-Oriented Messages
The Connection-oriented messages are used for protocol Class 2 and Class 3
traffic
• Connection Request (CORE)— The Connection Request is used to request that a connection be established between two endpoints This message
corresponds to the SCCP Connection Request (CR) message
• Connection Acknowledgement (COAK)— The Connection
Acknowledgement is used to send a positive acknowledgement to the
Connection Request This message corresponds to the SCCP Connection Confirm (CC) message
• Connection Refusal (COREF)— The Connection Refusal is used to refuse a Connection Request This message corresponds to the SCCP Connection Refusal (CREF) message
• Connection-oriented Data Transfer (CODT)— The Connection-oriented Data Transfer message is used to send data messages on an established
connection It corresponds to the SCCP Data Form 1 (DT1), Data Form 2 (DT2), and Expedited Data (ED) messages
• Connection-oriented Data Acknowledge (CODA)— The peer endpoint uses the Connection-oriented Data Acknowledge message to acknowledge receipt
of the data It is only used for protocol Class 3 messages It corresponds to the SCCP Data Acknowledgement (AK) message
• Release Request (RELRE)— The Release Request message is used to
request the release of an established connection This message corresponds
to the SCCP Connection Released (RLSD) message
• Release Complete (RELCO)— The Release Complete message is used to acknowledge the release of an established connection All resources that are associated with the connection should be freed This message corresponds to the SCCP Release Complete (RLC) message
• Reset Request (RESRE)— The Reset Request message is used to request the source and destination sequence numbers that are associated with the
established connection being reinitialized This message corresponds to the SCCP Reset Request (RSR) message
• Connection-oriented Error (COERR)— The Connection-oriented Error message is used to indicate that there was an error in a protocol data unit This message corresponds to the SCCP Protocol Data Unit Error (ERR) message
• Connection-oriented Inactivity Test (COIT)— The Connection-oriented Inactivity Test message is used to acknowledge the release of an established
Trang 6connection All resources that are associated with the connection should be freed This message corresponds to the SCCP Inactivity Test (IT) message MGMT Messages
SUA supports the same MGMT messages as M3UA but also provides SCCP
subsystem state information The DUNA, DAVA, DRST, SCON, and DAUD messages can optionally contain the SubSystem Number (SSN) In addition, the DUNA, DAVA, DRST, and SCON messages can optionally contain the Subsystem Multiplicity Indicator (SMI) parameter
ASPSM and ASPTM Messages
For more information about ASPSM and ASPTM messages, see the description in section, "MTP Level 3 User Adaptation (M3UA)."
RKM Messages
SUA supports the same RKM messages as M3UA, but the Routing Key parameter
is different in that it contains options for source and destination address and
address ranges
Message Flow Example
Figure 14-17 shows an example of connectionless and connection-oriented data transfer This diagram assumes that the Application Server is already active
Figure 14-17 SUA Message Flow Example
For the connection-oriented data transfer, the connection must be established first and can be removed when it is no longer needed