SCCP 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 p rovides 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 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: • 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. M essa g es 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 0 Management (MGMT) messages Error message 0 Notify message 1 2 SS7 Signaling Network Management (SSNM) messages Destination Unavailable (DUNA) 1 Destination Available (DAVA) 2 Destination State Audit (DAUD) 3 Signaling Congestion (SCON) 4 Destination User Part Unavailable (DUPU) 5 Destination Restricted 6 3 ASP State Maintenance (ASPSM) messages ASP Up 1 ASP Down 2 Heartbeat 3 ASP Up Acknowledge 4 ASP Down Acknowledge 5 Heartbeat Acknowledge 6 4 ASP Traffic Maintenance (ASPTM) messages ASP Active 1 ASP Inactive 2 ASP Active Acknowledge 3 ASP Inactive Acknowledge 4 7 Connectionless (CL) Messages Connectionless Data Transfer (CLDT) 1 Connectionless Data Response (CLDR) 2 8 Connection-oriented (CO) messages Connection Request (CORE) 1 Connection Acknowledge (COAK) 2 Connection Refused (COREF) 3 Release Request (RELRE) 4 Release Complete (RELCO) 5 Reset Confirm (RESCO) 6 Reset Request (RESRE) 7 Connection-oriented Data Transfer (CODT) 8 Connection-oriented Data Acknowledge (CODA) 9 Connection-oriented Error (COERR) 10 Inactivity Test (COIT) 11 9 Routing Key Management (RKM) messages Registration Request 1 Registration Response 2 Deregistration Request 3 Deregistration Response 4 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. Connection-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 connection. 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. M essa g e 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. . connectionless (Class 0 and 1) and connection-oriented (Class 2 and 3) services. SUA also p rovides SCCP management services to manage the status of remote destinations and SCCP subsystems. In addition,. 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. M essa g es and Formats The common message header and. 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 0 Management (MGMT) messages Error message 0 Notify