Signaling System No.7 Protocol Architecture And Sevices part 50 doc

The IETF SigTran Working Group was founded after a Birds of a Feather BOF session, which was held at the Chicago 1998 IETF meeting, to discuss transport of telephony signaling over packe

Short Message Service (SMS)

SMS provides paging functionality for alphanumeric messages of up to 160

characters to be exchanged with other GSM users The network itself can also generate messages and broadcast to multiple MSs or to a specific MS For

example, a welcome message can be sent to a subscriber when he or she roams onto a new network; in addition, it can provide useful information, such as how to retrieve voicemail The SMS service also transfers ring tones and logos to the MS

The SMS slightly blurs the image of the user traffic being separate from signaling because, in a sense, the messages are user traffic; they are for human processing (written and read), rather than for communication between network entities

The SMS does not have subcategories It has the following operations:

• forwardSM

• sendRoutingInfoForSM

• reportSMDeliveryStatus

• readyForSM

• alertServiceCentre

• informServiceCentre

The following sections examine each of these

forwardSM

Both the mobile originating (MO-SMS) and mobile terminating SMS (MT-SMS) procedures use the forwardSM operation to carry text messages between the MSC where the subscriber roams and the SMS-IWMSC or the SMS-GMSC,

respectively Figure 13-8 shows the MO-SMS procedure

Figure 13-8 MAP Operations Involved in Sending an SMS from MS to the

SMS-SC

In Appendix L, Example L-6 contains a trace that shows the decode of a MAP

operation forwardSM, including its SMS text

sendRoutingInfoForSM

The SMS-GMSC uses this message during an MT-SMS to deliver an SMS to the MSC in whose area the subscriber is currently roaming The message contains the subscriber's MSISDN, and the result contains the destination MSC's ISDN number SCCP then uses this ISDN number to deliver the SMS using a forwardSM

message Figure 13-9 shows the MT-SMS procedure

Figure 13-9 MAP Operations Involved in Sending an SMS from the SMS-SC to

the MS [View full size image]

In Appendix L, Example L-2 shows a trace showing a VLR's decode calling an HLR (to perform a location update)

reportSMDeliveryStatus

If the SMS-SC cannot deliver the MT-SMS to the MS (because the subscriber is not reachable, for example), then the SC returns a negative result to the SMS-GMSC Upon receiving this result, the SMS-GMSC sends a

reportSMDeliveryStatus to the HLR, which, in turn, sets a message waiting flag in the appropriate subscriber data The HLR also sends an alertServiceCentre

message to the SMS-IWMSC to inform it about the negative SM delivery and waits until the subscriber can be reached When the VLR (also aware of SM

delivery failure) detects that the subscriber is again reachable, it sends a readforSM message to the HLR The HLR, in turn, sends an alertServiceCentre message to the SMS-IWMSC, which informs the SMS-SC The delivery process then begins again with a forwardSM message

NOTE

The previous section also pertains to the readyForSM and alertServiceCentre

informServiceCentre

If a sendRoutingInfoForSM is received for a subscriber that is currently

unavailable, the HLR sends this message to the SMS-GMSC

< Day Day Up >

< Day Day Up >

Summary

MAP primary use is to allow calls to be delivered to mobile subscribers Unlike with fixed-line networks, the subscriber's location cannot be determined from the numbering scheme that is used in the network Therefore, the subscriber's location must be known in real-time so a call can be connected to the nearest switch to the mobile subscriber MAP keeps track of a mobile subscriber and provides other functionality, including allowing mobile subscribers to send alphanumeric two-way text between handsets; this is known as SMS MAP also provides mobile operator's with the functionality to manage a subscriber's subscription so that services can be added and removed in real-time

< Day Day Up >

< Day Day Up >

Chapter 14 SS7 in the Converged World

The "Converged World" of Next Generation Networks (NGNs) brings with it the promise of voice, video, and data over a single broadband network This transition from the traditional circuit-switched networks to packet-switched networks has been underway for many years, and Voice over IP (VoIP) is now leading the transition The immediate benefits of NGNs are decreased cost of infrastructure and improved ease of management Longer-term benefits include the ability to rapidly deploy new services

This chapter introduces the next generation architecture and presents a detailed discussion of the Signaling Transport (SigTran) protocols between the Media Gateway Controller (MGC) and the Signaling Gateway (SG) It also discusses the Transport Adaptation Layer Interface (TALI) and briefly covers an early Cisco SS7 over IP solution Finally, it looks at the role of SS7 in decentralized VoIP

signaling protocols such as Session Initiation Protocol (SIP) [124] and H.323 [125]

< Day Day Up >

< Day Day Up >

Next Generation Architecture

One NGN architecture for VoIP with centralized call processing decomposes the functional elements of a traditional circuit switch into specialized components with open interfaces Following are the key logical elements of this reconstruction are the following:

• The MG handles the media, or bearer, interface It converts media from the format used in one network to the format required in another network For example, it can terminate the TDM trunks from the PSTN, packetize and optionally compress the audio signals, and then deliver the packets to the IP network using the Real Time Protocol (RTP) [120]

• The MGC (also known as a Call Agent) contains the call processing In addition, it manages the resources of the MGs that it controls The MGC controls the MG using a control protocol to set up the RTP connections and control the analog or TDM endpoint in the MG

• The SG sits at the edge of an IP network and terminates circuit-switched network signaling, such as SS7 or ISDN, from the circuit-switched network

It transports, or backhauls, this signaling to the MGC or other IP-based application endpoint

Figure 14-1 shows an example of these logical elements and their connections

Figure 14-1 NGNs—Sample Architecture

[View full size image]

As Figure 14-1 shows, the evolution of specialized components provided open interfaces between these logical elements The Internet Engineering Task Forces (IETF) created two working groups to address these open interfaces at the same time that ITU-T SG16 began to study the MGC to MG interface Thus, the

definition of the bearer control protocol between the MG and the MGC became a joint effort by the IETF MeGaCo (MGC) Working Group and the ITU-T SG16 The output from these groups is known as the Megaco [RFC 3015] [121] protocol

in the IETF, and the H.248 [122] protocol in the ITU-T

Also worth mentioning is a precursor to Megaco protocol: the Media Gateway

Control Protocol (MGCP) [RFC 3435] [123]

NOTE

MGCP was originally published in RFC 2705, which has now been replaced by RFC 3435

MGCP can also be used as a control protocol between an MGC MGCU (TG) and

an MG While MGCP is defined by an Informational (versus standards track) RFC,

it is commonly used in many products today because the specification was

available before Megaco and H.248 were finished Both MGCP and Megaco/H.248 assume that the call control intelligence is outside the MGs and that the MGC handles it

Closely related to the MGCP protocol are the PacketCable protocols, Network-Based Call Signaling (NCS) and PSTN Gateway Call Signaling Protocol (TGCP) These protocols provide functionality similar to MGCP for cable-based networks

The IETF SigTran Working Group focused on the SG to MGC open interface The Working Group produced a set of standard protocols to address the needs and requirements of this interface

< Day Day Up >

< Day Day Up >

SigTran

There has been interest in interworking SS7 and IP for quite some time However, the initial solutions were proprietary This began to change in the late 1990s, when

an effort to standardize Switched Circuit Network (SCN) signaling (SS7) over IP transport began in the IETF

The IETF SigTran Working Group was founded after a Birds of a Feather (BOF) session, which was held at the Chicago 1998 IETF meeting, to discuss transport of telephony signaling over packet networks The result of the BOF was the creation

of the SigTran Working Group to do the following:

• Define architectural and performance requirements for transporting SCN signaling over IP

• Evaluate existing transport protocols, and, if necessary, define a new

transport protocol to meet the needs and requirements of transporting SCN signaling

• Define methods of encapsulating the various SCN signaling protocols The SigTran Working Group first met at the Orlando 1998 IETF meeting

The SigTran Working Group defined the framework architecture and performance requirements in RFC 2719 [126] The framework included the concept of

reconstructing the traditional circuit switch into MGC, MG, and SG elements, thereby separating the signaling and the media control plane

The framework document identified three necessary components for the SigTran protocol stack:

• A set of adaptation layers that support the primitives of SCN telephony signaling protocols

• A common signaling transport protocol that meets the requirements of transporting telephony signaling

• IP [127] network protocol

Figure 14-2 shows the three layers of the protocol stack

Figure 14-2 SigTran Protocol Layers

Further functional requirements were defined for the transport protocol and

adaptation layers The transport had to be independent of the telephony protocol it carried, and, more importantly, had to meet the stringent timing and reliability requirements of that telephony protocol

The Working Group began evaluating the two commonly used transport protocols, User Datagram Protocol (UDP) [128] and Transport Control Protocol (TCP) [129], against these requirements UDP was quickly ruled out because it did not meet the basic requirements for reliable, in-order transport While TCP met the basic

requirements, it was found to have several limitations A team of engineers from Telcordia (formerly Bellcore) completed an analysis of TCP against SS7's

performance and reliability requirements Their analysis was documented in an IETF draft [130], which introduced the following limitations of TCP:

• Head-of-line blocking— Because TCP delivery is strictly sequential, a

single packet loss can cause subsequent packets to also be delayed The analysis showed that a 1% packet loss would cause 9% of the packets being delayed greater than the one-way delay time

• Timer granularity— While this is not a limitation of the TCP protocol, it is a limitation of most implementations of TCP The retransmission timer is often large (typically one second) and is not tunable

The Working Group noted additional TCP limitations, including the following:

• A lack of built-in support for multihoming This support is necessary for meeting reliability requirements, such as five 9s and no single point of

failure

• Also, because of a timer granularity issue and the lack of a built-in heartbeat mechanism, it takes a long time to detect failure (such as a network failure)

in a TCP connection

Because of the deficiencies of UDP and TCP, a new transport protocol, Stream Control Transmission Protocol (SCTP) [131], was developed for transporting SCN signaling Note that SCTP is a generic transport that can be used for other

applications equally well

Stream Control Transmission Protocol (SCTP)

The SigTran Working Group presented several proposals for a new transport

protocol One proposal was Multinetwork Datagram Transmission Protocol

(MDTP), which became the foundation for SCTP RFCNext Generation

Network2960 defines SCTP, which has been updated with RFC 3309 [132] to replace the checksum mechanism with a 32-bit CRC mechanism Further, there is

an SCTP Implementers Guide [133] that contains corrections and clarifications to RFC 2960

SCTP provides the following features:

• Acknowledged error-free, nonduplicated transfer of user data

• Data segmentation to conform to path MTU size (dynamically assigned)

• Ordered (sequential) delivery of user messages on a per "stream" basis

• Option for unordered delivery of user messages

• Network-level fault tolerance through the support of multihoming

• Explicit indications of application protocol in the user message

• Congestion avoidance behavior, similar to TCP

• Bundling and fragmenting of user data

• Protection against blind denial of service and blind masquerade attacks

• Graceful termination of association

• Heartbeat mechanism, which provides continuous monitoring of reachability

SCTP is a connection-oriented protocol Each end of the connection is a SCTP endpoint An endpoint is defined by the SCTP transport address, which consists of one or more IP addresses and an SCTP port The two endpoints pass state

information in an initialization procedure to create an SCTP association After the association has been created, user data can be passed Figure 14-3 provides an example of two SCTP endpoints in an association

Figure 14-3 SCTP Endpoints in an Association

In Figure 14-3, Host A has endpoint [10.82.82.4, 10.82.83.4 : 2905] and Host B has endpoint [10.82.82.24, 10.82.83.24 : 2905] The association is the combination

of the two endpoints

The following sections discuss how SCTP addresses the deficiencies of TCP that are related to meeting the requirements for delivering telephony signaling over IP For additional details about the internals of SCTP, the Stream Control

Transmission Protocol, A Reference Guide, by Randall Stewart and Qiaobing Xie,

is a good resource

Head-of-Line Blocking

SCTP uses streams as a means of decreasing the impact of head-of-line blocking

In SCTP, a stream is a unidirectional channel within an association Streams

provide the ability to send separate sequences of ordered messages that are

independent of one another

Figure 14-4 provides an example of head-of-line blocking with TCP When packet

2 is dropped, packets 3 to 5 cannot be delivered to the application because TCP provides in-order delivery

Figure 14-4 Example of Head-of-Line Blocking in TCP

SCTP provides the ability to have multiple streams within an association Each stream provides reliable delivery of ordered messages that are independent of other streams Figure 14-5 shows an example of how SCTP can help resolve head-of-line blocking In this example, packet 2 is dropped again However, because packets 3,

4, and 5 belong to a different stream, they can be delivered to the application

without delay

Figure 14-5 Use of Streams in SCTP to Avoid Head-of-Line Blocking

Failure Detection

Quick failure detection and recovery is important for meeting the performance and