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 operations. 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 interfaces 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, current location,validationperiod).The Visitor LocationRegister(VLR)
is the location register other than the HLR used to retrieve information 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
which provides control and management in the telephone
network. CCS consists of supervisory functions, addressing, 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 interconnection. The reader is referred to [ 11 for a more complete
SS7 tutorial.
C
The SS7 Network Architecture
Figure 1 illustrates an example of the SS7 signaling network.
The figure only shows the parts that involve the interconnection between a PCN and the PSTN. The network consists of
three distinct components.
*Service Switching Point (SSP) is a telephone switch interconnectedbySS7links.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 messagesbetween 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 providing 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 suppliers have limited the number to 16.
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
A-Link
A-Link
I
The SS7 Protocol
The basic parts of the SS7 protocol and the corresponding OS1 layers are shown in Fig. 2. In the
protocol hierarchy, the Operations, Maintenance,
and AdministrationPart ( O W ) and Mobile Application Part (MAP) are TCAP (i.e., Transaction
Capabilities Application Part; to be defined)
applications. The details of the OMAP are omitted and can be found in [7].
The MAP will be elaborated based on the IS41 protocol. The other parts of the SS7 protocol
are described below.
*The Message Transfer Part (MTP) consists of
three levels corresponding to the OS1physical layer,
data link layer, and network layer, respectively.
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 management.
* T h e Signaling Connection Control Part
(SCCP) provides additional functions such as
Global Title Translation to the MTP to transfer
non-circuit-related signaling information such as
PCS registration and cancellation.
*The Transaction Capabilities Application
Part (TCAP) provides the ability t o exchange
information between applications using non-circuit
related signaling.
*Integrated Services Digital Network User
Part (ISUP) establishes circuit-switched network
connections (e.g., call setupirelease). Pass-alongsignaling 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 routing services between a PCN and the PSTN.
lnterconnection and Message
Routing between
PCN and PSTN
everal types of interconnections between a
PCN and the PSTN have been described in
[8, 171. We describe four types of SS7 interconnection between a PCN and the PSTN (specifically, the local telephone networks) using SS7:
S
IEEE Personal Communications
June 1995
~~------
1
~-
~~
W Figure 1. An example of the SS7 network architecture.
OS1 layers
The SS7 layers
-/I
Application
* I
I
...__________-.--..-.~-~~
ISDN-UP
Presentation
session
transport
I
MTP level 3
I
Data link
I
MTP level 2
I
Physical
I
MTP level 1
I
.~
_
.
W Figure 2. The SS7signalingprotocol.~
~
~
two for SS7 signaling, and two for trunk (voice
circuit)connections [8].The signaling interfacesrepresentsthe physical signalinglink connectionbetween
a PCN and the PSTN. The SS7 signaling interconnection 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 SS7supported 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
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
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
RETURN RESULT(Last) CONVERSATIONWITHPERMISSION
FacilitiesDirective
ISUP) are not delivered with GTT. Details of ISRETURN ERROR
FacilitiesDirective
RESPONSE
41 message routing can be found in Appendix B. The
FacilitiesDirective
REJECT
RESPONSE
appendix describes the fields of an IS-41 message
which are used for the routing purpose and how
HandoffMeasurementRequest INVOKE(Last)
QUERYWITHPERMISSION
the routing procedure is performed.
HandoffMeasurementRequest RETURN RESULT(Last) RESPONSE
HandoffMeasurementRequest RETURN ERROR
HandoffMeasurementReauest REJECT
IINVOKE
MobileOnChannel
RESPONSE
RESPONSE
Mobility Management
Using TCAP
]RESPONSE
~
QualificationRequest
QualificationRequest
QualificationRequest
QualificationRequest
INVOKE(Last)
QUERYWITHPERMISSION
RETURN RESULT(Last) RESPONSE
RETURN ERROR
RESPONSE
REJECT
RESPONSE
RegistrationCancellation
RegistrationCancellation
RegistrationCancellation
RegistrattonCancellation
INVOKE(Last)
QUERYWITHPERMISSION
RETURN RESULT(Last) RESPONSE
RESPONSE
RETURN ERROR
REJECT
RESPONSE
RegistrationNotification
RegistrationNotification
RegistrationNotification
RegistrationNotification
INVOKE(Last)
QUERYWITHPERMISSION
RElllRN RESULT(Last) RESPONSE
RESPONSE
RETURN ERROR
REJECT
RESPONSE
ServiceProfileRequest
ServiceProfileRequest
ServiceProfileRequest
ServiceProfileRequest
INVOKE(Last)
QUERYWITHPERMISSION
RETURN RESULT(La5t) RESPONSE
RETURN ERROR
RESPONSE
REJECT
RESPONSE
T
~~
-
-
~
-
~
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 interface, but are not available to Type 2B with SS7
interface.
Both Types 2A and 2B were originally supported 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)
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
I A mobile user may also
be assigned a Universal
Personal Telecommunication (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 operations are expected to be
included.
In IS-41.C, another
Package Type called ConversationWithoutPermission will be
introduced.
Same number of the
Cvmponent Types are
expected in IS-41
Revision C.
46
._I_.^._
wenty six TCAP operations2 are defined in
IS-41.B [ 131 for three purposes: Inter-MSC
Handoff [15], Automatic Roaming [12], and
Operations, Administration, and Maintenance
[16]. The details of handoff and automatic roaming (mobility management) alternatives can be
found in [21-271.
A TCAP message consists of two portions: the
Transaction Portion and the Component Portion.
The Transaction Portion specifies the Package
Type. Four of the seven Package Types [5, 131 are
defined in IS-41.5-B.3
~YwI~PEREIIssIoNNnitiates
aTCAP transaction
and informs the terminating node that it may
end the TCAP transaction.
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”indicates 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 successfully, the node shall respond with a RETURN
RESULT.
RETURN ERROR is
used to report the unsuccessful 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 rejection 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
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 implementation, we may expect that operations such as
authentication and registration notificationare combined 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<
IEEE Personal Communications
-
-.
~
.
,
June 1995
~
I
r-
/1
I
I
/L
A
U 1427
Type S (D links)
Tandem
MSC
Tandem
PSTN
(a) Type 2A with 557 trunk interface
supported by a Type 5 A-link
signaling interface
(b) Type 2A with 557 trunk interface
supported by a Type 5 D-link
signaling interface
office
(c) Type 2B with 557 trunk interface
supported by a Type 5 A-link
signaling interface
PSTN
(d) Type 2B with 557 trunk interface
supported by a Type S D-link
signaling interface
~~-
Figure 3. Types of interconnection between a PCN and the PSTN.
quest has a PackageType UNIDIRECTIONAL.Thismessage 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 maintaining 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 transactions described above, message sequencing is also
guaranteed (to be elaborated).
Every IS-41 TCAP transaction accompaniesa timeout 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
flows of IS-41 TCAP transactions. The TCAP messages described in these examples are summarized 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 messages 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 station servedby MSC A. Two transactionsare required
to perform inter-MSC handoff.
Transaction 7 - MSC A sends a HandoffMeasurementRequest (INVOKE) to the candidate
MSC B, and waits for the response from MSC B.
When MSC B receives the HandoffMeasurementRequest (INVOKE),it selectsacandidate base
station BS2for handoff. If nocandidate base station
is found, MSC B may exit this transaction. Otherwise, MSC B sends a HandoffMeasurementRequest (RETURN RESULT) to MSC A.6
For simplicity, we
express an IS-41 TCAP
message as a pair “Operation (Package Type)” or
“Component Type.”
Transadeon2 - Before this transaction is started,
MSC A checks if the handset has made too many
handoffs or if inter-MSC trunks are not available.
The result includes the
signal quality parameter
values.
47
......____._......~~....~~~~~..~~~~.....~~~~.~...~,
/ _ _ _ _ _ _
HandoffMeasurementRequest (INVOKE)
@+
HandoffMeasurementRequest (RETURN RESULT)
FacilitiesDirective (INVOKE)
c
1;-
FacilitiesDirective (RETURN RESULT)
MobileOnChannel (INVOKE)
MSC A exits this transaction, and the hand-off call
maybeforcedterminatedif there are toomanyhandoffs 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 transaction. 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.
*
The error code of the
message is resource
shortage[13].
The result includes the
parameters of the selected
voice channel.
48
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
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-41transaction . 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.
-
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 MobileOnChannel (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 MobileOnC h a n n e l (INVOKE) message before MSC A
receives the FacilitiesDirective (RETURN)message. Thus, number sequencing is achieved with
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
expires before the HandoffMeasurementRequest (RETURN)arrives, MSC A exits this transaction and performs some actions (e.g., blocks
the handoff call). If MSC A receives the HandOffMeasurementRequest (RETURN) afterLMMRT
has expired, then it sends a HandoffMeasurementRequest (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 registration 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 transactions. 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 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 recognize 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 CellularNationwide Roaming Services (see Appendix B for more
details). Our example assumes that STP 3 will performGTT(i.e.,theDPCof themessage points to STP
3). After global title translation,the actual destination
IEEE Personal Communications June 1995
1
PCN2
PSTN
PCNl
I
RegistrationNotifica‘ion (INVOKE)
6-
RegistrationNotification (RETURN RESULT)
t
Registrationcancellat o n (INVOKE)
*
RegistrationCancellat on (RETURN RESULT)
-
Registrationcan dlation (INVOKE)
d
Registrationcan illation (RETURN RESULT)
I
QualificationRequest (INVOKE)
d‘
QualificationReques’ (RETURN RESULT)
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’
2 and thus to the HLR. The HLR confirms the registration 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 RegistrationNotification (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
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 profile 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
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
T
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
period.
t
ACM
ACM
ANM
ANM
-
Step 3
Step 4
REL
Step 5
Signaling path from
PSTN to PCN
Signaling path from
PCN to PSTN
REL
L
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 signaling 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 applications. These steps are presented to provide the
reader a complete message flow of wireline-towireless call setup.
The ISUP messages
akcn‘bed in thefollowing
steps are delivered by
MTP routing.
50
__
__ --
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 delivered 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
Fig. 3 in IS-41.3 [12]). If the mobile user has call
forwarding or call waiting services, the busy line
situation is handled differently (see Figs. 6 and 9
in [12]).
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 tandem.
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 Complete Message (ACM) is sent from the MSC to
the EO. The message indicatesthat the routing information 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 appropriate 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 depending 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
I
Release Message ( R E L ) t o indicate that the
specified trunk is being released from the connection. 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 propagated 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
setup from a mobile user to a wireline user. The
PSTNiPCN interconnection follows the configuration 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 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 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 completion 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 Message (SUS) is sent from the E O at LEC2 to the
MSC to indicate that the called party has disconnected. 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 Message ( 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 timeout 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.
IEEE Personal Communications June 1995
1
I
-~ _ _ - _ _ _ _
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
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 messages related to call setupirelease are implemented 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 translation. The reader is referred to [6,9, 111 for further reading.
IS-41 mobility management is implemented by
TCAP with efficient connectionless service (i.e.,
W
51
out-of-order message delivery). Message sequencing 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 anonymous 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 - Signaling 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 - Signaling 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 - Signaling 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 specification supporting network interconnection, message transfer part,
and integrated services digital network user part, Issue 2, Technical 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-TSV001411, 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. Technical Report GR-606-CORE, Bellcore. 1994.
I121 ElAITlA Cellular radio-telecommunications intersystem operations:
Appendix A
AC
ACM
ANM
CCS
COT
DPC
EIR
Authentication Center
Address Complete Message
Answer Message
Common Channel Signaling
Continuity Message
Destination Point Code
Equipment Identification
Register
EO
End Office
EXM Exit Message
GT
Global Title
G7T
Global Title Translation
HLR
Home Location Register
IAM
Initial Address Message
IS-41 EIA/TIA Interim Standard:
Cellular RadioTelecommunications
Inter-System Operations
ISUP
Integrated Services Digital
Network User Part
52
IXC
LEC
MAP
MF
MSC
MTP
OMAP
OS1
PCN
PCS
PSTN
REL
RES
RI
RLC
SAC
Automatic roaming, Technical Report 15-41.3-8. EIAITIA. 1991.
[131 EIAITIA. Cellular radio-telecommunications intersystem operations: 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 operations Operations. administration. and maintenance. TechnicalReport
IS-41.4-6. EIMIA. 1991
1171 EIMIA. Cellular radio telecommunications interfacesstandard. Technical 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 Communications, 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 communications 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 ChannelAssignment 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 Strategies 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 Washington in 1990. Since then, he has been w i t h the Applied Research
Area at Bellcore. Morristown. New Jersey. His current research interests 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 General Chair for the 9th Workshop on Distributed and Parallel Simulation. 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.
- Acronym
List
Interexchange Carrier
Local Exchange Carrier
Mobile Application Part
Multi-frequency Signaling
Mobile Switching Center
Message Transfer Part
Operations, Maintenance,
Administration Part OPC
Originating Point Code
Open System Interconnection
PCS Network
Personal Communications
Services
Public Switched Telephone
Network
Release Message
Resume Message
Routing Indicator Code
Release Complete Message
Service Access Code
SIC
SCCP
SCP
SLS
SPC
SSP
ss7
SSN
STP
sus
TCAP
TLDN
UDT
UDTS
UPT
VLR
Service Indicator Code
Signaling Connection Control
Part
Service Control Point
Signaling Link Selection
Signaling Point Code
Service Switching Point
Signaling System No. 7
Subsystem Number
Signaling Transfer Point
Suspend Message
Transaction Capabilities
Application Part
Temporary Local Directory
Number
UnitData
UnitData Service
Universal Personal
Telecommunication
Visitor Location Register
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 Registrationcancellation (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 wirelesdwireline call setuphelease message).
Routing Label- This field contains the information
necessary to deliver the message to its destination
point. There are three sub-fields.
-,,'
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.
Priority = 0 or 1
SIC = 3
--_
ing
jsccp1'...\.
[
T
I
(b) The SCCP message
(a) The MTP message
I
- .1
RI = 1
I
I
National/lntl.
Address
i
RI = 0
I
Address
GT ind. = 2
GT ind. = 0
SPC ind. = 0
SPC ind. = 1
SSN ind. = 1
SSN ind. = 1
SPC
Address
SSN
(c) Calledlcalling party address format
(without global title translation)
'yDq
GT translation type
GT address
Address
(d) Called/calling party address format
(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
myeY
1
Construct
UnitData
Pointers
- These fields point to the beginning of
the called, calling, and data fields.
CalZed/CallingParty Address - These fields have
and set
return
RI=l
No
Yes
U
W Figure 9. The SCCP routingprocedures for IS-41messages.
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/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
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 elaborated) in the called party.
Global Title Indicator - There are four numbers assigned for U.S. networks. IS-41 messages
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 subsystem indicator is 1.
Address
The normal IS-41 messages are of type 9 (UnitDaTa or UDT). The SCCP returns a UnitDaTa
Service message (UDTS; SCCP message type 10)
when a received UDT message cannot be delivered 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 connectionless 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 segmented 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 implementations 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
_-
- 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 originating 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 translation, and the global title consists of two elements.
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 represents 800 service translation. Code 003 (cellular nationwide roaming) is used for the IS-41
messages.
GT address - The global title address in an IS41 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 requirements 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 provided by the MAP/TCAP (Step 4). One of the following 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 discards 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 appropriate, 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 routingprocedure 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