Use of SS7 in D-AMPS-Based PCS: Orthodoxy vs. Heterodoxy

Transcription

1 GLITHO LAYOUT 4/6/98 1:59 PM Page 15 Abstract D-AMPS, the digital version of the Advanced Mobile Phone System (AMPS), is among the key technologies for providing personal communications services (PCS). The bulk of signaling in D-AMPS-based PCS, as in most modern telecommunication systems, is based on Signaling System No. 7 (SS7). SS7 is a general-purpose common channel signaling (CCS) system specified by the International Telecommunication Union Telecommunications Standardization Sector (ITU-T) and adapted to North American needs by the American National Standard Institute (ANSI). Besides the orthodox use for signaling, SS7 is used in D-AMPS-based PCS for operation, administration, maintenance, and provisioning (OAM&P) of the D-AMPS-based PCS network and for short message service (SMS). This article reviews the use of SS7 in D-AMPS-based PCS. It motivates the need for a gradual return to orthodoxy where this use is confined to signaling. It also proposes alternatives to the current heterodox use. The alternatives the authors suggest are all rooted in orthodoxy. Use of SS7 in D-AMPS-Based PCS: Orthodoxy vs. Heterodoxy Roch H. Glitho, Ericsson Research D-AMPS, the digital version of the Advanced Mobile Phone System (AMPS), is among the key technologies for providing personal communications services (PCS). PCS will ultimately enable communication with a person anytime, anyplace, and in any form. Its key features have been described in recent publications [1 3]. D-AMPS has been specified by the Electronic Industry Association (EIA) in cooperation with the Telecommunication Industry Association (TIA). A simplified version of its reference model is depicted in Fig. 1. The functional entities shown in the figure can be implemented in a variety of physical configurations because more than one entity can be located in a node. When not collocated, these entities communicate via well-defined and standardized interfaces. Um, B, C, D, E, M, and N are the interfaces standardized so far. Signaling at these interfaces, except the air interface (Um), is based on Signaling System No. 7 (SS7). SS7 is a general-purpose common channel signaling (CCS) system specified by the International Telecommunication Union Telecommunications Standardization Sector (ITU- T) and adapted to North American needs by the American National Standards Institute (ANSI). It is made of a network services part (NSP) and user parts (UPs). The NSP can be further broken into the message transfer part (MTP) and the signaling connection control part (SCCP). Examples of UPs are the integrated service digital network (ISDN) user part (ISUP) and the mobile application part (MAP); for an overview see [4]. The use of SS7 in D-AMPS-based PCS goes beyond signaling, although signaling remains the sole purpose assigned to SS7 in its specifications. Besides its orthodox use for signaling, SS7 is used for the operation, administration, maintenance, and provisioning (OAM&P) of the D-AMPS-based PCS network and also for an alphanumeric messaging service known as short message service (SMS). This article contrasts the orthodox and heterodox uses of SS7 in D-AMPS-based PCS. It also makes a plea for a gradual return to orthodoxy with the use of SS7 confined to signaling. Our plea is motivated by the fact that currently deployed SS7 networks may not have enough capacity to spare for heterodox use. Furthermore, we argue that it does not make economic sense to add capacity to SS7 networks for meeting heterodox requirements. Viable alternatives to the current MS AC BS EIR HLR SME VLR MS Um BS AC SME A H M Figure 1. A simplified version of the D-AMPS-based PCS reference model. EIR HLR Authentication center Base station Equipment identity register Home location register Message center Message switching center Short message entity VIsitor location register Mobile station F C N E D M B VLR

2 GLITHO LAYOUT 4/6/98 1:59 PM Page 16 OMAP MAP Others heterodox use of SS7 are needed. This article makes suggestions. The next section presents the basics of SS7 use in D-AMPS-based PCS. The third and fourth sections review orthodox and heterodox use, respectively. The fifth section elaborates on the reasons a gradual return to orthodoxy, with SS7 use confined to signaling, is needed. It also sketches potential viable alternatives to current heterodox use. The alternatives sketched are actually orthodox solutions to OAM&P and messaging. We show that they bring benefits in the long run. Use of SS7 in D-AMPS-Based PCS: The Basics F igure 2 shows the SS7 protocol architecture as used in D- AMPS-based PCS. SS7 NSP which is made of MTP level 1, MTP level 2, MTP level 3 and SCCP is used as transportation mean for all SS7 messages. It should be noted that X.25 has been specified by EIA/TIA as alternative. However the trend in the industry is towards the use of SS7 NSP. Application Presentation Session Transport Network Data link Physical The operation, maintenance, and administration part (OMAP) is used for the management of the SS7 network itself. It is outside the scope of this article which focuses on how the SS7 traffic protocols are used in D-AMPS based - PCS. As SS7 networks are generally considered distinct from the telecommunications networks on which they are overlaid, the reader should be aware that in this article we consider the D-AMPSbased PCS networks distinct from the overlaid SS7 networks. The messages carried by SS7 NSP, besides the OMAP messages, are generated by an application which is ISUP, a combination of the Transactions Capabilities Application Part (TCAP) and MAP, or a combination of TCAP and other applications such as 800-number translation. ISUP is solely used for communicating with the outside world, or more precisely the Public Switched Telephone Network (PSTN). It is outside the scope of the article because as previously stated, we focus on how SS7 traffic protocols are used inside D- AMPS-based PCS networks. The reader interested in ISUP and the interconnection with the PSTN can consult reference [5]. Reference [6] gives an overview of OMAP. This section introduces successively SS7 NSP, TCAP, and MAP. An Introduction to SS7 NSP M TP and SCCP are specified in [7, 8]. MTP can be further broken down to MTP level 1, MTP level 2, and MTP level 3, as shown in Fig. 2. MTP level 1 corresponds to the physical layer of the open system interconnection (OSI) reference model (RM). It defines the physical, electrical, and functional characteristics of the physical links connecting SS7 components. The recommended bit rate is 56 kb/s. MAP SCCP MTP level 3 MTP level 2 MTP level 1 ISUP OMAP Operation, maintenance, and administration part MAP Mobile application part TCAP Transaction capabilities application part ISUP ISDN user part SCCP Signaling connection control part MTP Message transfer part Figure 2. SS7 protocol architecture as used in D-AMPS-based PCS. MTP level 2 corresponds to the data link layer of the OSI RM. It ensures the reliable transfer of messages known as signaling units (SUs) over the SS7 physical links. It uses a bit-oriented protocol with a strong similarity to the bit-oriented protocols used by OSI layer 2. The combination of MTP level 3 and SCCP corresponds to the network layer of the OSI RM. It ensures the reliable transfer of messages in the SS7 network by providing functions and procedures related to message routing and network management. This combination (or, more precisely, SCCP) also provides functions, such as global title translation (GTT), specific to telephony. SS7 networks are made of signaling points (SPs) and signaling transfer points (STPs). An SP contains a user part (UP) which generates messages; an STP does not. Figure 3 depicts a hypothetical D- AMPS-based PCS network with an overlaid SS7 network. It is used for illustration purposes in the rest of this article. A brief description of its key features follows. The STPs have a quad structure and are mated on a pairwise basis: STP1 and STP2 are mated; STP3 and STP4 are also mated. This provides 100 percent redundancy. If STP1 fails, STP2 will take over, and vice versa. The same applies to STP3 and STP4. An SP is overlaid on every D-AMPS-based PCS node. Every SP of the hypothetical network is connected to an STP pair. The functional entities are the mobile switching center (), home location register (HLR), visitor location register (VLR), and message center (). A, HLR A, VLR A, and A are connected to the pair STP1-STP2. B, HLR B, VLR B, and B are also connected to the pair STP1-STP2. C, HLR C, VLR C, and C, on the other hand, are connected to the pair STP3-STP4. HLR A, VLR A, and A are in the area covered by A; HLR B, VLR B, and B in the area covered by B; and HLR C, VLR C, and C in the area covered by C. An Introduction to TCAP TCAP is a generic UP (i.e., a UP used by other UPs) specified in [9]. It is based on the remote operation service element (ROSE) [10], which is a building block used at the OSI application layer to build request/reply applications. A TCAP message is made up of a component portion and a transaction portion. The Component Portion The component portion contains one or many components. A component is a request to perform an operation or a reply to such a request. It is characterized by a type. The component types currently defined are listed below. Invoke is used to request the performance of an operation. Invoke (Last) same as above. Last indicates that this component is last in the component portion.

3 GLITHO LAYOUT 4/6/98 1:59 PM Page 17 Return result is used to return the result of an invoked operation. Return result (Last) same as above. Last indicates that this component is last in the component portion. Return error is used to report the unsuccessful completion of an operation. Reject is used to report the receipt and rejection of a component that is syntactically incorrect. The Transaction Portion The transaction portion specifies the package type. The package type represents the modality of the transaction. The following package types are currently defined: Query With Permission is used to initiate a transaction, indicating to the receiving node that it may end it. Query Without Permission is used to initiate a transaction, indicating to the receiving node that it may not end it. A HLR A VLR A A B HLR B VLR B B Conversation With Permission is used to continue a transaction, indicating to the receiving node that it may end it. Conversation Without Permission is used to continue a transaction, indicating to the receiving node that it may not end it. Response is used to end a transaction. Unidirectional is used to indicate that no reply is expected. Abort is used to abort a transaction. An Introduction to MAP MAP as used in D-AMPS-based PCS is known as IS-41 [11 16]. It specifies the SS7 messages used in D-AMPS-based PCS and the rules governing their exchanges. The messages are specified as TCAP messages. This implies that for each message, package types and component types are specified. For a message there is usually more than one component type and more than one package type. Query With Permission, Conversation With Permission, Conversation Without Permission, Response, and Unidirectional are the four package types used for the SS7 messages defined by IS-41. Invoke (Last), Return result (Last), Return error, and Reject are the four component types. The following general rules govern the exchange of IS-41 messages between D-AMPS-based PCS nodes: The component portion is limited to a maximum of one component. That is why neither Invoke nor Return result is used. Most of the transactions are limited to the exchange of two messages, first a Query With Permission and second a Response. Unidirectional is seldom used. A timer is specified for the execution of each operation. The course of actions to take when the reply is received is specified for each possible answer Return result (Last), Return error, or reject. The course of action to take when a reply is not received before STP 1 STP 2 STP 3 STP 4 Signaling point (SP) Figure 3. Hypothetical D-AMPS-based PCS network from the SS7 point of view. the expiration of the timer is also specified. SS7 messages are specified by IS-41 to support: Signaling OAM&P of the D-AMPSbased PCS network SMS The next section is devoted to the use of SS7 messages to support signaling, and the section after that presents the use of SS7 to support D-AMPS-based PCS OAM&P and SMS. Use of SS7 in D- AMPS-Based PCS: Orthodoxy S S7 has been specified to be used for both circuit-related and non-circuit-related signaling. In circuit-related signaling, SS7 is used to control the setup and release of traffic circuits. In that case, the information conveyed by the SS7 messages is related to specific traffic circuits and can be identified by circuit numbers. In non-circuit-related signaling, there is no predetermined correlation between the information conveyed by SS7 messages and specific traffic circuits. However, the information remains call-related, although not directly. An example is 800 number translation. There is no correlation between the SS7 message sent to a database to request the translation (or the SS7 message which carries the reply) and any specific traffic circuit. Nevertheless, the information is subsequently used to set up a call. SS7 is used in D-AMPS-based PCS for both circuit related and non circuit related signaling: In the context of call setup/release between the D-AMPS-based PCS and the PSTN, it is used for circuit-related signaling. In the context of intersystem handoff [12] it is used for both circuit-related and non-circuit-related signaling. Signaling transfer point (STP) C HLR C VLR C C Messages Component type Package type HANDOFFMEASUREMENTREQUEST Invoke Last Query With Persmission handoffmeasurementrequest Return Result Last Response HANDOFFTOTHIRD Invoke Last Query With Persmission handofftothird Return Result Last Response FACILITIESDIRECTIVE Invoke Last Query With Permission facilitesdirective Return Result Last Response MOBILEONCHANNEL Invoke Last Unidirectional FACILITIESREALEASE Invoke Last Query With Permission facilitiesrelease Return Result Last Response Table 1. SS7 messages exchanged during a successful handoff to third with path minimization.

4 GLITHO LAYOUT 4/6/98 1:59 PM Page 18 In the context of automatic roaming [13] it is used for non-circuit-related signaling only. In this section we review successively the use of SS7 for intersystem handoff and automatic roaming. Intersystem Handoff Intersystem handoff ensures the continuity of an ongoing call when the mobile station (MS) moves from a base station (BS) served by a given to a BS served by another. We briefly survey the terminology related to intersystem handoff before presenting a concrete scenario. The which controls the BS, which is the first to assign a traffic channel to the ongoing call, is called the anchor. The serving is the that controls the BS which has assigned the traffic channel currently used for the ongoing call. The target is the which controls the BS that has been selected by the serving for a handoff. An is said to be on the call path of an ongoing call if it controls a BS that has assigned a traffic channel to the call since its beginning. Intersystem handoffs in D-AMPS-based PCS can be broadly grouped in two categories: Handoff forward The call is handed to an that is not already on the call path. Handoff back The call is handed to an that is already on the call path. Handoff-to-third with path minimization belongs to the handoff forward category, according to the classification scheme used in this article. We use it in this subsection for illustration purpose. Table 1 shows the SS7 messages used in a successful handoff-to-third with path minimization. The A HANDTHIRDREQUEST FACILITIESDIRECTIVEREQUEST facilitiesdirectiverequest handthirdrequest MOBILEONCHANNEL FACILITIESRELEASEREQUEST facilitiesreleaserequest B HANDOFFMEASUREMENTREQUEST handoffmeasurementrequest Figure 4. Handoff to third with path minimization. Messages Component type Package type REGISTRATIONNOTIFICATION Invoke Last Query With Permission registrationnotification Return Result Last Response QUALIFICATIONREQUREST Invoke Last Query With Permission qualificationrequest Return Result Last Response Table 2. SS7 messages exchanged during a successful registration notification followed by a successful profile transfer. C component and the package type of each message are indicated. FacilitiesDirective and FacilitiesRelease are the two circuit-related messages; all the others are non-circuit-related. Figure 4 shows a sequence diagram, explained as follows. B, the serving, determines, using internal mechanisms, that a handoff is appropriate. It initiates a first transaction by sending a HandoffMeasurementRequest to C, which is selected as a potential candidate for the handoff. The request might also be sent to other s. C answers, providing the data requested. B uses the data to make the selection. It is assumed here that C is selected. It then becomes the target. This ends the first transaction, which has consisted of the exchange of two messages. B determines, once again using internal mechanisms, that path minimization might be possible. The path minimization is done through a direct trunk connection between C, the target, and A, the from which the call was handed to B. It is assumed here that A is the anchor. B then initiates a second transaction by sending a HandThirdRequest to A to request the performance of a handoff with path minimization. A attempts the handoff with path minimization. It initiates a third transaction by sending a Facilities- Directive to C. C runs various internal checks, takes some actions, answers positively to the FacilitiesDirective, and closes the third transaction. A then answers positively to the HandoffToThird previously sent by B, and closes the second transaction. When the MS is received on the designated voice channel, C completes the voice path between the voice channel and the inter- trunk A- C. It then sends a MobileOnChannel to A. This fourth transaction is a one-message transaction with no reply expected. A connects the call path with the inter- trunk A- C to B. It then initiates a fifth transaction by requesting the release of the inter- trunk A- B with the FacilitiesRelease it sends to B. B marks the trunk idle and ends this fifth and last transaction by replying to the FacilitiesRelease. A also marks the trunk idle when it receives the reply from B. This completes the handoff to third with path minimization. Automatic Roaming The HLR and VLR are the functional entities that play the vital role in automatic roaming. Automatic roaming ensures that calls are automatically delivered to MSs wherever they are. This implies that their whereabouts are tracked. Besides tracking MSs whereabouts, automatic roaming includes: Authentication to prevent fraud Service profile transfer to facilitate ubiquitous service offering

5 GLITHO LAYOUT 4/6/98 1:59 PM Page 19 Verification of subscriber credit worthiness To illustrate automatic roaming, we assume in this section that a user whose home area is covered by A powers up his phone in an area covered by B and initiates a call. Table 2 shows the SS7 messages used to keep track of his whereabouts and get his service profile. All these messages are noncircuit-related. The component type and package type are indicated for each message. Figure 5 shows the sequence diagram, which we will now discuss. B detects that a user whose home area is covered by A is now in its serving area (the detection can be done, for instance, when the user powers on his MS). It initiates the first transaction by sending a RegistrationNotification to its VLR, VLR B. Let us assume that VLR B has not yet registered the roamer. Upon reception of the message sent by B, VLR B registers the MS and initiates a second transaction by sending in its turn a RegistrationNotification to the HLR associated with the MS, meaning HLR A. HLR A notes that the MS is now roaming in the area served by B, it sends an acknowledgment to VLR B, and closes the second transaction. VLR B then sends an acknowledgment to B, and closes the first transaction. When B receives a call originating from the MS and realizes that it does not know the MS profile, it initiates a third transaction and sends a QualificationRequest to its VLR, VLR B. If VLR B does not have the profile, it initiates a fourth transaction and sends a QualificationRequest to the MS home HLR, HLR A. HLR A sends back a Qualification- Request to VLR B, including the profile information, and closes the fourth transaction. VLR B then sends in its turn a QualificationRequest to B, including the MS profile information it has received from HLR A, and closes the third transaction. The call can then proceed. Use of SS7 in D-AMPS-Based PCS: Heterodoxy T he key characteristics of the use of SS7 for D-AMPSbased PCS OAM&P and SMS are successively presented in this section. SS7 for D-AMPS-Based PCS OAM&P The use of SS7 for D-AMPS-based PCS OAM&P is specified in [14]. According to the specification, the nodes of the D- AMPS-based PCS network exchange OAM&P messages specified as SS7 messages and transported by the very SS7 NSP which carries the signaling messages. The following messages have been specified so far: Blocking Blocking is used by an to direct another to remove a specific circuit from service. Unblocking Unblocking is used by an to direct another to return to service a circuit that was previously blocked. ResetCircuit ResetCircuit is used by an to direct another to reset a specific circuit to the idle condition. TrunkTest TrunkTest is used by an to redirect another to loop back a specific circuit. TrunkTestDisconnect TrunkTestDisconnect is used by an to direct another to disconnect the loopback of a specific circuit. HLR A REGISTRATIONNOTIFICATION registrationnotification QUALIFICATIONREQUEST qualificationrequest VLR B REGISTRATIONNOTIFICATION registrationnotification QUALIFICATIONREQUEST qualificationrequest B Figure 5. Registration notification followed by a service profile transfer. Messages Component type Package type Trunktest Invoke Last Query With Permission trunktest Return Result Last Response Table 3. SS7 messages exchanged during successful testing of a trunk. UnreliableDataRoamerDirective UnreliableData- RoamerDirective is sent by an HLR to inform its associated serving systems that it has experienced a failure which has made its MS roamer data unreliable. Figure 6 illustrates the testing of a trunk by a sequence diagram. Table 3 shows the message used with the component and package types. A sends a request to B for the testing of the inter- trunk A- B. B accepts the request, carries out the test, and sends the test result to A. SS7-Based SMS The use of SS7 for SMS in D-AMPS-based PCS is specified in [13]. SMS allows users to receive and send alphanumeric messages using SS7 messages which are carried by the very SS7 NSP that carries the signaling messages and the OAM&P messages previously discussed. The submission and the reception of the messages is done through the short message entity (SME). The SME can compose and decompose SMS messages. It can be integrated with the MS, allowing the user to use the same terminal for voice and SMS. An SMS message is a one-shot message, of limited size. Messages Component type Package type SMSDELIVERYPOINTTOPOINT Invoke Last Query With Permission smsdeliverypointtopoint Return Result Last Response SMSREQUEST Invoke last Query With Permission smsrequest Return Result Last Response Table 4. SS7 messages exchanged during the successful delivery of an SMS.

6 GLITHO LAYOUT 4/6/98 1:59 PM Page 20 A No call setup or teardown is needed. However, SMS users can have a dialogue by exchanging sequences of SMS messages. The delivery of the messages can be instantaneous or delayed. Delayed delivery is an example of an SMS supplementary service. SMS message delivery (instantaneous or delayed) is based on recipient availability, and retries can be attempted. An SME is attached to a home system. The home system includes a message center (), besides the and HLR. An is an entity that can store and forward SMS messages. A user equipped with an MSbased SME can roam like any other user. SMS is a point-to-point service; broadcast service and point-to-multipoint services have not yet been standardized. A message sent by an originator can cross many s and STPs on its way to the destination. Figure 7 shows a sequence diagram where an SMS message is successfully sent by an MS based SME to another MS based SME. The MSs are not shown. The sender has A as its home and the receiver B as its home. It is further assumed that the receiver is roaming in the area controlled by C. Table 4 lists the SS7 messages used in the scenario with their component and package types. The sequence diagram is further explained below. An originating-ms-based SME sends a message to its home, A, asking the home to deliver the message to a given MS-based SME, which is currently roaming in the area served by C. The message includes the originator SMS address, the destination SMS address, and the message itself. Upon reception, the sends an acknowledgment back to the MS-based SME. A sends the message to B, the by which the A SMSDELIVERYPOINTOPOINT smsdeliverypointopoint B SMSREQUEST HLR B TRUNKTEST trunktest Figure 6. Trunk testing. SMSREQUEST smsrequest smsrequest SMSDELIVERYPOINTOPOINT smsdeliverypointopoint (Result Last) VLR C B Figure 7. Successful delivery of an SMS message sent by a user with A as home system to a user with B as home system but roaming in the area controlled by C. destination MS-based SME is served, using the SMSDeliveryPointToPoint message. Upon reception, B sends an acknowledgment back to A. It then sends an SMSRequest to HLR B to request the temporary address and status information of the destination MS-based SME, assuming that it does not already have it. HLR B sends an SMSRequest to VLR C to request the temporary address and status information of the destination MS-based SME, assuming that it does not already have it. VLR C sends the same request to C, assuming that it does not already have the information. MS C returns the information to VLR C, which in turn returns it to HLR B, which in turn return it to B. B sends the message to C, using the information it has received from VLRC. C sends the message to the destination MS-based SME, which sends an acknowledgment back. The message is then delivered by C to the receiver over the air interface. C then sends an acknowledgment back to B. Use of SS7 in D-AMPS-Based PCS: A Plea for a Return to Orthodoxy I t is advisable to gradually confine the use of SS7 in D- AMPS-based PCS to signaling. Confining the use of SS7 to signaling implies, among other things, that alternatives are found to the current use for D-AMPS based PCS OAM&P and SMS. This section starts by elaborating on the reasons for which a progressive return to orthodoxy is advisable. Alternatives rooted SMSREQUEST smsrequest C in orthodoxy and which bring benefits in the long run are then proposed. Motivations for a Return to Orthodoxy The current use of SS7 for D-AMPSbased PCS OAM&P is far from appropriate. Very few messages have been specified [14]. It is indubitable that D-AMPS-based PCS networks cannot be properly managed using these standards. It is therefore not surprising that the world of D-AMPSbased PCS OAM&P is still populated by proprietary systems. Actually, the current heterodox use of SS7 for SMS is also inappropriate. This double inappropriateness is rooted in the capacity requirements of the two applications. In order to motivate a return to orthodoxy, we start by examining these requirements and showing that existing SS7 networks may not have enough spare capacity to meet them. We then argue that even if these networks do have spare capacity, this capacity can be put to better use, meaning orthodox use. More generally, we show

7 GLITHO LAYOUT 4/6/98 1:59 PM Page 21 that adding capacity to existing SS7 networks for meeting heterodox capacity requirements does not make economic sense. The Potential Lack of Sufficient Spare Capacity in Deployed SS7 Networks A key (implicit) assumption behind the standardization of heterodox SS7 applications such as SMS in D-AMPS-based PCS is that there is enough spare capacity in deployed SS7 networks to cater to these applications. Another related (implicit) assumption to be dealt with later in this article is that extra capacity can be added to deployed SS7 networks, in a cost-efficient manner, to cater to these heterodox applications in case the assumed spare capacity is not there. The chief assumption mentioned above remains highly hypothetical because very little is known today about the volume of signaling traffic generated by mobile systems in a PCS environment. Very few systematic studies exist [17]. SMS will require more and more capacity as its popularity grows. A more interesting case is D-AMPS-based PCS OAM&P. It can already be shown that many deployed SS7 networks might not have enough spare capacity to meet its requirements. We analyze here the capacity requirements of heterodox SS7 applications using the specific case of D- AMPS-based PCS OAM&P. The industry is well aware of the inadequacy of the heterodox use of SS7 for D_AMPS-based PCS OAM&P, so the Cellular Telecommunications Industry Association (CTIA) has recently produced requirements [18] for the development of proper standards for D-AMPS-based PCS OAM&P. These requirements are used in this article to give a flavor of the capacity requirements. The data to be transported, according to the requirements, includes data for fault, configuration, performance, accounting, and security management. This data needs to be collected from each and every node of the network, often in real time, by a dedicated and centralized node which further processes it. The data to be collected for any of the five management areas previously mentioned is potentially huge. This is illustrated in this article by the specific case of performance management. The goal of performance management is to measure the overall service quality of the D-AMPS-based PCS network in order to detect service deterioration due to faults and planning and provisioning errors. This involves a continuous process of data collection, data including: Measurements of call destinations Examples are counts of attempts, seizure, and answers per call destination, be it a country code, an area code, an exchange code, or any combination of the three. Measurements of radio interface traffic Examples are load on radio channels and counts of calls lost due to handover failure. OS OS Data communication network (DCN) HLR OS VLR OS Operation System DCN Data Communications Network Message center Message switching center HLR Home location register VLR Visitor location register Figure 8. A simplified D-AMPS-based PCS network managed by a TMN. VLR HLR Signaling interface Messaging interface HLR Home location register Message center Message switching center VLR Visitor location register Figure 9. A simplified architecture of a futuristic SMS. Measurements of handover Examples are counts of handovers per call and counts of intra-bs, inter-bs, and inter- handovers. Quality-of-service-related measurements These measurements are made on performance parameters. These parameters are numerous and reflect, for example, the quality of providing a desired level of service for connection establishment, connection retention, and billing integrity. These few examples of measurements sustain the assertion of a potential lack of sufficient spare capacity in deployed SS7 networks, showing that a key assumption behind the standardization of heterodox SS7 applications is certainly not correct in some cases if not most. Very few deployed SS7 networks, if any, indeed have enough spare capacity to cater to the transportation of both OAM&P and SMS data. The High Cost of SS7 Network Engineering The assumed sufficient spare capacity in deployed SS7 networks might not be there, as previously shown. However as this assumption is in fact a network design issue, one might argue, as in the related assumption mentioned above, that if the capacity is not there, it can always be added. We argue that, in the long run, it makes more sense from the economic perspective to use any SS7 spare capacity (existing or newly added) for transporting signaling data, since there are strong indications that the signaling traffic in D-AMPS-based PCS will continue to grow. An example of indication is the wireless intelligent network (WIN) standardization effort, which is now triggering the specification of an important amount of new signaling messages. For background information on WIN, the reader can consult [19]. Another example is the local number portability issue currently being discussed by CTIA. Any spare SS7 capacity is better used to transport these new signaling messages. The key reason behind this is that the reliability requirements on SS7 networks far exceed the reliability requirements for OAM&P and SMS data transportation. This makes the use of SS7 networks for messaging and OAM&P data transportation too pricy, since the more stringent the requirements, the more costly they are to meet. The reliability requirements on SS7 networks are very stringent because they are set by or any Internet server orthodox use, meaning signaling. We illustrate this stringency below by examples taken from the SS7 specifications [7]. The unavailability of a signaling route set (set of possible paths that can be used to send signaling messages from a given source to a given destination) should not exceed a total of 10 min/year. No more than 1 in 10 power 7 messages should be lost due to the failure of MTP. The 56 kb/s signaling data link shall have a long-term bit error

8 GLITHO LAYOUT 4/6/98 1:59 PM Page 22 rate of 10 6 and a medium-term one of Alternatives to Heterodox Use An orthodox alternative to the use of SS7 for D-AMPS-based PCS OAM&P and an orthodox alternative to the SS7-based SMS are successively presented in this subsection. TMN-Based OAM&P of D-AMPS-Based Networks Orthodoxy today in telecommunications network OAM&P consists of using telecommunications management network (TMN) principles [20]. For an overview of the principles [21] can be consulted. TMN aims at universal applicability, meaning applicability across SMTP: TCP: IP: telecommunication technologies. It is made of a generic part and technology specific parts. Its principles can be summarized as follows. A telecommunication network is managed by a separate network which is actually the TMN. Managed network and managing network communicate via well-defined standardized interfaces. The flagship interface of TMN is the interface which connects network elements (NEs) to operation systems (OSs), OSs being supervisory and control nodes. The protocols to be used at the interface are specified in ITU-T Recommendations Q.811 and Q.812 [22, 23]. The TMN has a functional, physical, and information architecture. It also has a layered architecture which allows the partitioning of an OS functionality into the following four layers: element management layer (EML), network management layer (NML), service management layer, and business management layer. The nodes of the TMN and those of the managed network exchange messages using a data communication network (DCN). The current trend in the industry is the use of dedicated X.25 networks, because the X.25 protocols are part of the lower-layer protocols for the interface as specified in Recommendation Q.811 [22]. It should be stressed that although SS7 NSP is included in Q.811 [22], dedicated SS7 networks will probably never be used in practice as TMN DCNs because of their higher engineering costs. Figure 8 depicts a simplified D-AMPS-based PCS network managed by a TMN. A TMN-based approach to OAM&P is certainly adequate for meeting the CTIA requirements for proper OAM&P of D-AMPS-based PCS. Since the primary goal of the DCN is to carry OAM&P messages, it can be designed with enough capacity to meet the D-AMPS-based PCS OAM&P requirements. Furthermore the spare capacity in this DCN, preferably an X.25 network due to the trend in the industry, can be used to carry SMS messages, as shown later in this article. Many factors make the TMN-based OAM&P approach attractive. Among these factors, the possibility of using the same set of principles, the TMN principles, for managing networks such as the signaling network and the transmission networks which are overlaid on the D-AMPS-based PCS network is worth mentioning. It is therefore not surprising that TIA/EIA has recently adopted the TMN approach for developing OAM&P standards for D-AMPS-based PCS [24]. SMTP TCP IP X.25 Figure 10. Protocol stack used by X.25-based SMS. X.25-Based SMS The introduction of TMN-based OAM&P systems in D-AMPS-based PCS will m ake the prospect of an orthodox SMS attractive. Because an orthodox approach to SMS consists of using a data communications network as in any messaging system, the spare capacity in the TMN DCN could reasonably be used instead of the spare capacity in the SS7 network, as currently done. The assumption here, of course, is that an SS7 network is not used as a TMN DCN since this does not make sense from an economic perspective. Since the spare capacity is a network design issue, if it is not there it can always be added; and adding capacity to a classical data communication network is less expensive than adding capacity to an SS7 network. An X.25-based SMS is particularly attractive for many reasons: X.25 facilities are already installed on many D-AMPS-based PCS network operators premises, used in conjunction with existing legacy OAM&P systems. These facilities will certainly be reused as DCN facilities when TMN is introduced. The trend in the industry is toward the use of X.25 networks as TMN DCNs, as previously stated. This will make the use of X.25 networks attractive to D-AMPS-based PCS network operators with no legacy OAM&P system when they introduce TMN. X.25 has already been specified in IS-41.5 [6] as an alternative to SS7 NSP. No additional standardization work will be required for carrying SMS messages using an X.25 network. An X.25-based SMS can go beyond plain replacement of SS7 NSP by X.25. We sketch in the next paragraphs a futuristic X.25-based SMS which allows SMS users to communicate with the outside world via the Internet. Further research is needed, of course, to study its economic and technical viability. Figure 9 depicts the general architecture. As shown in the figure, there are now two distinct interfaces: a signaling interface and a messaging interface. Furthermore, it is possible to reach Internet servers. The SS7 messages currently defined to support SMS can be grouped into two categories. The first comprises the messages used to keep track of the whereabouts of SMS users and locate them in order to deliver messages; this category includes the SMSrequest message. The second category comprises the messages for carrying the actual SMS data; it includes the SMSDeliveryPointToPoint message. In the futuristic X.25-based SMS, messages of the first category are assimilated with automatic roaming messages. They are therefore true signaling messages and will flow through the signaling interfaces of Fig. 9. They are still defined as SS7 messages, but transported by X.25 as in the plain X.25- based SMS. The messages of the second category are assimilated to electronic mail ( ) messages. They flow through the messaging interfaces of Fig. 9. They are carried using the Internet instead of the X.25 network used in the plain X.25-based SMS. This actually enables possible communication with Internet users outside the D-AMPS-based PCS environment. Carrying the actual SMS data using the Internet implies that s and s are equipped with the upper-layer protocols used for messaging in the Internet world, meaning the Simple Mail Transfer Protocol (SMTP) and Transmission Control Protocol (TCP) [25, 27]. As shown in Fig. 10, these upper-layer protocols are run on top of X.25, with the Internet Protocol (IP) [28] acting as glue. SMS users are assigned permanent Internet addresses at their home s, and when roaming, temporary Internet Simple Mail Transfer Protocol Transfer Control Protocol Internet Protocol

9 GLITHO LAYOUT 4/6/98 1:59 PM Page 23 addresses at the which covers the area where they are roaming. A message submitted to a is routed through the Internet to the to which the recipient belongs. If the recipient is roaming, then the message is forwarded to its temporary address, using the Internet mechanisms. The message is then delivered to the recipient over the air interface. Summary and Conclusions W e have provided a comprehensive review of the use of SS7 in D-AMPS-based PCS. The orthodox and heterodox perspectives have been contrasted. We have also made a plea for a gradual return to orthodoxy. This orthodoxy implies not only an orthodox use of SS7 (i.e. use of SS7 for signaling only), but also an orthodox approach to OAM&P (i.e., TMN) and an orthodox approach to messaging (i.e., use of a data communication network). From the orthodox standpoint, SS7 is used for circuit- and non-circuit-related signaling to allow the continuation of ongoing calls when users roam (intersystem handoff) and for non-circuit-related signaling to keep track of users locations when they are roaming (automatic roaming). From the heterodox standpoint, it is used to provide D-AMPS-based PCS OAM&P functionalities based on a node-by-node approach. The OAM&P messages are exchanged between the nodes of the D-AMPS-based PCS network. From the same standpoint, SS7 is also used for a messaging system known as SMS. A gradual return to orthodoxy, or, in other words, the confinement of SS7 use to signaling, is needed for at least two reasons. First, there might not be enough spare capacity in deployed SS7 networks to cater to heterodox traffic. Second and probably most important, SS7 is too expensive for heterodox use. For pure economic reasons, it is better to use any existing spare capacity in deployed SS7 networks (or any newly added capacity) for orthodox purposes, especially as there are strong indications that D-AMPS-based PCS signaling needs will continue to grow. In order to confine the use of SS7 in D-AMPS-based PCS to signaling, it is necessary to find alternatives to heterodox use. This article has proposed alternatives rooted in an orthodox vision of OAM&P and messaging. A TMN-based approach has been proposed for D-AMPS-based PCS OAM&P. The TMN approach brings many benefits, including the possibility of using the same set of principles for managing the two networks overlaid on the D-AMPS-based PCS network, meaning the SS7 network itself and the transport network. Furthermore, any spare capacity in the TMN DCN (or any newly added capacity) could be used to carry SMS messages in a cost-efficient way. X.25 is a good choice for this TMN DCN, as shown in the article. It opens the door to an X.25-based SMS which goes beyond plain replacement of SS7. We have sketched this futuristic X.25-based SMS. It allows SMS users to communicate with the outside world via the Internet. The research effort in the PCS arena has so far focused on the air interface. This article has shown that there are also significant challenges in other areas. Signaling in PCS relies mostly on SS7, and the signaling traffic in PCS will continue growing, as hinted by the recent initiatives for WIN and local number portability. SS7 was designed before the emergence of PCS. Will it be able to meet these ever growing signaling needs? References [1] J. E. Padgett, C. G. Gunther, and T. Hattori, Overview of Wireless Personal Communications, IEEE Commun. Mag., Jan [2] D. C. Cox, Wireless Personal Communications: What Is It? IEEE Pers. Commun., Apr [3] R. Pandya, Emerging Mobile and Personal Communication Systems, IEEE Commun. Mag., June [4] R. Modaressi and R. A. Skoog, Signaling System No. 7: A Tutorial, IEEE Commun. Mag., July [5] Y.-B. Lin and S. K. DeVries, PCS Network Signaling Using SS7, IEEE Pers. Commun., June [6] R. H. Glitho, The Standards Aspects of SS7 Network Management, J. Network and Sys. Mngmt., vol. 2, no. 3, 1994, pp [7] ANSI, Message Transfer Part (MTP), Rev. 2, Tech. Rep. ANSI T1.111, [8] ANSI, Signaling Connection Control Part (SCCP), Rev. 2, Tech. Rep. ANSI T1.112, [9] ANSI, Transaction Capabilities Application Part (TCAP), Rev. 2, Tech. Rep. ANSI T1.114, [10] CCITT Recs. X.219/X.229, Remote Operation Services Element, Blue Book, Geneva, Switzerland, [11] EIA/TIA IS-41.1-C, Cellular Radiotelecommunications Intersystem Operations: Functional Overview, [12] EIA/TIA IS-41.2-C, Cellular Radiotelecommunications Intersystem Operations: Intersystem Handoff Information Flows, [13] EIA/TIA IS-41.3-C, Cellular Radiotelecommunications Intersystem Operations: Automatic Roaming Information Flows, [14] EIA/TIA IS-41.4-C, Cellular Radiotelecommunications Intersystem Operations: Operations, Administration, and Maintenance Information Flows, [15] EIA/TIA IS-41.5-C, Cellular Radiotelecommunications Intersystem Operations: Signaling Protocols, [16] EIA/TIA IS-41.6-C, Cellular Radiotelecommunications Intersystem Operations: Signaling Procedures, [17] G. Pollini et al., Signaling Traffic Volume Generated by Mobile and Personal Communications, IEEE Commun. Mag., June [18] CTIA OAM&P SubTask Group, Requirements for Wireless Network OAM&P Standards, Rev. 0.3., Feb [19] CTIA Wireless Intelligent Network SubTask Group, Standards Requirement Document, Nov [20] ITU-T Rec. M.3010, Principles for a Telecommunications Management Network, Geneva, Switzerland, [21] R. Glitho and S. Hayes, Telecommunications Management Network: Vision vs. Reality, IEEE Commun. Mag., June [22] ITU-T Rec. Q.811, Lower Layer Protocol Profiles for the Interface, Geneva, Switzerland, [23] ITU-T Rec. Q.812, Upper Layer Protocol Profiles for the Interface, Geneva, Switzerland, [24] EIA/TIA, TR45 Network Management Ad Hoc Group Stage 2 and 3 Working Document, Draft Rev.0.1, May [25] J. B. Postel, S imple Mail Transfer Protocol, RFC 821, USC/Info. Sciences Inst., Aug [26] J. B. Postel, User Data Protocol, RFC 768, USC/Info. Sciences Inst. [27] J. B. Postel, Transmission Control Protocol, RFC 793, USC/Info. Sciences Inst., Sept [28] J. B. Postel, Internet Protocol, RFC 791, USC/Info. Sciences Inst., Sept Biography ROCH H. GLITHO [SM] (lmcrogl@lmc.ericsson.se) received M.Sc. degrees in business economics (University of Grenoble, France, 1990), mathematics (University of Geneva, Switzerland, 1985), and computer science (University of Geneva, Switzerland, 1984). He is currently pursuing a Ph.D. in computer communications at the Royal Institute of Technology of Stockholm, Sweden. He is a principal engineer at Ericsson, Montreal, Canada, where he works in the area of OAM&P. He joined Ericsson in Stockholm in 1990, after having worked five years for a computer manufacturer in Oslo, Norway. He moved to Montreal in He is active in many standardization bodies, including ITU-T.