User Adaptation (UA) Layers

The User Adaptation (UA) layers encapsulate different SCN signaling protocols for transport over an IP network using SCTP. While each UA layer is unique in terms of the encapsulation because of the differences of the signaling protocols themselves, following are some common features among all UA layers:

• Support for seamless operation of the UA layer peers over an IP network.

• Support for the primitive interface boundary of the SCN lower layer, which the UA layer replaces. For example, M2UA supports the primitive interface boundary that MTP Level 2 supports.

• Support for the management of SCTP associations.

• Support for asynchronous reporting of status changes to layer management.

The SigTran Working Group has defined several UA layers, which include the following:

• The MTP Level 2 User Adaptation (M2UA) layer is defined for the transport of MTP Level 3 messages between a SG and a MGC or IP database.

• The MTP Level 3 User Adaptation (M3UA) layer is defined for the transport of SS7 User Part messages (such as ISUP, SCCP, and TUP) between an SS7 SG and a MGC or other IP Signaling Point (IPSP).

• The SCCP User Adaptation (SUA) layer is defined for the transport of SCCP User Part messages (such as TCAP and RANAP) from an SS7 SG to an IP-based signaling node or database, or between two endpoints in the same IP network.

• The MTP Level 2 Peer Adaptation (M2PA) layer is defined for the transport of MTP Level 3 data messages over SCTP. M2PA effectively replaces MTP Level 2. It provides the ability to create an IP-based SS7 link.

• The ISDN User Adaptation (IUA) layer is defined for the transport of Q.931 between an ISDN SG and a MGC. IUA supports both Primary Rate Access and Basic Rate Access lines.

Each of these adaptation layers will be discussed in detail, with the exception of IUA because it is beyond the scope of this book. Other proposed adaptation layers (such as DPNSS/DASS2 DUA [144] UA and V5.2 V52UA [145] UA) are being worked on in the SigTran Working Group; however, like IUA, those adaptation layers are beyond the scope of an SS7 discussion.

When these adaptation layers were being developed, it became evident that some terminology and functionality were common, with the exception of M2PA. There was an effort to keep the UA documents synchronized with common text for these terms and functional discussions.

UA Common Terminology

The UAs introduce some new terminology that did not exist in the SS7 world. Some of these terms are common across all of the SS7 UAs; therefore, it is worth discussing them before starting with the adaptation layers. Following are the definitions of these terms, provided by RFC 3332 [137]:

• Application Server (AS)— A logical entity that serves a specific Routing Key. An example of an Application Server is a virtual switch element that handles all call processing for a unique range of PSTN trunks, identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a virtual database element, handling all HLR transactions for a particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more unique ASPs, of which one or more is normally actively processing traffic. Note that there is a 1:1 relationship between an AS and a Routing Key.

• Application Server Process (ASP)— A process instance of an Application Server. An ASP serves as an active or backup process of an Application Server (for example, part of a distributed virtual switch or database). Examples of ASPs are processes (or process instances) of MGCs, IP SCPs, or IP HLRs. An ASP contains an SCTP endpoint and can be configured to process signaling traffic within more than one Application Server.

• Signaling Gateway Process (SGP)— A process instance of a SG. It serves as an active, backup, load-sharing, or broadcast process of a SG.

• Signaling Gateway (SG)— An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. An SG appears to the SS7 network as an SS7 Signaling Point. An SG contains a set of one or more unique SG Processes, of which one or more is normally actively processing traffic. Where an SG contains more than one SGP, the SG is a logical entity, and the contained SGPs are assumed to be coordinated into a single management view to the SS7 network and the supported Application Servers.

• IP Server Process (IPSP)— A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a SG node.

Figure 14-8 puts these terms into context. In this diagram, the SG consists of two SGP. Each SGP is a separate hardware platform. The SGPs share a point code. The MGC supports the Application Server, which is a logical entity. For example, the Application Server is commonly provisioned as a point code and service indicator (SI) for M3UA. For more information, see the Application Servers section.

Finally, the ASP runs on the MGC platform that handles the UA protocol stack. In this diagram, the MGC consists of two hosts, each of which has an ASP. Therefore, the AS consists of ASP1 and ASP2. Depending on the MGC redundancy model (Active-Standby, Load Share, or Broadcast), one or more of the ASPs are Active (or able to send and receive user data) for the AS at any given time.

In addition to the common terminology, the text related to how the SG and SGPs manage the AS and ASP states is common in all of the UA layers (again, with the exception of M2PA).

Routing Keys and Interface Identifiers

The SG must be capable of distributing incoming SS7 data messages to the appropriate Application Server. For M3UA and SUA, the SG performs this routing based on statically or dynamically defined Routing Keys. From RFC 3332, a Routing Key is defined as:

A Routing Key describes a set of SS7 parameters and parameter values that uniquely define the range of signaling traffic to be handled by a particular Application Server. Parameters within the Routing Key cannot extend across more than a single Signaling Point Management Cluster.

The Routing Key has a one-to-one relationship with an Application Server. Further, it is uniquely identified by a 32-bit value, called a Routing Context.

The Routing Key is used to distribute messages from the SS7 network to a specific Application Server. According to SigTran, this key can be any combination of the following SS7 routing information:

• Network Indicator (NI)

• Service Indicator (SI)

• Destination Point Code (DPC)

• Originating Point Code (OPC)

• Subsystem number (SSN)

Refer to Chapter 7, "Message Transfer Part 3 (MTP3)," for more information on NI, SI, OPC and DPC. Refer to Chapter 9, "Signaling Connection Control Part (SCCP)," for more information on SSN.

A SG does not have to support all of these parameters.

Figure 14-9 provides an example of how a SG might be provisioned with Routing Key, Routing Context, Application Server, and ASP information. This diagram contains a mated pair of SGs that also act as STPs. Each SG has the same Application Server database. When a SG receives a message, it tries to match that message against its database. In the example, a message arrives for DPC 1.1.1 at SG2. This message matches Application Server CHICAGO, so it is sent to ASP ASP1.

For M2UA and IUA, the SG uses an Interface Identifier value to determine the distribution of incoming messages. The Interface Identifier is unique between the SG and the ASP. Unlike Routing Keys, there can be a many-to-one relationship between Interface Identifiers and Application Servers. In other words, an Application Server can contain more than one Interface Identifiers. Also, Interface Identifiers can be a 32-bit integer value or an ASCII string.

To give meaning to the Interface Identifier, one suggestion is to use the physical slot and port the SG's information to create the 32-bit value or ASCII string. Figure 14-10 provides an example of how Interface Identifiers would be configured on the SG. Note that the MGC must have the same Interface Identifiers provisioned. In this example, AS CANTON contains four Interface Identifiers, with each one mapped to a SS7 link.

Finally, because M2PA is a peer-to-peer arrangement between two IP-based SS7 Signaling Points, there is no need for message distribution or routing. Therefore, there is not a concept of Routing Key or Interface Identifier.