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

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
deployedin 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 ( O W ) 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-
ted and can be found in [7].
-/I
Application
The MAP will be elaborated based on the IS- * I I
41 protocol. The other parts of the SS7 protocol
...__________-.--..-.~-~~
are described below.
*The Message Transfer Part (MTP) consists of ISDN-UP
Presentation
three levels corresponding to the OS1physical 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 signalingpoints. The
MTP Level 3 provides the functions and procedures
related to message routing and network manage-
ment.
* T h e Signaling Connection Control Part
I MTP level 3
I
(SCCP) provides additional functions such as
Global Title Translation to the MTP to transfer
non-circuit-related signaling information such as
Data link
I MTP level 2
I
PCS registration and cancellation.
*The Transaction Capabilities Application
Physical I MTP level 1 I
Part (TCAP) provides the ability t o 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-
naling service sends the signalinginformationto each
switching point involved in a call connection.
The IS-41 protocol [12, 1.51 is implemented in
the MAP as an application of the TCAP. The
wireless call setup/release is completed by using
the ISUP. The MTP and the SCCP provide rout-
ing services between a PCN and the PSTN.
lnterconnection and Message
Routing between
PCN and PSTN
everal types of interconnections between a
two for SS7 signaling, and two for trunk (voice
circuit)connections [8].The signaling interfacesrep-
resentsthe physical signalinglink connectionbetween
a PCN and the PSTN. The SS7 signaling inter-
connection methods are described as follows:
A-link signaling interface involvesA-linksfrom
an MSC to a PSTN STP pair (Figs. 3a and c).
OD-linksignaling interface involves D-links
from a PCN STP pair to a PSTN STP pair (Figs.
3b and d).
The trunk interfaces represents a physical SS7-
supported trunkconnection between aPCN and the
PSTN. The types of the SS7 trunk interconnections
are described as follows:
*Type 2A with SS7 trunk interface provides
connection between a PCN and a PSTN tandem

S PCN and the PSTN have been described in

[8, 171. We describe four types of SS7 inter-
connection between a PCN and the PSTN (specif-
ically, the local telephone networks) using SS7:
switch. The Type 2A with SS7 interfaces are shown
in Figs. 3a and b.
*Type 2B with SS7 trunk interface provides
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) CONVERSATIONWITHPERMISSION
FacilitiesDirective RETURN ERROR RESPONSE
ISUP) are not delivered with GTT. Details of IS-
FacilitiesDirective REJECT RESPONSE
41 message routing can be found in Appendix B. The
- 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 IINVOKE ]RESPONSE
~

Using TCAP
QualificationRequest INVOKE(Last) QUERYWITHPERMISSION
wenty six TCAP operations2 are defined in

QualificationRequest
QualificationRequest
QualificationRequest
RegistrationCancellation
RegistrationCancellation
RegistrationCancellation
RegistrattonCancellation
RegistrationNotification
RegistrationNotification
RegistrationNotification
RegistrationNotification
ServiceProfileRequest
T
RETURN RESULT(Last) RESPONSE
RETURN ERROR RESPONSE IS-41.B [ 131 for three purposes: Inter-MSC
REJECT RESPONSE Handoff [15], Automatic Roaming [12], and
Operations, Administration, and Maintenance
INVOKE(Last) QUERYWITHPERMISSION [16]. The details of handoff and automatic roam-
RETURN RESULT(Last) RESPONSE ing (mobility management) alternatives can be
RETURN ERROR RESPONSE found in [21-271.
REJECT RESPONSE A TCAP message consists of two portions: the
INVOKE(Last) QUERYWITHPERMISSION Transaction Portion and the Component Portion.
RElllRN RESULT(Last) RESPONSE The Transaction Portion specifies the Package
RETURN ERROR RESPONSE Type. Four of the seven Package Types [5, 131 are
REJECT RESPONSE defined in IS-41.5-B.3
~~
~YwI~PEREIIssIoNNnitiates aTCAP transaction
INVOKE(Last) QUERYWITHPERMISSION and informs the terminating node that it may ~

ServiceProfileRequest RETURN RESULT(La5t) RESPONSE end the TCAP transaction.

ServiceProfileRequest
ServiceProfileRequest
- - ~ -
I A mobile user may also
be assigned a Universal
Personal Telecommunica-
tion (UPT) number. The
relationship between the
UPT number and the
MIN is illustrated in 1221.
This article assumes that
a mobile user is identified
by the MIN.
In IS-41.C, 28 new oper-
RETURN ERROR RESPONSE
REJECT RESPONSE
~
switch. The Type 2B with SS7 interfaces are shown
in Figs. 3 c and d.
Several applications that require calls to be
tandemed (e.g., operator services and 800 call
setup) are supported by Type 2A with SS7 inter-
face, but are not available to Type 2B with SS7
interface.
Both Types 2A and 2B were originally support-
ed by multi-frequency (MF) signaling protocols
[8]. Other interfaces supported by MF signaling
are Type 1, Type 2C for 911 emergency service
calls, and Type 2D for operator services. Both 911
calls (Type 2C) and operator services (Type 2D)
could be handled along with other types of calls
on a Type 2A with SS7 interface. The details of
MF signaling for PCN can be found in [SI.
We will show how signaling messages a r e
deliveredwith the configurationsin Fig. 3. Basically,
SS7 message routing is performed at the MTP
and the SCCP of a node (SSP, STP, or SCP). At the
MTP level, the signaling messages are delivered
with the actual destination address. The MTP level
receives messages from an adjacent node (SSP,
STP, or SCP) or from the TCAP (and thus the SCCP)
RESPONSEends the TCAP transaction.
CON~E;~SATION~I~~ERMISSION continues a TCAP
transaction and informs the destination node that
it may end the TCAP transaction.
UNIDIRECTIONAL sends information in one direction
only with no reply expected.
The Component Portion specifies the number
and the types of components (operations) to be
performed. Four of the six Component Types are
defined in IS-41 Revision B.4
INVOKE (Last)is used to invoke an operation
(such as location registration). “Last”indi-
cates that the operation is the last component
in the Component Part.
RE”RESULT ( u st ) is used to retum the results
of an invoked operation. If a node receives an
INVOKE and the operation is executed success-
fully, the node shall respond with a RETURN
RESULT.
RETURN ERROR is used to report the unsuccess-
ful completion of an invoked operation. For
example, the MIN in the INVOKE message is
not currently serviced by the HLR.
REJECT is used to report the receipt and rejec-
tion of an incorrect Package or Component
(e.g., ill-formatted). When a node receives a
REJECT message, it stops its timer, exits the
current task, and performs error recovery.
Note that an SS7 transaction alwavs begins
< . ,

ations are expected to be
included.
In IS-41.C, another
Package Type called Con-
versationWithoutPer-
mission will be
introduced.
Same number of the
Cvmponent Types are
expected in IS-41
Revision C.
layer or the ISUP layer of the same node. The
Destination Point Code (DPC) of the message
uniquely identifies the destination node. Routing to
the destination node is determined by the MTP using
look-up tables.
In the mobile application, every handset is
assigned a Mobile Identification Number (MIN).l
When an MIN is dialed, the originating node may
not have enough knowledge to identify the actual
address of the destination. In this case, the actual
destinationaddress is translated by a technique called
Global Title Translation (GTT) performed at the
SCCP level of the protocol. GTT is supported in
with a query message (QueryWithPermission
in IS-41), and ends with a response message
(Responsein IS-41). In IS-41,both the INVOKE and
the RETURN RESULT types are “Last”which
imply that every IS-41 TCAP message performs
exactly one operation. In an IS-41 implementa-
tion, we may expect that operations such as
authentication and registration notificationare com-
bined into a TCAPmessage. In the remainder of this
article, we omit the notation “Last.”All IS-41.B
transactions are two-message (a query and a response)
transactions except for two cases.
*A TCAP message with the operation FlashRe-

46 IEEE Personal Communications June 1995

._I_.^._ - -. ~
 I /1 r-
Tandem MSC
PSTN
(a) Type 2A with 557 trunk interface
supported by a Type 5 A-link
signaling interface
(c) Type 2B with 557 trunk interface
supported by a Type 5 A-link
signaling interface
~~-
Figure 3. Types of interconnection between a PCN and the PSTN.
quest has a PackageType UNIDIRECTIONAL.Thismes-
sage is sent from the serving MSC to the anchor MSC
to convey information for call control. No response
is expected from the anchor MSC, and no TCAP
transaction is established. This message is defined
in IS-41 Revisions B and C, but is not supported
in IS-41 Revision A [12].
* A TCAP transaction including the operation
FacilitiesDirective consists of three messages
exchanges. We will elaborate on this transaction
later.
(In IS-41.C,other transactionssuch as “inter-MSC
setup” also involve more than two messages.) IS-41
TCAP uses SCCP Class 0 connectionless service
[4] that provides efficient routing without main-
taining message sequencing between two or more
messages from the same originating node. Message
sequencing is implied in the two-message IS-41
transactions. For the three-message IS-41 transac-
tions described above, message sequencing is also
guaranteed (to be elaborated).
Every IS-41 TCAP transaction accompaniesa time-
out constraint. Typically, recovery procedures
(definedinIS-41.4B [16]) areexecutedwhen a timer
expires. For most IS-41 transactions timer expira-
..tion is considered as an error (i.e., the arrival of a
RETURN ERROR TCAP message).
We use two examples to illustrate the message
IEEE Personal Communications June 1995
I /L I A
U 1427 Type S (D links)
Tandem
(b) Type 2A with 557 trunk interface
supported by a Type 5 D-link
signaling interface
office
PSTN
(d) Type 2B with 557 trunk interface
supported by a Type S D-link
signaling interface
flows of IS-41 TCAP transactions. The TCAP mes-
sages described in these examples are summa-
rized in Table 1.
Inter-MSC Handoff
The inter-MSC handoff procedures are defined
in IS-41.2 [15]. We assume that the inter-MSC
handoff occurs within a PCN, and the SS7 mes-
sages are not delivered t o the PSTN. Figure 4
illustrates the IS-41 TCAP message flow for
handoff-forward. In this figure, a communicating
handset (mobile user) moves out of the base sta-
tion servedby MSC A. Two transactionsare required
to perform inter-MSC handoff.
Transaction 7 - MSC A sends a HandoffMea-
surementRequest (INVOKE) to the candidate
MSC B, and waits for the response from MSC B.
When MSC B receives the HandoffMeasure-
mentRequest (INVOKE),it selectsacandidate base For simplicity, we
station BS2for handoff. If nocandidate base station express an IS-41 TCAP
is found, MSC B may exit this transaction. Other- message as a pair “Opera-
wise, MSC B sends a HandoffMeasurementRe- tion (Package Type)” or
quest (RETURN RESULT) to MSC A.6 “Component Type.”
Transadeon2 - Before this transaction is started, The result includes the
MSC A checks if the handset has made too many signal quality parameter
handoffs or if inter-MSC trunks are not available. values.
47
 Transaction 2 is a three-message transaction.
Like Transaction 1,Transaction 2is initiated bythe
QUERYWITHPERMISSION message 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-
/ _ _ _ _ _ _ ......____._......~~....~~~~~..~~~~.....~~~~.~...~,
C h a n n e l (INVOKE) message before MSC A
HandoffMeasurementRequest (INVOKE) receives the FacilitiesDirective (RETURN)mes-
sage. 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 ( L M M R T ) . I f L M M R T
FacilitiesDirective (INVOKE) expires before the HandoffMeasurementRe-
c quest (RETURN)arrives, MSC A exits this trans-

1;-
FacilitiesDirective (RETURN RESULT)
MobileOnChannel (INVOKE)
MSC A exits this transaction, and the hand-off call
maybeforcedterminatedif there are toomanyhand-
offs or if there are no trunks. Otherwise, MSC A
sends a FacilitiesDirective (INVOKE) to MSC B.
When MSC B receives the FacilitiesDirective
(INVOKE),it replies with a FacilitiesDirective
(RETURN ERROR) if no voice channel is available
in BS2.' If BS2 is available to accommodate the
call, MSC B replies with a FacilitiesDirective
*
( R E T " RESULT) to MSC A.
When MSC A receives the FacilitiesDirective
(RETURN), one of the following two events occurs.
If the message is a RETURN ERROR,then MSC A
executes recovery procedures and exits the trans-
action. If the message is a R E T " RESULT,then
MSC A sends the handset a handoff order.
After the handset is connected to BS2, MSC B
sends a MobileOnChannel (INVOKE)to MSCAand
exits this transaction.
When MSC A receives the MobileOnChannel
(INVOKE),it connects the call path (trunk) to
MSC B and exits this transaction.
T h e IS-41 TCAP messages are delivered
through the PCN SS7 signaling links. (See dashed
links 1 and 2 in Fig. 4. In this example, an STP is
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-
mentRequest (REJECT) message to inform MSC
B that Transaction 1 has been terminated without
completion. At the beginning of Transaction 2,
MSC A sets a 12-second timer HOT. If H O T
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
from MSC B, it stops HOT. MSC A expects to
receive subsequent messages from MSC B, and
another 7-second timer HMOT is set. If HMOT
expires before the MobileOnChannel (INVOKE)
arrives,then MSCAexitsTransaction 2 and reclaims
the resources.
Mobile Registration
Figure 5 illustrates the message flow for the regis-
tration and validation process as a mobile user
roams from PCN 1 to PCN 2. This figure assumes
that an MSC and the corresponding VLR are
connected by an STP. In reality, it is more likely
that the VLR is collocated with the MSC. The
process consists of six two-message TCAP trans-
actions. When MSC 2 detects that the mobile
user is in its service area, it initiates Transaction 1
witha RegistrationNotification (INVOKE) toitsVLR
(VLR 2).
If both MSCs 1 and 2 are served by VLR2,
VLR 2 finds that the mobile user had previously
registered with an MSC within the domain of
VLR 2. In this case, VLR 2 may take no further
action other than to record the identity of MSC 1.
Otherwise, VLR 2 initiates Transaction 2 by
sending a RegistrationNotification (INVOKE)to

The error code of the
message is resource
shortage[13].
The result includes the
parameters of the selected
voice channel.
-
in the signaling path.) Before the handoff, the
voice path is (3) ++ (4) ++ (5). If the handoff is
successful, the new voice path is ( 3 ) H (4) H (6)
(7).
Transaction 1is a typical two-message IS-41trans-
action . T h e H a n d off Me a s u r e m e nt Req u est
(INVOKE)is of type QUERYWITHPERMISSION. With
this Package Type, MSC A implies that MSC B
may end this transaction after the response is
sent. The message replied from MSC B is of type
RESPONSE,which terminates the transaction.
the mobile user's HLR. Note that this TCAP
message is likely to be routed by using the global
title translation because VLR 2 may not recog-
nize the actual address of the HLR by the mobile
user's MIN. Thus, the mobile user's MIN is used
as the global title address, and the translation
type of the message is marked "3"for CellularNation-
wide Roaming Services (see Appendix B for more
details). Our example assumes that STP 3 will per-
formGTT(i.e.,theDPCof themessage points to STP
3). After global title translation,the actual destination

48 IEEE Personal Communications June 1995

 1 PCNl PSTN
t 6-
Registrationcancellat o n (INVOKE)
*
RegistrationCancellat on (RETURN RESULT)
-
Registrationcan dlation (INVOKE)
d Registrationcan illation (RETURN RESULT)
I
d‘
W Figure 5.7s-41 TCAP message flow for mobile registration.
address is found. STP 3 forwards this message to STF’
2 and thus to the HLR. The HLR confirms the reg-
istration by sending a Registration N o t if ica t i o n
(RETURN RESULT) to VLR 2. This message may
be delivered without global title translation
because the actual address of VLR 2 is included
as part of the SCCP in the previous Registra-
tionNotification (INVOKE)sent from VLR 2 to the
HLR. Note that Transaction 2 is nested within
Transaction 1.
The HLR sends a RegistrationCancellation
(INVOKE)to the mobile user’s previously visited
VLR (VLR 1) to cancel the obsolete registration
record (see Transaction 3). T h e cancellation
propagates to MSC 1 (see Transaction 4). Since
the actual address of VLR 1 has been recorded in
the HLR (in the previous registration operation),
the cancellation message may be delivered by
using the actual HLR address (Le., no GTT is
required). Note that the cancellation process (see
Transactions 3 and 4) can be performed at any
time after Transaction 2.
After Transaction 2 is completed, VLR 2creates
IEEE Personal Communications June 1995
. .
PCN2
I
RegistrationNotifica‘ion (INVOKE)
RegistrationNotification (RETURN RESULT)
QualificationRequest (INVOKE)
QualificationReques’ (RETURN RESULT)
t
ServiceProfileReques: (INVOKE)
ServiceProfileRequesI(RETURN RESULT
*
a registration record for the mobile user, and
may send a QualificationRequest (INVOKE)to
the HLR in order to authenticate the mobile user
(see Transaction 5) [18].
VLR 2 may also send a ServiceProfileRequest
(INVOKE)to the HLR to obtain the service pro-
file for the roaming mobile user (see Transaction 6).
Transaction 6 is required in some call delivery
schemes [21,24].
PCNIPSTN Call Control
Using I S U P
he ISUP messages a r e used for call
T setuphelease between the PSTN and a PCN
in the interconnection networks using Type
2A or Type 2B with SS7 trunk interfaces (see the
section, “Interconnection and Message Routing
between PCN and PSTN”). Nine of the 57 ISUP
message types [2] are discussed in this section for
basic call setup. Figure 6 illustrates the typical
49

t
ACM ACM
+ Step 3
ANM ANM
Step 4
Step 5 - REL
REL
L
Signaling path from
PSTN to PCN
Signaling path from
PCN to PSTN e4bQ+e-.9
m g K 6 . Typical message flowfor Type 24 with Sfiland-to-mobile call setup
~~
and release involving a tandem switch.
message flow for Type 2A with SS7 land-to-mobile
call setuphelease involving a tandem switch (see Fig.
3b). For other interconnection configurations, the
message flows between the originating switch and
the terminating switch are the same although the sig-
naling and trunk paths may be different.
The call setup procedure is described in the
following steps [2, 7, 101.
Note that Steps 1-6 of the call setup procedure
is general and is not unique to the mobile appli-
cations. These steps are presented to provide the
reader a complete message flow of wireline-to-
wireless call setup.
Step 0 - When an MIN is dialed, the E O notices
that the number is for wireless service. The EO
sends a query message to obtain the mobile user’s
Temporary Local Directory Number (TLDN)
[14]. The messages exchanged among switches,
VLR, and HLR are TCAP messages described in
Fig. 2, IS-41.3 [12]. These messages may be deliv-
ered with or without GTT. This example assumes
that the EO has the capability to query the HLR.
(Otherwise, the MIN must be routed from the EO
to a specific switch for location query and call
setup [9].)
If the called party (mobile user) is busy,
the situation is detected at this stage and a busy
indication is returned to the calling party (see
The ISUP messages Fig. 3 in IS-41.3 [12]). If the mobile user has call
akcn‘bed in thefollowing forwarding or call waiting services, the busy line
steps are delivered by situation is handled differently (see Figs. 6 and 9
MTP routing. in [12]).
50
__ __ --
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 informa-
tion is carried by the IAM. The IAM also indi-
cates 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
period.
Step 2 (if necessary) - If the IAM sent from the
E O to the tandem specifies a continuity check,
the selected trunk from the tandem to the EO is
checked to ensure a satisfactory transmission
path. After the continuity check is successfully
completed, a Continuity Message (COT) is sent
from the E O to the tandem, and the trunk is set
up. The same procedure could be performed
when the MSC receives the IAM from the tan-
dem.
Step3 - When the IAM arrivesat the MSC, the MSC
pages the mobile user. One of the following three
events occurs:
-The mobile user is connected with another
call (the call setup occurs between the end of
Step 0 and the end of Step 2). This situation is
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
to the EO (to be described in Step 5) with a cause
indicating the busy line.
*If the mobile user is idle, an Address Com- I
plete Message (ACM) is sent from the MSC to
the EO. The message indicatesthat the routing infor-
mation required to complete the call has been
received by the MSC. The message also informs
the E O of the mobile user information, charge
indications, and end-to-end protocol requirements.
The MSC provides an audible ring through the
setup trunk to the calling party. When the EO receives
the ACM, the IAM timer is stopped. The ACM
(and other ISUP messages) sent from the MSC
to the EO follows the path (5) + (4) + (2) + (3)
--;r (1) in Fig. 6.
*Ifthemobileuserdoesnot answerthe page, the
MSC may redirect the call based on an appropri-
ate procedure or return an REL message to the
EO (see Fig. 7 in IS-41.3 [12]).
Step 4 - When the mobile user answers the call,
an Answer Message (ANM) is sent from t h e
MSC to the EO to indicate that the call has been
answered. At this moment, the call is established
(through the trunk path (6) and (7) in Fig. 6) and
the conversation begins.
Step 5 - After the conversation is finished, the
call can be disconnected with procedures depend-
ing upon who hangs up first. Figure 6 assumes
that the calling party hangs up first. (In the next
example, we will illustrate the case when the
called party hangs up first.) T h e EO sends a
IEEE Personal Communications June 1995
Release Message ( R E L ) t o indicate that the
specified trunk is being released from the con-
nection. The specified trunk is released before
the R E L 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 E O (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.
The message flow for call setup is very similar
to the previous example except that an Exit mes-
sage (EXM) is sent from Tandem 1 to the MSC to
indicate that SS7 call setup information has suc-
cessfully progressed to the IXC. The EXM is sent
to the MSC when Tandem 1 has received an ACM,
ANM or R E L from the IXC or when an EXM
timer expires at Tandem 1. (Our example assumes
that the EXM timer expires first.) The timer is
set after an IAM is sent from Tandem 1 to the IXC.
The sending of the EXM does not affect the com-
pletion of any continuity check required on the
trunkbetween theMSCandTandem 1 . 0 n theother
hand, if a COT code “continuity check failed” is
received for this trunk, the EXM is not sent to
the MSC.
The call release procedure in this example
assumes that t h e called party hangs up first,
which is different from the previous example.
When the called party (the wireline user in this
example) hangs up the phone, a Suspend Mes-
sage (SUS) is sent from the E O at LEC2 to the
MSC to indicate that the called party has discon-
nected. The EO expects one of the following two
events to occur within a timeout period (14-16
seconds).
An RELfrom the MSCis received by the EO. The
EO disconnects the trunk.
T h e called party goes back off-hook. T h e
connection continues, and a Resume Mes-
sage ( R E S ) is s e n t f r o m t h e E O t o t h e
MSC (not shown in Fig. 7). The SUS timer is
stopped.
If the SUS timer expires, the E O disconnects
the trunk, and an REL is sent to the MSC. Upon
the receipt of the SUS, the MSC expects one of
the following three events to occur within a time-
out period (10-32 seconds).
The calling party hangs up. The MSC sends an
REL to the EO and disconnects the trunk.
An R E L (from the EO) arrives at the MSC.
The MSC disconnects the trunk.
An RES (from the EO) arrives at the MSC.
The SUS timer is stopped and the connection con-
.. tinues.
If the SUS timer expires, the MSC disconnects
the trunk.
I Conversation I
-~ _ _ - _ _ _ _ -. ____
Figure 7.Typical messageflow for Type 2A with SS7mobile-to-land call setup
and release involving a tandem switch.
Conclusions and Further
Reading
e have discussed the SS7-supported
W interactions between PSTN and PCN.
Specifically,we assumed that the mobile
communications protocol is IS-41. The purpose
of this article is to provide a quick overview of
the wireless-related signaling.
We described two types of SS7-supported
trunk connections, and two types of signaling
links between a PCN and the PSTN. If the trunk
is connected from the PCN to a PSTN end office,
then 911 calls and operator services may not be
supported. These servicesonly are supportedvia the
PCN trunkconnected to a PSTN access tandem. The
reader is referred to [8, 171 for more details.
All messages for mobility management are
implemented by the TCAP of SS7. Signaling mes-
sages related to call setupirelease are implement-
ed by the ISUP of SS7. All signaling messages are
routed between PCN and PSTN by the MTP and
SCCP of the SS7 protocols.
If the actual destination address is known, the
IS-41 TCAP messages a r e delivered without
global title translation. All ISUP messages for
call control are delivered without global title
translation. For IS-41TCAP messagesusing the mobile
users’ MINs, the actual destination addresses
may not be known. The destination addresses are
translated by the SCCP using global title transla-
tion. The reader is referred to [6,9, 111 for fur-
ther reading.
IS-41 mobility management is implemented by
TCAP with efficient connectionless service (i.e.,

IEEE Personal Communications June 1995 51

 out-of-order message delivery). Message sequenc-
ing is guaranteed by the simple two-message (a query
and a response) TCAP transactions. The reader is
referred to [ 12, 15, 19) for further reading.
Call setup/release between a PCN and the
PSTN follows standard ISUP procedures.
In the PSTN’s view, PCN call control is similar
to other applications such as 800 service. The
reader is referred to [6, 101 for further reading.
Acknowledgment
The professional review process provided by
Hamid Ahmadi is highly appreciated. Li-Fung Chang,
Zheng Chen, Robert Ephraim, Dipak Ghosal, Chris
Holmgren, Don Lukacs, Bob Schaefer, Howard
Sherry, Ding G. Wang, Fu-Lin Wu, and the anony-
mous reviewer provided valuable comments to
improve the quality of this article.
References
[11 A. R. Modarressi. and R. A. Skoog. Signaling System No. 7: A Tutorial,
IEEE Commun. Mag., vol. 28, no 7, July 1990.
[21 ANSI, American national standard for telecommunications - Signaling
system number 7: Integrated services digital network (ISDN) user
part, Issue 2, Rev. 2, Technical Report ANSI 11.1 13, ANSI, 1992.
[31 ANSI, American national standard for telecommunications - Sig-
naling system number 7: Message transfer part (MTP), Issue 2,
Rev. 2, Technical Report ANSI 11.111, ANSI, 1992.
(41 ANSI, American national standard for telecommunications - Sig-
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-
naling system number 7. Transaction capabilities application part
(TUP). Issue 2, Rev. 2, Technical Report ANSI T1.114. ANSI, 1992.
161 Bellcore Bell Communications Research specification of signaling
system number 7, Issue 2, Technical Report TR-NWT-000246,
Bellcore. 1991
[71 Bellcore. Common channel signaling network interface specifica-
tion supporting network interconnection, message transfer part,
and integrated services digital network user part, Issue 2, Techni-
cal Report TR-TSV-000905,Bellcore, 1993.
181 Bellcore. Compatibility information for interconnection of a wireless
services provider and a local exchange carrier network, Issue 2,
Technical Report TR-NPL-000145.Bellcore, 1993.
[91 Bellcore, PCS Access services interface specification i n support of
PCS routing service. PCS home database service, and PCS IS-41
message transport service. Issue 1, Technical Report TA-TSV-
001411, Bellcore. 1993.
[ l o 1 Bellcore. CCS Network Interface Specification Supporting Wireless
Services Providers, Issue 1, Technical Report GR-1434-CORE.
Bellcore, 1994.
1111 Bellcore. LSSGR: Common Channel Signaling Section 6.5. Techni-
cal Report GR-606-CORE, Bellcore. 1994.
I121 ElAITlA Cellular radio-telecommunications intersystem operations:
Automatic roaming, Technical Report 15-41.3-8. EIAITIA. 1991.
[131 EIAITIA. Cellular radio-telecommunications intersystem opera-
tions: Data communications.Technica1ReportlS-41.5-6,EIMIA, 1991
[14] ElMIA. Cellular radio-telecommunications intersystem operations:
Functional overview. Technical Report IS-41 1-6, EIMIA. 1991
[151 EIAITIA, Cellular radio-telecommunications intersystem operations:
Intersystem handoff, Technical Report IS-41.2-E. EIAITIA, 1991
1161 EIAITIA, Cellular radio-telecommunications intersystem opera-
tions Operations. administration. and maintenance. TechnicalReport
IS-41.4-6. EIMIA. 1991
1171 EIMIA. Cellular radio telecommunications interfacesstandard. Tech-
nical Report 15-93, EIAITIA. 1993
[181 EIAITIA. Cellular radiotelecommunications intersystem operations
authentication. signaling message encryption and voice privacy.
Technical Report TSB-51, EIAITIA, 1993.
[191 EIAITIA, Cellular Intersystem Operations - Baseline Text Draft 3
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-
cations, M Mouly. 49 rue Louise Bruneau, Palaiseau, France, 1992.
[211 R. Jain e t al.. “A caching strategy t o reduce network impacts of
PCS.”lEEEJSAC,vol. 12, no.8. 1994, pp. 1434-1445.
1221 5 Mohan and R Jain, Two user location strategies for personal
communications services IPCS). IEEE Personal Commun.. vol. 1.
no. 1, 1Q 1994, pp. 42-50
[231S. Tekinaty and B. Ja bbari, ”Handover policies and channel assignment
strategiesin mobilecellularnetworks.”IEEECommun.Mag., vol 29, no
11, Nov. 1991.
I241 YB: . Lin. “Determining the user locations for personal communi-
cations networks,” IEEE Trans. Veh. Technol.. vol. 43, no. 3, 1994.
pp. 466-473.
1251Y -B. Lin, and A Noerpel. “Implicit Deregistration in a PCS Network.”
IEEE Trans Veh Technol , vol 43. no. 4, 1994, pp. 1006-1010.
[26]Y -6. Lin. S Mohan, and A Noerpel. “Queueing Priority ChannelAssign-
ment Strategiesfor Handoff and Initial Access fora PCS Network.” IEEE
Trans. Veh Technol , vol 43. no. 3, 1994. pp. 704-712
[27] Y -B. Lin, S . Mohan,and A. Noerpel. “Channel Assignment Strate-
gies for Hand-off and Initial Access for a PCS Network.” IEEE Pers.
Commun , vol 1, no. 3. 3 0 1994, pp. 47-56
Biographies
YI-BING LIN received a B S E E. from National Cheng Kung University in
1983. and a Ph.D in computer science from the University of Wash-
ington in 1990. Since then, he has been w i t h the Applied Research
Area at Bellcore. Morristown. New Jersey. His current research inter-
ests include design and analysis of personal communications services
network, distributed simulation, and performance modeling. He i s a
subject area editor of the Journal o f Parallel and Distributed Computing,
an associateeditor of the International Journal in Computer Simulation, an
associateeditor of SIMULATION magazine.a memberof theeditorial board
of the lnternationallournalof Communications, a member of the editorial
board of Computer Simulation Modeling and Analysis, program chair
for the 8th Workshop on Distributed and Parallel Simulation, and Gen-
eral Chair for the 9th Workshop on Distributed and Parallel Simula-
tion. Heis an adjunct researchfellow at the Centerforlelecommunications
Research, National Chiao-Tung University, Taiwan. R. 0. C.
STEVEN K. DEVRIEShas been involved with the 557 protocol since 1985
as a technical manager and a network planner for Illinois Bell. Since
1991 he has been an instructor in the Intelligent Network district at
Bellcore TEC in Lisle. Illinois, where he teaches various 557, network,
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
Message Format
Figure 8a illustrates the fields of the IS-41 message
that will be processed in the MTP. The fields are
described below.
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
congestion and only priority levels 0 through 2
can be discarded. Normally this field is ignored.
IS-41 message priority levels are either 0 or 1.
Priority 0 is for information and status such as
RegistrationNotificationand Registrationcancel-
lation (see section on mobility management using
TCAP). Priority 1 is for establishing calls (e.g.,
trunk or radio channel reservation/release) such
as FacilitiesDirective and MobileOnChannel
(see section on interMSC handoff).
S e m k e lndicator Code (SKI - This field indicates
the upper SS7 layer that will process the message.
There are 12 SIC values. Among them, a value of 3
represents SCCP (e.g., the IS-41 TCAP message),
and a value of 5 represents ISUP (e.g., the wire-
lesdwireline call setuphelease message).
Routing Label- This field contains the information
necessary to deliver the message to its destination
point. There are three sub-fields.
-,,' Priority = 0 or 1
SIC = 3
--_
ing
jsccp1'...\.
[ T I
(a) The MTP message
I
- .1
National/lntl.
RI = 1 Address
GT ind. = 0
SPC ind. = 1
SSN ind. = 1
SPC
SSN
Address
(c) Calledlcalling party address format
(without global title translation)
1
~ _-
W Figure 8 The IS-41message format (only SCCPMTP-related fields are shown).
IEEE Personal Communications June 1995
Destination Point Code (DPC) - A 9-digit
number that uniquely identifies the node that
the message is bound for.
Originating Point Code (OPC) - A 9-digit
number that uniquely identifies the node that
the message came from.
Signaling Link Selection (SLS) - This field is
S-41 mobility management is implemented
by TCAP with ejficient connectionless service. Message
sequencing is guaranteed by the simple two-message (a
quely and a response) TCAP transactions.
used for load sharing. SLS selects an outgoing
linkset and link to the next node.
In the U. S., DPC/OPC is structured in three
levels (network identifier, network cluster, and
network cluster member) to hierarchically specify
the destinationiorigination node.
Besides DPC and OPC, the following fields of
an IS-41 message are processed by the SCCP
(Fig. 8b).
Message Type - This field uniquely defines the
function and format of each SCCP message.
Eighteen message typeswere defined for the SCCP.
Two message types are introduced in this article.
(b) The SCCP message
I
i RI = 0
I I
Address
GT ind. = 2
SPC ind. = 0
SSN ind. = 1
'yDq
GT translation type
GT address Address
(d) Called/calling party address format
(with global title translation)
~
~
~- -
53

TCAP
1
Construct
UnitData
myeY
and set
return
RI=l
No
Yes
U bers assigned for U.S. networks. IS-41 messages
W Figure 9. The SCCP routingprocedures for IS-41messages.
The normal IS-41 messages are of type 9 (Unit-
DaTa or UDT). The SCCP returns a UnitDaTa
Service message (UDTS; SCCP message type 10)
when a received UDT message cannot be deliv-
ered to the specified destination and has the
“return message on error” option set. (See the Option
field.)
Option - This field is used to decide whether to
“return” on error or not. Rulesfor selectingthe option
values are not defined in IS-41.
Protocol Class - The SCCP provides four classes
of connection/connectionless service. The IS-41
messages are supported by the basic connection-
less service (Class 0 service). This service does
not provide for segmenting/reassembling, flow
control or in-sequence delivery.
Note that with the segmenting/reassembling
function, a message exceeding 255 bytes is seg-
mented into more than one SCCP data transfer
message.When the destination SCCP receivesthese
messages, it reassembles the original message for
deliveryto the destination SCCP user. Although the
segmentindreassembling function is not used in the
IS-41 standard, we expect that this function (i.e.,
Class 1service)maybe required in some IS-41 imple-
mentations where long user profile messages are
exchanged.
With in-sequence delivery, the SCCP sets the
signallink selection (SLS) code to the samevalue for
all messages in the message stream. IS-41 messages
54
_-
do not require in-sequence delivery.We have shown
how in-sequencedelivery is guaranteed in IS-41 trans-
actions.
Pointers - These fields point to the beginning of
the called, calling, and data fields.
CalZed/CallingParty Address - These fields have
a length indicator and the following sub-fields
(Figs. 8 c and d).
Address Indicator -This field indicates the type
of addressinformationcontained in the called/call-
ing party, as follows:
National/International - indicates whether
the address coding is based on the U.S. stan-
dard or the international standard.
RoutingIndicator-(RI) identifieswhichaddress
element should be used for routing. If RI = 0,
the routing uses the global title in the address.
If RI = 1, the routing uses DPC (in the routing
label) and the subsystem number (to be elabo-
rated) in the called party.
Global Title Indicator - There are four num-
use two of the four types: Code 0 indicates that
no global title is included, and Code 2 indicates
that global title includestranslation 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
contain a subsystem number, and thus the sub-
system indicator is 1.
Address - This field is of variable length. The
various elements,when provided, occur in the order
described below.
7 ) Signaling Point Code (SPC) - The code has
the same format as OPCIDPC. When an originat-
ing node sends an IS-41 message with a global
title, the OPC of the message is replaced by the
address of the STP that performs the G’IT. Thus, the
SCCP calling party address field should include
the SPC and the SSN of the originating node.
2) Global Title - The IS-41 messages use type 2
(see global title indicator field) global title trans-
lation, and the global title consists of two ele-
ments.
GT translation type-The translation type isused
to direct the message to the appropriate global
title translation table. It may also provide the
context under which the global title digits are
to be interpreted. For example, Code 254 rep-
resents 800 service translation. Code 003 (cel-
lular nationwide roaming) is used for the IS-41
messages.
GT address - The global title address in an IS-
41 message is the 10-digit MIN, or the dialed
mobile number.
Global title may be used in a calling party address.
This is optional depending on the security require-
ments of network interconnections.
3) Subsystem Number (SSN) - This field identifies
an SCCPapplication functionat the destinationnode.
IEEE Personal Communications June 1995
Six of the fourteen SSNs are described in IS-41.
SSN 5 Mobile Application Part (MAP)
SSN 6 Home Location Register (HLR)
SSN 7 Visitor Location Register (VLR)
SSN 8 Mobile Switching Center (MSC)
SSN 9 Equipment Identification Register
(EIR). This code is reserved in IS-41.
SSN 10 Authentication Center (AC). This code
is reserved in IS-41 B but will be accommodated
in IS-41 C.
If GTT is required, the address of an IS-41
message always contains a subsystem number.
Before GTT, the SSN is encoded 0. After the
translation, the actual SSN is given.
The Routing Procedure
igure 9 illustrates the SCCP routing for an
IS-41 message. We note that this procedure
is ageneral routing procedure and is not unique
to IS-41. The message processed by the SCCP may
came from the MTP layer or the TCAP layer.
Case 7
The IS-41 message is transferred from the TCAP
to the SCCP (Step 1 in Fig. 9). A UDT message
is constructed based on the information provid-
ed by the MAP/TCAP (Step 4). One of the fol-
lowing two events occurs.
Case 1 . 7 - (the DPC is specified at Step 7). There
are two possibilities.
Case 1.1.1 (Step 10) The DPC is the node itself.
In this case, no G7T is required. Next, the Called
Party Field is examined. If RI = 0, it must be a
mistake and the Return procedure is invoked
(Step 5). The Return procedure returns or dis-
cards IS-41 messages (based on the option field)
which encounter routing failures and cannot
be delivered to their final destination.
If RI = 1, the SSN in the SCCP field is used
to determine the local subsystem (e.g., HLR,
VLR, and so on). If an appropriate subsystem
number is indicated in the message (Step 15),
then the message is forwarded to that SSN
TCAP layer (e.g., a query is sent to the HLR to
access the user profile) at Step 16. Otherwise,
an error occurs, and the Return procedure is
invoked (Step 5).
IEEE Personal Communications June 1995
all setuplrelease between a PCN and the
PSTN follows standard ISUP procedures. In the P S T N s
view, PCN call control is similar to other applications such
as 800 service.
Case 1.1.2 (Step 10)The DPC is not the node itself.
There are two possibilities.
*Case 1.1.2.1 (Step 1l)] If the DPC cannot be
used to deliver the message, an error occurs.
The Return procedure is invoked (Step 5).
*Case 1.1.2.2 (Step 11) If the DPC is appro-
priate, the message will be sent to the MTP
for delivery. If RI = 1 (Step 12),it implies that
G'IT will not be performed. In this case, an
appropriate SSN is required (Step 14) before
the message is sent to the MTP (Step 17).
If R I = 0 at Step 12, GTT is necessary.
Since the actual SSN is not expected before
the GTT, the message is sent directly to the
MTP without checking the SSN status.
Case 7.2 (the DPC is not specified at Step 7)- A
GTT is required to find the DPC (and the SSN).
This case occurs when an MIN is used to access
theHLR.IfRI= 1atStep8(noGTTrequired),then
an error occurs. If RI = 0, GTT is performed at
Step 6. Before the translation, the SSN is 0, the
translation type is 3 (Cellular Nationwide Roaming
Services), and the global title is the 10-digit MIN.
Since the G T indicator is 2 for an IS-41 message,
the 10-digitMIN and the translation type are used for
the translation. After the translation, both the
DPC and the SSN are specified, and the routingpro-
cedure proceeds to Step 10 (see Case 1.1). If the
translation fails (e.g., the MIN is not recognized
at Step 9), the Return procedure is invoked.
Case 2
The IS-41 message is transferred from the MTP to
the SCCP (Step 2 in Fig. 9). If RI = 1 (Step 3), then
the receiving SCCP is the termination point of
the message. The action taken is the same as Step
15 at Case 1.1.1 (with RI = 1). If RI = 0, then the
G 7 T is required. The Steps 6 and 9 are performed
as in Case 1.2. After the GTT is performed, the
situation is the same as Case 1.1 except that RI = 0
when the message is processed at Steps 12 or 13.
55