Signaling System No.7 Protocol Architecture And Sevices part 50

Chia sẻ: Dasdsadqwe Dsadasdsadsa | Ngày: | Loại File: PDF | Số trang:13

Thêm vào BST

Báo xấu

62
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Signaling System No.7 Protocol Architecture And Sevices part 50

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 SMS-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
reliability requirements that are specified for transporting SCN signaling. For a multihomed host, two types of failures can occur: • One or more destination addresses in the peer endpoint become unavailable or unreachable. • The peer endpoint becomes unavailable or unreachable. A destination address can become unreachable for one of several reasons. First, there could be a failure in the network path to the destination address, or a failure in the Network Interface Card (NIC) that supports the destination address. Likewise, a peer endpoint can become unavailable for several reasons. By definition, the peer endpoint is unavailable or unreachable if all of its destination addresses are unavailable or unreachable. SCTP provides two mechanisms for detecting failures: 1. Use of the Path.Max.Retrans threshold, which is the maximum number of consecutive retransmission that are allowed for a path. 2. Use of the heartbeat mechanism. When an endpoint sends a data message to a particular destination address, an acknowledgement is expected in return. If the acknowledgement has not been received when the retransmission timer expires, SCTP increases an error counter for that destination address and then retransmits the data message to the same destination or to another destination address, if one is available. The destination address is considered unreachable if the error counter reaches a defined threshold (Path.Max.Retrans). The other mechanism for detecting failures is a heartbeat mechanism. This mechanism is useful for monitoring idle destination addresses, such as a destination address that has not received a data within the heartbeat period. The heartbeat is sent periodically, based on a configured heartbeat timer. If a heartbeat response is not received, the same error counter is increased. Again, when the error counter reaches a defined threshold (Path.Max.Retrans), the destination address is considered unavailable or unreachable. To determine the availability of the peer endpoint, an error counter is kept for the peer endpoint. This error counter represents the number of consecutive times the retransmission timer has expired. It is also increased each time a heartbeat is not acknowledged. When this error counter reaches a defined threshold (Association.Max.Retrans), the peer endpoint is considered unavailable or
unreachable. SCTP enables faster failure detection by encouraging implementations to support tunable parameters. As noted, TCP is limited in this respect because most implementations do not allow the application to tune key TCP parameters. SCTP encourages an implementation to support tunable parameters through the definition of the upper-layer interface to the application. In RFC 2960, Section 10 contains an example that describes the upper-layer interface definition. One function in this definition, SETPROTOCOLPARAMETERS(), provides a means setoff-setting parameters such as minRTO, maxRTO, and maxPathRetrans. More importantly, the SCTP sockets Application Programmer Interface (API) [134] defines a socket option (SCTP_RTOINFO) for setting key parameters. Multihoming and Failure Recovery Multihoming provides a means for path level redundancy. This feature enables SCTP endpoints to support multiple transport addresses. Each transport address is equivalent to a different path for sending and receiving data through the network. Figure 14-6 shows an example of multihoming. Figure 14-6. Multihoming Support in SCTP In the case of multihoming, one network path is selected as the primary path. Data is transmitted on the primary path while that path is available. If a packet gets dropped—for instance, because of a failure in the path—the retransmission should be sent on the alternate path. Figure 14-7 provides an example based on the diagram in Figure 14-6, with the primary path between IP1 and IP3 (the 10.82.82.x network) and the alternate path between IP2 and IP4 (the 10.82.83.x network). In this example, the packet with Transmission Sequence Number (TSN) 1 is retransmitted on the alternate path. Figure 14-7. Failure Recovery Example
Retransmitting on the alternate path decreases failure recovery time. Further, if the primary path fails, the alternate path is automatically selected as the primary path. The path failure recovery mechanism is completely transparent to the application that uses SCTP. Proposed Additions The IETF Transport Working Group proposes two promising additions to the SCTP protocol: • Dynamic Address Reconfiguration [135] • Partial Reliability [136] The first proposal is to allow for IP address information reconfiguration on an existing association. This feature can be useful for hardware that provides for hot swap of an Ethernet card, for example. A new Ethernet card could be added and the Ethernet card's IP address could then be added to the association without requiring system downtime. The second proposal allows for partially reliable transport on a per message basis. In other words, the application can determine how a message should be treated if it needs to be retransmitted. For instance, the application can decide that a message is stale and no longer useful if it has not been delivered for two seconds. SCTP then moves past that message and stops retransmitting it.