PCS Network Signaling Using SS7

Supporting interconnection with the PSTN PCS Network Signaling Using SS7

YI-BINGLIN AND STEVEN K. DEVRIES

ersonal Communications Services this article is based on EIA,TIA IS-41 Revision B. We also describe , (PCS) facilitates the exchange of information (voice, data, video, some potential extensions of the IS-41 protocol based on a image, etc.) for mobile users independent of time, location, draft of IS-41Revision C. In this article, “IS-41.C”refers to EIAlTIA -and access arrangement. Tosupport PCS, mobile communications PN-2991, the Baseline Text Draft 3 9-2-94of IS-41 Revision C 1191. protocols such as EIWIAInterim Standard 41 (IS-41) 112-161 or Global System for Mobile Communications (GSM) [20] have been defined for PCS Network (PCN) inter-system oper- Signaling System No. 7 ations. To support interconnection between a PCN and the Public Switched Telephone Network (PSTN), it is essential ommon Channel Signaling (CCS) is a signaling method that the mobile communicationsprotocol interactswith the PSTN which provides control and management in the telephone signaling system for mobility management and call control. Cnetwork. CCS consists of supervisory functions, address- This article describes the interactions between a PCN and ing, and providing call information. A CCS channel conveys the PSTN in four aspects: messages to initiate and terminate calls, check on the status of some Interconnection Interfaces -What are the network inter- part of the network, and control the amount of traffic allowed. faces between a PCN and the PSTN? CCS uses a separate out-of-band signaling network to carry Message Routing - How is the information exchanged signaling messages. In all figures of this article, the signal links among the PCNPSTN network elements? will be represented by dashed lines, and the trunks will be Mobility Management - How d0es.a PCN recognize the represented by solid links. SS7 is a CCS system developed to locations of the mobile users? satisfy the telephone operating companies’ requirements for an Call Control - How are the calls set up between the mobile improvement to the earlier signaling systems (which lacked the users and the wireline users? sophistication required to deliver much more than Plain Old Mobility management merits further discussion. In a PCN Telephone Service or POTS). the current location of a mobile user is usually maintained by a This section provides a brief introduction to the SS7 network two-level hierarchical strategy with two types of databases. The architecture and protocol from the perspective of PCN inter- Home Location Register (HLR) is the location register to which connection. The reader is referred to [ 11 for a more complete a mobile user identity is assigned for record purposes such as mobile SS7 tutorial. user information (e.g., directory number, profile information, current location,validationperiod). The Visitor Location Register (VLR) The SS7 Network Architecture is the location register other than the HLR used to retrieve infor- Figure 1 illustrates an example of the SS7 signaling network. mation for handling of calls to or from a visiting mobile user [14]. The figure only shows the parts that involve the interconnec- When a mobile moves from the home PCN to a visited PCN, its tion between a PCN and the PSTN. The network consists of location is registered at the VLR of the visited PCN. The VLR then three distinct components. informs the mobile’s HLR of its current location. The details of the *Service Switching Point (SSP) is a telephone switch inter- registration processwill be discussed in asubsequent section. When connectedbySS7links.TheSSPsperformcallprocessingoncallsthat a call is delivered to a mobile, the HLR is first queried to find originate, tandem, or terminate at that node. In this article, an SSP its location (i.e., the VLR corresponding to its current location). in a PCN are called a Mobile Switching Center (MSC). The details of location tracking can be found in 1121, and the call *Signal Transfer Point (STP) is a switch that relays SS7 mes- setuphelease process is discussed in the section on PCN/PSTN sages between network switches and databases. Based on the address call control using ISUP. Since it is likely that two PCNs are fields of the SS7 messages, the STPs route the messages to the connected through the PSTN, it is important to understand correct outgoing signaling links. To meet the stringent reliability how the PSTN is involved in PCS mobility management. requirements, STPs are provisioned in mated pairs. To address these four aspects, we consider IS-41 as the mobile Service Control Point (SCP) contains databases for pro- communications protocol and Signaling System No. 7 (SS7) [2-51 viding enhanced services. An SCP accepts queries from an SSP as the PSTN signaling protocol. The IS-41 protocol considered in and returns the requested information to the SSP. In mobile

44 1070-9916/95/$04.000 1995 IEEE IEEE Personal Communications June 1995 1, applications,an SCP may contain an HLRor a VLR. There are six types of SS7 signaling links. Two types of the links are introduced in this article. Other types of links can be found in [7]. Each SSP and SCP will have a minimum of one signal link to each STP pair. The signal link is referred to as the Access Link (A-link). The number of A-links between an SSP and an STP pair can be up to 128 though most switch suppli- A-Link A-Link ers have limited the number to 16. I Signaling links that connect STPs of different networks (e.g., PCN and PSTN in our example) are called Diagonal Links (D-links). D-links are deployed in a quad arrangement with three-waypath diversity. The maximum link set size is 64. I 1

The SS7 Protocol ~~------~- ~~ The basic parts of the SS7 protocol and the cor- W Figure 1. An example of the SS7 network architecture. responding OS1 layers are shown in Fig. 2. In the protocol hierarchy, the Operations, Maintenance, and AdministrationPart (OW)and Mobile Appli- cation Part (MAP) are TCAP (i.e., Transaction OS1 layers The SS7 layers Capabilities Application Part; to be defined) applications. The details of the OMAP are omit- -/I ted and can be found in [7]. Application The MAP will be elaborated based on the IS- *I I 41 protocol. The other parts of the SS7 protocol are described below. ...______-.--..-.~-~~ ISDN-UP *The Message Transfer Part (MTP) consists of Presentation three levels corresponding to the OS1 physical layer, session data link layer, and network layer, respectively. transport The MTP Level 1 defines the physical, electrical, and functional characteristics of the signaling links connecting SS7 components. The MTP Level 2 provides reliable transfer of signaling messages between two directly connected signaling points. The MTP Level 3 provides the functions and procedures related to message routing and network management. I MTP level 3 I *The Signaling Connection Control Part (SCCP) provides additional functions such as Data link MTP level 2 Global Title Translation to the MTP to transfer I I non-circuit-related signaling information such as PCS registration and cancellation. Physical MTP level 1 *The Transaction Capabilities Application I I Part (TCAP) provides the ability to exchange information between applications using non-circuit .~ _.~ related signaling. W Figure 2. The SS7signalingprotocol.~ ~ *Integrated Services Digital Network User Part (ISUP) establishes circuit-switched network connections (e.g., call setupirelease). Pass-alongsig- two for SS7 signaling, and two for trunk (voice naling service sends the signaling information to each circuit) connections [8]. The signaling interfaces rep- switching point involved in a call connection. resents the physical signalinglink connectionbetween The IS-41 protocol [12, 1.51 is implemented in a PCN and the PSTN. The SS7 signaling inter- the MAP as an application of the TCAP. The connection methods are described as follows: wireless call setup/release is completed by using A-link signaling interface involves A-links from the ISUP. The MTP and the SCCP provide rout- an MSC to a PSTN STP pair (Figs. 3a and c). ing services between a PCN and the PSTN. OD-linksignaling interface involves D-links from a PCN STP pair to a PSTN STP pair (Figs. 3b and d). lnterconnection and Message The trunk interfaces represents a physical SS7- supported trunkconnection between aPCN and the Routing between PSTN. The types of the SS7 trunk interconnections PCN and PSTN are described as follows: *Type 2A with SS7 trunk interface provides everal types of interconnections between a connection between a PCN and a PSTN tandem PCN and the PSTN have been described in switch. The Type 2A with SS7 interfaces are shown S [8, 171. We describe four types of SS7 inter- in Figs. 3a and b. connection between a PCN and the PSTN (specif- *Type 2B with SS7 trunk interface provides ically, the local telephone networks) using SS7: connection between a PCN and a PSTN end office

IEEE Personal Communications June 1995 45 IS-41 Revisions B and C, but not in IS-41 Revision A. The ISUP messages for wireless call control FacilitiesDirective INVOKE(Last) QUERYWITHPERMISSION (see the section on PCN/PSTN call control using FacilitiesDirective RETURN RESULT(Last) CONVERSATIONWITHPERMISSIONISUP) are not delivered with GTT. Details of IS- FacilitiesDirective RETURN ERROR RESPONSE 41 message routing can be found in Appendix B. The FacilitiesDirective REJECT RESPONSE - appendix describes the fields of an IS-41 message HandoffMeasurementRequest INVOKE(Last) QUERYWITHPERMISSION which are used for the routing purpose and how HandoffMeasurementRequest RETURN RESULT(Last) RESPONSE the routing procedure is performed. HandoffMeasurementRequest RETURN ERROR RESPONSE HandoffMeasurementReauest REJECT RESPONSE Mobility Management MobileOnChannel I INVOKE ]RESPONSE ~ Using TCAP QualificationRequest INVOKE(Last) QUERYWITHPERMISSION QualificationRequest RETURN RESULT(Last) RESPONSE wenty six TCAP operations2 are defined in QualificationRequest RETURN ERROR RESPONSE IS-41.B [ 131 for three purposes: Inter-MSC QualificationRequest REJECT RESPONSE T Handoff [15], Automatic Roaming [12], and Operations, Administration, and Maintenance RegistrationCancellation INVOKE(Last) QUERYWITHPERMISSION [16]. The details of handoff and automatic roam- RegistrationCancellation RETURN RESULT(Last) RESPONSE ing (mobility management) alternatives can be RegistrationCancellation RETURN ERROR RESPONSE found in [21-271. RegistrattonCancellation REJECT RESPONSE A TCAP message consists of two portions: the RegistrationNotification INVOKE(Last) QUERYWITHPERMISSION Transaction Portion and the Component Portion. RegistrationNotification RElllRN RESULT(Last) RESPONSE The Transaction Portion specifies the Package RegistrationNotification RETURN ERROR RESPONSE Type. Four of the seven Package Types [5, 131 are RegistrationNotification REJECT RESPONSE defined in IS-41.5-B.3 ~~ ~YwI~PEREIIssIoNNnitiatesaTCAP transaction ServiceProfileRequest INVOKE(Last) QUERYWITHPERMISSION and informs the terminating node that it may ~ ServiceProfileRequest RETURN RESULT(La5t) RESPONSE end the TCAP transaction. ServiceProfileRequest RETURN ERROR RESPONSE RESPONSEends the TCAP transaction. ServiceProfileRequest REJECT RESPONSE --~-~ CON~E;~SATION~I~~ERMISSIONcontinues a TCAP transaction and informs the destination node that it may end the TCAP transaction. UNIDIRECTIONAL sends information in one direction switch. The Type 2B with SS7 interfaces are shown only with no reply expected. in Figs. 3 c and d. The Component Portion specifies the number Several applications that require calls to be and the types of components (operations) to be tandemed (e.g., operator services and 800 call performed. Four of the six Component Types are setup) are supported by Type 2A with SS7 inter- defined in IS-41 Revision B.4 face, but are not available to Type 2B with SS7 INVOKE (Last)is used to invoke an operation interface. (such as location registration). “Last”indi- Both Types 2A and 2B were originally support- cates that the operation is the last component ed by multi-frequency (MF) signaling protocols in the Component Part. [8]. Other interfaces supported by MF signaling RE” RESULT (ust ) is used to retum the results are Type 1, Type 2C for 911 emergency service of an invoked operation. If a node receives an calls, and Type 2D for operator services. Both 911 INVOKE and the operation is executed success- I A mobile user may also calls (Type 2C) and operator services (Type 2D) fully, the node shall respond with a RETURN be assigned a Universal could be handled along with other types of calls RESULT. Personal Telecommunica- on a Type 2A with SS7 interface. The details of RETURN ERROR is used to report the unsuccess- tion (UPT) number. The MF signaling for PCN can be found in [SI. ful completion of an invoked operation. For relationship between the We will show how signaling messages are example, the MIN in the INVOKE message is UPT number and the deliveredwith the configurationsin Fig. 3. Basically, not currently serviced by the HLR. MIN is illustrated in 1221. SS7 message routing is performed at the MTP REJECT is used to report the receipt and rejec- This article assumes that and the SCCP of a node (SSP, STP, or SCP). At the tion of an incorrect Package or Component a mobile user is identified MTP level, the signaling messages are delivered (e.g., ill-formatted). When a node receives a by the MIN. with the actual destination address. The MTP level REJECT message, it stops its timer, exits the receives messages from an adjacent node (SSP, current task, and performs error recovery. In IS-41.C, 28 new oper- STP, or SCP) or from the TCAP (and thus the SCCP) Note that an SS7 transaction alwavs<., begins ations are expected to be layer or the ISUP layer of the same node. The with a query message (QueryWithPermission included. Destination Point Code (DPC) of the message in IS-41), and ends with a response message uniquely identifies the destination node. Routing to (Responsein IS-41). In IS-41,both the INVOKE and In IS-41.C, another the destination node is determined by the MTP using the RETURN RESULT types are “Last” which Package Type called Con- look-up tables. imply that every IS-41 TCAP message performs versationWithoutPer- In the mobile application, every handset is exactly one operation. In an IS-41 implementa- mission will be assigned a Mobile Identification Number (MIN).l tion, we may expect that operations such as introduced. When an MIN is dialed, the originating node may authentication and registration notificationare com- not have enough knowledge to identify the actual bined into a TCAPmessage. In the remainder of this Same number of the address of the destination. In this case, the actual article, we omit the notation “Last.”All IS-41.B Cvmponent Types are destination address is translated by a technique called transactions are two-message (a query and a response) expected in IS-41 Global Title Translation (GTT) performed at the transactions except for two cases. Revision C. SCCP level of the protocol. GTT is supported in *ATCAP message with the operation FlashRe-

46 IEEE Personal Communications June 1995

._I_.^._ - -. ~ I /1 r- I /L I A

UType S (D1427 links)

Tandem MSC Tandem

PSTN

(a) Type 2A with 557 trunk interface (b) Type 2A with 557 trunk interface supported by a Type 5 A-link supported by a Type 5 D-link signaling interface signaling interface

office PSTN

(d) Type 2B with 557 trunk interface (c) Type 2B with 557 trunk interface supported by a Type S D-link supported by a Type 5 A-link signaling interface signaling interface

~~- Figure 3. Types of interconnection between a PCN and the PSTN.

quest has a PackageType UNIDIRECTIONAL. Thismes- flows of IS-41 TCAP transactions. The TCAP message is sent from the serving MSC to the anchor MSC sages described in these examples are summa- to convey information for call control. No response rized in Table 1. is expected from the anchor MSC, and no TCAP transaction is established. This message is defined Inter-MSC Handoff in IS-41 Revisions B and C, but is not supported The inter-MSC handoff procedures are defined in IS-41 Revision A [12]. in IS-41.2 [15]. We assume that the inter-MSC *ATCAP transaction including the operation handoff occurs within a PCN, and the SS7 mes- FacilitiesDirective consists of three messages sages are not delivered to the PSTN. Figure 4 exchanges. We will elaborate on this transaction illustrates the IS-41 TCAP message flow for later. handoff-forward. In this figure, a communicating (In IS-41.C, other transactionssuch as “inter-MSC handset (mobile user) moves out of the base sta- setup” also involve more than two messages.) IS-41 tion served by MSC A. Two transactions are required TCAP uses SCCP Class 0 connectionless service to perform inter-MSC handoff. [4] that provides efficient routing without main- taining message sequencing between two or more Transaction 7 - MSC A sends a HandoffMea- messages from the same originating node. Message surementRequest (INVOKE) to the candidate sequencing is implied in the two-message IS-41 MSC B, and waits for the response from MSC B. transactions. For the three-message IS-41 transac- When MSC B receives the HandoffMeasure- tions described above, message sequencing is also mentRequest (INVOKE),it selectsacandidate base For simplicity, we guaranteed (to be elaborated). station BS2for handoff. If nocandidate base station express an IS-41 TCAP Every IS-41 TCAP transaction accompaniesa time- is found, MSC B may exit this transaction. Other- message as a pair “Opera- out constraint. Typically, recovery procedures wise, MSC B sends a HandoffMeasurementRe- tion (Package Type)” or (definedinIS-41.4B [16]) areexecutedwhen a timer quest (RETURN RESULT) to MSC A.6 “Component Type. ” expires. For most IS-41 transactions timer expira- ..tion is considered as an error (i.e., the arrival of a Transadeon2 - Before this transaction is started, The result includes the RETURN ERROR TCAP message). MSC A checks if the handset has made too many signal quality parameter We use two examples to illustrate the message handoffs or if inter-MSC trunks are not available. values.

IEEE Personal Communications June 1995 47 Transaction 2 is a three-message transaction. Like Transaction 1,Transaction 2is initiated bythe QUERYWITHPERMISSIONmessage FacilitiesDirective (INVOKE)from MSC A. MSC B replies with a CONVERSATIONWITHPERMISSION.The MobileOn- Channel (INVOKE)sent from MSC B to MSC A has a Package Type RESPONSE,which terminates the transaction. Note that the FacilitiesDirective (RETURN) and the MobileOnChannel (INVOKE) must be received by MSC A in the order they are sent. The communication between MSC A, the handset, and MSC B through the air interface guaranteesthat MSCBwillnotsendthe MobileOn- /______...... ____._...... ~~....~~~~~..~~~~.....~~~~.~...~, Channel (INVOKE) message before MSC A HandoffMeasurementRequest (INVOKE) receives the FacilitiesDirective (RETURN)message. Thus, number sequencing is achieved with @ HandoffMeasurementRequest (RETURN RESULT) the connectionless service. + At the beginning of Transaction 1, MSC A sets a 7-second timer (LMMRT). If LMMRT FacilitiesDirective (INVOKE) expires before the HandoffMeasurementRe- c quest (RETURN)arrives, MSC A exits this trans- FacilitiesDirective (RETURN RESULT) action and performs some actions (e.g., blocks the handoff call). If MSC A receives the Hand- OffMeasurementRequest (RETURN) afterLMMRT has expired, then it sends a HandoffMeasure- MobileOnChannel (INVOKE) mentRequest (REJECT) message to inform MSC B that Transaction 1 has been terminated without completion. At the beginning of Transaction 2, 1;- MSC A sets a 12-second timer HOT. If HOT expires before the FacilitiesDirective (RETURN) arrives, MSC A exits Transaction 2 and releases associated inter-MSC facilities (see Section 4.3 in [15]). If MSC A receives the RETURN message MSC A exits this transaction, and the hand-off call from MSC B, it stops HOT. MSC A expects to maybeforcedterminatedif there are toomanyhand- receive subsequent messages from MSC B, and offs or if there are no trunks. Otherwise, MSC A another 7-second timer HMOT is set. If HMOT sends a FacilitiesDirective (INVOKE) to MSC B. expires before the MobileOnChannel (INVOKE) When MSC B receives the FacilitiesDirective arrives,then MSCAexitsTransaction 2 and reclaims (INVOKE),it replies with a FacilitiesDirective the resources. (RETURN ERROR) if no voice channel is available in BS2.' If BS2 is available to accommodate the Mobile Registration call, MSC B replies with a FacilitiesDirective Figure 5 illustrates the message flow for the regis- (RET" RESULT)* to MSC A. tration and validation process as a mobile user When MSC A receives the FacilitiesDirective roams from PCN 1 to PCN 2. This figure assumes (RETURN), one of the following two events occurs. that an MSC and the corresponding VLR are If the message is a RETURN ERROR,then MSC A connected by an STP. In reality, it is more likely executes recovery procedures and exits the trans- that the VLR is collocated with the MSC. The action. If the message is a RET" RESULT,then process consists of six two-message TCAP trans- MSC A sends the handset a handoff order. actions. When MSC 2 detects that the mobile After the handset is connected to BS2, MSC B user is in its service area, it initiates Transaction 1 sends a MobileOnChannel (INVOKE)to MSCAand witha RegistrationNotification (INVOKE) toitsVLR exits this transaction. (VLR 2). When MSC A receives the MobileOnChannel If both MSCs 1 and 2 are served by VLR2, (INVOKE),it connects the call path (trunk) to VLR 2 finds that the mobile user had previously MSC B and exits this transaction. registered with an MSC within the domain of VLR 2. In this case, VLR 2 may take no further The IS-41 TCAP messages are delivered action other than to record the identity of MSC 1. through the PCN SS7 signaling links. (See dashed Otherwise, VLR 2 initiates Transaction 2 by links 1 and 2 in Fig. 4. In this example, an STP is sending a RegistrationNotification (INVOKE)to in the signaling path.) Before the handoff, the the mobile user's HLR. Note that this TCAP voice path is (3) ++ (4) ++ (5). If the handoff is message is likely to be routed by using the global successful, the new voice path is (3)H (4) H (6) title translation because VLR 2 may not recog- (7). nize the actual address of the HLR by the mobile The error code of the - Transaction 1is a typical two-message IS-41 trans- user's MIN. Thus, the mobile user's MIN is used message is resource action . The H a nd off Me a s u reme nt Re q u est as the global title address, and the translation shortage [13]. (INVOKE)is of type QUERYWITHPERMISSION.With type of the message is marked "3"for CellularNation- this Package Type, MSC A implies that MSC B wide Roaming Services (see Appendix B for more The result includes the may end this transaction after the response is details). Our example assumes that STP 3 will per- parameters of the selected sent. The message replied from MSC B is of type formGTT(i.e.,theDPCof themessage points to STP voice channel. RESPONSE,which terminates the transaction. 3). After global title translation,the actual destination

48 IEEE Personal Communications June 1995 1 PCNl PSTN PCN2 I

RegistrationNotifica‘ion (INVOKE)

RegistrationNotification (RETURN RESULT)

t Registrationcancellat6- on (INVOKE) * RegistrationCancellat on (RETURN RESULT) Registrationcan- dlation (INVOKE) Registrationcan illation (RETURN RESULT) d I QualificationRequest (INVOKE)

QualificationReques’ (RETURN RESULT) d‘ t

ServiceProfileReques: (INVOKE)

ServiceProfileRequesI(RETURN RESULT *

W Figure 5.7s-41 TCAP message flow for mobile registration.

address is found. STP 3 forwards this message to STF’ a registration record for the mobile user, and 2 and thus to the HLR. The HLR confirms the reg- may send a QualificationRequest (INVOKE)to istration by sending a RegistrationNot if ica t ion the HLR in order to authenticate the mobile user (RETURN RESULT) to VLR 2. This message may (see Transaction 5) [18]. be delivered without global title translation VLR 2 may also send a ServiceProfileRequest because the actual address of VLR 2 is included (INVOKE)to the HLR to obtain the service pro- as part of the SCCP in the previous Registra- file for the roaming mobile user (see Transaction 6). tionNotification (INVOKE) sent from VLR 2 to the Transaction 6 is required in some call delivery HLR. Note that Transaction 2 is nested within schemes [21,24]. Transaction 1. The HLR sends a RegistrationCancellation (INVOKE)to the mobile user’s previously visited PCNIPSTN Call Control VLR (VLR 1) to cancel the obsolete registration record (see Transaction 3). The cancellation Using ISUP propagates to MSC 1 (see Transaction 4). Since the actual address of VLR 1 has been recorded in he ISUP messages are used for call the HLR (in the previous registration operation), setuphelease between the PSTN and a PCN the cancellation message may be delivered by T in the interconnection networks using Type using the actual HLR address (Le., no GTT is 2A or Type 2B with SS7 trunk interfaces (see the required). Note that the cancellation process (see section, “Interconnection and Message Routing Transactions 3 and 4) can be performed at any between PCN and PSTN”). Nine of the 57 ISUP time after Transaction 2. message types [2] are discussed in this section for After Transaction 2 is completed, VLR 2creates basic call setup. Figure 6 illustrates the typical

IEEE Personal Communications June 1995 49

.. Note that if the called party is a wireline user, the busy line situation is not detected until Step 3.

Step I - After the mobile user’s TLDN is known, the EO sends an Initial Address Message (IAM)9 to the PCN MSC to initiate signalingfor trunk setup. The EO marks the circuit busy, and the information is carried by the IAM. The IAM also indicates whether a contimi9 check is required (to be described in the next step). The IAM progresses switch-to-switch via the STPs to the PCN MSC (the message follows the path (1) 4 (2) + (3) + (4) + (5) in Fig. 6). When the IAM is sent, an IAM timer is set at the EO. The EO expectsto receive a response from the MSC within the timeout t ACM ACM period. + Step 3 ANM ANM Step 4 Step 2 (if necessary) - If the IAM sent from the EO to the tandem specifies a continuity check, the selected trunk from the tandem to the EO is checked to ensure a satisfactory transmission REL path. After the continuity check is successfully Step 5 REL completed, a Continuity Message (COT) is sent - L from the EO to the tandem, and the trunk is set up. The same procedure could be performed when the MSC receives the IAM from the tandem.

Signaling path from Step3- When the IAM arrivesat the MSC, the MSC PSTN to PCN pages the mobile user. One of the following three Signaling path from events occurs: PCN to PSTN e4bQ+e-.9 -The mobile user is connected with another call (the call setup occurs between the end of ~~ mgK6.Typical message flow for Type 24 with Sfi land-to-mobile call setup Step 0 and the end of Step 2). This situation is and release involving a tandem switch. referred to as Call Collision in Fig. 8, IS-41.3 [12]. Either the call is processed with call forwarding or callwaiting.Or the MSCreturns an RELmessage message flow for Type 2A with SS7 land-to-mobile to the EO (to be described in Step 5) with a cause call setuphelease involving a tandem switch (see Fig. indicating the busy line. 3b). For other interconnection configurations, the *If the mobile user is idle, an Address Com- I message flows between the originating switch and plete Message (ACM) is sent from the MSC to the terminating switch are the same although the sig- the EO. The message indicatesthat the routing infor- naling and trunk paths may be different. mation required to complete the call has been The call setup procedure is described in the received by the MSC. The message also informs following steps [2, 7, 101. the EO of the mobile user information, charge Note that Steps 1-6 of the call setup procedure indications, and end-to-end protocol requirements. is general and is not unique to the mobile appli- The MSC provides an audible ring through the cations. These steps are presented to provide the setup trunk to the calling party. When the EO receives reader a complete message flow of wireline-to- the ACM, the IAM timer is stopped. The ACM wireless call setup. (and other ISUP messages) sent from the MSC to the EO follows the path (5) + (4) + (2) + (3) Step 0 - When an MIN is dialed, the EO notices --;r (1) in Fig. 6. that the number is for wireless service. The EO *Ifthemobileuserdoesnot answerthe page, the sends a query message to obtain the mobile user’s MSC may redirect the call based on an appropri- Temporary Local Directory Number (TLDN) ate procedure or return an REL message to the [14]. The messages exchanged among switches, EO (see Fig. 7 in IS-41.3 [12]). VLR, and HLR are TCAP messages described in Fig. 2, IS-41.3 [12]. These messages may be deliv- Step 4 - When the mobile user answers the call, ered with or without GTT. This example assumes an Answer Message (ANM) is sent from the that the EO has the capability to query the HLR. MSC to the EO to indicate that the call has been (Otherwise, the MIN must be routed from the EO answered. At this moment, the call is established to a specific switch for location query and call (through the trunk path (6) and (7) in Fig. 6) and setup [9].) the conversation begins. If the called party (mobile user) is busy, the situation is detected at this stage and a busy Step 5 - After the conversation is finished, the indication is returned to the calling party (see call can be disconnected with procedures depend- The ISUP messages Fig. 3 in IS-41.3 [12]). If the mobile user has call ing upon who hangs up first. Figure 6 assumes akcn‘bed in thefollowing forwarding or call waiting services, the busy line that the calling party hangs up first. (In the next steps are delivered by situation is handled differently (see Figs. 6 and 9 example, we will illustrate the case when the MTP routing. in [12]). called party hangs up first.) The EO sends a

50 IEEE Personal Communications June 1995

__ __ -- Release Message (REL) to indicate that the specified trunk is being released from the connection. The specified trunk is released before the REL is sent, but the trunk is not set idle at the EO until a RLC message (see the next step) is received.

Step 6 - When the MSC receives the REL prop- agated from the EO, it replies with a Release Complete Message (RLC) to confirm that the indicated trunk has been placed in an idle state. After the RLC is sent, the EO (the tandem) waits for 0.5 to 1second before it seizes the released trunk for the next call.

Figure 7 illustrates the message flow for a call 1 I setup from a mobile user to a wireline user. The PSTNiPCN interconnection follows the configu- ration in Fig. 3a. In this example, two Local Exchange Carriers LEC1, LEC2, (local telephone companies) and an Interexchange Carrier IXC (a long distance telephone company) are in the call setup path. I Conversation I The message flow for call setup is very similar to the previous example except that an Exit message (EXM) is sent from Tandem 1 to the MSC to indicate that SS7 call setup information has successfully progressed to the IXC. The EXM is sent to the MSC when Tandem 1 has received an ACM, ANM or REL from the IXC or when an EXM -~__-____ -. ____ timer expires at Tandem 1. (Our example assumes Figure 7. Typical messageflow for Type 2A with SS7mobile-to-land call setup that the EXM timer expires first.) The timer is and release involving a tandem switch. set after an IAM is sent from Tandem 1 to the IXC. The sending of the EXM does not affect the completion of any continuity check required on the Conclusions and Further trunkbetween theMSCandTandem 1.0ntheother hand, if a COT code “continuity check failed” is Reading received for this trunk, the EXM is not sent to the MSC. e have discussed the SS7-supported The call release procedure in this example interactions between PSTN and PCN. assumes that the called party hangs up first, W Specifically,we assumed that the mobile which is different from the previous example. communications protocol is IS-41. The purpose When the called party (the wireline user in this of this article is to provide a quick overview of example) hangs up the phone, a Suspend Mes- the wireless-related signaling. sage (SUS) is sent from the EO at LEC2 to the We described two types of SS7-supported MSC to indicate that the called party has discon- trunk connections, and two types of signaling nected. The EO expects one of the following two links between a PCN and the PSTN. If the trunk events to occur within a timeout period (14-16 is connected from the PCN to a PSTN end office, seconds). then 911 calls and operator services may not be An RELfrom the MSCis received by the EO. The supported. These servicesonly are supportedvia the EO disconnects the trunk. PCN trunkconnected to a PSTN access tandem. The The called party goes back off-hook. The reader is referred to [8, 171 for more details. connection continues, and a Resume Mes- All messages for mobility management are sage (RES) is sent from the EO to the implemented by the TCAP of SS7. Signaling mes- MSC (not shown in Fig. 7). The SUS timer is sages related to call setupirelease are implement- stopped. ed by the ISUP of SS7. All signaling messages are If the SUS timer expires, the EO disconnects routed between PCN and PSTN by the MTP and the trunk, and an REL is sent to the MSC. Upon SCCP of the SS7 protocols. the receipt of the SUS, the MSC expects one of If the actual destination address is known, the the following three events to occur within a time- IS-41 TCAP messages are delivered without out period (10-32 seconds). global title translation. All ISUP messages for The calling party hangs up. The MSC sends an call control are delivered without global title REL to the EO and disconnects the trunk. translation. For IS-41TCAP messages using the mobile An REL (from the EO) arrives at the MSC. users’ MINs, the actual destination addresses The MSC disconnects the trunk. may not be known. The destination addresses are An RES (from the EO) arrives at the MSC. translated by the SCCP using global title transla- The SUS timer is stopped and the connection con- tion. The reader is referred to [6,9, 111 for fur- .. tinues. ther reading. If the SUS timer expires, the MSC disconnects IS-41 mobility management is implemented by the trunk. TCAP with efficient connectionless service (i.e.,

IEEE Personal Communications June 1995 51 out-of-order message delivery). Message sequenc- Automatic roaming, Technical Report 15-41.3-8. EIAITIA. 1991. [131 EIAITIA. Cellular radio-telecommunications intersystem opera- ing is guaranteed by the simple two-message (a query tions: Data communications.Technica1ReportlS-41.5-6, EIMIA, 1991 and a response) TCAP transactions. The reader is [14] ElMIA. Cellular radio-telecommunications intersystem operations: Functional overview. Technical Report IS-41 1-6, EIMIA. 1991 referred to [ 12, 15, 19) for further reading. [151 EIAITIA, Cellular radio-telecommunications intersystem operations: Call setup/release between a PCN and the Intersystem handoff, Technical Report IS-41.2-E. EIAITIA, 1991 PSTN follows standard ISUP procedures. 1161 EIAITIA, Cellular radio-telecommunications intersystem operations Operations. administration. and maintenance. Technical Report In the PSTN’s view, PCN call control is similar IS-41.4-6. EIMIA. 1991 to other applications such as 800 service. The 11 71 EIMIA. Cellular radio telecommunications interfacesstandard. Tech- nical Report 15-93, EIAITIA. 1993 reader is referred to [6, 101 for further reading. [181 EIAITIA. Cellular radiotelecommunications intersystem operations authentication. signaling message encryption and voice privacy. Acknowledgment Technical Report TSB-51, EIAITIA, 1993. [191 EIAITIA, Cellular Intersystem Operations - Baseline Text Draft 3 The professional review process provided by 9-2-94 (15-41 Rev. C). Technical Report PN-2991, EIAITIA, 1994 [201 M. Mouly and M.-B. Pautet. The GSM System for Mobile Communi- Hamid Ahmadi is highly appreciated. Li-Fung Chang, cations, M Mouly. 49 rue Louise Bruneau, Palaiseau, France, 1992. Zheng Chen, Robert Ephraim, Dipak Ghosal, Chris [211 R. Jain et al.. “A caching strategy to reduce network impacts of Holmgren, Don Lukacs, Bob Schaefer, Howard PCS.”lEEEJSAC,vol. 12, no.8. 1994, pp. 1434-1445. 1221 5 Mohan and R Jain, Two user location strategies for personal Sherry, Ding G. Wang, Fu-Lin Wu, and the anony- communications services IPCS). IEEE Personal Commun.. vol. 1. mous reviewer provided valuable comments to no. 1, 1Q 1994, pp. 42-50 [231S. Tekinaty and B. Ja bbari, ”Handover policies and channel assignment improve the quality of this article. strategiesin mobilecellularnetworks.”IEEECommun.Mag., vol 29, no 11, Nov. 1991. References I241 Y:B. Lin. “Determining the user locations for personal communications networks,” IEEE Trans. Veh. Technol.. vol. 43, no. 3, 1994. [11 A. R. Modarressi. and R. A. Skoog. Signaling System No. 7: A Tutorial, pp. 466-473. IEEE Commun. Mag., vol. 28, no 7, July 1990. 1251Y -B. Lin, and A Noerpel. “Implicit Deregistration in a PCS Network.” [21 ANSI, American national standard for telecommunications - Signaling IEEE Trans Veh Technol , vol 43. no. 4, 1994, pp. 1006-1010. system number 7: Integrated services digital network (ISDN) user [26]Y -6. Lin. S Mohan, and A Noerpel. “Queueing Priority ChannelAssign- part, Issue 2, Rev. 2, Technical Report ANSI 11.1 13, ANSI, 1992. ment Strategiesfor Handoff and Initial Access fora PCS Network.” IEEE [31 ANSI, American national standard for telecommunications - Sig- Trans. Veh Technol , vol 43. no. 3, 1994. pp. 704-712 naling system number 7: Message transfer part (MTP), Issue 2, [27] Y -B. Lin, S. Mohan,and A. Noerpel. “Channel Assignment Strate- Rev. 2, Technical Report ANSI 11.111, ANSI, 1992. gies for Hand-off and Initial Access for a PCS Network.” IEEE Pers. (41 ANSI, American national standard for telecommunications - Sig- Commun , vol 1, no. 3. 30 1994, pp. 47-56 naling system number 7: Signaling connection control part (SCCP). Issue 2, Rev. 2, Technical Report ANSI 11.112, ANSI, 1992 151 ANSI, American national standard for telecommunications - Sig- Biographies naling system number 7. Transaction capabilities application part (TUP). Issue 2, Rev. 2, Technical Report ANSI T1.114. ANSI, 1992. YI-BING LIN received a BSE E. from National Cheng Kung University in 161 Bellcore Bell Communications Research specification of signaling 1983. and a Ph.D in computer science from the University of Wash- system number 7, Issue 2, Technical Report TR-NWT-000246, ington in 1990. Since then, he has been with the Applied Research Bellcore. 1991 Area at Bellcore. Morristown. New Jersey. His current research inter- [71 Bellcore. Common channel signaling network interface specifica- ests include design and analysis of personal communications services tion supporting network interconnection, message transfer part, network, distributed simulation, and performance modeling. He is a and integrated services digital network user part, Issue 2, Techni- subject area editor of the Journal of Parallel and Distributed Computing, cal Report TR-TSV-000905,Bellcore, 1993. an associate editor of the International Journal in Computer Simulation, an 181 Bellcore. Compatibility information for interconnection of a wireless associateeditor of SIMULATION magazine. a memberof theeditorial board services provider and a local exchange carrier network, Issue 2, of the lnternationallournalof Communications, a member of the editorial Technical Report TR-NPL-000145. Bellcore, 1993. board of Computer Simulation Modeling and Analysis, program chair [91 Bellcore, PCS Access services interface specification in support of for the 8th Workshop on Distributed and Parallel Simulation, and Gen- PCS routing service. PCS home database service, and PCS IS-41 eral Chair for the 9th Workshop on Distributed and Parallel Simula- message transport service. Issue 1, Technical Report TA-TSV- tion. Heis an adjunct researchfellow at the Centerforlelecommunications 001411, Bellcore. 1993. Research, National Chiao-Tung University, Taiwan. R. 0. C. [lo1Bellcore. CCS Network Interface Specification Supporting Wireless Services Providers, Issue 1, Technical Report GR-1434-CORE. STEVEN K. DE VRIEShas been involved with the 557 protocol since 1985 Bellcore, 1994. as a technical manager and a network planner for Illinois Bell. Since 11 11 Bellcore. LSSGR: Common Channel Signaling Section 6.5. Techni- 1991 he has been an instructor in the Intelligent Network district at cal Report GR-606-CORE, Bellcore. 1994. Bellcore TEC in Lisle. Illinois, where he teaches various 557, network, I121 ElAITlA Cellular radio-telecommunications intersystem operations: and wireless courses.

Appendix A - Acronym List AC Authentication Center IXC Interexchange Carrier SIC Service Indicator Code ACM Address Complete Message LEC Local Exchange Carrier SCCP Signaling Connection Control ANM Answer Message MAP Mobile Application Part Part CCS Common Channel Signaling MF Multi-frequency Signaling SCP Service Control Point COT Continuity Message MSC Mobile Switching Center SLS Signaling Link Selection DPC Destination Point Code MTP Message Transfer Part SPC Signaling Point Code EIR Equipment Identification OMAP Operations, Maintenance, SSP Service Switching Point Register Administration Part OPC ss7 Signaling System No. 7 EO End Office Originating Point Code SSN Subsystem Number EXM Exit Message OS1 Open System Interconnection STP Signaling Transfer Point GT Global Title PCN PCS Network sus Suspend Message G7T Global Title Translation PCS Personal Communications TCAP Transaction Capabilities HLR Home Location Register Services Application Part IAM Initial Address Message PSTN Public Switched Telephone TLDN Temporary Local Directory IS-41 EIA/TIA Interim Standard: Network Number Cellular Radio- REL Release Message UDT UnitData Telecommunications RES Resume Message UDTS UnitData Service Inter-System Operations RI Routing Indicator Code UPT Universal Personal ISUP Integrated Services Digital RLC Release Complete Message Telecommunication Network User Part SAC Service Access Code VLR Visitor Location Register

52 IEEE Personal Communications June 1995 1. Appendix B - IS-47 Message Routing

lS-47 MTPISCCP Destination Point Code (DPC) -A 9-digit number that uniquely identifies the node that Message Format the message is bound for. Figure 8a illustrates the fields of the IS-41 message Originating Point Code (OPC) -A 9-digit that will be processed in the MTP. The fields are number that uniquely identifies the node that described below. the message came from. Signaling Link Selection (SLS) - This field is Priority - There are four priority levels (levels 0-3 with 3 as the highest) with each message signal unit (MSU). Priorities are only used during periods of S-41 mobility management is implemented congestion and only priority levels 0 through 2 by TCAP with ejficient connectionless service. Message can be discarded. Normally this field is ignored. IS-41 message priority levels are either 0 or 1. sequencing is guaranteed by the simple two-message (a Priority 0 is for information and status such as RegistrationNotificationand Registrationcancel- quely and a response) TCAP transactions. lation (see section on mobility management using TCAP). Priority 1 is for establishing calls (e.g., used for load sharing. SLS selects an outgoing trunk or radio channel reservation/release) such linkset and link to the next node. as FacilitiesDirective and MobileOnChannel In the U. S., DPC/OPC is structured in three (see section on interMSC handoff). levels (network identifier, network cluster, and network cluster member) to hierarchically specify Semke lndicator Code (SKI - This field indicates the destinationiorigination node. the upper SS7 layer that will process the message. There are 12 SIC values. Among them, a value of 3 Besides DPC and OPC, the following fields of represents SCCP (e.g., the IS-41 TCAP message), an IS-41 message are processed by the SCCP and a value of 5 represents ISUP (e.g., the wire- (Fig. 8b). lesdwireline call setuphelease message). Message Type - This field uniquely defines the Routing Label- This field contains the information function and format of each SCCP message. necessary to deliver the message to its destination Eighteen message types were defined for the SCCP. point. There are three sub-fields. Two message types are introduced in this article.

-,,' Priority = 0 or 1

SIC = 3 --_ ing jsccp1'...\.

[TI

(a) The MTP message (b) The SCCP message

I II National/lntl. I RI = 0 - Address RI = 1 .1 i Address GT ind. = 2 GT ind. = 0 SPC ind. = 0 SPC ind. = 1 SSN ind. = 1 SSN ind. = 1 GT translation type SPC GT address Address Address 'yDq SSN

(c) Calledlcalling party address format (d) Called/calling party address format (without global title translation) (with global title translation) 1

~ ~- - ~ _- W Figure 8 The IS-41message format (only SCCPMTP-related fields are shown).

IEEE Personal Communications June 1995 53 do not require in-sequence delivery.We have shown how in-sequencedelivery is guaranteed in IS-41 transactions. TCAP 1 Pointers - These fields point to the beginning of Construct myeY the called, calling, and data fields. UnitData CalZed/Calling Party Address - These fields have and set a length indicator and the following sub-fields return (Figs. 8 c and d). Address Indicator - This field indicates the type of addressinformation contained in the called/calling party, as follows: National/International - indicates whether the address coding is based on the U.S. standard or the international standard. RoutingIndicator-(RI) identifieswhichaddress RI=l element should be used for routing. If RI = 0, the routing uses the global title in the address. No If RI = 1, the routing uses DPC (in the routing Yes label) and the subsystem number (to be elaborated) in the called party. Global Title Indicator - There are four num- bers assigned for U.S. networks. IS-41 messages U use two of the four types: Code 0 indicates that no global title is included, and Code 2 indicates that global title includes translation type only (i.e., the GTT is performed by using the GT translation type and the GT address; see the address field). Point CodeIndicator-Thevalue 1indicates that the address contains a signaling point code. Subsystem Indicator-Thevalue 1 indicates that the address contains a subsystem number. When aglobal title is used, the address should also W Figure 9. The SCCP routingprocedures for IS-41 messages. contain a subsystem number, and thus the subsystem indicator is 1.

Address - This field is of variable length. The The normal IS-41 messages are of type 9 (Unit- various elements,when provided, occur in the order DaTa or UDT). The SCCP returns a UnitDaTa described below. Service message (UDTS; SCCP message type 10) when a received UDT message cannot be deliv- 7) Signaling Point Code (SPC) - The code has ered to the specified destination and has the the same format as OPCIDPC. When an originat- “return message on error” option set. (See the Option ing node sends an IS-41 message with a global field.) title, the OPC of the message is replaced by the address of the STP that performs the G’IT. Thus, the Option - This field is used to decide whether to SCCP calling party address field should include “return” on error or not. Rulesfor selecting the option the SPC and the SSN of the originating node. values are not defined in IS-41. 2) Global Title - The IS-41 messages use type 2 Protocol Class - The SCCP provides four classes (see global title indicator field) global title trans- of connection/connectionless service. The IS-41 lation, and the global title consists of two ele- messages are supported by the basic connection- ments. less service (Class 0 service). This service does GT translation type-The translation type isused not provide for segmenting/reassembling, flow to direct the message to the appropriate global control or in-sequence delivery. title translation table. It may also provide the Note that with the segmenting/reassembling context under which the global title digits are function, a message exceeding 255 bytes is seg- to be interpreted. For example, Code 254 rep- mented into more than one SCCP data transfer resents 800 service translation. Code 003 (cel- message. When the destination SCCP receives these lular nationwide roaming) is used for the IS-41 messages, it reassembles the original message for messages. deliveryto the destination SCCP user. Although the GT address - The global title address in an IS- segmentindreassembling function is not used in the 41 message is the 10-digit MIN, or the dialed IS-41 standard, we expect that this function (i.e., mobile number. Class 1service) maybe required in some IS-41 imple- Global title may be used in a calling party address. mentations where long user profile messages are This is optional depending on the security require- exchanged. ments of network interconnections. With in-sequence delivery, the SCCP sets the signal link selection (SLS) code to the samevalue for 3) Subsystem Number (SSN) - This field identifies all messages in the message stream. IS-41 messages an SCCP application functionat the destinationnode.

54 IEEE Personal Communications June 1995 _- Six of the fourteen SSNs are described in IS-41. SSN 5 Mobile Application Part (MAP) all setuplrelease between a PCN and the SSN 6 Home Location Register (HLR) SSN 7 Visitor Location Register (VLR) PSTN follows standard ISUP procedures. In the PSTNs SSN 8 Mobile Switching Center (MSC) view, PCN call control is similar to other applications such SSN 9 Equipment Identification Register (EIR). This code is reserved in IS-41. as 800 service. SSN 10 Authentication Center (AC). This code is reserved in IS-41 B but will be accommodated Case 1.1.2 (Step 10) The DPC is not the node itself. in IS-41 C. There are two possibilities. If GTT is required, the address of an IS-41 *Case 1.1.2.1 (Step 1l)] If the DPC cannot be message always contains a subsystem number. used to deliver the message, an error occurs. Before GTT, the SSN is encoded 0. After the The Return procedure is invoked (Step 5). translation, the actual SSN is given. *Case 1.1.2.2 (Step 11) If the DPC is appropriate, the message will be sent to the MTP for delivery. If RI = 1 (Step 12), it implies that The Routing Procedure G'IT will not be performed. In this case, an appropriate SSN is required (Step 14) before igure 9 illustrates the SCCP routing for an the message is sent to the MTP (Step 17). IS-41 message. We note that this procedure If RI = 0 at Step 12, GTT is necessary. is ageneral routing procedure and is not unique Since the actual SSN is not expected before to IS-41. The message processed by the SCCP may the GTT, the message is sent directly to the came from the MTP layer or the TCAP layer. MTP without checking the SSN status.

Case 7 Case 7.2 (the DPC is not specified at Step 7) - A The IS-41 message is transferred from the TCAP GTT is required to find the DPC (and the SSN). to the SCCP (Step 1 in Fig. 9). A UDT message This case occurs when an MIN is used to access is constructed based on the information provid- theHLR.IfRI= 1 atStep8(noGTTrequired),then ed by the MAP/TCAP (Step 4). One of the fol- an error occurs. If RI = 0, GTT is performed at lowing two events occurs. Step 6. Before the translation, the SSN is 0, the translation type is 3 (Cellular Nationwide Roaming Case 1.7 - (the DPC is specified at Step 7). There Services), and the global title is the 10-digit MIN. are two possibilities. Since the GT indicator is 2 for an IS-41 message, Case 1.1.1 (Step 10) The DPC is the node itself. the 10-digitMIN and the translation type are used for In this case, no G7T is required. Next, the Called the translation. After the translation, both the Party Field is examined. If RI = 0, it must be a DPC and the SSN are specified, and the routingpro- mistake and the Return procedure is invoked cedure proceeds to Step 10 (see Case 1.1). If the (Step 5). The Return procedure returns or dis- translation fails (e.g., the MIN is not recognized cards IS-41 messages (based on the option field) at Step 9), the Return procedure is invoked. which encounter routing failures and cannot be delivered to their final destination. Case 2 If RI = 1, the SSN in the SCCP field is used The IS-41 message is transferred from the MTP to to determine the local subsystem (e.g., HLR, the SCCP (Step 2 in Fig. 9). If RI = 1 (Step 3), then VLR, and so on). If an appropriate subsystem the receiving SCCP is the termination point of number is indicated in the message (Step 15), the message. The action taken is the same as Step then the message is forwarded to that SSN 15 at Case 1.1.1 (with RI = 1). If RI = 0, then the TCAP layer (e.g., a query is sent to the HLR to G7T is required. The Steps 6 and 9 are performed access the user profile) at Step 16. Otherwise, as in Case 1.2. After the GTT is performed, the an error occurs, and the Return procedure is situation is the same as Case 1.1 except that RI = 0 invoked (Step 5). when the message is processed at Steps 12 or 13.

IEEE Personal Communications June 1995 55