SUA defines a protocol for the transport of any SS7 SCCP user signaling (e.g., TCAP, RANAP, etc.) over IP using SCTP services. The protocol is designed to be modular and symmetric so as to allow it to work in diverse architectures such as an SG–to–IP signaling-endpoint architecture as well as a peer-to-peer IP Signaling Endpoint architecture. SUA supports the following:

• Transfer of SCCP user part messages (TCAP, RANAP, etc.)
• SCCP connectionless service
• SCCP connection oriented service.
• Management of SCTP transports associations between a SG and one or more IP–based signaling nodes
• Distributed IP–based signaling nodes
• Asynchronous reporting of status changes to management

Figure 9. Architecture for Connectionless Transport

ASP—MGC, IP SCP or IP HLR

In this architecture, the SCCP and SUA layers interface in the SG. Their needs to be interworking between the SCCP and SUA layers to provide the seamless transfer of the user and management messages. For messages destined for an ASP, there are two scenarios:

• SG as Endpoint

In this case, the connectionless SCCP messages are routed on point code and SSN. The subsystem identified by SSN and SS7 network appearance is regarded as local to the SG. This means that from the SS7 point of view, the SCCP user is located at the SG.

• SG as relay point

A GTT must be executed at the SG before the destination of the message can be determined. The actual location of the SCCP user is irrelevant to the SS7 network. GTT yields an "SCCP entity set," which now may contain one or more ASs (refer to Chapter 17). Selection of the AS is thus based on the SCCP called-party address.

All-IP Architecture

This architecture can be used to carry a protocol that uses the transport services of SCCP but is contained within an all–IP network. This allows extra flexibility in developing networks, especially when interacting between legacy signaling is not needed. Figure 10 describe this case:

Figure 10.