Signaling System No. 7 (SS7/C7) - Protocol, Architecture and Services (Full Book)
|< Top Index >|
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:
The SigTran Working Group has defined several UA layers, which include the following:
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  UA and V5.2 V52UA  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 :
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.
Figure 14-8. UA Terminology Example
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.
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 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:
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.
Figure 14-9. Routing Key Example
The SGs in this diagram are labeled ITP. The ITP, or IP Transfer Point, is a Cisco SG product offering. For more information, please refer to the following Web site:
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.
Figure 14-10. Interface Identifier Example
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.
|< Top Index >|
Copyright © Cisco, Inc. Published By Cisco Press. No part of this book maybe reproduced or transmitted in any form or by any means, electronic or mechanical, including photcopying or recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review.
Written permission was obtained by Lee Dryburgh to place the book at the domain SS7-Training.net