sjzl20082259-ZXWN MSCS MSC Server Technical Description PDF

ZXWN MSCS
MSC Server
Technical Description
Version 3.07.20
ZTE CORPORATION
ZTE Plaza, Keji Road South,
Hi-Tech Industrial Park,
Nanshan District, Shenzhen,
P. R. China
518057
Tel: (86) 755 26771900 800-9830-9830
Fax: (86) 755 26772236
URL: http://support.zte.com.cn
E-mail: doc@zte.com.cn
LEGAL INFORMATION
Copyright © 2006 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by
contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided “as is”, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Date Revision No. Serial No. Reason for Issue

Jul. 27, 2008 R1.0 sjzl20082259 First edition
ZTE CORPORATION
Values Your Comments & Suggestions!
Your opinion is of great value and will help us improve the quality of our product
documentation and offer better services to our customers.
Please fax to (86) 755-26772236 or mail to Documentation R&D Department, ZTE
CORPORATION, ZTE Plaza, A Wing, Keji Road South, Hi-Tech Industrial Park,
Shenzhen, P. R. China 518057.
Thank you for your cooperation!
Document
ZXWN MSCS MSC Server Technical Description
Name
Document Revision
Product Version V3.07.20 R1.0
Number
Equipment
Serial No. sjzl20082259
Installation Date
Presentation:
(Introductions, Procedures, Illustrations, Completeness, Level of Detail, Organization,
Appearance)
Good Fair Average Poor Bad N/A
Your evaluation Accessibility:

of this
(Contents, Index, Headings, Numbering, Glossary)
documentation
Intelligibility:
(Language, Vocabulary, Readability & Clarity, Technical Accuracy, Content)
Please check the suggestions which you feel can improve this documentation:
Improve the overview/introduction Make it more concise/brief
Improve the Contents Add more step-by-step procedures/tutorials
Improve the organization Add more troubleshooting information
Include more figures Make it less technical
Your Add more examples Add more/better quick reference aids
suggestions for Add more detail Improve the index
improvement of
this Other suggestions
documentation __________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
# Please feel free to write any comments on an attached sheet.
If you wish to be contacted regarding your comments, please complete the following:
Name Company
Postcode Address
Telephone E-mail
This page is intentionally blank.
Contents
About This Manual ............................................................ i

Purpose ................................................................................ i
Intended Audience ................................................................ ii
Prerequisite Skill and Knowledge ............................................. ii
What Is in This Manual .......................................................... ii
Conventions ......................................................................... ii
How to Get in Touch............................................................. iii
Declaration of RoHS Compliance..................................... v
Chapter 1.......................................................................... 1
Basic Knowledge.............................................................. 1
Overview ............................................................................. 1
Features of the R99 Version ................................................... 1
Features of the R4 Version ..................................................... 2
UMTS R4 Network Structure ................................................... 3
UMTS R5 Network Structure ................................................... 6
Chapter 2.......................................................................... 9
Interfaces and Communication ....................................... 9

Overview .......................................................................9
Interfaces ......................................................................9
Iu-CS Interface................................................................... 12
A Interface......................................................................... 13
Mc Interface....................................................................... 13
Nc Interface ....................................................................... 14
Mn Interface ...................................................................... 15
MAP Interface..................................................................... 15
CAP Interface ..................................................................... 16
Gs Interface ....................................................................... 17
Mj/Mg Interface ..................................................................17
Billing Interface...................................................................18
O&M Interface ....................................................................18
CORBA Interface .................................................................19
Lawful Interface ..................................................................20
SNMP Interface ...................................................................22
Signaling System (Protocols) .......................................... 23
Narrowband No.7 Protocol ....................................................24
Broadband No.7 Protocol ......................................................36
SIGTRAN Protocol Suite........................................................40
H.248 Protocol ....................................................................51
BICC Protocol .....................................................................56
RANAP Protocol ...................................................................66
BSSAP Protocol ...................................................................69
Gs Interface Protocol ...........................................................71
MAP Protocol ......................................................................75
CAP Protocol.......................................................................77
SIP Protocol........................................................................81
Chapter 3........................................................................ 93
Service Functions........................................................... 93
Overview ..................................................................... 93
Mobility Management Service.......................................... 94
Overview ...........................................................................94
General Location Update ......................................................96
Periodic Location Update .................................................... 101
IMSI Attachment/ Detachment ............................................ 101
Deleting a Subscriber......................................................... 102
UMTS → UMTS Intra-office Relocation .................................. 103
UMTS → UMTS Inter-office Relocation .................................. 107
UMTS → GSM Intra-system Handover................................... 112
UMTS → GSM Inter-office System Handover .......................... 116
GSM → UMTS Intra-system Handover................................... 121
GSM → UMTS Inter-office System Handover .......................... 124
GSM → GSM Intra-office System Handover ........................... 129
GSM → GSM Inter-office System Handover ........................... 133
Security Management .................................................. 138

Authentication Service ....................................................... 138
Encryption Services ........................................................... 143
Integrity Protection ........................................................... 144
TMSI Allocation/Release..................................................... 146
IMEI Check ...................................................................... 146
VLR Management ........................................................ 147
Subscriber Data Management ............................................. 147
Error Recovery Processing .................................................. 149
Mobile Call Service Function.......................................... 150
Overview ......................................................................... 150
Radio Channel Assignment Flow of the Basic Call of the UE ..... 152
Radio Channel Assignment Flow of the UE Terminated Call...... 155
Originated-Call Flow .......................................................... 157
Terminated-Call Flow......................................................... 162
Call Release Flow .............................................................. 173
Supplementary Services............................................... 176
Overview ......................................................................... 176
Basic Operations ............................................................... 177
Supplementary Services Processing ..................................... 182
Mobile Data Services ................................................... 199
Mobile Intelligent Service ............................................. 200
Overview ......................................................................... 200
Introduction to Intelligent Network ...................................... 201
Mobile Intelligent Service ................................................... 206
Mobile Intelligent Service Flow ............................................ 209
Short Message Service................................................. 236
Overview ......................................................................... 236
SM MO Processing Flow...................................................... 236
SM MT Processing Flow ...................................................... 237
Alerting Message Processing Flow ........................................ 239
Operation and Maintenance Service ............................... 240
Subscriber Tracing ............................................................ 240
Equipment Tracing ............................................................ 241
Deleting an MS ................................................................. 242
Querying IMSI according to ISDN ........................................ 242
Interception Services ................................................... 243
Overview ......................................................................... 243
Introduction to Interception Services ................................... 243
China 2G Interception........................................................ 245
China 3G Interception........................................................ 247
ETSI Interception .............................................................. 250
Russia Interception............................................................ 250
Location Service ......................................................... 252
MS-Terminated Location Request......................................... 253
MS-Originated Location Request .......................................... 255
Network-Initiated Location Request...................................... 257
Deferred MS-Terminated Location Request............................ 259
Region System Function............................................... 262
Dual-homing Disaster Recovery Function ........................ 264
Load Control Function .................................................. 267
Overview ......................................................................... 267
Principle........................................................................... 268
Function Implementation.................................................... 270
R2 Function................................................................ 271
Roaming Pool Function................................................. 273
Multi-EIR Function....................................................... 274
M2PA Networking Function ........................................... 275
Interworking Services between the IMS and the CS/PSTN . 277
The Terminal Subscriber in the IMS Domain Calling the Subscriber
in the CS Domain/PSTN...................................................... 278
The Subscriber in the CS Domain/PSTN Calling the Terminal
Subscriber in the IMS Domain ............................................. 280
Function of Detecting and Restricting Cheaters ................ 282
Overview ......................................................................... 282
Introduction to Detecting and Restricting Cheaters ................. 282
Generating Call Attempt CDRs............................................. 284
Restricting the Call Originating Service of Cheaters ................ 285
False Billing Function ......................................................... 285
Restricting the SMS of Cheaters .......................................... 286
Location Update Restriction Function .................................... 286
Periodically Enabling the Function of Restricting Cheaters........ 287
Sorting Call Attempt CDRs .................................................. 287
Sorting SM CDRs ............................................................... 287
Configuring Cheater Detection Policy .................................... 287
Default Restriction Policy Configuration................................. 288
Cheater Detection Function................................................. 288
Cheater List Maintenance Function ....................................... 289
Rerouting Function ...................................................... 289
Dynamically Selecting Routes Based on Load of IP Bearer
Network and QoS ........................................................ 290
Bidirectional Forwarding Detection Function .................... 290
Compatibility Function with 2G...................................... 291
Grading Access Based on Half Rate...................................... 292
Determining Whether to Authenticate the UE according to the IMSI
...................................................................................... 294
Judging the Type of An Incoming Call according to the FOCIN
Information in the ISUP/BICC Signaling................................ 295
PSTN Subscribers Accessing EGSM ...................................... 296
Not Generating SM Acknowledgment CDRs ........................... 297
Adjusting Separate IP Addresses ......................................... 297
Restricting the Number of USSD Dialogs through Security
Variables ......................................................................... 298
Playing a Separate Tone for Number Incomplete ................... 299
Abbreviations ............................................................... 301
Glossary........................................................................ 305
Figures.......................................................................... 309
Tables ........................................................................... 317
Index ............................................................................ 319

About This Manual
Purpose
At first, thank you for choosing ZXWN wireless core network
system of ZTE Corporation!
ZXWN system is the 3G mobile communication system
developed based on the UMTS technology. ZXWN system boasts
powerful service processing capability in both CS domain and PS
domain, providing more abundant service contents. Comparing
with the GSM, ZXWN provides telecommunication services in
wider range, capable of transmitting sound, data, graphics and
other multi-media services. In addition, ZXWN has higher speed
and resource utilization rate. ZXWN wireless core network
system supports both 2G and 3G subscriber access, and
provides various services related with the 3G core network.
ZXWN MSCS MSC Server boasts the functions of mobile
switching server, gateway mobile switching server, SMS
gateway/interworking MSC, tandem mobile switching server.
ZXWN MSCS is totally compatible with 3GPP R4 of June 2003,
and is downward compatible with 3GPP R99 of June 2002. ZXWN
MSCS has powerful processing capability, various communication
interfaces, abundant service functions, and flexible diversified
networking modes. ZXWN MSCS not only supports the
networking mode of bearer independent of control in 3GPP R4,
but also can be bound to a MSC with ZXWN MGW, supporting
the networking mode of 3GPP R99. Besides satisfying the
requirements of constructing the common mobile switching
network, ZXWN MSCS also can satisfy the requirements of
construct the No.7 signaling network and mobile intelligent
network, and can be adapted to various complicated networking
modes of the mobile switching network. Thus the continuity
development capability of the network is improved.
The purpose of writing this manual is to help operators fully
master the basic knowledge, interfaces and protocols, and
service functions of ZXWN MSCS.
Confidential and Proprietary Information of ZTE CORPORATION i

Intended Audience
This document is intended for engineers, technical and
maintenance personnel who have mastered the principles of
mobile network communications.
Prerequisite Skill and Knowledge

To use this document effectively, users should have a general
understanding of wireless telecommunications technology.
Familiarity with the following is helpful:
ZXWN MSCS system and its various components
User interfaces on MSCS
Local operating procedures of MSCS
What Is in This Manual

This manual contains the following chapters:
TABLE 1 CHAPTER SUMM ARY
Chapter Summary
Chapter 1, Basic Introduces features of CN in each version
Knowledge of 3GPP, and the network structures in R4
and R5 versions
Chapter 2, Interfaces Introduces the external signaling
and Communication interfaces provided by the MSCS system
Chapter 3, Service Introduces various service functions of the
Functions ZXWN MSC Server
Conventions
Typographical ZTE documents employ the following typographical conventions.
Conventions
TABLE 2 TYPOGRAPHICAL CONVENTIONS
Typeface Meaning
Italics References to other Manuals and documents.
“Quotes” Links on screens.
Bold Menus, menu options, function names, input
fields, radio button names, check boxes, drop-
down lists, dialog box names, window names.
ii Confidential and Proprietary Information of ZTE CORPORATION

About This Manual
Typeface Meaning
CAPS Keys on the keyboard and buttons on screens
and company name.
Constant width Text that you type, program code, files and
directory names, and function names.
[] Optional parameters.
{} Mandatory parameters.
| Select one of the parameters that are delimited
by it.
Note: Provides additional information about a
certain topic.
Checkpoint: Indicates that a particular step needs
to be checked before proceeding further.
Tip: Indicates a suggestion or hint to make things
easier or more productive for the reader.
Mouse TABLE 3 MOUSE OPERATION CONVENTIONS

Operation
Conventions Typeface Meaning
Click Refers to clicking the primary mouse button (usually
the left mouse button) once.
Double-click Refers to quickly clicking the primary mouse button
(usually the left mouse button) twice.
Right-click Refers to clicking the secondary mouse button
(usually the right mouse button) once.
Drag Refers to pressing and holding a mouse button and
moving the mouse.
How to Get in Touch

The following sections provide information on how to obtain
support for the documentation and the software.
Customer If you have problems, questions, comments, or suggestions
Support regarding your product, contact us by e-mail at
support@zte.com.cn. You can also call our customer support
center at (86) 755 26771900 and (86) 800-9830-9830.
Documentation ZTE welcomes your comments and suggestions on the quality
Support and usefulness of this document. For further questions,
comments, or suggestions on the documentation, you can
contact us by e-mail at doc@zte.com.cn; or you can fax your
comments and suggestions to (86) 755 26772236. You can also
browse our website at http://support.zte.com.cn, which contains
various interesting subjects like documentation, knowledge base,
forum and service request.
Confidential and Proprietary Information of ZTE CORPORATION iii

iv Confidential and Proprietary Information of ZTE CORPORATION

Declaration of RoHS
Compliance
To minimize the environmental impact and take more

responsibility to the earth we live, this document shall serve as
formal declaration that the ZXWN MSCS manufactured by ZTE
CORPORATION are in compliance with the Directive 2002/95/EC
of the European Parliament - RoHS (Restriction of Hazardous
Substances) with respect to the following substances:
Lead (Pb)
Mercury (Hg)
Cadmium (Cd)
Hexavalent Chromium (Cr (VI))
PolyBrominated Biphenyls (PBB’s)
PolyBrominated Diphenyl Ethers (PBDE’s)
…
The ZXWN MSCS manufactured by ZTE CORPORATION meet the

requirements of EU 2002/95/EC; however, some assemblies are
customized to client specifications. Addition of specialized,
customer-specified materials or processes which do not meet the
requirements of EU 2002/95/EC may negate RoHS compliance of
the assembly. To guarantee compliance of the assembly, the
need for compliant product must be communicated to ZTE
CORPORATION in written form.
This declaration is issued based on our current level of
knowledge. Since conditions of use are outside our control, ZTE
CORPORATION makes no warranties, express or implied, and
assumes no liability in connection with the use of this
information.
Confidential and Proprietary Information of ZTE CORPORATION v

vi Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1
Basic Knowledge
Overview
Introduction The 3GPP standard has several releases. This chapter introduces
features of R99, R4, R5, and R6.
Contents This chapter includes the following topics.
Topics Page No.

Features of the R99 Version 1
UMTS R4 Network Structure 3
UMTS R5 Network Structure 6
Features of the R99 Version

The R99 version is the first version of Universal Mobile
Telecommunications System (UMTS), and its main features are
as follows:
The air interface adopts the UMTS technology, which greatly
increases the radio access rate and the frequency usage
efficiency. The maximum radio access rate is up to 2 Mbps.
Adopts the ATM technology for the interface technology
between NEs in the RAN, which increases the transmission
efficiency and simplifies the design and the configuration of
each NE in the RAN.
Adopts the AMR technology for the voice coding/decoding
technology, which can dynamically adjust the voice rate
according to the radio resource condition, and improves the
voice quality and network capacity.
Confidential and Proprietary Information of ZTE CORPORATION 1

The Core Network (CN) is divided into Circuit Switched (CS)

domain and Packet Switched (PS) domain. The CS domain
consists of the MSC and the GMSC, processing voice services.
The PS domain consists of the SGSN and the GGSN,
processing packet services.
The TDM bearer is still adopted between NEs in the CS-
domain CN, which is consistent with GSM.

The R4 version is the second version of UMTS, and its main
features are as follows:
The CS domain introduces the soft switch technology,
supporting the networking mode of bearer independent of
control. The MSC is split to the MSC Server and the MGW.
The R4 version makes the call control part totally
independent of the bearer part, makes the transmission in
the CS domain based on IP, implements voice packetization
and signalling packetization, and implements convergency
with the transmission resources in the PS domain. Therefore,
the transmission resource efficiency is improved.
The CS domain supports multiple bearer modes: IP, ATM and
TDM.
Enhances the location service capability.
Supports TD-SCDMA.

The R5 version is the third version of UMTS, and its main
Adds the IMS domain, which provides IP multi-media
services. Implements the interworking between the CS
domain and the IMS domain through the IM-MGW and the
MGC.
Further enhances each kind of capacity in the CS domain and
supports CAMEL4.
The RAN supports the HSDPA technology, the downlink rate
is increased to 8Mbps～10Mbps, and the peak rate is up to
14.4Mbps.
The introduction of Iu Flexible allows one RNC access
multiple CN NE (MSC MSC/MSC Server + MGW/SGSN) nodes.
2 Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1 Basic Knowledge

The R6 version is the fourth version of UMTS, and its main
Further improves the IMS system, and supports conference
services, the interworking with WLAN, and the interworking
with other multi-media networks.
Supports the MBMS service.
Further enhances the location service capability.
Supports the Push service.
UMTS R4 Network Structure

Network The network structure of the 3GPP R4 version is shown in Figure
Structure 1.
Diagram
FIGURE 1 STRUCTURE OF THE R4 CN
PS Domain
Iu-
Iu-PS
Iu-
Iu-CS
BSS
RNS
BSS
Note: Heavy lines mean bearer interfaces, while dashed lines

mean signaling interfaces.
Structure In the R4 phase, the UMTS system is divided into the CN and the
Description RAN. The RAN provides all functions related with the radio
network; the CN processes all voice and data services in UMTS
system, and implements the switching and routing functions
with the external network.
The CN is logically divided into the CS domain and the PS
domain.
CS domain: provides various services based on the CS
connection to the MS, such as call services, CS-based Short
Message Services (SMS), CDS services and H.324 multi-

media services. The CS domain is composed of (G) MSC

Server, (G) MGW and VLR.
PS domain: provides various services based on the PS
connection to the MS, such as Internet connection services,
VPN services and PS-based SMS. The PS domain is composed
of SGSN and GGSN.
Interface Interfaces between NEs in the 3GPP R4-version CN are shown in
Schematic Figure 2.
Diagram
FIGURE 2 INTERFACES IN 3GPP R4 PLMN
Note 1: Heavy black lines mean bearer interfaces, while dashed

lines mean signaling interfaces.
Note 2: In Figure 2, the direct interconnection is adopted
between entities. However, in the practical application, entities
may be interconnected through a bottom-layer network (such as
SS7 network or IP network).

Note 3: One (G) MSC Server and its associated CS-MGW can be
integrated into one node: the （G）MSC.
Interfaces between NEs in the CS domain are shown in Figure 3.
FIGURE 3 INTERFACES BETWEEN NES IN THE CS DOMAIN
PSTN
UTRAN
MGW GMGW /
Legacy/External
A/Iu N
Iu b
Mc Mc
Nc
GERAN MSC GMSC
A/Iu Server Server
CAP CAP
C
D
Applications HL
& R
Service
s
Signalling Interface
Signalling and Data Transfer Interface
The CN is the CS domain is composed of (G) MSC Server, VLR

and (G) MGW. The (G) MSC Server provides subscriber access,
call control and other functions; the VLR is generally combined
with the MSC Server, storing the subscriber data under its
coverage; and the (G) MGW provides the bearer control function.
Interfaces of In the R4 phase, the MSCS has the following interfaces with
the MSCS other NEs:
1. Iu_CS interface: interface between the MSC Server and the
UTRAN (which is the radio side of the UMTS), adopting the
RANAP protocol.
2. A interface: interface between the MSC Server and the
GERAN (which is the radio side of the GSM), adopting the
BSSAP protocol.
3. C interface: interface between the MSC Server and the HLR,
adopting the MAP protocol.
4. D interface: interface between the VLR and the HLR,
adopting the MAP protocol.
5. CAP interface: interface between the MSC Server and the
gsmSCP, adopting the CAP protocol.
6. Nc interface: interface between MSC Servers, adopting the
ISUP or BICC protocol.
7. Mc interface: interface between the MSC Server and the
MGW, adopting the H.248 protocol.
8. Gs interface: interface between the MSC Server and the
SGSN, adopting the BSSAP+ protocol.
Through introducing the Mc interface, the MSC NE in the R99
version is split into the MSC Server and the MGW in the R4
version. The MSC Server applies for, modify and release each
bearer resource from the MGW through the Mc interface to

realize bearer independent of control. The Mc interface adopts

the H.248 protocol drafted by ITU-T, and the mobile related
expansion function is added.
UMTS R5 Network Structure

Network The network structure of the 3GPP R5 version is shown in Figure
Structure 4.
Diagram
FIGURE 4 STRUCTURE OF THE R5 CN
Note: Heavy lines mean bearer interfaces, while dashed lines

mean signaling interfaces.
The IMS domain is added, which provides the IP multi-media
services and implements fusion of the existing networks. The
IMS adopts the architecture of mutual independence among
bearer, control and services. The IMS system is composed of the
core control unit (I/P/S-CSCF), service-layer NEs (AS/MRFC/HSS)
and interworking NEs (BGCF, MGCF/IM-MGW)
The network control core of the IMS is the S-CSCF NE. The P-
CSCF is used to process subscriber access security and routing
functions. The I-CSCF is used to select the S-CSCF, and routing,
network security and other functions. The HSS saves the
subscription information of subscribers. The service layer is
mainly composed of AS and various service logics for subscribers
residing. The MGCF/IM-MGW in the IMS is mainly used to
process the traffic between the IMS network and the CS, and
PSTN networks.
Interfaces of Interfaces of the MGCF and the IM-MGW are shown in Figure 5.
the MGCF and
the IM-MGW

FIGURE 5 INTERFACES OF THE MGCF AND THE IM-MGW
IP Multimedia Networks Legacy mobile

signalling Networks
PSTN
Mb Mb PSTN
BGCF CSCF
PSTN Mm
Mk Mk
Mw
C, D,
Mj BGCF
Mi G Gr
Gc, G
Cx
IMS- MGCF HSS
CSCF
MGW Mn Mg
Mr
SLF
Mb Mw Dx
MRFP MRFC P-CSCF

UE
MP Gm
Mb Mb Mb Gq IM Subsystem
The descriptions of the interfaces of the MGCF and IM-MGW are

as follows:
1. Mb interface: IMS network bearer interface, adopting the
protocol stack in CodeC/RTP/IP mode. The Mb interface is
mainly used between the following NEs:
i. Mb interface between the UE and the IM-MGW: used for
the IMS UE to implement media interworking with the
opposite-end entities through the IM-MGW;
ii. Mb interface between the MRFP and the IM-MGW, or the
MRFP and the UE: used when the MRFP is required to
perform the media plane processing;
iii. Mb interface between the MRFP and the UE: used when
the MRFP is required to perform the media plane
processing.
2. Mj/Mg interface: IMS network control interface between the
MGCF-BGCF and the CSCF, adopting the SIP protocol stack.
For the specific template, please refer to the TS24.229
protocol.
3. Ai interface: interface between the MGCF/IM-MGW and the
PSTN, adopting the ISUP/TUP protocol.
4. Nb interface: interface between the IM-MGW and the MGW,
adopting the CodeC/NbUP/RTP/IP protocol.
5. Nc interface: interface between the MGCF and the MSCS,
adopting the BICC/ISUP protocol.


Chapter 2
Interfaces and
Communication
Overview
Introduction This chapter introduces the external signaling interfaces
provided by the MSCS system.
Contents This chapter includes the following sections.
Sections Page No.

Interfaces 9
Signaling System (Protocols) 23
Interfaces
Function The ZXWN MSCS system is embedded with the VLR and SG
Description functions, and integrated with the SSP function. Therefore, in
the mobile communication network, the ZXWN MSCS can act as
the following NEs at the same time:
VMSCS: responsible for processing MO and MT traffic,
roaming and relocation traffic, SMS, supplementary service
unrelated with calls, and location-based services of the MS
under its coverage.
GMSCS: responsible for processing traffic between a PLMN
and other PLMNs, PSTN and ISDN networks.
TMSCS: responsible for processing tandem traffic in a PLMN.
MGCF: responsible for processing traffic between the IMS
and the CS/PSTN.
SMS-IW/GMSCS: responsible for processing MO-SMS and
MT-SMS traffic between a PLMN and other a SC.

SSP: responsible for accessing the mobile Intelligent Network

(IN), implementing the service switching function and
processing the intelligent services.
Interface The main interfaces of the ZXWN MSCS system in the mobile
Schematic communication network are shown in Figure 6.
Diagram
FIGURE 6 MAIN INTERFACES OF THE ZXWN MSCS SYSTEM
Interface As shown in Figure 6, the ZXWN MSCS implements the functions

Description of the above NEs, having the following interfaces.
Iu-CS interface: Interface between the RNS and the
MSCS/VLR
Based on the ATM mode in the R4 phase, this interface is the
Iu-CS control plane interface, and accesses the RNS. For
details, refer to Iu-CS Interface.
A interface: Interface between the MSCS/VLR and the BSS
Based on E1 interfaces, this interface accesses the BSS, and
is responsible for control plane processing of the 2G call
service. For details, refer to A Interface.
Mc interface: Interface between the MSCS and the MGW
This interface applies for, releases and changes MGW bearer
resources. For details, refer to Mc Interface.
Mn interface: Interface between the MGCF and the IM-MGW
This interface controls the bearer resources of the IM-MGW.
For details, refer to Mn Interface.
Nc and MAP interfaces: Interfaces between MSCSs
The Nc interface negotiates call parameters of outgoing call
services and controls bearer resources. The MAP interface
implements location update, and subscriber ID. For details,
refer to Nc Interface and MAP Interface.
MAP Interface: Interface between the MSCS/VLR and the
HLR

Chapter 2 Interfaces and Communication
Based on the narrowband No.7 signaling interface, this

interface implements location update, subscriber data
insertion, supplementary service processing and MT call
routing. For details, refer to MAP Interface.
CAP and MAP I interfaces: Interfaces between the
MSCS/VLR/SSP and the SCP
Based on the narrowband No.7 signaling interface, this
interface implements intelligent service access and control,
supplementary service invoking notification, and mobility
management notification. For details, please refer to CAP
Interface.
SW/GMSCS－SC interface: Interface between the SW/GMSCS
and the SC
Based on TCP/IP, this interface implements MO-SMS
submitting and MT-SMS delivery of the MS. This interface is
an internal interface.
Gs Interface: Interface between the MSCS/VLR and the
SGSN
This interface implements the combined united location
update of the subscriber, and the association of the CS and
PS domains. For details, refer to Gs Interface.
Mj/Mg interface: Interface between the MGCF and the
BGCF/CSCF
This interface negotiates call parameters of the call between
the IMS and the CS, and controls bearer resources. For
details, refer to Mj/Mg Interface.
Billing interface (not shown in Figure 6)
This interface sends the CDRs of the MSCS to the billing
center. For details, refer to Billing Interface.
Network management interface (not shown in Figure 6)
Based on TCP/IP, this interface implements centralized
maintenance, monitoring and network management for the
MSCS. For details, refer to O&M Interface.
CORBA interface (not shown in Figure 6)
This interface implements the interworking between the NMC
(network management center of the operator) and the OMC
provided by equipment manufactures. For details, refer to
CORBA Interface.
Lawful interface (not shown in Figure 6)
This interface traces and monitors all the traffic and non-
traffic actions of the controlled number in real time. For
details, refer to Lawful Interface.
SNMP interface (not shown in Figure 6)
This interface implements the interworking between the NMC
(network management center of the operator) and the OMC

provided by equipment manufactures. For details, refer to

SNMP Interface.
Iu-CS Interface
Application The Iu-CS interface between the MSC Server and the MGW is
defined by 3GPP R4 standard. This interface is responsible for
subscriber mobility management, RNS access, call service
control plane processing, and SMS service. The Iu-CS interface
is physically based on ATM or IP.
Protocol Stack The protocol stack of the Iu-CS interface (control plane) is
shown in Figure 7.
FIGURE 7 PROTOCOL STACK OF THE IU-CS INTERFACE CONTROL PLANE
Note: At R4 stage, only the ATM-based mode is adopted.

At R5 stage, the IP-based mode is added.
As shown in Figure 7, the protocol stack of the Iu-CS interface

control plane can adopt two modes.
One is the ATM cell transmission mode, with the protocol

stack as RANAP/SCCP/MTP3B/SSCF-NNI/SSCOP/AAL5/ATM.
The other is the SIGTRAN mode, with the protocol stack as
RANAP/SCCP/M3UA/SCTP/IP.
Configure the appropriate mode according to the actual
networking requirement. At R4 stage, the Iu-CS interface only
supports the ATM mode.

A Interface
Application The interface between the MSC Server and the BSS is A
interface. The MSC Server only processes the control plane of
the A interface. This interface implements subscriber mobility
management, BSS access, control plane processing of call
service and SMS service. This interface is physically based on
the E1 interface.
Protocol Stack Figure 8 shows the protocol stack of the A interface.
FIGURE 8 PROTOCOL STACK OF THE A INTERFACE CONTROL PLANE
A Control Plane
BSSAP
SCCP-SAP
SCCP
MTP 3
MTP 2
L1
As shown in Figure 8, the protocol stack of the A interface

control plane adopts the narrowband SS7 signaling transmission
mode, which is based on BSSAP/SCCP/MTP3/MTP2.
Mc Interface
Application The interface between the MSC Server and the MGW is Mc
interface. This interface can be based on ATM or IP.
Protocol Stack Figure 9 shows the protocol stack of the Mc interface:

FIGURE 9 MC INTERFACE PROTOCOL STACK
Note 1: For pure IP links, H.248/SCTP/IP is preferred, and

H.248/M3UA/SCTP/IP is optional.
Note 2: For ATM/IP mixed links, H.248/M3UA/SCTP/IP is
mandatory, and H.248/MTP3b/SSCF/SSCOP is optional.
As shown in Figure 9, the protocol stack of the Mc interface can
adopt multiple signaling transmission modes.
The IP signaling transmission mode can adopt either

H.248/SCTP/IP or H.248/M3UA/SCTP/IP. For pure IP links,
H.248/SCTP/IP is preferred
The ATM signaling transmission mode can adopt
H.248/MTP3B/SSCF/SSCOP/AAL5.
Nc Interface
Application The interface between MSC Servers is Nc Interface. This
interface can be based on ATM, IP or E1.
Protocol Stack Figure 10 shows the protocol stack of the Nc interface.
FIGURE 10 PROTOCOL STACK OF THE NC INTERFACE
As shown in Figure 10, the protocol stack of the Nc interface can

adopt three signaling transmission modes:
Narrowband SS7 signaling transmission mode, based on

BICC/MTP3/MTP2
SIGTRAN signaling transmission mode, based on
BICC/M3UA/SCTP/IP
ATM signaling transmission mode, based on
BICC/MTP3B/SSCF-NNI/SSCOP/AAL5.

Mn Interface
Application The Mn interface between the MGCF and the IM-MGW is based
on IP transmission.
Protocol Stack Figure 11 shows the protocol stack of the Mn interface.
FIGURE 11 PROTOCOL STACK OF THE MN INTERFACE
Note: For pure IP links, H.248/SCTP/IP is preferred, and

H.248/M3UA/SCTP/IP is optional.
As shown in Figure 11, the protocol stack of the Mn interface can
adopt multiple signaling transmission modes. There are two IP
signaling transmission modes:
H.248/SCTP/IP transmission mode
H.248/M3UA/SCTP/IP transmission mode.
MAP Interface
Application The MAP interface is used for multiple interfaces, including:
C interface (interface between the GMSC server and the HLR)

D interface (interface between the VLR and the HLR)
E interface (interface between the MSC server and the SMC)
G interface (interface between VLRs).
This interface can be physically based on E1 or IP.
Protocol Stack Figure 12 shows the protocol stack of the MAP interface.

FIGURE 12 PROTOCOL STACK OF THE M AP INTERFACE
MAP
TCAP
SCCP
MTP3 M3UA
MTP2 SCTP
IP
L1 Data Link
As shown in Figure 12, the signaling protocol stack of the MAP

interface falls into two modes:
Narrowband SS7 signaling transmission mode, which adopts

MAP/TCAP/SCCP/MTP3/MTP2
SIGTRAN signaling transmission mode, which is based on
MAP/TCAP/SCCP/M3UA/SCTP/IP.
CAP Interface
Application The CAP interface implements transaction interaction between
CAP entities, and is physically based on E1 or IP interfaces. The
CAP interface is used for the following interfaces:
Interface between the SSP and the SCP (Completing mobile

service access and call control)
Independent IP–SCP interface (Completing the interaction
between the subscriber and the CSE).
Protocol Stack Figure 13 shows the protocol stack of the CAP interface.
F I G U R E 1 3 P R O T O C O L S T A C K O F T H E C AP I N T E R F A C E
CAP
TCAP
SCCP
MTP3 M3UA
MTP2 SCTP
IP
L1 Data Link
As shown in Figure 13, the signaling protocol stack of the CAP

interface also falls into two modes:


CAP/TCAP/SCCP/MTP3/MTP2
CAP/TCAP/SCCP/M3UA/SCTP/IP.
Gs Interface
Application The interface between the VLR and the SGSN is Gs interface.
The Gs interface is used to complete combined location update,
paging and TMSI assignment in the CS/PS domain. The Gs
interface is based on E1 or IP interfaces physically.
Protocol Stack Figure 14 shows the protocol stack of the Gs interface.
FIGURE 14 PROTOCOL STACK OF THE GS INTERFACE
BSSAP+
SCCP
MTP3 M3UA
MTP2 SCTP
IP
L1 Data Link
As shown in Figure 14, the signaling protocol stack of the Gs

interface falls into two modes:

BSSAP+/SCCP/MTP3/MTP2
BSSAP+/SCCP/M3UA/SCTP/IP.
Mj/Mg Interface
Application The interface between the MGCF and the BGCF is Mj interface.
The interface between the MGCF and the CSCF is Mg interface.
Through the Mj and Mg interfaces, interworking between the CS
domain and the IMS domain can be implemented. The signaling
protocol stack of the Mj/Mg interface is based on SIP.
Protocol Stack Figure 15 shows the protocol stack of the Mj/Mg interface.

FIGURE 15 PROTOCOL STACK OF THE MJ/MG INTERFACE
As shown in Figure 15, the signaling protocol stack of the Mj/Mg

interface is based on IP transmission, and can be over
UDP/TCP/SCTP.
Billing Interface
The billing interface is shown in Figure 16.
FIGURE 16 BILLING INTERFACE
The ZXWN MSCS sends CDRs to the ZXWN billing server through
an internal interface, whose bottom layer adopts the TCP/IP
protocol for communication.
After pre-processing CDRs, the billing server uses the FTP or

FTAM to send them to the billing center. The billing interface can
be physically based on 10/100 M Ethernet interface or standard
X.25 interface.
O&M Interface
Application ZXWN MSCS Network Management Subsystem (NMS) adopts
TMN architecture, and its interfaces include OMC-oriented N
interface, client-oriented F interface, Q3 interface between main
modules of NMS server, and the interface between the NMS and
the MSC server/VLR.
The N interface describes such application protocols as

CORBA/CNMP/CMIP, to implement interconnection between
the network element management system and the OMC.
As an interface between the client and the NMS server, the F
interface describes commands and command responses in
text format between the client and the server.

Q3 interface is between NMS modules such as LMF, LAF and

NAF. When it adopts CMIP specifications, the message
stream is the CMIS stream.
The internal message interface or SNMP protocol interface is
used between the NMS and MSC server/VLR.
Protocol Figure 17 shows the protocol architecture of the O&M interface.
Architecture
FIGURE 17 O&M INTERFACE PROTOCOL ARCHITECTURE
Features All O&M interfaces are application layer interfaces. They

resolve problems of interconnection and interoperation
between the NMS and the equipment. They run on the
TCP/IP protocol.
These interfaces are not involved in specific communication
protocols, and just give a canonical description of the
application connection.
In ZTE NMS, the XML text format is adopted to implement
the F interface, for which TMN protocol does not specify the
command format.
CORBA Interface
Definition The CORBA interface is the interface between the NMC and the
OMC. This interface supports public management, configuration
management, performance management, and alarm
management functions.
Physical The CORBA interface is the IF2 interface in Figure 18.The upper-
Location level network management gives management operation
commands on the NMC, while the OMC executes management
operations, returns the execution result to the NMC, and may
report the related notification to the NMC.

FIGURE 18 POSITION OF THE CORBA INTERFACE
Standards At present, the CORBA interface supports China Mobile

Supported by Specification, and China Unicom Specification (based on TDM or
CORBA IP).
Interface
Connection The connection between the CORBA interface and the upper-
between level network management usually adopts the naming service
CORBA mode and the IOR file mode. If the naming service mode is
Interface and adopted, it is required to provide the upper-layer network
Upper-level management with the IP address used for the interconnection
Network between the upper-layer network management and the ZTE
Management OMC. If the IOR file mode is adopted, it is required to provide
the upper-layer network management with the IOR file ending
with “EPIRPImpl” among the object persistence files.
Lawful Interface
Concept of the Interception services refers to performing real-time tracing and
Lawful Service interception on all the traffic and non-traffic activities of
controlled numbers (including MSISDN, IMSI and IMEI)
according to some special requirements in the NE of the mobile
communication system. These activities includes MS power-on
and power-off, outgoing and incoming calls, handoff and location
update during the call, short message receiving/sending of MS,
data communication and fax receiving/sending and other special
services.
The lawful service should be able to give real-time responses to
activities (all traffic and non-traffic activities defined in the ETSI
specification) of the controlled MS. For traffic activities,
corresponding MS activity report and traffic contents are sent as
an output. For non-traffic activities, only MS activity report is
sent as an output.

Concept of the The lawful interface is between the MSCS NE and the Lawful
Lawful Information Center (LIC).
Interface
ZXWN supports the following interception specifications:
China 2G Interception
ETSI Interception
Russia Interception
3G The connection relationship between the LIC and the NEs in the
Interception mobile communication system is shown in Figure 19.
Interface
FIGURE 19 STRUCTURE OF THE LAWFUL INTERFACE
As shown in Figure 19, the lawful interface consists of X1

interface, X2 interface and X3 interface. The messages of the X1
interface are initiated by the LIC, while the messages of the X2
and X3 interfaces are actively reported by NEs.
The X1 and X2 interfaces adopt the TCP/IP protocol; the X3
interface in the CS domain adopts the ISUP/TUP/BICC protocol;
and the X3 interface in the PS domain adopts the TCP/IP or
UDP/IP protocol.
2G The China 2G interception interface has three types, as shown in
Interception Table 4.
Interface

TABLE 4 FUNCTIONS OF CHINA 2G INTERCEPTION INTERFACES
Interface
Interface Functions Interface Protocols
Name
Used to input operation X.25 or TCP/IP protocol, and
commands related with its working protocol stack is
IF1 the lawful software, and X.25 ISO/IEC, ISO/IEC
output the corresponding 8208; TCP/IP ISO/IEC
responses 802.2, ISO/IEC 802.3
Used to output activity X.25 or TCP/IP protocol, and
reports of the controlled its working protocol stack is
IF2 MS, short messages and X.25 ISO/IEC, ISO/IEC
alarm information of 8208; TCP/IP ISO/IEC
lawful software 802.2, ISO/IEC 802.3
Used to output contents 2048kbit/s digital interface.
of the calls, data The interface parameters
communication and their should comply with the
mapping IDs. The specifications of GB7611-87,
IF3 mapping ID is used to and the signal mode of the
associate the activity digital interface should have
reports of the controlled the TUP mode or the ISUP
MS output by the IF2 mode of the NO.7 signal at
interface in the same call least
SNMP Interface
Definition The SNMP interface is the interface between the NMC (network
management center of the operator) and the OMC provided by
equipment manufactures.
Physical The SNMP interface is the IF2 interface in Figure 20. The upper-
Location level network management gives management operation
commands on the NMC, while the OMC executes management
operations, returns the execution result to the NMC, and may
report the related notification to the NMC.
FIGURE 20 POSITION OF THE SNMP INTERFACE
Functions 1. Getting the version No. of ALARM IRP

This function enables the upper-layer network management

to query the version No. of the ALARM IRP object.
2. Getting the version No. of CS IRP
to query the version No. of the CS IRP object.
3. Getting the current heartbeat value
to monitor and manage the links to the lower-layer network
management to get the current heartbeat value.
4. Setting a new heartbeat value
to monitor and manage the links to the lower-layer network
management to set a new heartbeat value. The range of the
heartbeat value is [1, 60] and 0, and the unit is minute.
Where, 0 means that no heartbeat value is set. A heartbeat
notification will be reported when the heartbeat value is set
to 0 for the first time, and no heartbeat notification will be
report when the heartbeat value is set to 0 again.
5. Reporting the heartbeat notification
This function enables the alarm heartbeat events generated
on the NE to be sent to the NMC according to the TRAP
destination information.
6. Managing the TRAP destination: including adding a new TRAP
trace address, deleting a TRAP trace address, and querying
TRAP trace address information
This function enables upper-layer network management to
manage and maintain TRAP addresses.
7. Reporting alarms according to TRAP
This function enables the newly-generated alarms and
recovered alarms on the NE to be reported to the NMC
according to the TRAP destination information.
Signaling System (Protocols)

The ZXWN MSCS system mainly applies the following protocols:
Narrowband No.7 protocol: For details, refer to Narrowband
No.7 Protocol.
Broadband No.7 protocol: For details, refer to Broadband
No.7 Protocol.
SIGTRAN protocol: For details, refer to SIGTRAN Protocol
Suite.
H.248 protocol: For details, refer to H.248 Protocol.
BICC protocol: For details, refer to BICC Protocol.

RANAP protocol: For details, refer to RANAP Protocol.

BSSAP protocol: For details, refer to BSSAP Protocol.
Gs interface protocol: For details, refer to Gs Interface
Protocol.
MAP protocol: For details, refer to MAP Protocol.
CAP Protocol: For details, refer to CAP Protocol.
SIP Protocol: For details, refer to SIP Protocol.
Narrowband No.7 Protocol

Protocol Stack Figure 21 shows the narrowband No.7 protocol stack of ZXWN
MSCS.
FIGURE 21 NARROWBAND NO.7 SIGNALING PROTOCOL STACK
TCAP ISUP TUP
SCCP SCCP SCCP
MTP3
MTP3
MTP2
MTP1
Protocol The narrowband No.7 protocol stack includes the following

Composition protocols:
MTP1 protocol
MTP2 protocol
MTP3 protocol
SCCP protocol
TCAP protocol
TUP protocol
ISUP protocol
MTP1 Protocol Message Transfer Part Level 1 (MTP1) implements the data-link-
level function of the narrowband No.7 signaling system, defines
physical and electrical functions and features, and decides the
connection method of the data link. MTP1 is the physical media
for signaling transmission. At present, most No.7 signaling is
transferred on 2048 kb/s PCM.
MTP2 Protocol 1. Description
Message Transfer Part Level 2 (MTP2) implements the
signaling-link-level function of the narrowband No.7 signaling

system. The signaling-link-level function defines the function

and program for the transfer of signaling messages on a
signaling data link. Cooperating with the signaling data-link-
function, the signaling-link-level function provides the
signaling link for reliable transmission of signaling messages
between two signaling points. It implements the functions of
managing and maintaining the No. 7 signaling links, and
transferring signaling messages.
Since the links and the processing modules are configured to
one-to-one-correspondence relationship in the database, the
link management and message transfer are only related with
the configured L3 module. The links managed by MTP2 can
be 64 k signaling links, n X 64 k signaling links and 2M high-
speed signaling links.
2. Signal Units
In the narrowband No.7 signaling system, the signaling
information and other information generated by the user part
are transferred on signaling links through signal units.
The narrowband No.7 signaling has three different signal
units: Message Signal Unit (MSU), Link Status Signal Unit
(LSSU), and Fill-In Signal Unit (FISU).
The format of the MSU is shown in Figure 22.
FIGURE 22 MSU OF NARROWBAND NO.7 SIGNALING
The format of the LSSU is shown in Figure 23.
FIGURE 23 LSSU OF NARROWBAND NO.7 SIGNALING
The format of the FISU is shown in Figure 24.
FIGURE 24 FISU OF NARROWBAND NO.7 SIGNALING

The meaning of each field in the signal unit is as follows:

i. Field F: Signaling unit delineation flag (01111110)
It generally indicates the beginning of a signal unit, and
indicates the end of the previous signal unit as well.
ii. Field CK: error detecting code.
It detects errors occurring during the transfer of signal
units.
iii. Field LI: length indicator of signal units
It indicates how many bytes are contained between field
LI and field CK (with themselves excluded). It is counted
to 63 when exceeding 62. For the MSU, LI>2; for the
LSSU, LI=1 or 2; for the FISU, LI=0.
iv. Field SIO: service information field
Only used for MSUs, it indicates message types and
network types.
v. Field SIF: signaling information field
Only used for MSUs, it contains the contents of the
messages sent by users.
vi. Field SF: status field
Only used for LSSUs, it indicates link status. Its format is
shown in Figure 25.
F I G U R E 2 5 F O R M AT O F S F
The codes of CBA are as follows:

f 000 indicates Status Indicator-Out of alignment (SIO).
f 001 indicates Status Indicator-Normal (SIN).
f 010 indicates Status Indicator-Emergency (SIE).
f 011 indicates Status Indicator- Out of Service (SIOS).
f 100 indicates Status Indicator-Processor Outage (SIPO).
f 101 indicates Status Indicator-Busy (SIB).
vii. Fields FSN/FIB and BSN/BIB: signal unit sequence
number and indicator bit
f Forward Sequence Number (FSN) is the sending
sequence number of this message, which is encoded
based on modulo 128.

f Forward Indicator Bit (FIB) is inverted to indicate

retransmission of a message at the local end.
f Backward Sequence Number (BSN) indicates the last in-
sequence signal unit received correctly by the peer end.
f Backward Indicator Bit (BIB) is inverted to indicate
retransmission of messages from the No. BSN ＋ 1
message at the peer end.
viii.All idle bits in the signal units are set to 0.
The arrows in Figure 22~Figure 25 indicate the sending
sequence of messages.
3. The MTP2 protocol module implements the following
functions:
Signal unit delimitation and location
There is a unique eight-bit code called flag both at beginning
and end of each signal unit. The flag will not appear at other
places of unit. During delimitation process, if not-permitted
bit code patterns (more than six consecutive "1"s) are
received or signal unit exceeds permitted maximum length, it
will regard that the signal unit location has been lost.
Error detection
Error detection is completed by 16-bit check code at the end
of each signal unit.
Error correction
There are two methods of error correction: Basic method and
preventive cyclic method.
Initial location
When link recovers after it is started for first time (after it is
connected) or a fault occurs, the system first implements
message transmission for a period of time. If error is within
permitted range, link enters into operation. Otherwise, link is
out of service.
Signaling link error monitoring
Monitors error rate of message transmission on link during
initial location and in service status. If error rate is higher
than set value, link is out of service.
Processor fault
Detects local processing faults and reports to opposite end.
In addition, function reports to MTP3 when receiving the
information on opposite processor faults.
Link status control
Controls conversion of link status, and reports link status
changes to MTP3.
Traffic control

Judges whether there is any congestions and reports to

upper layer or opposite end according to buffer application
on link.
MTP3 Protocol 1. Structure diagram
The Message Transfer Part Level 3 (MTP3) system structure
is shown in Figure 26.
FIGURE 26 MTP3 ARCHITECTURE
MTP3
SMH
Message Message
distribution discrimination
( HMDT) (HMDC)
Message routing
( HMRT)
SCCP MTP2
Signaling network
management
Signaling service
management
Signaling route Signaling link

management management
MTP 3 management
2. Composition
MTP3 is split into two main modules: Signaling Message
Handling (SMH) and Signaling Network Management (SNM).
i. SMH module: completes messaging routing, and
distribution
The SMH module transfers the signal messages occurring
in the user part of a signaling point to the target user
part specified by this user part, and implements load
sharing of signal messages on different links according to
the selection of the user part to ensure no loss,
retransmission, or disorder of message transferring. The
SMH module is composed of three parts: message
routing (HMRT), message discrimination (HMDC), and
message distribution (HMDT) parts. The relationship
among these three parts is shown in Figure 26.
f HMRT part
The HMRT part selects the signaling link set and signaling
link to the destination of a signaling message from the
routing table at a signaling point. The routing function is

implemented through routing labels. A route label

contains three parts: Destination signaling Point Code
(DPC), Originating signaling Point Code (OPC), and
Signaling Link Selection code (SLS).They are used in the
load sharing on signaling links. For the messages only
transferred to level 3, the SLS corresponds to the
Signaling Link Code (SLC) of the signaling link between
the destination point and the originating point. However,
for the messages unrelated with the signaling link, the
SLC is 0000.
f HMDC part
After a signaling point receives a message signaling unit
from the signaling link function level, the HMDC part
judges whether this signaling point is the destination
signaling point according to the DPC in the message
routing label. If it is, the message signaling unit is sent to
the HMDT part; otherwise, the message signaling unit is
sent to HMRT part for transfer.
f HMDT part
After the destination signaling point receives a message,
the HMDT part determines the user part where the
message belongs according to the code of the service
information octet SIO in the signaling unit sent from the
HMDC part, and transfers the message to the
corresponding upper-layer user.
ii. SNM module: updates routing and ensures reliable
message transferring by cooperating with other signaling
points in the network when faults occur in the in the
network.
The SNM module is divided into three parts: signaling
service management, signaling link management and
signaling route management. The SNM module has its
own message format and encoding mode. If a signaling
link or a signaling point fails, the SNM module can
provide the actions and procedures necessary to maintain
signaling service and recover normal signaling conditions.
The relationship among these three parts is shown in
Figure 26.
f Signaling Service Management
This part completes switchover, switchback, forced
rerouting, controlled rerouting, signaling point restart,
flow control, management blocking and unblocking.
f Signaling Link Management
Belonging to the basic signaling link management process,
the signaling link management completes signaling link
start, quit, status query and status change notification.
f Signaling Route Management

This part guarantees the reliability of signaling routing

information exchange between the signaling points.
Signaling route management is implemented through the
following four processes: transfer prohibited, transfer
allowed, transfer controlled, and transfer restricted (not
implemented).
SCCP Protocol 1. Overview
The Signaling Connection Control Protocol (SCCP) in the No.7
signaling system completes the network-layer function of the
No.7 signaling system together with the MTP3 protocol of the
lower layer.
2. Service Class
The SCCP can provide users with connectionless and
connection-oriented services, including the following four
classes:
Class 0: Basic connectionless service
Class 1: Sequenced connectionless service
Class 2: Basic connection-oriented service
Class 3: Flow control connection-oriented service
3. Structure diagram
The structure of the SCCP protocol is shown in Figure 27.
FIGURE 27 STRUCTURE OF THE SCCP PROTOCOL
4. Functional block
The SCCP consists of four functional blocks as follows:
i. SCCP Routing Control (SCRC)
Upon receipt of a message from the MTP, SCRC forwards
the message to SCLC, SCOC, or the MTP. SCRC also
receives internal messages from SCOC or from SCLC and

performs any necessary routing functions before passing

them to the MTP.
SCCP routing has two modes: DPC+SSN and GT
addressing. The GT addressing is usually used when the
originating point does not know the DPC. In this case, the
SCCP must translate the GT to DPC+SSN or the
combination of DPC, SSN and GT, so that the message
can be forwarded to the MTP for transfer. Due to resource
limitation of each node, it is impossible for the SCCP of
one node to translate all GTs. Therefore, the SCCP of the
originating node may translate the GT to the DPC of one
middle node, and the SCCP of the middle node translates
the GT, and finally forwards it to the destination node.
These middle nodes are called relay nodes of SCCP
messages.
ii. SCCP Connectionless Control (SCLC)
The SCLC service includes class-0 service and class-1
service. Class-0 service requires no in-sequence
transferring, while class-1 service requires in-sequence
transferring.
The connectionless procedures allow a user of the SCCP
to request transfer of user data without first requesting
establishment of a SCCP connection.
The SCCP user of the originating node uses the N-
UNITDATA request primitive to request transfer of user
data by the SCCP and for the SCCP to indicate delivery of
connectionless user data to the destination user.
Parameters associated with the N-UNITDATA request
primitive must contain all information necessary for the
SCCP to deliver the user data to the destination.
The user data is then transferred in XUDT or UDT
message (s), using SCCP and MTP routing functions, to
the "Called address" indicated in the N-UNITDATA
request primitive. The "Called address" can be different
combinations of DPC, SSN and GT. When the "Called
address" contains the GT, the GT translation must be
performed, and data are transferred to the destination
node.
If XUDT or UDT messages are unable to be delivered to
the destination due to various causes, the SCCP node
where errors occur during message delivery starts the
message return procedure to return the user data in
UDTS or XUDTS messages to the released SCCP node
with the return cause.
The connectionless data service can transfer the upper-
layer user data of the SCCP, and SCCP ManGement
(SCMG) messages as well. The content of a SCMG
message is in the data area of a UDT message. Upon
receipt of the XUDT, LUDT or UDT message, the SCCP
functions at the destination node perform the analysis. If

the message is not a SCMG message, the SCCP uses the

N-UNITDATA indication primitive to notify the SCCP user.
If the message is a SCMG message, the SCCP transfers it
the SCMG for processing.
iii. SCCP Connection-Oriented Control (SCOC)
The SCOC service includes class-2 service and class-3
service. Class-2 service has no traffic control function,
while class-3 has the traffic control function.Class-3
service is not used at present.
SCOC implements a series of procedures for connection-
oriented data transfer, including connection
establishment, data transfer, connection release, and
inactivity detection. The following describes these
procedures in detail.
f SCCP connection establishment
When the SCCP at the originating node receives a N-
CONNECT.request to establish a SCCP connection from a
SCCP user, it allocates a local reference number, and
other resources, and forwards a CR message to that
destination node, and start T (conn est).
On receipt of the CR message, the destination node
sends the N-CONNECT.indication message to notify the
upper-layer SCCP user. Upon receipt of the N-
CONNECT.response message from the SCCP user, the
destination node allocates a local reference number, and
other resources for the input connection section, sends a
CC message to the originating node, and starts inactivity
control timers, T (ias) and T (iar).
Upon receipt of the CC message, the originating node
sends an N-CONNECT.confirm message to notify the
SCCP user of SCCP connection establishment success,
stops T (conn est), and starts inactivity control timers, T
(ias) and T (iar).
Till now, the SCCP connection between the originating
node and the destination node is established and
transmission of messages may commence.
f SCCP connection release
The SCCP connection release may be initiated by either of
the connected nodes.
When a connection release is initiated at an end node of a
SCCP connection, by the SCCP user invoking an N-
DISCONNECT request primitive or by the SCCP itself, the
following actions are performed at the initiating node: An
RLSD message is transferred on the connection section. A
release timer T (rel) is started. The inactivity control
timers, T (ias) and T (iar), if still running, are stopped.
Upon receipt of an RLSD message, the other end node of
the SCCP connection sends a release complete message

RLC. The resources associated with the connection are

released, the inactivity control timers, T (ias) and T (iar),
are stopped, and the local reference number is frozen.
The end node sends the N-DISCONNECT.indication
primitive to notify the upper-layer SCCP user.
Upon receipt of the RLC message, the release initiating
node releases resources associated with the connection,
freezes the local reference number, and strop the release
timer T (rel).
f Inactivity detection
The inactivity control procedure is to set two inactivity
control timers, the receiving inactivity control timer T (iar)
and the sending inactivity control timer T (ias), are
required at each end of a connection section. When any
message is sent on a connection section, T (ias) is reset.
When any message is received on a connection section, T
(iar) is reset. When T (ias) expires, an IT message is sent
on the connection section. When T (iar) expires, the
connection section is released.
f Data transfer
Since only class-2 services are applied in the UMTS
system, only the transfer of DT1 data is described here.
After the SCCP connection is established, the users at
both ends can use this connection to transfer DT1 data.
The upper-layer SCCP user at either end can request
transfer of user data on a SCCP connection by invoking
the N-DATA.request primitive. After receiving the N-
DATA.request, the SCCP checks the length of user data to
see whether segmentation is required. If it is not required,
the user data in a DT1 message are transferred to the
peer end.
Upon receipt of the DT1 message, the peer end delivers
the data to the SCCP user by invoking the
N-DATA.indication primitive.
The too long data must be segmented before insertion
into the "data" field of a DT1 message. Then they are
sent to the destination node in multiple DT1 messages.
Upon receipt of the segmented DT1 messages, the
destination node needs to reassemble the data in these
messages, and notify the upper-layer user by invoking
the N-DATA.indication primitive.
iv. SCCP ManaGement (SCMG)
The SCMG function is applied to the connectionless
service, and the connection-oriented service as well.
Based on different managed objects, SCMG can be
divided into:
f Signaling point status management

Signaling point status management updates the SCCP

address translation table and the node status, and
modifies and reassembles the related routes based on the
signaling point status message provided by the MTP.
Thus, users can take measures to stop sending or reduce
the times of sending signaling messages to the related
signaling points. Signaling point status management
includes Signaling Point Allowed Control (SPAC),
Signaling Point Prohibited Control (SPPC), Signaling Point
Congested Control (SPCC), and congestion clear control.
f Subsystem status management
Subsystem status management updates the SCCP
translation table and the subsystem status based on the
information of failure, withdrawal, and recovery of the
related subsystems. Subsystem status management
includes Subsystem Prohibited Control (SSPC),
Subsystem Allowed Control (SSAC), and Subsystem
Status Test Control (SSTC).
TCAP Protocol 1. Overview
The Transaction Capability Application Part (TCAP) is above
the SCCP in the SSN7 layered structure. It provides the
same support for information exchange of different
application services in the network environment, and
transfers address translation information, subscriber data
information, billing information, management information, or
other non-circuit-related information between exchange
nodes and control nodes. The TCAP signaling procedure
processes and controls operations and dialogues.
2. Layered structure
To implement operation and dialogue control, TCAP is divided
into Component Sub-Layer (CSL) and Transaction Sub-Layer
(TSL). The CSL performs operation management, while the
TSL performs transaction (dialogue) management. The TC
user communicates with the CSL through TCAP primitives,
while the CSL communicates with the TSL through TR
primitives.
The layered structure of the TCAP is shown in Figure 28.

FIGURE 28 LAYERED STRUCTURE OF THE TC AP
Application
Process (AP)
TC user
TCAP service TC
Component primitive
T
Sub-Layer (CSL)
C
A
Transaction Sub-
P Layer (TSL)
Network
N －primitive
service
SCCP
MTP
3. Descriptions of sub-layers
TCAP TSL
The function of the TCAPTSL is to manage signaling
communication process between local TCAP TSL users and
remote TCAP TSL users, that is, to manage transactions.
TCAPTSL users refer to TR–users. The present TR–user is
only CSL. Communication between peer CSLs is
communication between peer TC–users, which is called a
dialogue. Consequently, transactions and dialogues are
completely the same, with a one-to-one correspondence
between them.
To complete signaling process of one application service, two
TC-users have to conduct bi-directional exchange for a series
of TCAP messages. The start, termination, sequence and
message contents of message exchange are all controlled
and explained by TC-users. However, the start, holding and
termination of dialogues, including the detection and
handling of abnormal dialogues, are all managed by the
TCAP TSL. The protocol process is applicable to dialogues of
any application service.
TCAP CSL
TCAP CSL functions include operation management,
component error detection and dialogue component
allocation.
Normally, a TC-user initiates a request for invoking an
operation. The TCAP CSL sets up a status diagram for each
operation, thereby implementing operation management.

Component errors include protocol errors and response

timeout. Protocol errors refer to the inconsistency between
the component type received by the TCAP CSL and the
expected input of the operation status diagram, or the fact
that the component format has syntax errors or it is
unidentifiable. Response timeout refers to timeout of various
operation timers.
The TCAP CSL allocates dialogue components through its
management over dialogue IDs.
TUP Protocol Telephone User Part (TUP) functions include:
Incoming/outgoing call
Completes call connection, conversation and call release, and
implements call status migration and call resource
occupation/release.
Circuit management function
Includes circuit recovery, circuit reconnection check
(including reconnection check output and input), circuit
group maintenance (including maintenance-oriented circuit
group maintenance, hardware-oriented circuit group
maintenance and circuit group recovery process), and circuit
blocking. Circuit blocking is to prevent faulty circuits or
tested circuits from accepting or generating signal services
(or recovering services).
ISUP Protocol ISDN User Part (ISUP) functions include:
Incoming call processing, connection check and release.
Outgoing call processing, connection check and release.
Circuit monitoring and control, including circuit
blocking/unblocking, maintenance-oriented circuit group
blocking/unblocking, hardware fault circuit group
blocking/unblocking, circuit recovery, circuit reconnection
check, and circuit group query.
Depending on the CIC, the MTP3 decides the module, and
sends messages accordingly. Message is sent to the MTP3 of
the local module.
CDR and traffic statistics, which are distributed among
outgoing and incoming calls.
Broadband No.7 Protocol

Application In R4 phase, broadband NO.7 protocols are mainly applied on
the Iu-CS interface, providing reliable transfer services between
the RANAP and the SCCP. In addition, broadband NO.7 protocols
can be applied on the Nc interface, providing services for the
BICC protocol.

Comparison The main difference between broadband NO.7 protocols and

with narrowband NO.7 protocols is changes in MTP layers. The MTP-1
Narrowband and MTP-2 are changed to the Signaling ATM Adaptation Layer
No.7 protocol (SAAL), while the MTP-3 is changed to MTP-3B. The physical
connection is changed to the ATM (PVC) connection from the E1
trunk connection.
Protocol Stack The broadband signaling system is divided into the following
layers:
Physical layer
ATM
Service Specific Connection Oriented Protocol (SSCOP)
Service Specific Coordination Function (SSCF)
Message Transfer Part Level 3 Broadband (MTP3B)
Broadband-Signaling Connection Control Part (B-SCCP)
Its protocol stack is shown in Figure 29.
FIGURE 29 PROTOCOL STACK OF THE BROADB AND SIGNALING SYSTEM
SAAL Functions
In the broadband signaling network, to transfer signaling
messages in the ATM network, it is required to adapt the
signaling message to be transferred (that is, convert the
message format of the signaling message to be transferred
into that able to be transferred in the ATM network), and
establish the AAL connection for the signaling message. The
SAAL implements this function.
Structure

The SAAL adopts ATM Adaptation Layer Type 5 (AAL5), and

is mainly composed of Convergence Sub-layer (CS) and
Segmentation And Reassembly sub-layer (SAR). The CS
consists of Service-Specific Convergence Sub-layer (SSCS)
and Common Part Convergence Sub-layer (CPCS). The SSCS
consists of Service Specific Coordination Function sub-layer
(SSCF), Service Specific Connection Oriented Protocol sub-
layer (SSCOP) and Layer Management (LM).
The SAAL structure is shown in Figure 30.
FIGURE 30 SAAL STRUCTURE
MTP-3B
SSCF
L
SSCOP
M
CPCS-SAR
SAAL
SSCOP SSCOP provides mechanisms for the establishment and release

of connections and reliable exchange of signalling information
between signalling entities.
SSCOP layer functions include:
SD PDU sequence control: Guarantees continuity and

integrity of SD PDU sequence.
Error correction and retransmission: Uses SD PDU sequence
number to judge whether information is lost or not, and then
retransmits lost data.
Flow control: Through sliding window mechanism, receiver
can control data transmission rate of sender, and report
errors to layer management part.
Link hold: If no data is transmitted between two SSCOP
users for a longer period of time, SSCOP can periodically
send POLL PDU to confirm whether the link is still in the
connection status.
Local data retrieval: User SSCF of SSCOP can use this
function to retrieve data in a sending queue or in sending
buffer.

Connection control: It is used for connection setup and

release and performs re-synchronization upon connection
fault.
User information transfer: Allows SSCOP subscriber data to
be transmitted through SSCOP. Here, two options are
available: Acknowledged data transmission and
unacknowledged data transmission & management data
transmission.
SSCOP layer detects and recovers errors in the
implementation of the SSCOP.
SSCOP layer exchanges status information between receiver
and sender.
SSCF Service-Specific Coordination Function (SSCF-NNI) assists
SSCOP in completing link-level functions, and has the following
functions:
Link establishment: Includes the location process and
certification process (optional).
Data transmission: Provides signaling transmission channel
for MTP3b.
Link release: Releases connection so that link cannot provide
reliable data transfer for MTP3b any more.
SDU access: After link is disabled, MTP3b performs link
switchover and gets back those messages that have been
sent but not received by opposite end.
Unacknowledged transmission: Message can be transmitted
in any status, but no confirmation is made for transmission.
Signaling link error monitoring: Cooperates with LM to
implement link monitoring, which is distributed among
different processing procedures.
SSCF-UNI implements services requested by layer 3 signaling
users, negotiates between services provided by SSCOP, and
provides primitive mapping between upper/lower layer protocol
modules (including upper/lower layer data forwarding, SSCOP
signaling establishment and release, so that specific Layer 3
service users are independent of SSCOP module. Its main
functions include:
Support for point to point and point to multi-point
unacknowledged data transmission.
Support for point-to-point reliable data transmission, which
includes connection establishment and release.
SAAL-LM LM is the Layer Management (LM) of Signaling ATM Adaptation
Layer (SAAL). SAAL consists of SSCOP and SSCF. LM
corresponds to logical link layer in seven-layer OSI model and
provides point-to-point link connection, so main function of LM is
to monitor and manage link performance and state of
connections and handle link fault. Specific functions are as
follows:

LM interacts with SSCF and SSCOP, traces link state,

processes and records errors from SSCF and SSCOP.
After SSCOP connection at both ends of a link is completed,
LM enters data transfer stage to notify SSCF, and SSCF will
send a test message to peer end to test whether link error
rate meets the requirements. LM judges whether link meets
quality requirements according to MAA_ERROR_IND of
SSCOP and MAAL_REPORT_IND of SSCF.
LM monitors error rate of a link in service state, and releases
link if necessary.
Flow control function in SSCOP will disable the receiving if
traffic is too large, so LM should be able to monitor duration
of such a case. If duration is too long, LM should be able to
release this link in time.
LM monitors the SSCOP recovery frequency and releases this
link if interval between two recovery events is less than a
threshold.
MTP3B In addition to narrowband MTP3 function, MTP3B modifies the
following contents:
The maximum transmission message length is changed to
4000 bytes. For narrowband signaling links, the maximum
transmission message length is 250 bytes.
Upon the switchover, switchover messages change to
extended switchover messages. The sequence number of
lower-layer messages is expanded to three bytes to meet the
SSCOP protocol.
B-SCCP Besides having the functions of the narrowband SCCP, the
Broadband Signaling Connection Control Part (B-SCCP) has two
new parts.
LUDT
Long Unit Data messages (LUDT) are used to transmit data
at SCCP nodes in connectionless mode. Without
segmentation, LUDT can transfer Network Service Data Unit
(NSDU) with up to 3,949 octets. LUDT is used for
connectionless protocol types 0 and 1.
LUDTS
Long Unit Data Service messages (LUDTS) are used to notify
source the SCCP that LUDT cannot be transferred to the
destination. LUDTS will be sent only when returning message
upon error is configured in LUDT.
SIGTRAN Protocol Suite

Overview The SIGnaling TRANsport (SIGTRAN) protocol suite is the
specification for interworking between the No.7 signaling and the
IP signaling, which is formulated by the SIGTRAN workgroup in

IETF. This protocol suite supports transferring the traditional

Switched Circuit Network (SCN) signaling through the IP
network, and supports the standard inter-layer primitive
interface in the layered model definition of the SCN signaling
protocol to ensure that the existing SCN signaling applications
can be used without modification. At the same time, this
protocol suite uses the standard IP transferring protocol as the
transmission bottom layer, and meets the special transmission
requirement of the SCN signaling through its own functions.
ZXWN MSCS supports the whole SIGTRAN protocol stack.
Protocol Stack The structure of the SIGTRAN protocol stack is shown in Figure
31.
FIGURE 31 SIGTR AN PROTOCOL STACK
As shown in Figure 31, the SIGTRAN protocol stack is composed

of the following three parts:
Signaling adaptation sub-layer, including:

f M3UA
f M2UA/M2PA
f SUA
f IUA
SCTP
Standard IP transport protocol
SCTP 1. Overview
The Stream Control Transmission Protocol (SCTP) follows the
requirements in the RFC2960 specification. The SCTP mainly
bears signaling in the IP network. It enables signaling
messages to be exchanged in the IP-based public packet
switched network and performs end-to-end flow control and
error control.
The SCTP is actually a connection-oriented protocol, but the
concept of the SCTP association is wider than the TCP
connection. The SCTP is more complete than the TCP,
providing more reliable signaling transferring. The
advantages of the SCTP include congestion control, avoiding
multicast flooding and anonymous attack, excellent real-time
performance and multi-homing support. Considered as a

transport-layer protocol, the upper layer of the SCTP serves

as the user application and the lower layer servers as the
packet network. In the SIGTRAN protocol application, the
upper-layer user of the SCTP is the adaptation module of the
SCN signaling (such as M2UA and M3UA), and the lower-
layer user is the IP network.
2. Transferring mode
The SCTP protocol provides reliable message transferring
services between two SCTP users through the association
established between two SCTP endpoints. Moreover, the
SCTP protocol provides the method of establishing the
association for transferring a group of addresses between
two SCTP endpoints. The SCTP endpoint can send SCTP
packets through the established association. One SCTP
association can contain several groups of possible
source/destination addresses, which are contained in the
transferring address list of each endpoint, as shown in Figure
32.
FIGURE 32 STRUCTURE OF THE SCTP
3. Features
SCTP functions to:
Transmits user message packets
Ensures that user messages are transferred orderly or
disorderly in the stream.
Establishes multiple streams in one association, without
mutual interference in the data transmission between
streams.
Supports the multi-homing function at one or two ends of the
association to improve the reliability of the association.
Requires COOKIE authentication during the association
establishment, ensuring the security of the association.
Provides the real-time path fault test function.
4. Related terms
The related terms of the SCTP are introduced as follows:

i. Transport Address
The SCTP transport address refers to one IP address plus
one SCTP port number. Same with the TCP port number,
the SCTP port number is used for the SCTP to identify
users with the same address.
For example, the IP address “10.105.28.92” and the
SCTP port number “1024” identify one transport address,
while the IP address “10.105.28.93” and the SCTP port
number “1024” identify another transport address.
Similarly, the IP address “10.105.28.92” and the SCTP
port number “1023” can identify a different transport
address.
ii. Host and Endpoint
A host means one computer with one or more IP
addresses, which is a typical physical entity.
Endpoint is the basic logical concept of the SCTP. An
endpoint is a typical logic entity, which is the logic sender
and receiver of the datagram.
The SCTP protocol specifies that only one association can
be established between two endpoints, but that one host
can have many endpoints.
iii. Association and stream
f An association refers to the logic connection or channel
between two endpoints for data transferring, which is
established through the four-way handshake specified in
the SCTP protocol.
f The “stream” is a characteristic term in the SCTP protocol.
To be specific, a stream is a one-way logic channel in a
SCTP association from one endpoint to another. The data
to be orderly transferred must be transferred in one
stream.
One association can contain multiple streams.
iv. TSN and SSN
f At one end of an association of the SCTP, each data block
sent by the local end is allocated with a 32-digit sequence
number based on the initial Transmission Sequence
Number (TSN), so that acknowledgement can be
performed when the opposite end receives the data block.
The TSN is maintained based on the association.
f In each stream in one association of the SCTP, each data
block sent in this stream by the local end is orderly
allocated with a 16-digit Stream Sequence Number (SSN),
so that data blocks can be orderly transferred in a stream.
The SSN is maintained based on the stream.
The TSN allocation and the SSN allocation are mutually
independent.
v. Other

f CWND: congestion window. The SCTP is also a sliding

window protocol. The CWND is maintained based on each
destination address, and can be adjusted according to the
network condition. When the length of the sending-
without-acknowledgment message of the destination
address exceeds its CWND, the endpoint will stop sending
data to this address.
f RWND: receiving window. The RWND is used to describe
the size of the receiving buffer of the opposite end of an
association. During the association establishment process,
the two ends will exchange their initial RWNDs. The
RWND will change according to the data sending and
acknowledgment conditions. The size of the RWND
restricts the size of the data to be sent by the SCTP.
When the size of the RWND is 0, the SCTP can still send
one datagram to know the change of the buffer at the
opposite end through the acknowledgement message
until the restriction of the CWND is reached.
5. Functional structure
Functional modules of SCTP to implement service
transmission are shown in Figure 33.
FIGURE 33 FUNCTIONAL MODULES OF SCTP
Upper-layer application
SCTP user
Orderly delivery of the

messages in the multi-data flow
Association setup and
User data segmentation

SCTP
Acknowledgement and function
release
congestion avoidance
Data block binding
Packet validity validation
Path management
IP layer
6. Functions of functional modules

Association set up and release
Association setup is started upon SCTP user’s initiation and
COOKIE mechanism is adopted during start process of
association.

The SCTP provides a normal shutdown program for activated

associations and this program is executed based on SCTP
user’s request. Meanwhile, an abnormal abort program is
provided as well which can be started based on user’s
request or actively performed by the SCTP.
Orderly Delivery of Messages
Streams in the SCTP are used to indicate user’s message
sequence to be orderly delivered to higher protocols, and
messages in a stream must be delivered orderly. The SCTP
user can specify the number of streams supported in an
association during association setup. This number is
negotiated by both sides and user messages are associated
through stream numbers. The SCTP allocates a stream
sequence number for each user message passing through
the SCTP. At the receiving end, the SCTP ensures that in the
given stream, messages are orderly delivered to the user. If
a stream is blocked when waiting for the next continuous
message, orderly deliveries on other streams are not
affected.
Meanwhile, the SCTP also provides non-orderly delivery
service. After a user message is received, it can be
immediately delivered to the SCTP in this mode without
ensuring its sending order.
User Data Segmentation
The SCTP can segment user messages as required when
sending them to ensure that the length of the SCTP packet to
be sent to lower layer meets the requirements of channel
MTU. At the receiving end, it is required to combine all
segments into a complete message, and deliver it to the
SCTP user.
Acknowledgement and congestion avoidance
The SCTP allocates a Transmission Order Number (TSN) for
each user data segment or non-segmentation message, and
TSN allocation is independent from stream-level allocation.
The receiving end acknowledges all the received TSNs, even
though the received TSN discontinuity may exist in the
receiving sequence. Through this mode, reliable delivery and
orderly stream delivery are independent from each other.
Acknowledgement and congestion avoidance can retransmit
packets when acknowledgement is not received within a
specified duration. Packet re-transmission can be realized
through the congestion avoidance program similar to TCP.
Data block binding
When a SCTP packet is sent to the lower layer, it must
contain a public packet header and one or multiple data
blocks following it. Each data block contains user data or
SCTP control information. An option is provided for SCTP
users, which requests whether more than one user messages
can be bound to one SCTP packet for transmission. Through

the data block binding function of the SCTP, a complete SCTP

packet will be generated at the sending end and this packet
will be disassembled at the receiving end. When congestion
occurs, though the user can request the SCTP not to bind,
the SCTP still implement the binding. If binding is prohibited,
only SCTP implementation is affected, that is, there may be a
short delay before a SCTP packet is transmitted.
Packet Validation
Each SCTP public packet header contains a necessary
validation label field and a 32-bit check field. The validation
label value is selected by the association endpoint when the
association is started. If the expected validation label value is
not contained in the received packet, this packet will be
discarded. The check code is set by the sending end to
provide additional protection to avoid data errors caused by
the network. The receiving end will discard SCTP packets of
invalid check codes.
Path Management
The SCTP user of the sending end can use a group of
transmission addresses as destination addresses of SCTP
packets. SCTP path management will select a destination
transmission address for each SCTP packet according to
SCTP user’s instruction and accessibility of current qualified
destination address set. When accessibility cannot be fully
expressed by packet traffic, path management will monitor
accessibility to a certain destination address through
heartbeat message that indicates the SCTP user when
accessibility changes. When an association is set up, path
management will report the qualified local transmission
address set to the remote, and report the transmission
address returned from the remote end to the local SCTP user.
After an association is set up, a preferred channel will be
defined for each SCTP endpoint to send SCTP packets.
Main The SCTP protocol is similar to the TCP protocol in the Internet,
Differences but it has considerable improvement in functions compared with
between SCTP the TCP. The main differences between the SCTP and the TCP
and TCP are as follows:
The TCP endpoint use a single IP address; while the SCTP
can use multiple IP addresses, has multiple-homing feature
and can use multiple routers for access.
The TCP can only provide the orderly submission service;
while the SCTP can use multiple streams, and provide orderly
and non-orderly submission services in a stream.
The TCP adopts header blocking mode to transmit data.
When the transmitted content is lost, the subsequent
messages fail to be submitted to the upper-layer user. The
SCTP uses multiple streams, and they do not affect each
other.

The TCP transmission message is based on data bytes, and

the TCP sequence number numbers bytes. The SCTP
transmission message is based on data messages, and the
SCTP sequence number numbers messages. Thanks to using
the sliding window control, the SCTP data throughput can be
greatly improved.
TCP transmission parameters are fixedly calculated; while
SCTP transmission parameters can be set by the upper-layer
use, such as RTP and heartbeat interval.
The TCP has poor capability of preventing network attacks;
while the SCTP enhances the network security.
M3UA 1. Function
The MTP3 User Adaptation (M3UA) layer supports following
functions:
Message transmission of all SS7 MTP3 users borne over IP
(ISUP, SCCP, TUP, H.248 and BICC);
Distributed IP–based signaling nodes;
SCTP transmission connection management;
Seamless operation for the MTP3 user protocol peer layer;
MTP3 network management;
Observation of important data at the protocol layer on a real-
time basis.
2. Related terms
AS
An Application Server (AS) is a logical entity, which
represents certain resources, and corresponds to a “routing
key word”. For example, an AS can be a virtual database unit,
and is used to process the transaction identified by the
combination of the No.7 signaling DPC/OPC/SUA_SSN. An AS
contain a group of exclusive AS processes, one or several of
which are activated and process services.
ASP
An Application Server Process (ASP) is the process of AS
activation or AS standby. For example, an ASP can be the
process of the MGC, IPSCP or the IP HLR. An ASP contains
SCTP endpoints, and can be configured to process multiple
AS signaling service.
IPSP
An IP Server Process (IPSP) is a process instance based on
the IP application. The IPSP is essentially consistent with the
ASP, but the IPSP uses the point-to-point M3UA instead of
signaling gateway services.
SG

A Signaling Gateway (SG) receives or sends upper-layer user

messages of the No.7 signaling at the border between the IP
signaling network and the No.7 signaling network.
SGP
The Signaling Gateway Process (SGP) is a process instance
of the SG, and serves as the process of SG activation,
standby or load sharing.
Routing keyword
The routing keyword describes a group of parameters and
parameter values (such as DPC, SIO+DPC and
SIO+DPC+OPC) of the No.7 signaling. It exclusively defines
the signaling service processed by the specified AS. The
parameters in the routing keyword cannot be based on
multiple destination signaling point codes.
3. Functional structure
M3UA protocol function is shown in Figure 34.
FIGURE 34 FUNCTIONAL STRUCTURE OF M3U A
4. Functions of sub-functional modules

Message processing
The SG maps messages from the MTP side to various SCTP
streams and sends them to the relevant ASPs through the
address mapping function. It assembles messages from the
SCTP to MTP3 user messages and sends them to the MTP
side. Through this function, various management messages
will be distributed to each internal functional module. It is
provided with address mapping function, achieving
translation between ROUTE KEY and ASP and maintaining
this address mapping table. It manages ROUTE KEY register
of ASP.
Signaling network management
The SG processes signaling point accessibility, congestion
and restart indications at the MTP side, and sends indications

to the relevant ASPs; it converts signaling network

management messages sent from peer M3UA into the
relevant primitives, and notify the upper layer user; it
executes the transmission control function.
SCTP connection management
It manages setup, removal, management blocking and
unblocking of the SCTP connection. Managed SCTP
connections must be between SGs and ASPs, between SGs or
between ASPs.
AS status maintenance
It saves the status of the connected AS, and process AS
status related messages.
ASP status maintenance
It saves the status of the connected ASP, and starts, exits,
activates and deactivates ASP.
LM functions
According to local office configuration, SCTP connection setup,
removal and blocking are initiated, and ASP status and SCTP
connection status information is received.
IUA 1. Overview
The destination endpoint in the IP network still keeps the
interface between Q.921 and Q.931, with the IUA protocol
adopted and the interworking between the SCN signaling and
IP implemented through SG. IUA can only implement the
interworking between the SCN signaling and IP, but cannot
implement the interworking between two points in the IP
network.
2. Functions
Supports the border interface between Q.921 and Q.931,
transferring Q.931 messages;
Supports communication management between the SG and
the MGC;
Supports association management between the SG and the
MGC;
Supports association stream mapping between the SG and
the MGC.
M2UA/M2PA 1. Overview
The signaling point in the IP network still keeps the interface
between MTP3 and MTP2, using the M2UA protocol to
implement interworking between SCN signaling and IP
through the SG. The M2UA protocol cannot implement
interworking between two IPSPs in the IP network.
2. Function
Supports the boundary interface between MTP3 and MTP2
primitive function;


the MGC;
MGC;
the MGC.
3. Comparison between M2UA and M2PA
Same points between M2PA and M2UA
f They are both signaling adaptation protocols in the
Sigtran protocol suite, using the services provided by the
SCTP.
f Supporting primitive interfaces between MTP2 and MTP3,
they both can transfer MTP3 messages.
f They both can be used by the MGC for interworking with
the narrowband No.7 signaling network through the SG.
Differences between M2PA and M2UA are as follows:
f M2UA can only be used between the MGC and the SG;
M2UA can be used both between the MGC and the SG
and between the MGC and the MGC (IPSP).
f When the SG uses M2UA, M2UA is the signaling link
terminal of the MGC without MTP3 or signaling point
function. When the SG uses M2PA, M2PA can be used as
an independent signaling point, with MTP3 and signaling
point code. It can be regarded as a signaling transfer
point in the signaling network.
f M2UA can only support interfaces of MTP3 and MTP2 in
the MGC and the SG respectively. There are no users in
upper layer of M2UA in the SG, and M2UA implements
transfer adaptation from MTP2 of the MGC to MTP2 of the
SG. M2PA completely supports MTP2/MTP3 interface and
it implements MTP2 function together with SCTP.
f When M2UA is used between the MGC and the SG, it is
not a real signaling link, and M2UA uses its own
management function. When M2PA is used between the
MGC and the SG, M2PA can be regarded as a real
signaling link and it manages links depending on MTP3.
SUA SUA defines how to transfer SCCP user messages between two
signaling points through IP. SUA implements interworking
between No.7 signaling and IP through the SG, and implements
interworking between IPSPs in the IP network as well.
The main functions of SUA include:
Supports message transfer of SCCP user parts (TCAP,
RANAP).
Supports the SCCP connectionless service.
Supports the SCCP connection-oriented service.

Supports seamless operations between peer layers of the

SCCP user
Supports the address translation and mapping function.
the MGC.
MGC.
the MGC.
H.248 Protocol
Background H.248 is ITU-T specified Media Gateway Control Protocol (MGCP).
It has been specified in conjunction with Internet Engineering
Task Force (IETF). ITU-T calls it H.248, while IETF calls it MGCP
titled Media Gateway Control (MEGACO). In this manual, it is
generally called H.248.
The H.248 protocol is a MGCP. In the separated gateway system
shown in Figure 35, the H.248 protocol is used for
communication between the Media Gateway Controller (MGC)
and the Media Gateway (MG), enabling the MGC to control the
MG.
FIGURE 35 SEPAR ATED G ATEWAY MODEL
Circuit Switched
IP Network
Network
Signaling
Gateway (SG)
SIGTRAN
Media Gateway
Controller (MGC)
Media H.248
Gateway (MG)
In the UMTS system, the H.248 protocol is used on the Mc

interface.
Functions In the R4 structure, separating MSC Server from MGW can be

used to introduce more services. The H.248 protocol is the

protocol between the MSC Server and the MGW, as shown in

Figure 36.
FIGURE 36 APPLICATION OF THE H.248 PROTOCOL
H.248 can implement the following functions:
Under the control of the MSC Server, it can establish and

release media channels in the MGW.
Under the control of the MSC Server, it can
connect/disconnect media channels with/from bearer
channels in the MGW.
Under the control of MSC Server, it can configure attributes
of media channels and bearer channels in the MGW.
In the MGW, it enables the MSC Server to operate media
channels and bearer channels, such as tone playing and
auditing.
It enables the MGW to report generated events to the MSC
Server.
Connection As shown in Figure 37, the H.248 connection model describes
Model the logical entities and objects in the MG, which can be
controlled by the MGC.

FIGURE 37 H.248/MEG ACO PROTOCOL CONNECTION MODEL
Media Gateway
Context Termination
SCN Bearer
Channel
4
Termination Termination
RTP Stream SCN Bearer
Channel
Context
Termination
SCN Bearer
Channel 4 Termination
SCN Bearer
Channel
Context
4
Termination Termination
RTP Stream SCN Bearer
Channel
Termination and context are two abstract concepts that are used
for describing the H.248 connection model.
Termination falls into two types. First is physical termination,

which is permanently existent upon power-on, such as a
termination representing a TDM channel. It can always exist
even if there is a failure until the MGW deletes it. Other types of
terminations representing ephemeral information streams, such
as RTP stream only exist during a call only and deleted after the
call.
Context indicates relationship between multiple terminations. If

a context involves more than two terminations, it describes
topology (receiving/transmitting of specific objects) and media
mixing and/or switching parameters. There is another special
context, that is, null Context. It contains all terminations that
have no contact with other terminations.
H.248 can add, subtract or move terminations into/from/in the

context via command. After last termination is subtracted from
or moved out of a context, context (implicit) will be deleted.
Descriptor H.248 uses descriptors to describe features of terminations.

Each type of termination has its own features, which are divided
into four types:
Property: Falls into termination status feature and media

stream feature. Former indicates service status of a
termination (such as normal service and exiting service/test),
while latter indicates media attributes of an ephemeral
termination (such as receiving/transmitting mode, coding
format and coding parameter).

Event: Indicates the event that a termination needs to

monitor and report to MSC Server, such as bearer
establishment, network congestion and voice quality
degrading.
Signal: Indicates actions that MSC Server requires MGW to
take for terminations, such as playing busy tones,
transmitting DTMF signals and recording announcement.
Statistic: Indicates statistics that a termination should collect
and report to MSC Server.
Command H.248 defines eight commands:
Add: Used to add a termination into a context.
Modify: Used to modify features of a termination.
Subtract: Used to subtract a termination from a context
(context is subtracted at the same time in case termination
is last one).
Move: Used to move a termination from one context to
another. This command applies to destination context, while
termination in parameter is located in other context currently.
AuditValue: Used to acquire current values about property,
event, signal and statistic features of a termination.
AuditCapability: Used to acquire all possible values about
property, event, signal and statistic features of a termination
permitted by MGW.
Notify: MGW uses this command to report events that occur
in it to MSC Server.
Service Change: This is a bi-directional command. MGW can
use it to report to MSC Server that a termination or a group
of terminations will exit from service or just recovered
normal services, and initiate registration to MSC Server. In
addition, MGW can use this command to notify MSC Server
of changing termination status, and MSC Server can use this
command to notify MGW of replacement by another MSC
Server.
Transaction 1. Overview
To transmit multiple commands concurrently and improve
transmission efficiency of protocol, H.248 adopts transaction
communication mode to transmit commands.
2. Transaction interaction
Multiple commands can be combined into a transaction,
which will be interacted between ZXWN MSCS and MGW. A
transaction ID is used to identify a transaction interaction. A
transaction contains one or multiple actions, and each action
contains one or more commands. All commands in an action
are controlled within same context, so each action has a
context identifier except the context is to be created or
command applies to a termination outside context.

Transaction interaction guarantees sequential processing to

commands, that is, commands in a transaction interaction
are sequentially executed. However, sequential processing
between all transaction interactions is not guaranteed, that is,
a transaction interaction can be processed in any sequence
or simultaneously with others. If execution of a command
fails, all other commands in transaction interaction will stop
being executed.
3. Category
One transaction interaction procedure contains four types of
transactions:
TransactionRequest sent by the transaction originator
TransactionResponseAck sent by the transaction originator
TransactionReply sent by the transaction receiver
TransactionPending sent by the transaction receiver
Message Multiple transactions can be combined into a message. H.248
Transfer messages can be transferred via IP or ATM.
For UDP transfer, H.248 messages in text format use default

UDP port 2944 and messages in binary format use default UDP
port 2945.
In the R4 structure, H.248 bottom layer transmission can adopt

one of the following three modes:
1. H.248/SCTP/IP, for application environment with pure IP

connections.
2. H.248/MTP3b/SSCF/SSCOP/AAL5/ATM, for application
environment with pure ATM transmissions.
3. H.248/M3UA/SCTP/IP, for application environment with both
ATM and IP. ATM and IP can be compatible, and IP can be
based on ATM.
H.248 Package Service types supported by H.248 are embodied in H.248
packages. MSC Server and MGW can provide services that match
their own requirements. In this case, for the interoperability
between MSC Server and MGW, parameters describing specific
services (such as Events, Signals, Properties, Methods and
Statistics) are defined to a package. If MSC Server and MGW
identify same package, they can support same service.
Operators can make use of it to define packages with their own
features and provide users with more featured and personalized
services.
For example, MSC Server and MGW in R4 support the following

packages for implementation of 3G services:
Generic package, with the ID as g.

Tone generation package, with the ID as tonegen.

Basic DTMF generation package, with the ID as dg.

DTMF detection package, with the ID as dd.
Call progress tone generation package, with the ID as cg.
BCP bearer feature package, with the ID as BCP.
GB generic bearer connection package, with the ID as GB.
Bearer control tunnel package, with the ID as BT.
Basic call progress tone generation package with direction
indication, with the ID as BCG.
BICC Protocol
Background Bearer Independent Call Control (BICC) is developed based on
the ISUP signaling protocol. BICC supports the whole set of
services of the narrowband ISDN on the broadband network
without affecting the interfaces and end-to-end services of the
current networks. BICC solves problem of call control
independent of bearer control, so that call control signaling can
be born on all networks such as the MTP SS7 network, ATM
network and IP network. Currently, BICC intends to develop
from Capability Set 1 (CS1) and CS2 to CS3.
In BICC CS1, the call service function and bearer control

function are integrated in the same physical equipment, so only
call control signaling is defined. CS1 has the following features:
Supports forward/backward backbone network establishment.

Uses the call control transfer of MTP or ATM of No.7 signaling.
Supports most of existing narrowband services.
Uses the backbone network connection with/without CODEC.
Reuses idle backbone network connection.
Separates calls and releases the backbone network
connection.
Supports bearer transfer types of AAL1 and AAL2.
Imposed by physical separation of network node functions, BICC
CS2 separates the call service function from the bearer control
function physically in service nodes. CS2 has the following
features:
Applies the BICC extension to the local switch.

Supports IP bearer.
Defines call bearer control interfaces.
Uses new identifiers, such as traffic group and global call
reference.
Supports call negotiation nodes.

Supports IP signaling transfer.

Supports the structured AAL1.
BICC CS3 focuses on the bearer application quality (such as IP QoS)
and interconnection with the Session Initiated Protocol (SIP).
At present, BICC CS2 is implemented in UMTS R4, providing the

basic call signaling capability, generic signaling program and
supplementary service function. BICC CS2 supports multiple
bearer establishment modes: tunnel mechanism for three types
(fast establishment, delay forward establishment, and delay
backward establishment), and non-tunnel mechanism for two
types (forward call bearer establishment and backward call
bearer establishment).
Related Terms To better understand the features of the BICC protocol, the
following introduces some important terms related with the BICC
protocols:
1. Backbone Network Connection (BNC): Represents the edge
to edge transport connection within the backbone network,
consisting of one or more Backbone Network Connection
Links (BNCL). The BNC represents a segment of the end to
end Network Bearer Connection (NBC).
2. BNCL: Represents the transport facility between two
adjacent backbone network entities containing a bearer
control function.
3. Bearer Control Function (BCF): Note that five types of BCFs
are illustrated in the composite functional model; BCF-G,
BCF-J, BCF-N, BCF-R and BCF-T.
i. The Bearer Control Joint Function (BCF-J) provides the
control of the bearer switching function, the
communication capability with two associated call service
functions (CSF), and the signaling capability necessary to
establish and release the backbone network connection.
ii. The Bearer Control Gateway Function (BCF-G) provides
the control of the bearer switching function, the
communication capability with its associated call service
function (CSF-G), and the signaling capability necessary
to establish and release of the backbone network
connection.
iii. The Bearer Control Nodal Function (BCF-N) provides the
function (CSF), and the signaling capability necessary to
establish and release of the backbone network connection
to its peer (BCF-N).
iv. The Bearer Control Relay Function (BCF-R) provides the
control of the bearer switching function and relays the
bearer control signaling requests to next BCF in order to
complete the edge to edge backbone network connection

v. The Bearer Control Transit Function (BCF-T) provides the

function (CSF-T), and the signaling capability necessary
to establish and release of the backbone network
connection.
4. Bearer Control Segment (BCS): Represents the signaling
relationship between two adjacent Bearer Control Functional
entities (BCF).
5. Bearer InterWorking Function (BIWF): A functional entity
which provides bearer control functions (BCF) and media
mapping/switching functions within the scope of a Serving
Node (BCF-N, BCF-T or BCF-G) and one or more MCF and
MMSF, and is functionally equivalent to a Media Gateway that
incorporates bearer control.
6. Bearer Inter-Working Node (BIWN): A physical unit
incorporating functionality similar to a BIWF.
7. Call Control Association (CCA): Defines the peer to peer
signaling association between Call, and Call & Bearer state
machines located in different physical entities.
8. Call Mediation Node (CMN): A functional entity that provides
CSF-C functions without an associated BCF entity.
9. Media Control Function (MCF): A functional entity that
interacts with the BCF to provide the control of the bearer
and MMSF. The precise functionality is outside the scope of
BICC.
10. Media Mapping/Switching Function (MMSF): An entity
providing the function of controlled interconnection of two
bearers and optionally the conversion of the bearer from one
technology and adaptation/encoding technique to another.
11. Call Service Function (CSF): Four types of CSF are defined:
i. The Call Service Nodal Function (CSF-N) provides the
service control nodal actions associated with the
narrowband service by interworking with narrowband and
Bearer Independent Call Control (BICC) signaling,
signaling to its peer (CSF-N) the characteristics of the call,
and invoking the Bearer Control Nodal Functions (BCF-N)
necessary to transport the narrowband bearer service
across the backbone network.
ii. The Call Service Transit Function (CSF-T) provides the
service transit actions necessary to establish and
maintain a backbone network call, and its associated
bearer by relaying signaling between CSF-N peers and
invoking the Bearer Control Transit Functions (BCF-T)
across the backbone network.
iii. The Call Service Gateway Function (CSF-G) provides the
service gateway actions necessary to establish and
maintain a backbone network call and its associated

bearer by relaying signaling between CSF-N peers and

invoking the Bearer Control Gateway Functions (BCF-G)
between backbone networks.
iv. The Call Service Co-ordination Function (CSF-C) provides
the call co-ordination and mediation actions necessary to
establish and maintain a backbone network call by
relaying signaling between CSF-N peers. The CSF-C has
no association with any BCF. It is only a call control
function.
12. Gateway Serving Node (GSN): A functional entity which
provides gateway functionality between two network
domains. This functional entity contains one or more call
service gateway functions (CSF-G), and one or more bearer
interworking functions (BIWF). GSNs interact with other
GSNs, in other backbone network domains and other ISNs
and TSNs within its own backbone network domain. The
network signaling flows for a GSN are equivalent as those for
a TSN.
13. Interface Serving Node (ISN): A functional entity which
provides the interface with non-BICC networks and terminal
equipment. This functional entity contains one or more call
service nodal functions (CSF-N), and one or more bearer
inter-working functions (BIWF) which interact with the non-
BICC networks and terminal equipment and its peers within
the broadband backbone network.
14. Signaling Transport Layers (STL): Any suite of protocol
layers currently specified to provide Transport and/or
Network Layer services to the BICC.
15. Signaling Transport Converter (STC): A protocol layer
between the STL and BICC. This layer enables the BICC
protocol to be independent of the STL being used.
16. Transit Serving Node (TSN): A functional entity which
provides transit functionality between ISNs and GSNs. This
functional entity contains one or more call service transit
functions (CSF-T), and one or more bearer interworking
functions (BIWF). TSNs interact with other TSNs, GSNs and
ISNs within their own backbone network domain.
17. Serving Node (SN): A generic term referring to ISN, GSN or
TSN nodes.
BICC Protocol The BICC protocol model is shown in Figure 38.
Model

FIGURE 38 BICC PROTOCOL MODEL
Model In the BICC protocol model shown in Figure 38, interaction

Description between the CSF and the BCF is completed through the mapping
function. The mapping function performs mapping between BICC
bearer control primitives and the interfaces provided by different
bearer control protocols.
The signaling receiving/sending of the CSF is completed through
the STC. The STC shields the interface difference of the lower-
layer transport protocol, and provides the unified interface to the
upper-layer BICC protocol.
The BICC protocol model uses signaling interface points to
encapsulate BICC messages to the messages on the signaling
transport layer to implement message exchange between BICC
entities. The primitive conversion (for example, among MTP3,
MTP3B, and SCTP) between the BICC signaling transport
primitives and the specific STL is implemented through the STC.
On the STL, the MTP3 is used for the TDM signaling bearer
network, the SCTP over IP is used for the IP signaling bearer
network, while the MTP3B is used for the ATM network.
BICC uses bearer interface points to implement the control and
query of bearers.
The BICC protocol model describes a solution clew:
To be totally independent of any part (transferring signaling or
bearer) connected with it, BICC is standardized at these two
interface points. From the BICC-procedure view point, BICC
provides an exclusive set of abstracted operation primitives, and
then implements primitive conversion with the related parts

(transferring signaling or bearer) through a conversion/mapping

part.
Capabilities 1. Capabilities supported by BICC for basic call
Supported
Table 5 lists the signaling capabilities supported by BICC for
basic call.
TABLE 5 CAPABILITIES SUPPORTED BY BICC FOR BASIC CALL
Function/Service Remark
Speech/3.1 kHz audio -
64 kbit/s unrestricted -
Multirate connection types (Note 1) Multirate connection
types are 2 × 64, 384,
1 536 and 1 920 kbit/s
N × 64 kbit/s connection types -
En bloc address signaling -
Overlap address signaling -
Transit network selection -
Continuity indication -
Forward transfer -
Simple segmentation -
Tones and announcements -
Access delivery information -
Transportation of User teleservice -
information
Suspend and resume -
Signaling procedures for connection type -
allowing fallback capability
Propagation delay determination -
procedure
Simplified echo control signaling -
procedures
Automatic repeat attempt -
Blocking and unblocking -
CIC group query -
Dual seizure -
Reset -
Receipt of unreasonable signaling -
information
Compatibility procedure (BICC and BAT -
APM user application)

ISDN User Part signaling congestion If BICC is deployed on
control an MTP3 or MTP3b
signaling transport
service, these functions
are provided by the STC
sublayer as described in
ITU－T Q2150.x
Automatic congestion control -

Interaction with INAP -
Unequipped CIC -
ISDN User Part availability control If BICC is deployed on
an MTP3 or MTP3b
signaling transport
service, an equivalent
procedure is provided
by the STC sublayer
MTP pause and resume If BICC is deployed on
an MTP3 or MTP3b
signaling transport
service, these functions
are provided by the STC
sublayer as described in
ITU－T Q2150.x
Overlength messages -
Temporary Alternative Routing (TAR) -
Hop counter procedure -
Collect call request procedure -
Hard-to-Reach -
Calling geodetic location procedure -
Carrier selection indication -
Inter-nodal traffic group identification -
Codec negotiation and modification -
procedures
Joint BIWF support -
Global Call Reference procedure -
Out of band transport of DTMF tones and -
information
2. Generic signaling procedures, supplementary services and

some additional functions/services supported by BICC
Table 6 lists the generic signaling procedures, supplementary
services and some additional functions/services supported by
BICC.

TABLE 6 GENERIC SIGNALING PROCEDURES, SUPPLEMENTARY SERVICES AND

SOME ADDITIONAL FUNCTIONS/SERVICES SUPPORTED BY BICC
Generic signaling procedures -
Generic number transfer -
Generic digit transfer -
Generic notification procedure -
Service activation -
Remote Operations Service Element -
(ROSE) capability
Network specific facilities -
Pre-release information transport -
Application Transport Mechanism (APM) -
Redirection -
Pivot routing -
Bearer redirection -
Supplementary services -
Direct-Dialing-In (DDI) -
Multiple Subscriber Number (MSN) -
Calling Line Identification Presentation -
(CLIP)
Calling Line Identification Restriction -
(CLIR)
Connected Line Identification Presentation -
(COLP)
Connected Line Identification Restriction -
(COLR)
Malicious Call Identification (MCID) -
Sub-addressing (SUB) -
Call Forwarding Busy (CFB) -
Call Forwarding No Reply (CFNR) -
Call Forwarding Unconditional (CFU) -
Call Deflection (CD) -
Explicit Call Transfer (ECT) -
Call Waiting (CW) -
Call HOLD (HOLD) -
Completion of Calls to Busy Subscriber -
(CCBS)
Completion of Calls on No Reply (CCNR) -
Terminal Portability (TP) -

Conference calling (CONF) -
Three-Party Service (3PTY) -
Closed User Group (CUG) -
Multi-Level Precedence and Preemption Only transiting of MLPP
(MLPP) information is supported
Global Virtual Network Service (GVNS) -
International telecommunication charge -
card (ITCC)
Reverse charging (REV) -
User-to-User Signaling (UUS) -
Additional functions/services -
Support of VPN applications with PSS1 -
Information Flows
Support of GAT protocol -
Support of Number Portability (NP) -
BICC Protocol The BICC protocol can be used in any network to transfer
Stack signaling, such as ATM, IP, and TDM networks.
Protocol stack based on IP
The structure of the BICC protocol based on the IP transport
network is shown in Figure 39.
FIGURE 39 STRUCTURE OF THE BICC PROTOCOL BASED ON THE IP

TRANSPORT NETWORK
BICC
BICC
M3UA
SCTP SCTP
IP IP
Protocol stack based on ATM

The structure of the BICC protocol based on the ATM
transport network is shown in Figure 40.

FIGURE 40 STRUCTURE OF THE BICC PROTOCOL BASED ON THE ATM

TRANSPORT NETWORK
BICC
STC
MTP3B
SAAL
AAL5
ATM
Protocol stack based on TDM

The structure of the BICC protocol based on the TDM
transport network is shown in Figure 41.
FIGURE 41 STRUCTURE OF THE BICC PROTOCOL BASED ON THE TDM

TRANSPORT NETWORK
BICC
MTP3
MTP2
MTP1
Relationship The relationship between BICC and ISUP is described as follows:

between BICC
1. Bearer independent of control
and ISUP
The protocol stack of the ISUP is based on MTP3, so the
signaling transport layer of the ISUP is MTP3, and the voice
channel bearer of the ISUP must be through the narrowband
TDM trunk circuits. However, after call control is independent
of bearer control, BICC signaling can be transported through
various signaling transport layers, and bearer
signaling/media flows can be transported through various
bearer networks (the voice channel bearer of the ISUP can
only be transported through the SS7 bearer network, i.e.
TDM trunk circuits).
2. Expansion of the CIC concept
In the ISUP, the label part of the SIF field in a message
includes Circuit Identification Code (CIC).The CIC is the logic
number of the inter-office trunk circuit, indicating which

circuit is related to this message. The CIC of the ISUP is

represented by 12 bits, which restricts the maximum number
of trunk circuits between signaling points to 4,096 (12 power
of 2).
To correspond to the ISUP structure, the BICC message also
has the CIC concept, which is Call Instance Code. This CIC is
the corresponding logical number of the inter-office call,
indicating which call instance this message corresponds to.
The CIC of the BICC is represented by 32 bits, which makes
the number of inter-office call instances be up to
4,294,967,296 (32 power of 2) in theory.
3. Changes of messages and parameters
Based on the ISUP protocol, the BICC protocol removes the
messages and parameters related with the specific bearer,
and adds Application transport Messages (APM) and APP
parameters, to control multiple bearer types.
About the call procedure, BICC adds the interaction
procedure of APM messages. The other aspects of BICC are
consistent with those of ISUP. The APM message is mainly
used to implement interaction between bearer-related
control messages. This point embodies the heritance of BICC
from the ISUP call control procedure, so BICC has many
features that ISUP has, and supports various services that
ISUP supports.
RANAP Protocol
Definition Located at the bottom of the network layer, the Radio Access
Network Application Part (RANAP) is a user of the SCCP layer.
The RANAP provides services to the upper-layer MM, GMM, and
HO modules to complete call, switchover, and other functions.
The RANAP can accept the encoding/decoding service from the
RANAP encoding/decoding module, encoding/decoding the
messages from/to the SCCP.
RANAP RANAP signaling function falls into:

Signaling
Function Management module: Responsible for management function
between CN and RNC.
Service processing module: Responsible for occupation and
release functions of resources between layers.
Network management service function: Responsible for
management of the background network management
system.
Multi-module management function: Responsible for multi-
module management.
Management The main functions of the management module are as follows:
Module

Office maintenance: Responsible for processing status such

as signaling point reachability, unreachability and flash, and
responsible for real-time synchronization between RANAP
modules.
Processing overload between offices: The RANAP
management module will report to the peer office if it detects
overload of the local office, and perform traffic control
processing if it receives overload signal from the peer office.
Global reset between offices: The RANAP management
module will initiate global reset to reset RANAP resources on
both ends of office, due to reasons such as too long signaling
point disconnection time, initial start or synchronization
failure of resources of both parties.
Resetting resources: The RANAP management module will
perform such operation if local office or peer office needs to
reset some resources of the Iu interface.
Error indication: If an error occurs to RANAP signal during
decoding, RANAP management module can send an error
indication signal to peer office as required for notification.
Service The main functions of the service processing module are as
Processing follows:
Module
RAB assignment: Responsible for assignment of service data
bearer in call process.
Relocation: If RNC or UE detects that service quality
degrading and determines to initiate relocation after
measurement of peer RNC, RNC will initiate this relocation
process and CN will control it to hand over voice channel to
RNC with high service quality. Relocation involves intra-
system handover and inter-system handover.
Iu interface release: If RNC detects some errors and needs
to release signaling association of Iu interface, or CN does
not need IU signaling association any more, RNC or CN can
initiate Iu interface release to release signaling association of
Iu interface and related resources.
SRNS context transfer: SRNS data forwarding indication
process is only used for CN query. In routing area update
from UMTS to GSM, if SGSN queries RNC for context
information of related RAB, SGSN will send a SGSN DATA
FORWARD COMMAND message to RNC to ask RNC to forward
data to new SGSN after GMM operations such as GSM
authentication and encryption. After data transfer, IuRelease
will be initiated.
SRNS context forwarding: If no Iur interface is available
between RNCs in relocation, original RNC will send context
information to destination RNC through SGSN and ask
original RNC to forward data to destination RNC.

Paging: If a CN service needs communications with a UE,

RANAP initiates paging process, and RNC advertises to
trigger service process of UE.
COMMON ID: If signaling connection of Iu interface is
available and also IMSI is known, this message (that is,
COMMON ID) will be sent to RNC. RNC will associate this
user ID with RRC connection. Association will last till release
of signaling connection of Iu interface. Based on this
association, the RNC will send paging of user over this RRC.
Invoke Trace: Covers CN invoke trace and RNC invoke trace.
It is expected that peer end will generate trace records
according to local format.
Security mode control: CN sends encryption and integrity
information to RNC and RNC selects and loads encryption
algorithm to encrypt signaling and subscriber data.
Location report: CN sends a location report request message
to RNC, and RNC adds subscriber location message to
location report. Location information interaction between CN
and an MS is implemented in LCS service operation in L3.
Data volume report: CN queries RNC for unsuccessful
downlink data volume on specified RAB.
Initial UE message: Used to initiate L3 service processing,
such as paging response, location update request and CM
service request.
Fax: Used for RANAP to provide upper-level services with a
service control information transmission mechanism.
NM Service Function
Function
The service report function involves normal service report
and abnormal service report which are reported to
background.
f Normal services, such as Iu interface connection
establishment and release.
f Abnormal services, such as Iu connection abnormality, Iu
release abnormality and RAB release abnormality.
Office reset and reset resource initiation flow
If an office fails, the background can initiate an inter-office
reset flow. RANAP reports activity test results to the
background, and the background judges whether the voice
channel is suspended according to related conditions and
resets resources of the suspended connection.
Multi-Module Signaling synchronization function: The management module
Management conducts unified management over individual modules and
Function implements signaling synchronization among modules.
Active/standby changeover: Active/standby changeover
protects the Iu connection going into the conversation status,
which coordinates with the service layer to prevent resource
suspension upon changeover.

BSSAP Protocol
Overview The Base Station System Application Part (BSSAP) is the A
interface protocol processing module between the MSC and the
BSC. The A interface adopts E1 interfaces. The BSSAP is a
narrowband signaling processing system. Located at the lower
layer of the MM, the BSSAP is a user of the SCCP layer. It
exchanges messages with the HO module, database module,
and OMC module.
Signaling The BSSAP mainly processes A interface signaling procedures

Function related with calls, mobility management and resource
management. The BSSAP signaling function falls into:
Management function
Service processing function
Service report function
Multi-module processing function
Active/standby changeover.
Management The management module maintains terrestrial circuits of the A
Module interface, and blocks/unblocks and resets circuits according to
the actual needs. In addition, the module needs to implement
office direction management. Its functions include:
Office maintenance: Responsible for processing status such

as signaling point reachability, unreachability and flash and
responsible for real-time synchronization between BSSAP
modules.
Processing overload between offices: RANAP management
module will report to neighbor office if it detects overload of
local office, and perform load indication and traffic control
processing if it receives overload signal from neighbor office.
Global reset between offices: BSSAP management module
will initiate global reset to reset BSSAP resources on both
ends of office, due to reasons such as too long signaling
point disconnection time, initial start or synchronization
failure of resources of both parties.
Reset circuit message: Operation performed when local or
peer office needs to reset some circuit resources.
Blocking/unblocking message: Covers OMC/BSC
blocking/unblocking message reception and
blocking/unblocking response message of BSC.
Service The service processing module transfers and processes
Processing messages between MSCS and BSC, and also transmits
Module MM/CC/SMS L3 messages between MSCS and UE transparently.
These messages are those related to call and mobility

management, and normally are connection-oriented messages.

They include:
1. Complete L3 message: that is, initialization MS message.

Normally, this message is first message in call or mobility
management, and A interface connection is set up through
this message.
2. Direct data transfer message: Transfers MM/CC/SMS L3
messages between CN and MS.
3. Clear command message: Releases A interface connection
and related resources.
4. Assignment message: Assigns radio resources and allocates
land circuits of A interface. BSSAP requests a CIC from
database according to information such as channel rate and
voice version in assignment message.
5. Paging message: Initiated by CN to search called MS. After
called MS is found, paging response message will be sent to
CN through BSC. This message is a complete L3 message.
6. Handover message: To hand over to a new BSC from current
BSC, MS transmits a handover request message to CN
through BSC. And then, CN sends handover request message
to new BSC, reassigns radio resources and land circuit of A
interface, and releases original signaling connection and
related resources after handover completion.
Service Report Function
Function
The service report function involves normal service report
and abnormal service report. Normal services, such as A
interface connection establishment and release, are reported
to background. Abnormal services, such as A interface
connection/release abnormality, are also reported to
background.
Office reset and CIC reset initiation flow
If an office fails, the background can initiate an inter-office
reset flow. BSSAP reports activity test results to the
background, and the background judges whether voice
channel is suspended according to related conditions and
resets CIC of suspended connection.
Multi-Module Signaling synchronization function: The management module
Management conducts unified management over individual modules and
Function implements signaling synchronization among modules.
Overload control: The management module periodically
queries load level of each module and calculates load level of
MSC according to reported results.
Active/standby changeover: Active/standby changeover
protects the A interface going into the conversation status,
which coordinates with service layer to prevent resource
suspension upon changeover.

Gs Interface Protocol
Overview The Gs interface is between the VLR and the SGSN, coordinating
interaction between the MSCS/VLR and the SGSN.
Protocol Stack The protocol stack is shown in Figure 42.
FIGURE 42 GS INTERFACE PROTOCOL STACK
BSSAP+
SCCP
MTP3 M3UA
SCTP
MTP2
IP
PCM
DataLink
The VLR/SGSN is over SCCP through BSSAP+, using class-0

SCCP service (basic connectionless service), and using SSN+DPC
or SSN+GT for addressing.
Applied Users The Gs interface is only used by the MS that is in Class-A or
Class-B mode, and subscribes the GPRS service and non-GPRS
service. The basic subscriber data table in the VLR/SGSN
database contains the Gs interface status. When a MS is
attached to both GPRS and non-GPRS services, the Gs interface
status is “associated”.
Implementatio Through the Gs interface, the SGSN can implement some CS-
n of Related CS related services, including:
Services
1. Location update of the non-GPRS service
When an MS initiates a combined location update, the SGSN
can complete the location update of the MS in the VLR
through the Gs interface, and change the Gs interface status
of the MS in the VLR/SGSN database to “associated”.
The location update of the non-GPRS service is shown in
Figure 43.

FIGURE 43 LOCATION UPDATE OF THE NON-GPRS SERVICE
SGSN VLR
Location update request
Location update
request accepted
TMSI
reallocation completed
2. Paging procedure of the non-GPRS service

When the Gs interface is in “associated” status, the VLR
sends a paging request to the MS preferably through the
SGSN to save radio channels of UMTS.
The paging procedure of the non-GPRS service is shown in
Figure 44.
FIGURE 44 PAGING PROCEDURE OF THE NON-GPRS SERVICE
SGSN VLR
Paging request
3. Alert procedure of the non-GPRS service

When a short message is unable to be delivered due to
subscriber inaccessibility, and if the Gs interface is in
“associated” status, the VLR requests the SGSN to alert the
VLR by sending an activity indication message to the VLR
and clears the NGAF at the same time through the Gs
interface when detecting the next MS activity.
The alert procedure of the non-GPRS service is shown in
Figure 45.

FI G U R E 4 5 AL E R T P R O C E DUR E O F T HE NO N- GP RS S ER V I C E
SGSN VLR
Alert request
Alert request accepted
Subscriber activity indication
4. Explicit IMSI detach procedure of the GPRS service

When the Gs interface is in “associated” status, and the MS
or the network side initiates a GPRS detach procedure, or the
location update in the combined RA/LA update is rejected by
the SGSN, the SGSN sends an explicit GPRS detach request
to the VLR. After that, the Gs interface becomes
“unassociated”, all the running Gs interface services of the
MS are stopped, and the VLR starts the implicit detach timer.
The explicit IMSI detach procedure of the GPRS service is
shown in Figure 46.
FIGURE 46 EXPLICIT IMSI DETACH PROCEDURE OF THE GPRS SERVICE
SGSN VLR
Explicit GPRS detach request
Explicit GPRS detach response
5. Explicit IMSI detach procedure of the non-GPRS service

When the Gs interface is in “associated” status, and the MS
initiates a GPRS detach procedure or a combined detach
procedure, the SGSN sends an explicit IMSI detach request
to the VLR. After that, the Gs interface becomes
“unassociated”, all the running Gs interface services of the
MS are stopped, and the MS status is set to “Detach”.
The explicit IMSI detach procedure of the non-GPRS service

FIGURE 47 EXPLICIT IMSI DETACH PROCEDURE OF THE NON-GPRS

SERVICE
SGSN VLR
Explicit IMSI detach request
Explicit IMSI detach response
6. Implicit IMSI detach procedure of the non-GPRS service

When the “reachable” timer of the SGSN expires (losing
touch with the MS), the SGSN sends an implicit IMSI detach
request to the VLR. After that, the Gs interface becomes
“unassociated”, and all the running Gs interface services of
the MS are stopped.
The implicit IMSI detach procedure of the non-GPRS service
FIGURE 48 IMPLICIT IMSI DETACH PROCEDURE OF THE NON-GPRS

SERVICE
SGSN VLR
Implicit IMSI detach request
Implicit IMSI detach response
7. Reset procedure
When the VLR restarts or recovers from faults, it sends a
reset indication message to all the associated SGSNs to clear
the “associated” status of their Gs interfaces. If the VLR
receives a reset indication message from a SGSN, it makes
the Gs interface of all the subscribers associated with this
SGSN to be “unassociated”.
The reset procedure is shown in Figure 49.

FIGURE 49 VLR/SGSN RESET PROCEDURE
SGSN VLR
Reset indication
Reset response
Reset indication
Reset response
8. MS information procedure
When the Gs interface is in “associated” status, the VLR can
request for the location, ID, and status information of the MS
through the SGSN. If there is any requested information in
the SGSN database, it is returned by being carried in the MS
information response message. If there is no requested
information in the SGSN database, the SGSN initiates a
procedure of requesting for the MS ID or a location
information report procedure at the Iu interface to get the
MS ID or location information, and returns it in the MS
information response message.
The reset procedure is shown in Figure 50.
FIGURE 50 MS INFORMATION PROCEDURE
SGSN VLR
Request for the

MS information
MS information response
MAP Protocol
Definition The Mobile Application Part (MAP) enables real-time
communication between nodes in a mobile cellular network. The
MAP is located in upper layer of TCAP in OSI reference model,
and only the connectionless mode of the SCCP is used. The
standard MAP protocol is employed between MSCS/VLR and HLR,
between SMS-VMSC and SMS-IWMSC (inter-working MSC) and
between SMS-MSC and SMS-GMSC (gateway MSC), to set up
dialogues or transfer information between different entities.

Functions of Setting up dialogues between MSCS/VLR and entities such as

MAP Signaling HLR, other MSCS/VLRs, IW/GMSC and SCP by invoking TC
primitives.
Cooperating with access processing module to complete
UMTS services by transferring internal messages.
Querying database to acquire related information about a
subscriber, and informing database of latest data of
subscriber for proper modification.
MAP Signaling The MAP signaling procedures related to the MSCS/VLR cover:
Procedure
Location registration and deletion.
Supplementary services processing.
It includes activation, deactivation, registration, cancellation,
utilization and query of supplementary services. Normally,
these operations are initiated by MSs. MSCS/VLR queries
HLR for such data as supplementary service authority of
subscribers and accordingly decides whether to execute
these operations. If changes take place in registration
request of supplementary services of a subscriber, HLR will
notify MSCS/VLR directly.
Retrieving subscriber parameters during call setup, covering
two cases:
i. General information retrieval: VLR needs to acquire part
of or all subscriber parameters from HLR.
ii. Routing information retrieval: When a PSTN subscriber
calls MS, GMSCS asks HLR for a roaming number.
Relocation: Supports basic relocation and subsequent
relocation.
Subscriber management: Covers subscriber location
information management and subscriber parameter
management. This function is used for VLR to verify
information to HLR or for HLR to retrieve information from
VLR. Function applies to data recovery after VLR/HLR reset
or normal database updating.
Fault recovery: After the VLR is restarted, all MS records are
marked with “Recovery” tags, meaning they are subject to
verification. If VLR receives messages (such as, call setup,
location update and subscriber authentication messages)
from MSCS and HLR, it indicates that this subscriber is still in
control area of VLR, and “Recovery” tag can be removed. If
VLR receives a location deletion message, it will delete
records of this MS.
IMEI management: Defines signaling process when MSCS
queries EIR for MS equipment validity.
Subscriber authentication, covering:
i. VLR requests HLR for authentication quintuple. This is
performed when authentication quintuple kept by VLR is
lower than threshold.

ii. Requesting subscriber information from previous VLR

during location update, covering authentication triplet
and IMSI.
CAP Protocol
Definition The CAMEL Application Part (CAP) is the core protocol of a
mobile intelligent network. Actually, the CAP protocol is an
extension of fixed Intelligent Network Application Protocol (INAP)
in the mobile field. Therefore, the basic application rules of the
CAP are the same as those of the INAP.
System The CAP protocol is a Remote Operation Service Element (ROSE)

Structure user protocol, and its protocol system is shown in Figure 51.
FIGURE 51 CAP SYSTEM
SACF
SACF
SACF
Single Association Control Function (SACF) coordinates use of

Application Service Element (ASE), covering sequence of
operations contained in ASE. Operation sequence depends on
sequence of received primitives. However, Single Association
Object (SAO) represents interaction of SACF plus a group of
ASEs between a pair of physical entities. Multiple Association
Control Function (MACF) coordinates SAO actions if several SAOs
are available. If a physical entity is associated with only a single
physical entity, system in the right diagram of Figure 51 is
adopted; if the physical entity is associated with multiple
physical entities, the left diagram is used.
SACF/MACF SACF/MACF rules involve two aspects:

Rules
As required in TCAP Application Context (AC) negotiation
regulations, if AC being processed is received, it should be
indicated in first backward message. If AC user rejects it,

hoping to disconnect dialogue, another AC can be provided to

start a new dialogue.
If it is necessary to differentiate serial or parallel operations,
an operation to be synchronized must be put into same
dialogue message. In other cases, operations to be
completed in serial mode should be sent in different dialogue
messages according to their sequence. It must be noted that
all operations sent in same dialogue message do not mean
that operations will be executed simultaneously. If this rule is
inconsistent with that stipulated by specific functional entity,
latter prevails.
INAP INAP is established on basis of SS7. This ROSE protocol is
transmitted in TCAP component sub layer, and Application
Protocol Data Units (APDUs) of ROSE are transmitted in SCCP of
SS7 as Unit Data (UDT). Communications between peer entities
on same layer are implemented by means of TCAP transaction
management function and SCCP service of type 0 (basic
connectionless service). Communications among INAP peer
entities (layers) are expressed with “operation”, “result” and
“error”. Protocol is a service-independent application protocol,
that is, operations in protocol are applicable to different services,
and same operation can be invoked in different services, as
shown in Figure 52.
FIGURE 52 OPERATION DESCRIPTION
CAP User ASE
XYZ OPERATION
ARGUMENT{Parameter1,Parameter2,…};
RESULT{Parameter1,Parameter2,…};
LINKED{Operation3,Operation4,…};
ERRORS{Error1,Error2,…} Operations
Results
To peer Errors
Error1 ERROR
PARAMETER{Parameter6,Parameter7,…};
etc
TCAP ASE INVOKE
RETURN RESULT
RETURN ERROR
COMPONENT SUB-LAYER REJECT
To peer
BEGIN
CONTINUE
TRANSACTION SUB-LAYER END
To peer ABORT
UNIDIRECTIONAL
CONNECTIONLESS SCCP
CAP can address with SCCP GT, MTP SPC (signal point code) or
SSN (subsystem number). At present, it is specified that CAP
SSN is equal to 146 in UMTS.

CAP CAP operations are similar to INAP operations, and only

Operations difference lies in parameter contents, since parameters specific
to mobile networks are supplemented. At present, CAMEL3
controls CS service, as well as SMS and GPRS services.
Therefore, compared with CAMEL2, CAMEL3 adds many new
CAMEL operations. Table 7 and Table 8 describe operations.
TABLE 7 C AP OPERATIONS ASSOCIATED WITH CS
CAP Operation Name Operation Explanation

Activity test: Tests whether dialogue
ActivityTest
between CAP entities is activated
Applying charging: SCP requires SSP
ApplyCharging
for charging control
Applying charging report: Indicates
ApplyChargingReport result of applying charging operation
of SSP to SCP
Assistant request instructions: Assists
AssistRequestInstructions in setting up dialogues between SSP
and SCP
Call information request: Used for SCP
CallInformationRequest
to monitor call information
Call information report: Indicates
CallInformationReport response of SSP to call information
request
Cancellation: Used for SCP to cancel
Cancel
previously sent operation
Call gap: Used for SCP to restrict call
CallGap
volume of SSP
Connection: Used for SCP to set up a
Connect
connection with party B
Connecting to resource: Used to set
ConnectToResource up a connection with SRF and
subsequently play announcement tone
Continuity: Used to set up a
Continue connection without changing call
information
Continuity with argument: Used to set
up a connection with some call
ContinueWithArgument
information changed (except called
number)
Disconnecting forward connection:
DisconnectForwardConnecti
Used to disconnect connection with
on
SRF
Establishing temporary connection:
EstablishTemporaryConnecti Used to set up a connection to an
on independent IP and play subsequent
announcement


BCSM event report: When SSP meets
a DP point, if this DP point is
EventReportBCSM
monitored, event will be reported to
SCP
Furnishing charging information: Used
FurnishChargingInformation for SCP to send to SSP in need of
charging
Initiating DP: Used for SSP to enable
InitialDP
dialogue with SCP
Releasing call: Used for SCP to release
ReleaseCall
SSP connection
Requesting BCSM event report: Used
RequestReportBCSMEvent
for SCP to monitor or cancel DP point
Resetting timer: Used for SCP to ask
ResetTimer SSP to reset hold timer, to prevent
SSP timer timeout
Sending charging information: Used
SendChargingInformation
for AOC service
Playing announcement: Used for SCP
PlayAnnouncement
to play announcement to subscribers
Prompting and collecting user
PromptAndCollectUserInfor
information: Used for SCP to collect
mation
user information
Specialized resource report: Used for
SpecializedResourceReport SSP to report to SCP after PA
operation
TABLE 8 C AP OPERATIONS ASSOCIATED WITH SMS

Connecting to SMS: Used to set up a
ConnectSMS
connection with SMS of party B
Continuing SMS: Used for SMS
ContinueSMS connection without changing
information
SMS event report: When SMS
transaction meets a DP point, if DP
EventReportSMS
point is monitored, event will be
reported to SCP
Furnishing charging information: Used
FurnishChargingInformation
for SCP to furnish charging
SMS
information to SSP
Initiating DP SMS: Used to enable
InitialDPSMS
dialogue between SSP and SCP
Releasing SMS: Used to release SMS
ReleaseSMS
transaction
Requesting SMS event report: Used to
RequestReportSMSEvent
monitor or cancel SMS DP point


Resetting timer: Used for SCP to ask
ResetTimerSMS SSP to reset hold timer, to prevent
SSP timer timeout
SIP Protocol
Functions of Session Initiation Protocol (SIP) is the IP telephone/multi-media
the SIP conference protocol proposed by IETF based on text coding. The
Protocol SIP protocol is used to set up, modify and terminate the multi-
media session. The SIP protocol can be used to initiate a session
and invite members to a session set up by other methods.
The multi-media session can be point-to-point voice
communication or video conference, and multi-point voice or
video conference as well. The SIP protocol transparently
supports name mapping and redirection services, which
facilitates implementing ISDN, IN and individual mobile services.
The SIP protocol can use the Multi-point Control Unit (MCU) or
full interconnection mode to initiate multi-party calls instead of
using the multicast mode. The IP telephone gateway connected
with the PSTN also can use the SIP protocol to set up calls
between common subscribers.
Five Aspects of Five Aspects of multi-media communication supported by the
Multi-Media SIP protocol are as follows:
Communicatio
1. Subscriber location: confirms the terminal system used for
n Supported by
communication;
the SIP
Protocol 2. Subscriber capability: confirms parameters used for
communication media and media;
3. Subscriber accessibility: confirms whether the called party
wants to join the communication;
4. Call setup: creates the call parameters of calling and called
parties;
5. Call processing: includes call forwarding and call termination.
Advantages of The SIP protocol has the following advantages:
the SIP
1. Least status: one conference call or common call can
Protocol
contain one or more request-response transactions. The
proxy server can adopt the zero-status working mode.
2. Lower-layer protocol independence: the lower-layer protocol
can provide the SIP protocol layer with both reliable or
unreliable services, and packet or byte-flow services. In the
Internet environment, when the SIP protocol layer can use
the UDP protocol or the TCP protocol, it prefers the UDP
protocol; when the UDP protocol cannot be used, it uses the
TCP protocol.

3. Text based: the SIP protocol adopts the text-based UTF-8

coding mode and the ISO 10646 character set, which are
flexible and facilitate implementation, debugging and
expansibility.
4. Robustness: the robustness of the SIP protocol is embodied
as follows. The proxy server does not need to save call
statues; the subsequent requests and retransmission can
adopt different routes; the self addressing mode is adopted
to transfer the response message.
5. Expansibility: the expansibility of the SIP protocol is
embodied as follows. Unidentifiable head domains can be
omitted; the user can specify the message contents that the
SIP server must understand; it is easy to introduce a new
head domain; the status code adopts the layered coding
mode for coding.
6. Easy to support the IN services: cooperating with the
terminal system, the SIP protocol and its call control
expansion can support most services in Capability Set 1 and
Capability Set 2 of ITU T.
Main Concept 1. Physical model
Model of the
The SIP protocol defines two types of main entities: User
SIP Protocol
Agent and Server.
The SIP protocol divides the User Agent (UA) into two parts:
User Agent Client (UAC) and User Agent Server (UAS). The
caller (called as User Agent Client) initiates an invitation (or
a call), and the callee (called as User Agent Server) receives
or rejects the invitation (or the call). The packet terminal
equipment and the media gateway/media equipment are
often the User Agent including User Agent Client and User
Agent Server. In addition, the Proxy Server mentioned below
will also implement the User Agent function.
The SIP protocol defines three main types of Servers: Proxy
Server, Redirect Server and Register Server:
i. The Register Server is mainly used to register the current
location of the packet terminal and the original data of
the location service.
ii. As the middle media between the User Agent Client and
the User Agent Server, the Proxy Server forwards the
invitation sent from the User Agent Client. Before the
forwarding, the Proxy Server gets possible locations of
the callee according to the identification request location
server of the callee, and then separately sends invitations
to them.
iii. The Redirect Server accepts the invitation from the User
Agent Client, gets possible locations of the callee
according to the identification request location server of
the callee, and then returns the information to the
invitation originator (User Agent Client). Different from
the Proxy Server, the Redirect Server does not forward

the invitation, and the invitation is completed by the

calling terminal.
2. Concepts of the Basic Network Model
The related concepts of the network model are described as
follows:
Call: One call is composed of all the members invited by one
call originator in a conference. One SIP call is identified by
the global exclusive call identifier (CALL_ID). Therefore, if
one subscriber is invited by different subscribers to the same
multi-point conference, each invitation has one exclusive call.
One point-to-point Internet phone conversation is also
considered as a SIP call. In one MCU-based phone
conversation program, each participant uses an exclusive call
to connect with the MCU.
Call leg: One call leg is identified by the Call-ID, and the
addr-spec and the tag in “To” and “From”. Only the user and
hostport parts in the addr-spec are meaningful. In the same
Call-ID, both the request from A to B and the one from B to
A belong to the same call leg. The call leg can be considered
as the path passed by the message in one call.
Conference: Refers to one multi-media conversation,
identified by the common conversation description. One
conference can be composed by zero or more members,
which can be a multi-point conference, fully-interconnected
conference, point-to-point conference or their combination.
One conference can be set up by an arbitrary number of calls.
Initiator or Caller: Initiates a conference invitation. It should
be noted that the initiator is not necessarily the conference
creator.
Invitee or Callee: Invited to the conference by the initiator or
caller.
Invitation: Refers to a request for asking subscribers to join
the conversation. One successful SIP invitation includes two
transactions: one INVITE request and one ACK request.
Isomorphic request or response: Refers to two
requests/responses containing the same Call-ID, To, From
and CSeq head domains. In addition, the isomorphic
requests must contain the same Rquest-URI.
Parallel search: In one parallel search, the agent sends
multiple requests to possible callees after receiving the
request. In the parallel search, it is unnecessary to wait for
the response to the previous request when a new request is
sent.
Final response: Corresponding to the provisional response,
the final response is used to terminate the SIP transaction.
All the 2xx, 3xx, 4xx, 5xx and 6xx responses are final
responses.

Provisional response: Refers to one kind of response for the

server to indicate the work progress, but not to terminate
the SIP transaction. The response with 1xx code is the
provisional response, and other responses are all final
responses.
Session: According to the definition of the Session
Description Protocol (SDP) specification, the multi-media
session is a set composed of the multi-media sender, multi-
the media receiver and data flow from the sender to the
receiver, such as multi-media conference. According to the
definition, one callee can be invited to the same session by
different calls for many times. If the SDP is used to describer
the session, one session can be co-defined by the subscriber
name, session ID, network type, address type and the source
address.
SIP Transaction: One SIP transaction occurs between the
client and the server, including all the messages between the
time when the first request is sent from the client to the
server and that when the final response sent from the server
to the client. The transaction is identified by the Cseq
sequence number in one call leg. One ACK request and its
corresponding INVITE request have the same CSeq, and
compose their own transaction.
Back-To-Back User Agent (B2BUA): Refers to a logical entity
receiving requests and acting as a UAS. To confirm how to
respond to the request, the B2BUA acts as a UAC to initiate a
request. Different from the proxy server, the B2BUA
maintain the session status and must join all the requests
sent on the set-up session. Being a serial UAC and UAS, the
behaviors of the B2BUA do not need to be explicitly defined.
3. Main messages
The SIP protocol is constituted in the format of layer
protocols, which means that its behaviors are described by a
set of relatively independent processing phases. The relation
between phases is not very close. The SIP protocol divides
the communication message between the Server and the
User Agent into two types: request messages and responses
messages.
i. Request message: Refers to the SIP message sent to the
server by the client to activate specific operations,
including INVITE, ACK, BYE, CANCEL, OPTION and
UPDATE messages.
ii. Response message: Refers to the SIP message sent to
the client by the server to feed back the processing result
of the corresponding request, including 1xx, 2xx, 3xx,
4xx, 5xx and 6xx responses.
iii. SIP message format: Both request messages and
responses messages include the SIP message head field
and the SIP message body field.

The SIP message head is mainly used to indicate who

initiates the message, who receives it, how many times
of jumping it passes, and other basic information.
The format of the SIP request message is composed of
the SIP message head and a group of parameter lines, as
shown in Figure 53.
FIGURE 53 FORM AT OF THE SIP REQUEST MESSAGE
Command Name Opposite-end URI Protocol Version

Message
Head
Call_id value
Via value
From value
To value
Contact value Parameter

Line
Cseq value
Content-Length value
Max-Forward value
Content-Type value
White Space
SDP
The format of the SIP response message is composed of

the SIP response message head and a group of
parameter lines, as shown in Figure 55.

FIGURE 54 FORM AT OF THE SIP RESPONSE MESSAGE
SIP / Protocol Version Response Message Head

Message
Head
Call_id value
Via value
From value
To value
Contact value Parameter

Line
Cseq value
Content-Length value
Max-Forward value
Content-Type value
White Space
SDP
Main Response 1. Overview

Codes of the
The SIP response message is used to respond to the request
SIP Protocol
message, indicating the success or failure status of the call.
Different types of response messages are distinguished by
the status code that is a 3-digit integer. The first digit is
used to define the response type, and the other two digits
are used to describe the response more detailedly.
2. Category
The category of response messages is shown in Table 9.

TABLE 9 CATEGORY OF RESPONSE MESSAGES
Types of Response Categories of

Status Codes
Messages Messages
1xx Progress response Provisional response
2xx Success Final response
3xx Relocation response Final response
4xx Client error Final response
5xx Server error Final response
6xx Global error Final response
3. Description of each type of messages

In the message category, the provisional response is
used to indicate that the call is under way, while the final
response is used to terminate the request message. The
description of each type of messages is as follows:
i. 1xx messages
The 1xx message indicates that the request is being
processed by the server or the agent, but no response is
obtained yet. The client should continue to wait for the
response from the server. When the server forecasts that
the final response cannot be obtained within 200 ms, it
should send a 1xx response message. Table 10 shows the
list of common 1xx messages.
TABLE 10 LIST OF COMMON 1XX MESSAGES
Status
Meanings
Codes
Trying: The call-related operation (such as visiting the
100 database) is being performed, but the callee is not
located yet
Ringing: The callee agent has obtained the location of
180
the callee, and is alerting the callee
Call Is Being Forwarded: The proxy server can use this
181 status code to indicate that the call is being forwarded
to other destination
Queued: The callee cannot be visited temporarily, and
the call is queued instead of being rejected. When the
server becomes valid, it can respond to this call. The
"reason phrase" in the response can further show the
182
information about the queued call. For example, there
are five calls in the queue, and the expected waiting
duration is 15 minutes. The server can send multiple
182 responses to update the information of queued calls
ii. 2xx messages

The 2xx message indicates that the request has been
received, processed and successfully accepted.
200: OK——the request is successful.

iii. 3xx messages

The 3xx message indicates that the response gives
information about the new location of the subscriber and
other optional services.
Table 11 shows the list of common 3xx messages.
Status
Meanings
Codes
Multiple Choice: The address in the request is analyzed
to multiple locations, and the user can re-direct the
request to a proper address. This response should
300
contain the list of locations and resources available for
users or user agents, and available addresses should be
listed in the Contact head domain
Moved Permanently: In the request, the address
indicated by Request-URI cannot find the user, and the
client should try the new address given by the Contact
301 head domain. After receiving the response, the caller
should update all the local directories, address books
and subscriber location buffers, and re-directs requests
received subsequently to the new address
Moved Temporarily: The client should make call
attempts by using the new address given by the Contact
head domain. The Expire head domain in the response
302
indicates the expiration date of the re-direction. If no
expiration date is specified, the re-direction is only valid
for the current call
Use Proxy: The resources requested by the client must
be visited through the agent given by the Contact head
305
domain. The Contact domain gives the URI of the agent.
This response can only be sent by the UAS
Alternate Service: The call is unsuccessfully, but other
services (such as email and voice box) can be selected.
380
The message body of this response gives the
descriptions of available services
iv. 4xx messages

The 4xx message indicates that the request message
contains grammar errors or that the SIP server cannot
completely process the request message.
Status
Meanings
Codes
400 Bad Request: The request has grammar errors, so the
server cannot understand it
401 Unauthorized: The request needs user authentication

Status
Meanings
Codes
402 Payment Required: This response is reserved for the
future applications
403 Forbidden: The server understands the request, but
refuses it. The client should not resend it again
404 Not Found: There is no subscriber to be called in the
address given by the Request-RUL in the request. When
the address given by the Request-RUL does not match
the domain managed by the server, the server will also
send this response
405 Method Not Allowed: The method specified in the
request is not allowed. This response should contain the
Allow head domain and list the methods supported by
the server
406 Not Acceptable: According to the Accpe head domain in
the request, the content characters in the response
entity generated by the resource given by the request
are not acceptable
407 Proxy Authentication Required: This response is similar
to the 401 (Unauthorized) response, but it indicates that
the user must authenticate itself first to the agent
408 Request Tiemout: The server cannot generate the
response within the duration specified by the Expire
head domain in the request. The client can resend this
request after a period of time
409 Conflict: The request from the client conflicts with the
current status, so the request cannot be completed.
When the “action” parameter in the REGISTER request
conflicts with the exiting register, this response will be
returned
410 Gone: The server has no resource requested, and does
not know the address for further contact. This condition
is considered to be permanent. If the server cannot
confirm whether this condition is permanent, it should
send the 404 (Not Found) response
411 Length Required: The server refuses to accept the
request not including the Content-Length head domain.
The client can resend the request after adding a Cotent-
Length head domain indicating the length of the
message body
413 Request Entity Too Large: The server refuses to process
the too long message entity. If this condition is
temporary, the server should send the response
containing the Retry-After head domain to indicate when
the client should resend the request
414 Request-URI Too Long: The server cannot analyze the
too long Request-URI
415 Unsupported Media Type: The server does not support
the format of the request message. The server should
use Accept, Accept-Encoding and Accept-Language head
domains in the response to list its supported formats

Status
Meanings
Codes
420 Bad Extension: The server does not understand the
protocol extension specified by the Require head domain
in the request
480 Temporarily Unavailable: The called terminal has been
successfully connected, but the subscriber cannot visit it
temporarily (for example, the subscriber is unregistered,
or the Do Not Disturb service is enabled). The server
can specify another visit time in the Retry-After head
domain
481 Call leg/Transaction Does Not Exist: This response is
returned under three conditions. One is when the server
receives a BYE request but cannot find the matched call
leg; one is when the server receives a CANCEL request
but cannot find the matched transaction; and another is
when the server receives an INVITE request different
from the original TAG mark (For the unmatched ACK
request, the server direct discard it without responding
to it)
482 Loop Detected: The Via head domain in the request
message contains the address of the receiving server
483 Too Many Hop: The number of hops contained in the Via
head domain in the request message exceeds the value
specified by the Max-Forwards head domain
484 Address Incomplete: The address indicated by To or
Request-RUL in the request is incomplete
485 Ambiguous: The address provided in the request is
ambiguous. This response can list the ambiguous
addresses in the Contact head domain
486 Busy Here: The called terminal has been successfully
connected, but the subscriber does not want to or
cannot receive more calls. The server can specify
another visit time in the Retry-After head domain in the
response. The client can also visit the called terminal
through other methods, such as voice box, so this
response does not terminate a query
487 Request Cancelled: The original request message is
cancelled by a CANCEL request
v. 5xx messages
The 5xx message indicates that the SIP server cannot
correctly process the request message because it is faulty.
Status
Meanings
Codes
Server Internal Error: The server is exceptional , so it
500
cannot process the request

Not Implemented: The server does not support the

501
functions required for completing the request
Bad Gateway: As a gateway or an agent, the server
502 receives an invalid response from other server when
processing the request
Service Unavailable: Due to temporary overloading or
503
being maintained, the server cannot process the request
Gateway Timeout: As a gateway, the server does not
504 receive responses from other servers (such as the
location server) in time when processing the call
Version Not Supported: The server cannot or refuses to
505
support the version used by the request message
vi. 6xx messages

The 4xx message indicates that the request message
contains grammar errors or that the SIP server cannot
completely process the request message.
Status
Meanings
Codes
Busy Everywhere: The called terminal has been
successfully connected, but the subscriber is busy and
does not want to accept the current call. The server can
specify another visit time in the Retry-After head
600 domain in the response. This response is only returned
when the called terminal cannot be visited through other
methods (such as voice box). If the called terminal can
be visited through other methods, the 486 (Busy Here)
response will be returned
Decline: The called terminal has been successfully
connected, but the subscriber is busy and clearly
603 expresses that he/she does not want to accept the
current call. The server can specify another visit time in
the Retry-After head domain in the response
Does Not Exist Anywhere: The subscriber specified by
604
the To head domain in the request does not exist
Not Acceptable: The user agent has been successfully
connected, but some session descriptions such as the
media type and the broadband or address style cannot
606
be accepted. This response indicates that the user want
to set up communication, but cannot fully support the
session described in the request


Chapter 3
Service Functions
Overview
Introduction This chapter introduces various service functions of the ZXWN
MSC Server.
Contents This chapter includes the following sections.
Sections Page No.

Mobility Management Service 94
Security Management 138
VLR Management 147
Mobile Call Service Function 150
Supplementary Services 176
Mobile Data Services 199
Mobile Intelligent Service 200
Short Message Service 236
Operation and Maintenance Service 240
Interception Services 243
Location Service 252
Region System Function 262
Dual-homing Disaster Recovery Function 264
Load Control Function 267
R2 Function 271
Roaming Pool Function 273
Multi-EIR Function 274
M2PA Networking Function 275
Interworking Services between the IMS and the 277
CS/PSTN
Function of Detecting and Restricting Cheaters 282

Sections Page No.

Rerouting Function 289
Dynamically Selecting Routes Based on Load of IP 290
Bearer Network and QoS
Bidirectional Forwarding Detection Function 290
Compatibility Function with 2G 291
Mobility Management
Service
Overview
Introduction In the ZXWN MSCS system, mobility management service
consists of following parts: Location update and
relocation/handover.
1. Location Update
Location of a mobile subscriber always changes due to
mobility of the subscriber. To obtain location information of
mobile subscribers during processing of call service, SMS and
supplementary services and meanwhile to improve valid
utility of radio resources, mobile subscribers must register
their location information and report activity status on
network, that is, subscribers must originate location update
service.
Location update service falls into the following three
categories:
General location update: Used for registering new location
information on the network. It can be further divided into
three types: VLR location update, GPRS location update and
joint location update.
Periodic location update: Used for periodically notifying
network of the availability of mobile subscribers.
IMSI (GPRS) attachment/detachment: Used for indicating
attachment or detachment of IMSI subscriber status.
Different location updates are identified by location update
category information in location update request message.
Processing flow is almost the same.
2. Relocation/handover
When a mobile subscriber moves to a boundary area of two
cells, if BTS detects that signal of mobile subscriber is too
weak, BS will automatically initiate a relocation request to

Chapter 3 Service Functions
MSC/VLR and perform relocation, to sustain existing service.

For MSCS/VLR, switching with 2G system is possible.
Therefore, handover and relocation are more complicated
than those inside 2G system. Specifically, they may fall into
the following types:
Intra-GSM handover: Includes intra-office handover and
inter-office handover.
Inter-system handover from GSM to UMTS: Includes intra-
office handover and inter-office handover.
Inter-system handover from UMTS to GSM: Includes intra-
office handover and inter-office handover.
Relocation from UMTS to UMTS: Includes intra-office
relocation and inter-office relocation.
Relocation or handover between different BSs within an
MSCS is called intra-MSCS relocation or handover. Relocation
or handover between different MSCSs is called inter-MSCS
external relocation or handover. According to the criterion
whether there is a subsequent handover after a handover,
external relocation between MSCSs can be divided into two
types: basic handover and subsequent handover.
Relocation or handover can be divided into 4 kinds according
to whether the circuit is established:
Basic relocation or handover with a circuit
Basic relocation or handover without a circuit
Subsequent relocation or handover with a circuit
Subsequent relocation and handover without a circuit.
Major difference between relocation without a circuit and
relocation with a circuit is that whether bearer planes are set
up in MSCS A and MSCS B before or after relocation. If
circuit is set up before relocation, it is called relocation with a
circuit; otherwise, it is called relocation without a circuit.
After completion of relocation with/without a circuit, MS is
already at MSCS B and enters talking status. During
relocation without a circuit, MS has been relocated to
MSCS/VLR-B. However, bearer plane between MSCS/VLR-A
and MSCS/VLR-B has not been set up.
Subsequent reposition or handover can also be further
divided into following types:
Subsequent relocation or handover handed over back to
MSCS A
Relocation or handover handed over to third party MSCS B’
and internal relocation or handover inside MSCS B.
Because there are multiple handover cases, we take intra-office
and inter-office as examples here and introduce handover with a
circuit. Difference between handover without a circuit and that
with a circuit is that no bearer is set up in handover without a
circuit.

Contents This section includes the following topics.
Topics Page No.

General Location Update 96
Periodic Location Update 101
IMSI Attachment/ Detachment 101
Deleting a Subscriber 102
UMTS → UMTS Intra-office Relocation 103
UMTS → UMTS Inter-office Relocation 107
UMTS → GSM Intra-system Handover 112
UMTS → GSM Inter-office System Handover 116
GSM → UMTS Intra-system Handover 121
GSM → UMTS Inter-office System Handover 124
GSM → GSM Intra-office System Handover 129
GSM → GSM Inter-office System Handover 133
General Location Update

VLR location If Location Area (LA) changes when subscriber roams, MS will
update originate a location update operation. If both original LA and
new LA belong to same MSCS/VLR, it can be modified simply in
VLR. If not, new MSCS/VLR should request HLR for data of this
MS. HLR will notify original MSCS/VLR to delete location and
register MS in new MSCS/VLR at the same time when HLR sends
out information necessary for new MSCS/VLR. When MS uses
TMSI and previous location area ID (PLAI) to update location in
new MSCS/VLR. If PLAI is not in new MSCS/VLR, new MSCS/VLR
can deduce previous VLR (PVLR) according to TMSI and PLAI, so
as to send a verification request message to PVLR, asking PVLR
for IMSI of MS and unused authentication parameter sets.
Detailed processing flow varies with location information
reported by MS and location information registered in VLR and
HLR. If new LA registered by MS is not in the original MSCS/VLR
or LA information of MS is uncertain, it is necessary to initiate
location update to HLR; otherwise, it is unnecessary to initiate
location update to HLR. These two cases are described as follows.
Processing flow without need of location update to HLR
Processing flow without need of location update to HLR is
shown in Figure 55.

FIGURE 55 PROCESSING FLOW WITHOUT NEED OF LOCATION UPDATE TO HLR
MS MSCS/VLR HLR
Update_Location_ Area_Req
Step1
Send_Authentication_Info
Send_Authentication_Info_ack Step2
Authenticate_REQ
Authenticate _RSP Step3
SECURITY_MODE_CMD
SECURITY_MODE_COM Step4
TMSI_Reallocation_CMD (Note)
Step5
Update_Location_Area_ack
Step6
TMSI_Reallocation_COM
Step7
IU_REL_CMD
IU_REL _COMPLETE Step8
Note: If MS updates location through TMSI, MSCS/VLR will

originate this message.
Descriptions of the flow:
i. Step 1
MSCS/VLR receives location update request
(Updata_Location_Area_Req) from MS, checks
correctness of the subscriber data and judges location
update category, to determine subsequent operations.
ii. Step 2
MSCS/VLR requires authentication of subscriber, but if
there is no available authentication parameter of this
subscriber in local database, VLR will apply to HLR for
new authentication parameters. After successful
execution, HLR will return subscriber’s authentication
parameter set.
iii. Step 3
When MSCS/VLR requires authentication of subscriber
and there are available authentication parameters of this
subscriber in the local database, MSCS/VLR will originate
authentication operation to MS and authenticates validity
of subscriber.
iv. Step 4
If subscriber has subscribed to encryption or integrity
protection service, MSCS/VLR will originate ciphering
mode command CIPH_MODE_CMD to set up encryption
and integrity protection algorithm and ciphering key on
subscriber side and network side. After receiving this
message, MS returns ciphering mode completion
message.

v. Step 5
If subscriber has subscribed to encryption service,
MSCS/VLR will originate this operation to allocate a new
TMSI number to subscriber.
vi. Step 6
After finishing location update processing for MS,
MSCS/VLR returns acknowledgement message to the MS.
vii. Step 7
If the configuration of the new TMSI of subscriber is
completed, result will be returned to MSCS/VLR.
viii.Step 8
After receiving message about completion of subscriber’s
new TMSI setting, MSCS/VLR sends clear command to
subscriber. MS returns acknowledgement message to end
processing.
Processing flow needing location update initiation to HLR
Processing flow needing location update initiation to HLR is
shown in Figure 56.
FIGURE 56 PROCESSING FLOW NEEDING LOCATION UPDATE INITIATION TO

HLR
MS MSCS /VLR HLR PVLR
Update _ Location_Area_ REQ

Step1
Update_Location
Step2
Cancel_Location
Step3
Cancel_Location_ack
Step4
Activate_Trace_Mode
Activate _Trace_ Mode_ack Step5
Insert _Subscriber_Data
Step6
Insert_ Subscriber_Data_ ack
Step7
Forward_Check_SS_Indication
Step8
Update_ Location_ ack
Step9
Update_Location
_Area_ack
Step10
i. Step 1
MS sends a location update request to MSCS/VLR. After
receiving location update request from MS, MSCS/VLR
checks correctness of subscriber data and judges location
update category, to determine subsequent operations.
ii. Step 2
According to some conditions, MSCS/VLR determines
whether to send location update request to HLR. In
general, this operation is originated in the following cases:

f Subscriber starts the system for the first time.

f Subscriber roams across the MSCS/VLR system.
f Subscriber data is incorrect or inconsistent with that in
the HLR due to VLR reset or individual reasons.
iii. Step 3
MSCS/VLR receives location canceling request from HLR.
According to the subscriber identity IMSI in the
parameters, MSCS/VLR deletes this record from
subscriber data to release subscriber’s TMSI.
iv. Step 4
No matter whether subscriber has ever been registered in
VLR, MSCS/VLR will return location canceling
acknowledgement to HLR and close dialogue.
v. Step 5
MSCS/VLR receives an Activate_Trace_Mode request
from HLR and directly returns the Activate_Trace_Mode
acknowledgement to HLR. MSCS sets a subscriber tracing
flag in the corresponding Data Area (DA), to implement
real-time subscriber tracing.
vi. Step 6
MSCS/VLR sends a location update request to HLR, which
causes HLR to originate subscriber data insertion
operation, to transmit subscriber data from HLR to VLR.
vii. Step 7
MSCS/VLR acknowledges that all subscriber data from
HLR is correct and returns acknowledgement primitive to
HLR.
viii.Step 8
MSCS/VLR receives Forward_Check_SS_Indication
request from HLR, unnecessary for acknowledgement.
ix. Step 9
At the end of location update processing, HLR will return
acknowledgement primitive to MSCS/VLR.
x. Step 10
After location update originated by MSCS/VLR to MSCS is
completed, MSCS/VLR will return acknowledgement
message to MS.
GPRS Location SGSN initiates location update to HLR, and the process is similar
Update to VLR location update. When SGSN address received by HLR is
not consistent with original SGSN address, HLR will initiate a
location deletion service to previous SGSN, as shown in Figure
57.

FIGURE 57 GPRS LOCATION UPDATE SERVICE FLOW
1. Step 1
SGSN where MS is currently located initiates a location
update request to HLR. HLR determines whether to allow this
subscriber to roam. If yes, it will proceed with the next.
2. Step 2
After HLR receives location update request from new SGSN
where MS is located, if HLR has already recorded SGSN
where MS is located originally, HLR will initiate location
deleting operation to previous SGSN (PSGSN), to request
PSGSN to delete data of this subscriber.
3. Step 3
After PSGSN deletes data of this subscriber, it sends a
response message to the HLR.
4. Step 4
HLR initiates a request for SGSN to insert subscriber data
(depending on the quantity of subscriber data, they can be
transmitted in one or more packages).
5. Step 5
SGSN where MS is currently located responds and
acknowledges to HLR for subscriber data insertion.
6. Step 6
HLR confirms SGSN location update request.
Combined If there is Gs interface connection, SGSN will notify VLR to
Location originate location update after GPRS location update is
Update completed. This is called joint location update, as shown in
Figure 58.

FIGURE 58 JOINT LOCATION UPDATE SERVICE FLOW
This location update service flow is the same as general location

update service flow.
Periodic Location Update

Function When an MS is powered off, MSCS may fail to know this event
due to poor radio transmission quality or some other reasons,
and MSCS still regards MS as in “attach” status. Alternatively,
MS is powered on but has roamed beyond service coverage, that
is, MS is in a blind area, GSM system cannot also know its
location and still regards the MS in “attach” status. In both cases,
if the subscriber is called, the system will keep sending paging
messages, wasting radio resources.
To solve above-mentioned problems, MSCS takes measures of

forced registration. That is, to require MS to register at regular
intervals, which is periodic location update.
Flow Periodic location update process is the same as general location

update process.
IMSI Attachment/ Detachment

When the MS is powered off (or the SIM card is removed), this
MS can not set up any connection. If MSCS still sends normal
paging to it, this will unavoidably waste precious resources.
Introduction of IMSI attachment/detachment is to avoid such
waste of resources.
Subscriber will originate location update when MS is powered on

and its current LA will be registered in MSCS/VLR where
subscriber is located. If current MSCS/VLR has no record of this
subscriber, it will request HLR for subscriber data according to
subscriber IMSI. HLR records subscriber’s current location

(recording current MSCS/VLR number) and sends subscriber

data to MSCS/VLR. MSCS/VLR will set subscriber status to
“attach”.
If MSCS/VLR has subscriber data, it need not ask HLR for data.
MSCS/VLR just originates location update and then sets
subscriber status to “attach”.
When MS is powered off, it will send a message to MSCS/VLR.

When network receives this message, it regards MS as power off
and sets subscriber status as “detach”.
Deleting a Subscriber
Function If a subscriber makes no operation for a long time (flexibly set
by the system administrator, normally 24 hours) and if the
system administrator requires deleting invalid subscriber records
in the VLR through OMC, the VLR will delete subscriber data and
notify the HLR.
Flow The service flow of the VLR requesting data deletion is shown in
Figure 59.
FIGURE 59 VLR REQUESTING DAT A DELETION FLOW
1. Step 1: The VLR requests to delete subscriber data.

2. Step 2: The VLR resets the Purge flag of this subscriber and
sends a reply message to the VLR.

UMTS → UMTS Intra-office

Relocation
UMTS → UMTS Network models as shown in Figure 60, Figure 61 and Figure 62
Intra-office indicate calling control signaling and bearer control signaling
Relocation before, during and after the handover. Here, actual lines indicate
Network control plane signaling and virtual lines indicate bearer plane
Models control signaling.
Note 1: Terminal T1 orients RNC A side and the T2 orients other
MGWs. T3 orients RNC B side.
FIGURE 60 UMTS → UMTS NETWORK MODEL BEFORE INTRA-OFFICE

SUBSCRIBER HANDOVER
MSCS
T1 T2
RNC A CTX1
MGW
FIGURE 61 UMTS → UMTS NETWORK MODEL DURING INTRA-OFFICE

SUBSCRIBER HANDOVER
MSCS
T1
CTX1 T2
RNC A MGW
T3
RNC B

FIGURE 62 UMTS → UMTS NETWORK MODEL AFTER THE INTRA-OFFICE

SUBSCRIBER HANDOVER
MSCS
T3 T2
RNC B CTX1
MGW
UMTS → UMTS UMTS → UMTS intra-office relocation message flow is shown in

Intra-office Figure 63 and Figure 65.
Relocation
Message Flow

FIGURE 63 UMTS → UMTS INTRA-OFFICE RELOCATION FLOW
RNC A MSCS MGW RNC B
Iu Relocation Required
Step1
Context(C1) ADD.request ($)
Prepare bearer
Context(C1) ADD.reply(T3)
Context(C1) Mod.request (T2,T3,oneway)

Change Flow Direction
Step2
Context(C1) Mod.reply (T2,T3)
Context(C1) Mod.request (T1,T3,isolate)

Iu Relocation Request
Bearer
Establish- Step3
ment
Iu Relocation Request-Ack
Iu Relocation Step4
Command
Relocation
execution
triggered
in target
RNC
Iu Relocation Detect
Context(C1) Mod.request (T2,T3,bothway) Step5

Context(C1) Mod.request (T2,T1,oneway)


FIGURE 64 UMTS → UMTS INTRA-OFFICE RELOCATION FLOW (CONTINUED)
RNC A MSCS MGW RNC B
Iu Relocation Complete
Iu Release Command
Release of bearer
Step6
Iu Release Complete
Context(C1) SUB.request (T1)
Context(C1) Release Termination

SUB.reply (T1)
Flow Descriptions:
1. Step 1
When an RNS decides to originate relocation, RNS-A (RNC A)
sends a relocation request message to MSCS A. message
carries target cells list arranged according to their priorities.
RNC A judges that handover is needed and it sends handover
request message Iu Relocation Required to MSCS.
2. Step 2
MSCS invokes Prepare Bearer procedure to apply for terminal
T3 to MGW, requesting MGW to provide binding reference
BNC ID and MGW address. After the T3 is applied
successfully, MSCS invokes command Change Flow
Direction to modify connection relationships among
terminals T1, T2 and T3. T2 is connected with T3
unidirectional and T1 is separated from T3.
3. Step 3
MSCS sends Relocation Request message to RNC B,
requesting RNC B to apply for wireless resources. MSCS
converts MGW address and BNCID parameters relevant to T3
and bearer service parameters into relevant RAB parameters
to set up RNC B bearer at access side.
4. Step 4
When RNC B finishes applying for wireless resources, it
returns message Iu Relocation Request-Ack to MSCS. MSCS
returns Iu Relocation Command message to RNC A carrying
applied wireless resources.
5. Step 5

When RNC B receives handover message of UE/MS, it sends

message Iu Relocation Detect to MSCS. MSCS sends
command Change Flow Direction to MGW to modify
connection relationships among terminals T1, T2 and T3. T2
and T3 are connected in bi-directional manner and T2 is
connected to T1 in unidirectional manner.
6. Step 6
When RNC B receives handover completion message of
UE/MS, it sends message Iu Relocation Complete to MSCS.
MSCS sends Iu Release Command message to RNC A,
requesting RNC A to release the Iu resource. After Iu
resource is released, MSCS sends the command Release
Termination to MGW to release terminal T1.
UMTS → UMTS Inter-office

Relocation
UMTS → UMTS Network models shown in Figure 65, Figure 66, and Figure 67
Inter-Office indicate call control signaling and bearer control signaling before,
Relocation during, and after handover respectively. Here, actual lines
Network Model indicate control plane signaling and virtual lines indicate bearer
plane control signaling.
Note 1: In MGW A, terminal T1 orients RNC A, terminal T2 is for
other terminals and terminal T3 orients MGW B.
Note 2: In MGW B, terminal T4 orients RNC B and terminal T5

orients MGW A.
FIGURE 65 UMTS → UMTS NETWORK MODEL BEFORE THE INTER-OFFICE

HANDOVER
MSCS A
T1 T2
RNC A CTX1
MGW A

FIGURE 66 UMTS → UMTS NETWORK MODEL DURING THE INTER-OFFICE

HANDOVER
MSCS A
RNC A
MSCS B
T1 CTX1 T2
MGW A
T3
T4 T5
RNC B CTX2
MGW B
FIGURE 67 UMTS → UMTS NETWORK MODEL AFTER THE INTER-OFFICE

HANDOVER
MSCS B MSCS A
T4 T5 T3 T2
RNC B CTX2 CTX1

MGW B MGW A
UMTS → UMTS The UMTS → UMTS inter-office relocation message flow is shown
Inter-office in Figure 68 and Figure 69.
Relocation
Message Flow

FIGURE 68 UMTS → UMTS INTER-OFFICE HANDOVER FLOW

FIGURE 69 UMTS → UMTS INTER-OFFICE HANDOVER FLOW (CONTINUED)
RNC A MSCS A MGW A MSCS B MGW B RNC B
Context(C1) MOD.request (T2,T3,bothway)

Context(C1) MOD.reply (T2,T3)
Context(C1) MOD.request (T2,T1,oneway) Step9

MAP Send End Signal Req. Step10

Answer
Step11
Iu Release Command
Release of bearer
Iu Release Complete Step12
Context(C1) SUB.reply (T1) Release Bearer Termination
Flow Descriptions:
1. Step 1
sends a relocation request message to MSCS A. This
message carries target cells list arranged according to their
priorities. RNC A judges that handover is needed and it sends
handover request message Iu Relocation Required to MSCS A.
MSCS A judges that it is inter-office handover and it sends
preparing relocation message MAP Prepare Handover Req
that carries necessary information of wireless resource
application for UE/MS handover to destination MSCS B. For
handover with a circuit, MSCS A will request MSCS B to apply
for handover number.
2. Step 2
When MSCS B receives message MAP Prepare Handover Req
from MSCS A, it judges whether there is circuit relocation, if
there is, handover number must be applied first, and if there
is a circuit in handover, MSCS B invokes Prepare Bearer
procedure to apply for terminal T4 to MGW B and requests
MGW to provide binding reference BNCID and MGW address.
3. Step 3
MSCS B sends message Iu Relocation Request to RNC B,
carrying information brought by MAP Prepare Handover Req
for applying for wireless resource. MSCS B adopts MGW

address and BNCID parameters corresponding to T4 to

establish bearer at access side.
4. Step 4
After applying for wireless resource, RNC B sends message
Iu Relocation Request Ack to MSCS B and MSCS B sends
message MAP Prepare Handover Resp to MSCS A, carrying
applied wireless resource and handover number information.
5. Step 5
After MSCS A receives message MAP Prepare Handover Resp,
it establishes call to MSCS B through handover number.
Establishment process of call between MGW A and MGW B is
a basic mobile originating call process and process is
established through forward or backward bearer. In this
process, MSCS A applies for endpoint T3 and MSCS B applies
for endpoint T5.
6. Step 6
MSCS A modifies connection relationships among endpoints
T1, T2 and T3 through command Change Flow Direction.
T2 is connected to T3 in unidirectional manner and T1 is
separated from T3.
7. Step 7
MSCS A sends message Iu Relocation Command to RNC A to
bring new wireless resource to UE/MS.
8. Step 8
When receiving UE/MS handover message, RNC B will send
message Iu Relocation Detect to MSCS B. MSCS B sends
message MAP Process Access Signaling Req to MSCS A,
carrying UE/MS handover message.
9. Step 9
After receiving message MAP Process Access Signaling Req,
MSCS A sends command Chang Flow Direction to MGW A
to modify connection relationships among endpoints T1, T2
and T3. T2 is connected to T3 in bi-directional manner and
T2 is separated from T1.
10. Step 10
When receiving UE/MS handover completion message, RNC B
will send the message Iu Relocation Complete to MSCS B.
MSCS B sends message MAP Send End Signal Req to MSCS A,
carrying UE/MS handover completion message.
11. Step 11
MSCS B sends message answer to MSCS A, indicating
handover is completed.
12. Step 12
After receiving message MAP Send End Signal Req, MSCS A
sends Iu Release Command to RNC A to release bearer at

access side. MSCS A sends command Release Bearer

Termination to MGW A to release endpoint T1.
UMTS → GSM Intra-system

Handover
UMTS → GSM Network models shown in Figure 70, Figure 71, and Figure 72
Intra-system indicate call control signaling and bearer control signaling before,
Handover during, and after handover respectively. Here, solid lines
Network Model indicate control plane signaling and dotted lines indicate bearer
plane control signaling (no bearer control signaling on port A).
Note 1: Terminal T1 orients the RNC A side and T2 orients other
MGWs. The T3 orients the BSC B side.
FIGURE 70 UMTS → GSM NETWORK MODEL BEFORE INTRA-OFFICE

HANDOVER
MSCS
T1 T2
RNC A CTX1
MGW
FIGURE 71 UMTS → GSM NETWORK MODEL DURING INTRA-OFFICE

HANDOVER
MSCS
T1 CTX1 T2
RNC A MGW
T3
BSC B

FIGURE 72 UMTS → GSM NETWORK MODEL AFTER INTRA-OFFICE HANDOVER
MSCS
T3 T2
BSC B CTX1
MGW
UMTS → GSM UMTS → GSM intra-system handover flow is shown in Figure 73

Intra-system and Figure 74.
Handover Flow

FIGURE 73 UMTS → GSM INTRA-OFFICE HANDOVER FLOW
RNC A MSCS MGW BSC B
Iu Relocation Required
Step1
Context(C1) ADD.request (T3)
Context(C1)
ADD.reply (T3) Reserve Cirquit
Context(C1) MOD.request (T2,T3,oneway)

Context(C1) Step2
MOD.reply (T2,T3)
Context(C1) MOD.request (T1,T3,isolate)

A Handover Request
Step3
A Handover Request-Ack
Context(C1) MOD.request (T3)

Modify Bearer Characteristics
Context(C1) MOD.reply (T3) (when applicable) Step4
Iu Relocation Command
Handover
detected in
target BSC
A Handover Detect

Step5


FIGURE 74 UMTS → GSM INTER-OFFICE HANDOVER FLOW (CONTINUED)
RNC A MSCS MGW BSC B
A Handover Complete
Iu Release Command
Release of bearer
Step6
Iu Release Complete
Context(C1)
SUB.request (T1)
Release Termination
Context(C1) SUB.reply (T1)
Flow Descriptions:
1. Step 1
sends a relocation request message to MSCS A. This
message carries target cells list arranged according to their
priorities. RNC A judges that handover is needed and it sends
handover request message Iu Relocation Required to MSCS.
2. Step 2
For handover with a circuit, MSCS invokes Reserve Circuit
procedure to apply for terminal T3 to MGW, requesting MGW
to provide binding reference BNC ID and MGW address. After
T3 is applied successfully, MSCS invokes command Change
Flow Direction to modify connection relationships among
terminals T1, T2 and T3. T2 is connected with T3
unidirectional and T1 is separated from T3.
3. Step 3
MSCS sends message A Handover Request to BSC B,
requesting BSC B to apply for wireless resources.
4. Step 4
When BSC B finishes applying for wireless resources, it
returns message A Handover Request-Ack to MSCS. MSCS
returns Iu Relocation Command message to RNC A carrying
5. Step 5
When BSC B receives handover message of UE/MS, it sends
message A Handover Detect to MSCS. MSCS sends command

Change Flow Direction to MGW to modify connection

relationships among terminals T1, T2 and T3. T2 and T3 are
connected in bi-directional manner and T2 is connected to T1
in unidirectional manner.
6. Step 6
When BSC B receives handover completion message of
UE/MS, it sends message A Handover Complete to MSCS.
MSCS sends Iu Release Command message to RNC A,
requesting RNC A to release Iu resource. After Iu resource is
released, MSCS sends command Release Termination to
MGW to release terminal T1.
UMTS → GSM Inter-office System

Handover
UMTS → GSM Network models shown in Figure 75, Figure 76, and Figure 77
Inter-office indicate call control signaling and bearer control signaling before,
System during, and after handover respectively. Here, actual lines
Handover indicate control plane signaling and virtual lines indicate bearer
Network Model plane control signaling (no bearer control signaling on port A).
Note 1: In MGW A, terminal T1 orients RNC A, terminal T2
orients MGW and terminal T3 orients MGW B.
Note 2: In MGW B, terminal T4 orients BSC B and terminal T5

orients MGW A.
FIGURE 75 UMTS → GSM NETWORK MODEL BEFORE INTER-OFFICE

HANDOVER
MSCS A
T1 T2
RNC A CTX1
MGW A

FIGURE 76 UMTS → GSM NETWORK MODEL DURING INTER-OFFICE

HANDOVER
MSCS A
RNC A
MSCS B
T1 CTX1 T2
MGW A
T3
T4 T5
BSC B CTX2
MGW B
FIGURE 77 UMTS → GSM NETWORK MODEL AFTER INTER-OFFICE HANDOVER
MSCS B MSCS A
T4 T5 T3 T2
BSC B CTX2 CTX1

MGW B MGW A
UMTS → GSM UMTS → GSM inter-office system handover flow is shown in

Inter-office Figure 78 and Figure 79.
System
Handover Flow

FIGURE 78 UMTS → GSM INTER-OFFICE HANDOVER FLOW

FIGURE 79 UMTS → GSM INTER-OFFICE HANDOVER FLOW (CONTINUED)
Flow Descriptions:
1. Step 1
When an RNS decides to originate relocation, RNS-A sends a
relocation request message to MSCS A. This message carries
target cells list arranged according to their priorities. RNC A
judges that handover is needed and it sends handover
request message Iu Relocation Required to MSCS A. MSCS A
judges that it is inter-office handover and it sends preparing
relocation message MAP Prepare Handover Req that carries
necessary information of wireless resource application for
UE/MS handover to destination MSCS B. For handover with a
circuit, MSCS A will request MSCS B to apply for handover
number.
2. Step 2
there is, the handover number must be applied first, and if
there is a circuit in handover, MSCS B invokes Reserve
Circuit procedure to apply for terminal T4 to MGW B.

3. Step 3
MSCS B sends message A Handover Request to BSC B,
for applying for wireless resource.
4. Step 4
After applying for wireless resource, BSC B sends message A
Handover Request Ack to MSCS B and MSCS B sends
5. Step 5
a basic mobile originating call process and process is
for endpoint T5.
6. Step 6
separated from T3.
7. Step 7
MSCS A sends the message Iu Relocation Command to RNC
A to bring new wireless resource to the UE/MS. The handover
is performed for the mobile phone.
8. Step 8
When receiving UE/MS handover message, BSC B will send
message A Handover Detect to MSCS B. MSCS B sends
9. Step 9
10. Step 10
When receiving UE/MS handover completion message, BSC B
will send the message A Handover Complete to MSCS B.
11. Step 11
MSCS B sends message Answer to MSCS A, indicating

12. Step 12
sends Iu Release Command to RNC A to release bearer at
the access side. MSCS A sends command Release Bearer
GSM → UMTS Intra-system

Handover
GSM → UMTS Network models shown in Figure 80, Figure 81, and Figure 82
Intra-system indicate call control signaling and bearer control signaling before,
Handover during, and after handover respectively. Here, solid lines
Network Model indicate control plane signaling and dotted lines indicate bearer
plane control signaling.
Note: Terminal T1 orients the BSC A and T2 orients other MGWs.
T3 orients the RNC B.
FIGURE 80 GSM → UMTS NETWORK MODEL BEFORE THE INTRA-SYSTEM

HANDOVER
MSCS
T1 T2
BSC A CTX1
MGW A

FIGURE 81 GSM → UMTS NETWORK MODEL DURING THE INTRA-SYSTEM

HANDOVER
MSCS
T1 CTX1 T2
BSC A MGW
T3
RNC B
FIGURE 82 GSM → UMTS NETWORK MODEL AFTER THE INTRA-SYSTEM

HANDOVER
MSCS
T3 T2
RNC B CTX1
MGW
GSM → UMTS GSM → UMTS intra-system handover flow is shown in Figure 83.
Intra-system
Handover Flow

FIGURE 83 GSM → UMTS INTRA-SYSTEM HANDOVER FLOW
BSC A MSCS MGW RNC B
A Handover Required
Step1
Prepare bearer
Context(C1) ADD.reply (T3)

Change Flow Direction Step
Context(C1) MOD.reply (T2,T3) 2

Iu Relocation Request
Bearer
Establish- Step3
ment
Iu Relocation Request-
Ack
A Handover Command Step4
Relocation
execution triggered
in target RNC

Context(C1) MOD.reply (T2,T3) Step5

A Clear Command
A Clear Complete
Step6
Release Termination
Context(C1) SUB.reply (T1)
Flow Descriptions:
1. Step 1
BSC A judges that handover is needed, and it sends
handover request message A Handover Required to MSCS.

Message carries target cells list arranged according to their

priorities.
2. Step 2
MSCS invokes Prepare Bearer procedure to apply for terminal
T3 to MGW. After T3 is applied successfully, MSCS invokes
command Change Flow Direction to modify connection
relationships among terminals T1, T2 and T3. T2 is
connected with T3 unidirectional and T1 is separated from T3.
3. Step 3
MSCS sends message Iu Relocation Request to RNC B,
requesting RNC B to apply for wireless resources. MSCS
converts MGW address and BNCID parameters relevant to
the T3 and bearer service parameters into relevant RAB
parameters to set up RNC B bearer at the access side.
4. Step 4
When RNC B finishes applying for wireless resources, it
returns message Iu Relocation Request-Ack to MSCS. MSCS
returns message A Handover Command to BSC A carrying
5. Step 5
When RNC B receives handover message of UE/MS, it sends
message Iu Relocation Detect to MSCS. MSCS sends
command Change Flow Direction to MGW to modify
and T3 are connected in bi-directional manner and T2 is
connected to T1 in unidirectional manner.
6. Step 6
When RNC B receives handover completion message of
UE/MS, it sends message Iu Relocation Complete to MSCS.
MSCS sends message A Clear Command to BSC A,
requesting BSC A to release port A resource. After ort A
resource is released, MSCS sends command Release
GSM → UMTS Inter-office System

Handover
GSM → UMTS Network models shown in Figure 84, Figure 85, and Figure 86
Inter-office indicate call control signaling and bearer control signaling before,
System during, and after handover respectively. Here, solid lines
Handover indicate control plane signaling and dotted lines indicate bearer
Network Model plane control signaling.
Note 1: In MGW A, terminal T1 orients BSC A, terminal T2
orients the forward or backward MGW and terminal T3 orients
MGW B.


orients MGW A.
FIGURE 84 GSM → UMTS NETWORK MODEL BEFORE INTER-OFFICE SYSTEM

HANDOVER
MSCS A
T1 T2
BSC A CTX1
MGW A
FIGURE 85 GSM → UMTS NETWORK MODEL DURING INTER-OFFICE SYSTEM

HANDOVER
MSCS A
BSC A
MSCS B
T1 CTX1 T2
MGW A
T3
T4 T5
RNC B CTX2
MGW B
FIGURE 86 GSM → UMTS NETWORK MODEL AFTER THE INTER-OFFICE

SYSTEM HANDOVER
MSCS B MSCS A
T4 T5 T3 T2
RNC B CTX2 CTX1

MGW B MGW A

GSM → UMTS GSM → UMTS inter-office system handover flow is shown in

System
Handover Flow FIGURE 87 GSM → UMTS INTER-OFFICE SYSTEM HANDOVER FLOW

FIGURE 88 GSM → UMTS INTER-OFFICE SYSTEM HANDOVER FLOW

(CONTINUED)
BSC A MSCS A MGW A MSCS B MGW B RNC B
Relocation
execution triggered
in target RNC
Step8
MAP Process Access Signalling Req.

Context(C1) MOD.request (T2,T1,oneway) Step9

MAP Send End Signal Req Step10
Answer
Step11
A Clear Command
A Clear Complete
Step12
Context(C1) SUB.reply (T1) Release Termination
Flow Descriptions:
1. Step 1
BSC A judges that handover is needed and it sends handover
and it sends handover request message A Handover
Required to MSCS. This message carries target cells list
arranged according to their priorities. MSCS A judges that it
is inter-office handover and it sends preparing handover
message MAP Prepare Handover Req that carries necessary
information of wireless resource application for UE/MS
handover to destination MSCS B. For handover with a circuit,
MSCS A will request MSCS B to apply for handover number.
2. Step 2
is a circuit in handover, MSCS B invokes Prepare Bearer
MGW to provide binding reference BNCID and the MGW
address.
3. Step 3

MSCS B sends message Iu Relocation Request to RNC B,

for applying for wireless resource. MSCS B adopts MGW
address and BNCID parameters corresponding to T4 to
establish bearer at the access side.
4. Step 4
After applying for wireless resource, RNC B sends message
Iu Relocation Request-Ack to MSCS B and MSCS B sends
5. Step 5
a basic mobile originating call process and this process is
for endpoint T5.
6. Step 6
MSCS A modifies the connection relationships among
endpoints T1, T2 and T3 through command Change Flow
Direction. T2 is connected to T3 in unidirectional manner
and T1 is separated from T3.
7. Step 7
MSCS A sends message A Handover Command to BSC A to
8. Step 8
When receiving UE/MS handover message, RNC B will send
message Iu Relocation Detect to MSCS B. MSCS B sends
9. Step 9
10. Step 10
When receiving UE/MS handover completion message, RNC B
will send message Iu Relocation Complete to MSCS B. MSCS
B sends message MAP Send End Signal Req to MSCS A,
11. Step 11
MSCS B sends message Answer to MSCS A, indicating
12. Step 12


sends the A Clear Command to BSC A to release bearer at
the access side. MSCS A sends command Release Bearer
GSM → GSM Intra-office System

Handover
GSM → GSM Network models as shown in Figure 89, Figure 90 and Figure 91
Intra-office indicate calling control signaling and bearer control signaling
System before, during and after handover. Here, the solid lines indicate
Handover control plane signaling and dotted lines indicate bearer plane
Network Model control signaling.
Note: Terminal T1 orients the BSC A side and T2 orients MGW.
T3 orients BSC B side.
FIGURE 89 GSM → GSM NETWORK MODEL BEFORE INTRA-OFFICE SYSTEM

HANDOVER
MSCS
T1 T2
BSC A CTX1
MGW A
FIGURE 90 GSM → GSM NETWORK MODEL DURING INTRA-OFFICE SYSTEM

HANDOVER
MSCS
T1 CTX1 T2
BSC A MGW
T3
BSC B

FIGURE 91 GSM → GSM NETWORK MODEL AFTER INTRA-OFFICE SYSTEM

HANDOVER
MSCS
T3 T2
BSC B CTX1
MGW
GSM → GSM GSM → GSM intra-office system handover flow is shown in

Intra-office Figure 92 and Figure 93.
System
Handover Flow

FIGURE 92 GSM → GSM INTRA-OFFICE SYSTEM HANDOVER FLOW
BSC A MSCS MGW BSC B

A Handover Required Step1
Reserve Circuit

Context(C1) MOD.reply (T2,T3) Step2
Context(C1) MOD.request (T1,T3, isolate)

A Handover Request
Step3
A Handover Request
- Ack
Context(C1) MOD.request (T3)

Modify Bearer Characteristics
Context(C1) MOD.reply (T3) (when applicable) Step4
A Handover Command
Handover detected
in target BSC
A Handover Detect

Step5

A Handover Complete
Step6

FIGURE 93 GSM → GSM INTRA-OFFICE SYSTEM HANDOVER FLOW

(CONTINUED)
BSC A MSCS MGW BSC B
A Clear Command
A Clear Complete Step6
Context(C1) SUB.request(T1)
Release Termination
Context(C1) SUB.reply(T1)
Flow Descriptions:
1. Step 1
BSC A judges that handover is needed, and it sends
This message carries target cells list arranged according to
their priorities.
2. Step 2
MSCS invokes the Reserve Circuit procedure to apply for
terminal T3 to MGW. After the T3 is applied successfully,
MSCS invokes command Change Flow Direction to modify
is connected with T3 unidirectional and T1 is separated from
T3.
3. Step 3
MSCS sends message A Handover Request to BSC B,
requesting BSC B to apply for wireless resources.
4. Step 4
When BSC B finishes applying for wireless resources, it
returns message A Handover Request-Ack to MSCS. MSCS
returns message A Handover Command to BSC A carrying
5. Step 5
When BSC B receives access message of UE/MS, it sends
message A Handover Detect to MSCS. MSCS sends command
Change Flow Direction to MGW to modify connection
relationships among terminals T1, T2 and T3. T2 and T3 are
connected in bi-directional manner and T2 is connected to T1
in unidirectional manner.
6. Step 6

When BSC B receives handover completion message of

UE/MS, it sends the message A Handover Complete to MSCS.
MSCS sends message A Clear Command to BSC A,
requesting BSC A to release port A resource. After port A
resource is released, MSCS sends command Release
GSM → GSM Inter-office System

Handover
GSM → GSM Network models shown in Figure 94, Figure 95, and Figure 96
inter-office indicate call control signaling and bearer control signaling before,
System during, and after handover respectively. Here, solid lines
Handover indicate control plane signaling and dotted lines indicate bearer
Network Model plane control signaling.
Note 1: In MGW A, terminal T1 orients BSC A, terminal T2
orients MGW and terminal T3 orients MGW B.

orients MGW A.
FIGURE 94 GSM → GSM NETWORK MODEL BEFORE INTER-OFFICE SYSTEM

HANDOVER
MSCS A
T1 T2
BSC A CTX1
MGW A

FIGURE 95 GSM → GSM NETWORK MODEL DURING INTER-OFFICE SYSTEM

HANDOVER
MSCS A
BSC A
MSCS B
T1 CTX1 T2
MGW A
T3
T4 T5
BSC B CTX2
MGW B
FIGURE 96 GSM → GSM NETWORK MODEL AFTER INTER-OFFICE SYSTEM

HANDOVER
MSCS B MSCS A
T4 T5 T3 T2
BSC B CTX2 CTX1

MGW B MGW A
GSM → GSM GSM → GSM inter-office system handover flow is shown in

System
Handover Flow

FIGURE 97 GSM → GSM INTER-OFFICE SYSTEM HANDOVER FLOW
BSC A MSCS A MGW A MSCS B MGW B BSC B

A Handover Required
MAP Prepare Handover Req. Step1
Context($) ADD.request (T4)

Reserve Circuit Step2
AHandover Request
Step3
A Handover Request_Ack
MAP Prepare Handover Resp. Step4
Call and Bearer Establishment Step5

FIGURE 98 GSM → GSM INTER-OFFICE SYSTEM HANDOVER FLOW

(CONTINUED)
BSC A MSCS A MGW A MSCS B MGW B BSC B

Step6
A Handover Command
Step7
Handover
detected in
target BSC
Step8
A Handover Detect
MAP Process Access Signalling Req.
Context(
MOD.request (T2,T3,bothway)
C1)
Context(
MOD.reply (T2,T3)
C1)
Context(
MOD.request (T2,T1,oneway) Step9
C1)
Context( Change Flow Direction
MOD.reply (T2,T1)
C1)
A Handover Complete
MAP Send Signal Step10
End Req.
Answer Step11
A Clear Command
A Clear Complete
Step12
Release Termination
Context(C1) SUB.reply)(T1)
Flow Descriptions:
1. Step 1
BSC A judges that handover is needed and it sends the
Message carries the target cells list arranged according to
their priorities. MSCS A judges that it is inter-office handover
and it sends preparing handover message MAP Prepare
Handover Req that carries necessary information of the
wireless resource application for UE/MS handover to
destination MSCS B. For handover with a circuit, MSCS A will
request MSCS B to apply for handover number.

2. Step 2
is a circuit in handover, MSCS B invokes Reserve Circuit
MGW to provide binding reference BNC ID and the MGW
address.
3. Step 3
MSCS B sends message A Handover Request to BSC B,
for applying for wireless resource.
4. Step 4
After applying for wireless resource, BSC B sends message A
Handover Request-Ack to MSCS B and MSCS B sends
5. Step 5
inter-office connection to MSCS B is established by handover
number through forward or backward bearer. In this process,
MSCS A applies for endpoint T3 and MSCS B applies for
endpoint T5.
6. Step 6
separated from T3.
7. Step 7
MSCS A sends message A Handover Command to BSC A to
8. Step 8
When BSC B receives access message of UE/MS, it sends
message A Handover Detect to MSCS B. MSCS B sends
carrying UE/MS access message.
9. Step 9
10. Step 10
When receiving UE/MS handover completion message, BSC B
will send the message A Handover Complete to MSCS B.


11. Step 11
MSCS B sends message Answer to MSCS A to connect speech
channel.
12. Step 12
sends A Clear Command to BSC A to release bearer at the
access side. MSCS A sends command Release Bearer
Security Management
Technically, radio transmission is more vulnerable to
eavesdropping and deceit than fixed line transmission. ZXWN
MSCS system guarantees system security with a variety of
approaches.
Barring of unauthorized subscribers’ access via

authentication. For details, refer to Authentication Service.
Protecting subscriber privacy via encryption and integrity
protection. For details, refer to Encryption Services and
Integrity Protection.
Preventing subscriber IMSI from being stolen, which is
implemented via TMSI allocation. For details, refer to TMSI
Allocation/Release.
Preventing subscriber’ mobile phone from being used without
authorization, which is implemented via IMEI check. For
details, refer to IMEI Check.
Authentication Service
Functions and Authentication is to protect legal subscribers against “intrusion”
Features by illegal users.
UMTS authentication is implemented by means of Authentication
and Key Agreement (AKA). In AKA process, bi-directional
authentication is used: network can authenticate subscribers,
and on the other hand, subscribers can also authentication
network. In this way, unauthorized “illegal” subscribers cannot
access network, and unauthorized “illegal” networks cannot
provide subscribers with services.
Compared with GSM authentication, UMTS authentication has
the following additional features:
Bi-directional authentication: function of network
authentication by subscribers is added.

Introduction and use of Sequence Number (SQN)

Use of authentication management field (AMF) parameter
Authentication vector cannot be reused.
With these features, security of UMTS is improved.
Generation and 1. Overview

Composition of
Subscriber authentication needs authentication quintuple
Authentication
provided by system. Quintuple is generated in AUC. During
Parameters
registration, each subscriber is allocated an IMSI. IMSI is
written into a USIM card with a USIM card writer, and
meanwhile a unique subscriber key Ki corresponding to this
IMSI is generated in card writer and stored in USIM card and
AUC independently. In addition, parameters stored in USIM
and AUC include authentication algorithms: f1, f2, f3, f4, f5,
f1star and f5star. Sequence numbers SQNms and SQNhe are
stored in USIM and AUC individually. These sequence
numbers change continuously during authentication. AUC has
a pseudo number generator, used to generate an
unpredictable pseudo-RAND (RANDom number) for
subscriber. Furthermore, AUC stores the AMF parameter.
2. Generation of quintuple parameters
Functions of the algorithms are as follows:
RAND, Ki, AMF and SQNhe generate authentication code
MAC-A by using f1 algorithm of AUC.
RAND and Ki generate response number XRES by using f2
algorithm of AUC.
RAND and Ki generate Ciphering Key (CK) by using f3
algorithm of AUC.
RAND and Ki generate Integrity Key (IK) by using f4
algorithm of AUC.
RAND and Ki generate Anonymous Key (AK) by using f5
algorithm of AUC.
If it is necessary to protect SQN, use AK to cipher SQN
(exclusive or), and combine SQN, AMF and MAC-A into an
authentication token (AUTN). Thus, RAND, XRES, CK, IK and
AUTN form a quintuple. Detailed generation process in the
AUC is shown in Figure 99.

FIGURE 99 GENERATION OF AUTHENTICATION P AR AM ETERS IN AUC
RAND
K K K
AMF
f5 xor SQN f1 f2 f3 f4
MAC-A XRES CK IK
AK SQN ⊕ AK
AUTN = SQN [ ⊕ AK] || AMF || MAC-A

Q = （RAND, XRES, CK, IK, AUTN）
Generation process of XMAC-A, RES, CK and IK in USIM is

shown in Figure 100.
FIGURE 100 GENERATION OF AUTHENTICATION P AR AMETERS IN USIM
RAND
SQN ⊕ AK
K K K
AMF
f5 xor f1 f2 f3 f4
SQN
AK XMAC-A RES CK IK
Normal For normal authentication process, see Figure 101.

Authentication
Process FIGURE 101 NORM AL AUTHENTICATION PROCESS
MS VLR/SGSN HLR/AUC
Step 1:Calculate and Step1: Generate

verify whether Step1: Transmit authentication
XMAC _A=MAC _ A RAND and AUTN vectors (RAND,
based on Ki and AuthReq SendAuthInfoReq AUTN, RES, CK
to the MS
.
AUTN.Verify whether and IK) based on
SQN is in the correct Ki, SQN and
range. AMF parameters .
AuthRsp Step2: Compare SendAuthInfoRsp Step2: Transmit

Step2: Calculate the response the generated
XRES, CK and IK. numbers to see authentication
Transmit the XRES whether parameter set to
to the VLR/SGSN XRES=RES. the VLR/SGSN.
1. When HLR receives request of VLR/SGSN for authentication

vectors, it will judge whether it is necessary to transmit
authentication vectors in segments. Judgment method: If
version number is V3, and furthermore, authentication
parameter set requested by VLR/SGSN exceeds number of
authentication parameter sets permitted each time or each
packet, vectors must be transmitted in segments. In this
case, if VLR/SGSN supports segmentation, multiple

authentication requests and responses are needed. In other

cases, segmentation is not needed.
2. HLR determines whether to return a quintuple or triple
according to authentication operation version number and
subscription options. If UMTS subscribers require HLR to
provide authentication parameters from “R99+VLR/SGSN”,
HLR will return quintuple, and will return triple in all other
cases. HLR invokes AUC interface function to obtain
authentication parameter set. UMTS subscribers apply for
quintuple, while GSM subscribers apply for triple. Maximum
requested number of parameter sets is five.
3. According to the IMSI of a subscriber, AUC finds such
parameters as Ki, SQN and AMF of subscriber in database,
meanwhile generates certain groups of random numbers
(RAND) and calculates XRES, CK, IK and AUTN.
4. After obtaining authentication parameters successfully from
AUC, HLR will check if UMTS subscriber accesses network
from VLR/SGSN of R98. If yes, HLR needs to convert
quintuple into triple and also sends authentication parameter
set to VLR/SGSN; otherwise, it does not make any
conversion and just sends authentication parameter set to
VLR/SGSN directly.
5. VLR/SGSN originates authentication operation and sends a
RAND and an AUTN to MS.
6. MS obtains authentication code XMAC-A by using same f1
algorithm according to Ki, RAND and AUTN. Then, MS will
verify whether XMAC-A is equal to MAC-A. If not, it indicates
that network is an “illegal” network, that is, MS fails in
network authentication; otherwise, MS will verify whether
SQN is in a correct range. If not, a resynchronization process
will be generated; if yes, it indicates that network is an
authorized network, that is, MS succeeds in network
authentication.
7. Based on Ki and RAND, MS obtains RES by using same f2
algorithm, obtains CK by using same f3 algorithm and
obtains IK by using same f4 algorithm. Furthermore, MS will
send RES to VLR/SGSN.
8. VLR/SGSN compares RES calculated by MS with RES
calculated by AUC. If they are same, it indicates that
subscriber is a legal subscriber and has completed subscriber
authentication initiated by network.
Resynchroniza 1. Overview
tion Process
When MS fails in verifying SQN, that is to say, MS finds that
SQN is not in a correct range, it will initiate a
resynchronization process to resynchronize sequence number
of MS and that in HLR/AUC.
2. Process description
i. Based on Ki, SQN, AMF and RAND, USIM calculates MAC-
S by means of f1star algorithm. MAC-S and SQN form

AUTS. Then, USIM sends authentication failure message

to VLR/SGSN, carrying parameter AUTS.
ii. If VLR/SGSN finds it is a resynchronization process after
receiving authentication failure message carrying AUTS
parameter, it will ask HLR/AUC for new authentication
vectors.
iii. If HLR finds it is a resynchronization process after
receiving request of VLR/SGSN to demand authentication
vectors, it will perform synchronization processing. HLR
will first verify whether SQN is in a correct range, that is,
whether next SQN will be accepted by USIM. If SQN is in
a correct range, HLR/AUC will generate a batch of new
authentication vectors and send them to VLR/SGSN. If
SQN is not in correct range, HLR/AUC will calculate and
verify XMAC-S by using f1star algorithm according to Ki,
SQN, AMF and RAND. If XMAC-S=MAC-S, HLR/AUC will
assign SQNms value to SQNhe, and then generate a new
batch of authentication vectors and send them to
VLR/SGSN.
iv. VLR/SGSN reinitiates an authentication flow. Processing
is same as that in a normal authentication process.
3. Generation of AUTS
Generation of authentication resynchronization parameter
AUTS in USIM is shown in Figure 102.
FIGURE 102 GENERATION OF AUTHENTIC ATION RESYNCHRONIZATION

P AR AMETER AUTS IN USIM
RAND
SQN MS
K
AMF* f1 * f5 xor
MAC-S AK SQNMS⊕AK
AUTS = SQN MS [ ⊕ AK] || MAC-S
4. MAC-S verification process

During authentication resynchronization, MAC-S verification
process in HLR/AUC is shown in Figure 103.

FIGURE 103 GENERATION OF AUTHENTIC ATION RESYNCHRONIZATION

P AR AMETER AUTS IN AUC
RAND
SQN MS ⊕ AK
K AMF* K
f5 xor f1*
AK SQNMS XMAC-S
MAC-S = XMAC-S ?
Encryption Services
Overview Subscriber data and some signaling elements must be protected
because they are regarded as sensitive. To guarantee
confidentiality of identity, Temporary Subscriber Identity (TMSI)
must be transmitted in a protected mode during allocation and
other signaling processes. Such protection is guaranteed by
using ciphering algorithm on dedicated channel between ME and
RNS.
Ciphering Figure 104 illustrates how to use ciphering algorithm f8 to obtain
Method cipher text. “Exclusive or” of key stream and plain text obtains
cipher text, and “exclusive or” of cipher text and key obtains
plain text.
Following modules are concerned: algorithm outputs key stream
block (KEYSTREAM), used to cipher and input plain text block
(PLAINTEXT) to generate and output cipher text block
(CIPHERTEXT).

FIGURE 104 CIPHERING PROCESS
COUNT-C DIRECTION COUNT-C DIRECTION
BEARER LENGTH BEARER LENGTH
CK f8 CK f8
KEYSTREAM KEYSTREAM
BLOCK BLOCK
PLAINTEXT CIPHERTEXT PLAINTEXT

BLOCK BLOCK BLOCK
Sender Receiver
UE or RNC RNC or UE
Input COUNT-C: With a length of 32 bits, each logical RLC AM

Parameters of channel and each RLC UM channel have a COUNT-C value,
Ciphering and all logical channels in transparent RLC mode (and logical
Algorithm channels mapped to DCH) have a COUNT-C value. COUNT-C
value consists of two parts: “short” serial number and “long”
serial number.
CK: With a length of 128 bits, CK is saved in USIM, and its
backup is saved in ME. CK is sent from USIM to ME as soon
as the request of ME is received.
BEARER: With a length of five bits, each subscriber only has
one parameter BEARER, multiplexed in an independent 10-
ms physical layer frame. This parameter is used to prevent
use of the same input parameters for different key streams.
DIRECTION: With a length of one bit, this parameter is used
to prevent use of same input parameters in integrity
algorithm when uplink and downlink calculate message
authentication code. For a message from UE to RNS,
DIRECTION is set to 0, while for a message from RNS to UE,
DIRECTION is set to 1.
LENGTH: With a length of 16 bits, “LENGTH” indicator
indicates length of necessary key stream block.
Integrity Protection
Overview Most control signaling information elements transmitted between
MSs and network are regarded as sensitive data, so integrity
protection must be conducted. Message authentication function
will be applied to protect se signaling information elements
transmitted between ME and RNS.

Data Integrity Figure 105 illustrates use of integrity protection algorithm f9 to

Protection verify data integrity of signaling messages.
Method
FIGURE 105 INTEGRITY PROTECTION PROCESS
COUNT-I DIRECTION COUNT-I DIRECTION
MESSAGE FRESH MESSAGE FRESH
IK f9 IK f9
MAC -I XMAC -I
Sender Receiver
UE or RNC UE or RNC
Input parameters of algorithm include Integrity Key (IK),

integrity serial number (COUNT-I), random value (FRESH)
generated by network, direction (DIRECTION) and signaling data
(MESSAGE). Based on se input parameters, MS uses integrity
algorithm f9 to calculate message authentication code MAC-I of
data integrity. MAC-I is transmitted on radio access links
together with messages. Receiver calculates XMAC-I of message
and compares it with MAC-I sent by sender to verify integrity of
received data.
Input COUNT-I: With a length of 32 bits, each logical signaling

Parameters of channel has one COUNT-I. COUNT-I value consists of two
Integrity parts: “short” serial number and “long” serial number.
Algorithm
CK: With a length of 128 bits, IK is saved in USIM, and its
backup is saved in ME. IK is sent from USIM to ME as soon
as request of ME is received.
FRESH: FRESH on network is 32-bit long. Each subscriber
only has one FRESH parameter, which is used to protect
network from retransmission attack of subscriber signaling.
DIRECTION: With a length of one bit, this parameter is used
to prevent use of same input parameters in integrity
algorithm when uplink and downlink calculate message
authentication code. For a message from UE to RNS,
DIRECTION is set to 0, while for a message from RNS to UE,
DIRECTION is set to 1.
MESSAGE: Indicates signaling message.

TMSI Allocation/Release
Overview TMSI is used to replace IMSI for transmission on radio channels
to enhance confidentiality of subscriber identity, and its value is
determined inside VLR. Therefore, TMSI is only valid in area of
VLR, covering time information and information that can
differentiate subscriber identity. Once a new TMSI is successfully
allocated, it will be transmitted to MS in ciphering mode.
Conditions for When a subscriber updates its location, system should
TMSI encrypt ID and data of subscriber.
Allocation
RestartNum in TMSI is inconsistent with record in current
system.
Absolute difference between RunDays in TMSI and days
recorded in system is greater than a threshold M, which
means that system should allocate a new TMSI to subscriber
after M days. M is a user-defined value.
During location update, a subscriber is identified with TMSI
and Previous LAI (PLAI). Through judgment of whether PLAI
is within coverage of this system, it is decided whether to
reallocate TMSI. Result is that PLAI does not belong to the
system.
Authentication (practically, authentication is performed with
IMSI of subscriber corresponding to TMSI) with subscriber’s
TMSI fails.
Subscriber data shows that subscriber has two TMSIs at
same time because after allocating a new TMSI to subscriber,
VLR fails to receive subscriber’s acknowledgement due to
subscriber or network reasons. VLR will keep new and old
TMSIs at same time. Two TMSIs can be used next time, but
VLR will reallocate a new TMSI to subscriber.
Conditions for VLR receives acknowledgement information of subscriber for
TMSI Release new TMSI.
VLR receives a subscriber deletion command from HLR.
IMEI Check
IMEI refers to International Mobile Equipment Identity. VLR can
check IMEI during configuration of location update and access
request. In CheckIMEI response originated by VLR, it checks
whether result of IMEI is in line with expected value. VLR can
also send ObtainIMEI request.

VLR Management
The ZXWN MSCS office is embedded with the VLR NE function,
providing the VLR management function, and mainly including:
Subscriber data management. For details, please refer to
Subscriber Data Management.
Error recovery processing. For details, please refer to Error
Recovery Processing.
Subscriber Data Management

Overview When subscription information of a subscriber in HLR changes, a
synchronization message will be originated to keep subscriber
data in VLR consistent with those in HLR.
Synchronizatio There are two synchronization modes:
n Mode
1. Inserting subscriber data
2. Deleting subscriber data
These two types of messages have message retransmission
mechanism, which are described as follows:
Inserting To add or modify subscriber subscription information, HLR

Subscriber performs subscriber data insertion, and service flow is shown in
Data Figure 106.
FIGURE 106 FLOW OF INSERTING SUBSCRIBER DATA
Flow Descriptions:
1. Step 1: HLR originates subscriber data insertion request to

VLR (according to quantity of subscriber data, data can be
transmitted in one or more packets).
2. Step 2: After VLR successfully inserts subscriber data, it
returns a response.
Note: Due to restriction of SCCP layer of No.7 link, a message
packet cannot exceed a certain length. So, if too many
subscriber data are to be inserted, HLR must send subscriber

data insertion message in several times. Furthermore,

subscriber data can be divided into following groups:
Group A
Includes IMSI, MSISDN, and category and subscriber status
Group B
Includes Bearer Service list and Tele-service list
Group C
Includes supplementary service data
Group D
ODB data
Group E
Does not support features causing roaming barring
Group F
Regional subscription limit
Group G
VBS/VGCS subscription information
Group H
CAMEL subscription information
Order for sending multiple packets must be:
1. Group A must be sent in first packet.

2. Group B must be sent after Group A but before Groups C, E,
F, G and H.
3. Group D must be sent after Group A, but can be sent either
before or after Group B, C, E, F, G or H.
4. There is not specific requirement for sending order of Groups
C, E, F, G and H.
Deleting If it is necessary to delete subscriber subscription information,
Subscriber HLR deletes subscriber data. Service flow is shown in Figure 107.
Data
FIGURE 107 SERVICE FLOW OF DELETING SUBSCRIBER DATA

Flow descriptions:
1. Step 1: HLR originates a request to delete subscriber data to

VLR.
2. Step 2: After VLR successfully deletes corresponding
subscriber subscription information, it returns a response.
Error Recovery Processing

Overview The ZXWN MSCS system has the error recovery function, and is
mainly embodied by the error recovery in the case of VLR restart
and HLR restart.
VLR Restart VLR system might stop working due to faults or sudden power
failure. After restart, data in VLR must be recovered in the
following two modes:
VLR recovery operation is triggered during subscriber calling

and short message operation process, and HLR sends data of
this subscriber to VLR. Processing flow is shown in Figure
108.
FIGURE 108 VLR RESTART SERVICE FLOW
Flow descriptions:
i. Step 1: VLR sends request to HLR for data recovery
during call and short message operation processes.

ii. Step 2: If tracing of this subscriber is activated, HLR

sends a request to VLR to activate subscriber tracing.
iii. Step 3: After VLR responds, it sets subscriber as
activated and acknowledges to HLR for subscriber tracing
activation.
iv. Step 4: HLR originates a request for VLR to insert
subscriber data (according to quantity of subscriber data,
they can be transmitted in one or more packets).
v. Step 5: VLR where subscriber is currently located
responds and acknowledges to HLR for subscriber data
insertion.
vi. Step 6: HLR acknowledges data recovery request of VLR.
Recovery operation due to a subscriber’s location update is
same as that of aforementioned “IMSI attachment”.
Note: In GSM Phase 1, VLR requests subscriber data from HLR
with “Send Parameters” service.
HLR Restart After HLR restarts, it will send RESET message to all VLRs in HLR
to which subscriber roams. After VLRs receive this message,
they will add “uncertainty” flags to subscriber data belonging to
this HLR. In subsequent incoming or outgoing calls, VLR
performs location update, to re-obtain subscriber data. The flow
FIGURE 109 HLR RESTART FLOW
Mobile Call Service Function

Overview
Introduction Category
Mobile call service contains local call, outgoing call, incoming
call and tandem call.
Local calls are supported by signaling system similar to ISDN
(Call control signaling differs from that specified in Q.931 but
works in the same logic. Lower layer transmission signaling
used is different from that for ISDN), but other three are

supported by inter-office signaling that is divided into two

types: Channel Associated Signaling (CAS) and Common
Channel Signaling (CCS). CCS is applicable to signaling
transfer between SPC offices, while CAS is applicable to
communications between such repeaters as DT, ABT and SFT
and other offices. This section describes mobile call handling
part in CAS of local calls.
Call procedure description
In CS domain, original MSC NE falls into two NEs including
MSC Server and MGW, in which MSC Server NE is responsible
for call control process, and MGW is responsible for
establishment of call bearer link. MSC Server controls MGW
NE to establish bearer connection through Mc interface,
whose signaling is in conformity with standard H.248
signaling interface. Completion of a call needs switching of
multiple MSC Servers. Where, MSC Server in direct
interaction with MSs is VMSC Server. In the VMSC Server,
module that completes call function is MCC module, that is,
Mobile Call Control module.
In MSCS/VLR, multiple modules are needed to complete
whole process of a call, as shown in Figure 110.
FIGURE 110 STRUCTURE OF THE MOBILE CALL SERVICE PROCESSING

MODULE
MSCMAP
VLRMAP
CCF SSF SRF CCF
OCH ICH
CCF CCF
MTC
GMSC
F
TUP/ ISUP/ BICC
H.248
MM
OCH module conducts mobile originated call process control,

ICH module conducts mobile terminated call process control
and MM module processes mobility management process.
GMSC module is responsible for call route function, VLRMAP
is responsible for subscribers’ subscription information check

and MSRN assignment functions, MTCF completes call

forwarding control processing, and MSCMAP module is
responsible for terminated call route, SMS transmission and
inter-MSCS switching function.
TUP/ISUP/BICC modules are responsible for completion of
various inter-office signaling functions.
H.248 module is responsible for the interaction between
bearer control planes.
A call setup process contains setup process of control plane
and setup process of bear plane:
Setup process of control plane is originated by Outgoing Call
Handling (OCH), maybe passes through Gateway MSC
(GMSC) or Management of Call Forwarding (MCF), and at last
arrives at Incoming Call Handling (ICH) module or
TUP/ISUP/BICC modules. Their different combinations
construct different “call links” of a call, and these entities
form a “control plane”.
MGW NE is responsible for bearer establishment,
maintenance and coordination on bearer plane and MSCS
controls the MGW via standard H.248 signaling. A bearer is a
channel responsible for subscriber data transmission, and
whose establishment is controlled by control plane. In 3GPP
R4 stage, bearer may be TDM, ATM or IP. But these different
bearer attributes correspond to the same control panel. This
is an advantage of bearer control separation, and control
plane or bear plane can be evolved separately.
Following sections describe multiple types of service flows in
details.
Topics Page No.

Radio Channel Assignment Flow of the Basic Call of the 152
UE
Radio Channel Assignment Flow of the UE Terminated 155
Call
Originated-Call Flow 157
Terminated-Call Flow 162
Call Release Flow 173
Radio Channel Assignment Flow of

the Basic Call of the UE
Network The network structure of the UE originated call is shown in
Structure Figure 111.

FIGURE 111 NETWORK STRUCTURE OF THE UE ORIGINATED CALL
Radio I / IAM
F Interface Iu Interface
UE RNC VMSCS
Complete Call
SIFOC
VLR
VPLMN
Involved NEs The call originated by the UE involves the following NEs: UE,
RNC, VMSCS, VLR and the target switch.
Signaling Flow The basic signaling flow is shown in Figure 112.
FIGURE 112 SIGNALING FLOW OF THE UE ORIGINATED CALL
The flow is described as follows:

1. When the UE originates a call, its CM sub-layer sends a
CM_Service_Req (Connection Management service request)

message to the MM sub-layer, requesting the MM to establish

a signaling connection. The UE sends a Channel Request
message to the RNC of the network side, and the RNC
returns an Immediate Assignment message. After the Radio
Resource (RR) connection is established, the MM sends the
CM_Service_Req to the network through the RR connection.
2. The RNC transparently transfers the CM_Service_Req
message to the VMSC.
3. The VMSC sends a Process Access Request message to the
VLR.
4. The VLR authenticates the UE. The VLR sends an
Authenticate message to the MSCS, and the MSCS and the
RNC transparently transfer this message. The UE returns an
Authentication Response and the MSCS relays an
Authentication Ack to the VLR. The VLR considers that the
call originated by the UE is legal, and will send a Process
Access Response message to the VMSC. The VMSC sends a
CM Service Accept message to the RNC, and the RNC
transparently transfers this message to the UE.
5. If security control is required, the MSCS/VLR requests the
RNC to perform security control on the air channel of the UE.
The RNC sends a security control command to the UE. After
starting the security procedure, the UE sends a security
procedure response message to the RNC. The RNC sends a
security procedure complete message to the MSCS/VLR.
6. UE receives a CM Service Accept message or the security
procedure has succeeded. The CC sub-layer of the UE will
send a Setup message to the CC sub-layer of the MSCS,
containing the address of the callee and bearer capability
indication required by this call. The RNC does not process
messages on the CM layer, and just transparently transfers
them.
7. The VMSC derives a basic service type from the bearer
capability parameters of the SETUP message, and decides
whether the IWF resource is required.
8. The VMSC sends a SIFOC message to the VLR to perform call
restriction, subscription services, CUG check and outgoing
call requests.
9. If the VLR judges that the UE can originate this call according
to its subscription information, it will send a Complete Call
message to the VMSC; otherwise, it will send a denial
response SIFOC to the VMSC to reject the call setup.
10. The VMSC sends a Call Processing message to the UE,
indicating that the call request has been accepted.
11. According to the bearer capability parameters, the VMSC
sends a RAB Assignment Request message to the RNC to
start the RAB establishment procedure.
12. After receiving the RAB Assignment Request message, the
RNC assigns the corresponding channel to the UE to initiate

the connection establishment between the UE and the RNC.

After the channel assignment is completed, the RNC sends a
RAB Assignment Response message to the VMSC.
13. After receiving the RAB Assignment Response message, the
VMSC performs number analysis on the called address
information in the SETUP message. The VMSC selects a trunk
route to the callee to send the IAM signaling to the opposite-
end switch.
Radio Channel Assignment Flow of

the UE Terminated Call
Network The network structure of the UE terminated call is shown in
Structure Figure 113.
FIGURE 113 NETWORK STRUCTURE OF THE UE TERMINATED CALL
IAM IAM Setup

GMSCS VMSCS RNC UE
SIFIC
SRI/Ack Call Arrived
PRN/Ack
Signaling Flow When the mobile subscriber acts as a callee, the network will
first page the UE at the radio interface. If the VPLMN supports
the Gs interface, that is, the UE establishes the relationship
between the VLR and the SGSN, the paging message will be
preferably sent out from the packet domain. The basic signaling
flow is shown in Figure 116.

FIGURE 114 SIGNALING FLOW OF THE UE TERMINATED CALL WITH THE

P AGING PROCEDURE
GMSCS HLR VMSCS/VLR RNC UE
IAM
SRI PRN
SRI_Ack PRN_Ack
IAM
Paging Paging
Channel _Request
Immediately Assign
Paging Response Paging Response
Authenticate Authenticate
Authenticate_Rsp Authenticate_Rsp
Start Security
Procedure Security Control
Command
Security Procedure Security Control
Complete Response
Setup
Call Confirmed
RAB_Assignment_Req
Assignment Cmd
Assignment Complete
RAB_Assignment_Rsp
Alerting

1. After receiving the IAM message, the GMSC obtains the
number of the called UE. After deriving the home HLR of the
UE from its MSISDN, the GMSC sends a Send Routing
Information (SRI) message to the HLR.
2. After receiving the SRI message, the HLR obtains the
MSISDN of the UE. After searching for the subscriber records
according to the MSISDN, the HLR obtains the number of the
VLR where the UE is currently located. Therefore, the HLR
sends a Provide Roaming Number (PRN) message to the VLR.
3. After receiving the PRN message, the VLR allocate a roaming
number. The VLR sends a PRN_Ack message to the HLR. The
HLR sends a SRI_Ack message to the GMSCS, containing the
roaming number of the callee.
4. After receiving the SRI Ack message, the GMSC analyzes the
roaming number, searches for a trunk to the VMSCB
according to the analysis result, and then sends an IAM
message to the VMSC.
5. After receiving the IAM message, the VMSC sends a SIFIC
message to the VLR to request for authenticating the
incoming call, containing the roaming number. The VLR
searches for the subscriber records of the called UE
according to the roaming number, and judges whether this

call is allowed to be admitted according to the subscriber

information of the called UE. If the call is allowed to be
admitted, the VLR will send a Call arrived message to the
MSCS. The VLR will send a Paging message to the VMSC,
requesting the VMSC to page the UE.
6. If the radio channel between the network and the UE has
been established, the VMSC will immediately respond to the
call request message. If the radio channel is not established,
the VMSC will send a paging request message to the RNC,
and the RNC will broadcast the paging message on the
paging channel. If there is a Gs interface between the VMSC
and the SGSN, the paging will be initiated though the SGSN.
7. Under the common condition, the UE in idle status is
monitoring the paging channel all the time. After receiving its
own paging message, the UE sends a Channel Request
message to the network.
8. The RNC immediately assigns a channel and establishes the
signaling connection for the UE.
9. After receiving an Immediately Assign message, the UE
sends a Paging Response message to the network through
the signaling connection.
10. After receiving the Paging Response message, the RNC
establishes the signaling connection between the RNC and
the MSC, and transfers the Paging Response message to the
VMSC.
11. Then the VLR can perform authentication procedure or the
security procedure (Note: The authentication procedure and
the security procedure can be performed at the same time to
shorten the call setup duration).
12. After receiving a call complete message, the VMSC sends a
Setup message to the UE, containing the bearer capability
required for the call. (If the caller originates the call from the
PSTN, the bearer capability parameters may not be obtained.
In this way, the SETUP message will not carry the bearer
capability parameters).
13. After receiving the Setup message, the UE performs
necessary service checks and judges whether the subscriber
has the right to admit this service. If the checks are passed,
the UE will send a Call confirmed message to the network.
14. After receiving the Call confirmed message, the VMSC will
start the channel assignment procedure, which is similar to
that of the UE originated call flow.
Originated-Call Flow
Network Model Figure 115 shows the network model of mobile originated call, in
which call control signaling is represented by solid line, and

bearer control signaling is represented by broken line (there is

no bearer control signaling on A interface). MSC Server controls
contexts of two bearer terminals in MGW, in which bearer
terminal T1 is oriented to bearer of RNC/BSC, and bearer
terminal T2 is oriented to bearer in next MGW.
FIGURE 115 NETWORK MODEL OF ORIGINATED CALL
MSCS
T1 T2
RNC/BSC CTX1
MGW A
Category Based on the establishment mode of inter-office bearer, there

are two kinds of call time sequences: One is forward bearer
establishment, and other is backward bearer establishment.
Forward Bearer Originated call time sequence of forward bearer establishment

Establishment mode is shown in Figure 116 and Figure 117.

FIGURE 116 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE OF FORWARD

BEARER ESTABLISHMENT
UE RNC/ BSC MSCS MGW
SETUP
CALL PROCEEDING Step1

Initial Address
Bearer Information
Context($) ADD.request ($) Step2

Establish Bearer +
Context (C1) ADD. reply(T2) ChangeThrough - Connection
Bearer
Establishment
UMTS :
Context(C 1) ADD. request ($)
Prepare Bearer +
Context (C1) ADD. reply(T1)
Change Through - Connection Step3
RAB ASSIGNMENT REQ
Bearer Establishment and Iu UP

Initialization UP Init
RAB ASSIGNMENT COMPL
UP Init Ack
GSM:
Context (C1) ADD. request(T1)

Reserve Circuit + Step4
Context (C1) ADD. reply (T1) Change Through - Connection
ASSIGNMENT REQUEST
ASSIGNMENT COMPL
Continuity Step5
FIGURE 117 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE OF FORWARD

BEARER ESTABLISHMENT (CONTINUED)
UE RNC / BSC MSCS MGW
Address Complete
ALERTING
Answer
Change Through- Connection+

Context (C1) MOD. request(T1) Activate Inter - Working
Function(when applicable) +
Context (C1) MOD. reply(T1) Activate Voice Processing Step6
Function (when applicable)
Context(C1) MOD. request(T2)
Activate Inter- Working
Context(C1) Function (when applicable) +
MOD. reply(T2)
Activate Voice Processing
Function ( when applicable )
CONNECT
Description of the process:
1. Step 1
In case a subscriber originates a call and inputs the number
of a called subscriber on MS, presses “send” function key,
then MS will start to call. MS first applies for a control
channel, and establishes an MM connection with MSC Server
to complete necessary subscriber access works, including

authentication and encryption. After works finish, MS sends a

piece of “Setup” message with number of called subscriber
and bearer attribute to MSC Server. Once MSC Server
receives “Setup” message, it conducts necessary service
check to judge whether subscriber has authority to originate
service. If the check is passed, MSC Server sends back a
piece of “CallProceeding” message to MS, notifying MS that
call is processing. Because forward bearer establishment will
combine IAM message at the same time to forward to next
node, forward bearer establishment as mode of this
establishment is indicated in this piece of IAM message. If
access-side bearer establishment is not finished, “Continuity”
will be indicated in this piece of IAM message.
2. Step 2
After receiving “Bearer Information” message, including
bearer address, binding reference and bearer attribute of
incoming office bearer terminal applied by next node, sent by
next node, MSC Server sends ADD command to MGW based
on messages, requiring to establish outgoing-side bearer
terminal. Because it is forward bearer establishment,
“Establish Bearer” process is contained. Newly established T2
bearer terminal will demand incoming office bearer terminal
of the next node to establish a bear connection. “Change
Through-Connection” process indicates external continuity
attribute of newly established bearer terminal is bidirectional.
3. Step 3
RNC accesses wireless-side bearer establishment. Because
wireless-side mode is irrelative to network-side bearer
establishment mode, it is established by RNC for MSCS.
Thereafter, MSC Server starts RAB establishment process:
First apply to MGW for a terminal T1 through “PrepareBear”
process, and once application is approved, MSC Server
obtains MGW address and BNCID parameter corresponding
to T1, and converts bearer service parameter to relative RAB
parameter. Then, server sends address and parameter to
RNC over RAB assignment request, and based on the
received MGW address and BNCID, RNC can originate bearer
establishment process with MGW. After bearer establishment
finishes, IuUP initialization process begins. Once initialization
finishes, RNC sends RAB assignment completion message to
MSC Server, then RAB assignment finishes.
4. Step 4
BSC accesses wireless bearer establishment. Call accessed
by BSC occupies terrestrial circuit by adopting reserve circuit,
and if successful, originates the assignment process with BSC.
5. Step 5
Send continuity message to backward office, indicating
forward bearer establishment is successful.
6. Step 6

Once a call reaches called party, this party is ringed, and

switch of this party sends “Address Complete” message to
MSC Server, and then MSC Server sends “ALERTING MS”
message to MS, and MS will ring. After the called party hooks
off, switch of called party sends back “Answer" message to
calling party, and upon receiving message, MSC Server will
demand MGW to connect with T1 and T2 through
“ChangeThrough –Connection” process, to optionally
originate “Activate IWF” process (data service) and “Activate
VoiceProcessingFunction” (such as echo suppression
function). After all processes finish, MSC Server sends
“CONNECT” message to MS, and calling party starts to talk.
Backward Bearer Originated call time sequence of backward bearer establishment
FIGURE 118 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE OF

BACKWARD BEARER ESTABLISHMENT
RN MS
UE RNC/BSC MSCS MGW
E C C W
SETUP
CALL PROCEEDING
UMTS:
Context (C$) ADD.request ($)

Prepare Bearer +
Context (C1) ADD.reply (T1)
Change Through- Connection Step1
RAB ASSIGNMENT REQ
Bearer Establishment and Iu UP

Initialization
GSM:
Context (C$) ADD.request (T1)

Reserve Circuit +
Context (C1) ADD.reply (T1) Change Through- Connection
Step2
ASSIGNMENT REQUEST
ASSIGNMENT COMPL
Context (C1) ADD.request ($)

Prepare
Context (C1) ADD.reply (T2) Bearer
Initial Address
Step3
Bearer Establishment
UP Init
UP Init Ack

FIGURE 119 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE OF

BACKWARD BEARER ESTABLISHMENT (CONTINUED)
UE RNC/BSC MSCS MGW

E C C W
Address Complete
ALERTING
Answer
Context (C1) MOD.request (T1) Change Through-Connection +

Step3
Activate Inter-Working Function
Context (C1) MOD.reply (T1) (when applicable) + Activate
Voice
Processing Function (when
applicable)
Context (C1) MOD.request (T2)
Activate Inter-Working
Function (when applicable) +
Context (C1) MOD.reply (T2)
Activate Voice Processing
CONNECT
1. Step 1
In case a subscriber originates a call, inputs the number of a
called subscriber on his (her) MS, and presses “send”
function key, then MS will start to call. MS first applies for a
control channel, and establishes an MM connection with MSC
Server to complete necessary subscriber access works,
including authentication and encryption. After works finish,
MS sends a “Setup” message with number of called
subscriber and bearer attribute to MSC Server. Once MSC
Server receives “Setup” message, it conducts necessary
service check to judge whether subscriber has authority to
originate service. If the check is passed, MS is sent back a
piece of “CallProceeding” message, notifying that call is
processing. Because it is backward bearer establishment
mode, RAB assignment process starts before IAM is sent to
backward office.
2. Step 2
If a subscriber accesses BSC, circuit assignment process will
be conducted.
3. Step 3
After completing RAB assignment, apply for a network-side
bearer T2 with MGW through PrepareBear process.
“InitialAddress” message carries MGW-ID, MGW address and
BNC ID corresponding to T2 to backward office. Other
aspects are the same with forward establishment mode.
Terminated-Call Flow
Overview When MSC Server/VLR receives a call request from another
office, that is, when called subscriber is subscriber of this MSC
Server/VLR, MSC Server/VLR will start setup of the call with MS

as called party. In this case, MSC Server/VLR has assigned an

MSRN to this call, which is the called number in IAM. MSRN has
been set in original called number in IAM.
Network Model Figure 120 shows the network model of mobile terminated call,
in which call control signaling is represented by solid line, and
bearer control signaling is represented by broken line. MSC
Server controls contexts of two bearer terminals in MGW B, in
which bearer terminal T1 is oriented to bearer of RNC/BSC, and
bearer terminal T2 is oriented to bearer in the MGW A selected
by GMSC Server. GMSC Server controls contexts of two bearer
terminals in MGW A, in which bearer terminal T3 is oriented to
bearer in MGW B selected by MSC Server, and bearer terminal
T4 is oriented to bearer in the previous MGW.
FIGURE 120 NETWORK MODEL OF TERMINATED CALL
GMSCS MSCS
T4 T3 T2 T1
CTX2 CTX1 RNC/BSC

MGW A MGW B
Category Based on the establishment mode of inter-office bearer, there

are two kinds of call time sequences: One is forward bearer
establishment, and the other is backward bearer establishment.
Forward Bearer Terminated call time sequence of forward bearer establishment

FIGURE 121 TERMINATED CALL SETUP TIME SEQUENCE IN CASE OF

FORWARD BEARER ESTABLISHMENT


FORWARD BEARER ESTABLISHMENT (CONTINUED)
GMSCS MGW A MSCS MGW B RNC /BSC UE
UMTS:

Prepare Bearer +
Context (C1) ADD.reply ( T1)
Change Through - Connection
RAB ASSIGNMENT REQ Step8
Bearer
Establish.
and Iu UP
Initializa.
GSM:
Context (C1) ADD.request (T1)

Reserve Circuit +
Change Through -Connection Step9
ASSIGNMENT REQUEST
ASSIGNMENT COMPL
ALERTING
Address Complete
Send Tone (start providing a
Address Complete Context (C1) MOD.request ( T2)
Step10
ringing tone for a speech call)
CONNECT
Context (C1)
MOD.request ( T1) Change Through- Connection + Activate
Inter- Working Function (when
Context (C1) MOD.reply (T1) applicable) + Activate Voice Processing
Context (C1) MOD.request ( T2)Stop Tone (stop providing a ringing tone Step11
for speech call) + Activate Interworking
Function (when applicable) + Activate
Answer Voice Processing Function (when
applicable)
Context (C2) MOD.request ( T3) Activate Voice Processing Function
13 (when applicable)
Context (C2) MOD.request ( T4) Activate Voice Processing Function Step12

(when applicable)
Answer

1. Step 1
After GMSC Server receives IAM message from the previous
node, it requests route information of called subscriber from
HLR. HLR requests roaming number from VLR, and after HLR
obtains roaming number from called subscriber, it returns
route information of called subscriber to GMSC Server. GMSC
Server can select an MGW at that time or after receiving
Bearer Information. IAM message is forwarded to MSC
Server, indicating forward bearer establishment is current
bearer establishment mode.
2. Step 2
MSCS Server/VLR receives IAM message and then sends a
paging message to called party. If there is radio channel
between the network and called party, called party will
directly return a paging response. If there is no radio channel,
UE will send a channel request message to RNS, and return
paging response message after RNS assigns channel. MSC
Server/VLR authenticates UE. If encryption is required, MSC
Server/VLR requests RNS to encipher air channel of this
subscriber. RNS sends an encryption command to UE. After
starting encryption mode, UE sends an encryption completion
message to RNS, and then RNS sends an acknowledgement
message to MSC/VLR. MSC/VLR sends a SETUP message to
UE and then UE returns a CALL CONFIRMED (call
confirmation) message, indicating that UE is ready.
3. Step 3
After receiving CALL CONFIRMED message of UE, MSC
Server/VLR starts to set up incoming office-side bearer
terminal, and selects MGW B, and then sends ADD command
to MGW B. Because it is forward bearer establishment mode,
“Prepare Bearer” process is contained. “Change Through-
Connection” process indicates external continuity attribute of
newly established bearer terminal is bidirectional. After MGW
B sets up incoming office-side bearer terminal T2 of MSC
Server, it returns a successful message to MSC Server.
4. Step 4
MSC Server transfers bearer address, binding reference and
bearer attribute of T2 bearer terminal to GMSC Server
through “Bearer Information”. If original GMSC Server does
not select MGW, MGW can be selected now. GMSC Server
sends ADD command to MGW A, including “Establish Bearer”
process with bearer attribute of peer end in “Bearer
Information”. “Change Through-Connection” process
indicates external continuity attribute of newly established
bearer terminal is bidirectional. T3 bearer terminal in the
MGW A initiatively requests to set up bearer connection with
the T2 bearer terminal in the MGW B.
5. Step 5

GMSC Server starts to conduct incoming-side bearer

establishment process. Because it is forward bearer
establishment mode, GMSC Server sends ADD command to
MGW A with “Prepare Bearer” process. “Change Through-
newly established bearer terminal is bidirectional. After
setting up incoming-side bearer terminal T4 of GMSC Server,
MGW A returns a successful message to GMSC Server with
bearer address, binding reference and optional bearer
attribute of T4 terminal. GMSC Server informs bearer
attribute of T4 to previous node through “Bearer
Information”.
6. Step 6
Previous node of GMSC Server applies for its own outgoing-
side terminal, which initiatively requests to set up bearer
connection with T4 bearer terminal in MGW A, and transfers
initialization information of user plane to T4 bearer terminal.
At that time, if user plane related to T4 bearer terminal
returns successful response on the initialization of user plane,
MGW A deems that bearer connection is set up successfully,
and it will send a notification to GMSC Server. In addition, it
continuously sends the initialization information of user plane
to T2 bearer terminal in MGW B. At that time if user plane
related to T2 bearer terminal returns a successful message of
user plane, and MGW B deems that bearer connection is set
up successfully, and sends a notification to MSC Server.
7. Step 7
After GMSC Server receives notification of successfully
setting up incoming office-side bearer connection and
receives “Continuity” message sent by previous node, it
forwards “Continuity” message to MSC Server, and then MSC
Server deems that network-side bearer connection is set up
successfully. If it is 3G subscriber that accesses, transfer to
Step 8; if 2G subscriber, transfer to Step 9.
8. Step 8
MSCS Server starts to conduct the access-side bearer
connection establishment. MSCS Server sends ADD
command to MGW B, including “Prepare Bearer” process.
“Change Through-Connection” process indicates external
continuity attribute of newly established bearer terminal is
bidirectional. After completing the access-side bearer
terminal establishment, MGW B sends a successful message
to MSC Server. MSC Server starts RAB assignment process.
After RNC confirms that bearer connection is set up and
initialization process of user plane is completed, it sends a
message of successfully assigning RAB to MSC Server. Then,
skip to Step 10.
9. Step 9
MSCS Server starts to conduct the access-side bearer
connection establishment. MSCS Server sends ADD

command to MGW B, including “Reserve Circuit” process.

“Change Through-Connection” process indicates external
continuity attribute of the newly established bearer terminal
is bidirectional. After completing the access-side bearer
terminal establishment, MGW B sends a successful message
to MSC Server. MSCS Server starts to conduct the access
channel setup process, and RNC returns response of
successfully setting up access channel. Then, skip to Step 10.
10. Step 10
UE plays ring-back tone to subscriber, and sends “Alerting”
message to MSC Server. MSCS Server forwards ACM
message to GMSC Server, and starts to play ring-back tone
to calling subscriber. That is, MSC Server sends Modify
command to MGW B, including “Send Tone” process, and
informs T2 terminal to play ring-back tone.
11. Step 11
After the called subscriber answers, UE sends “Connect”
message to MSC Server. It sends “Modify” command to MGW
B to request to modify attribute of the access terminal. For
example, “Change Through-Connection” process requests to
modify external continuity attribute of access terminal to
bidirectional, or optional “Activate Interworking Function”
process requests access terminal to activate gateway
function, or optional “Active Voice Processing Function”
requests to activate language processing function. Send
another “Modify” command to MGW B to request to modify
attribute of incoming office-side terminal. For example, “Stop
Tone” process requests to stop playing tone to calling
subscriber, or optional “Activate Interworking Function”
requests to activate language processing function. After
completing above terminal modification processes, MSCS
Server forwards “Answer” message to GMSC Server.
12. Step 12
Once GMSC Server receives “Answer” message, it will modify
two terminals, corresponding to both “Modify” messages in
context it manages if language processing function needs to
be activated. Otherwise, it directly forwards “Answer”
message to previous node.
Backward Bearer Terminated call time sequence of backward bearer
Establishment establishment mode is shown in Figure 123 and Figure 124.


BACKWARD BEARER ESTABLISHMENT
GMSCS MGW A MSCS MGW B RNC/BSC UE
Initial Address + Bearer Information
HLR Interrogation
Step1
Context ($) ADD.request ($)
Context (C2) ADD.reply (T4) Establish Bearer +
Change Through- Connection
UP Init
UP Init Ack
Step2
Context (C2) NOTIFY.request( T4)
Bearer Established
Context (C2) NOTIFY.reply (T4)

Prepare Bearer + Step3
Change Through- Connection
Initial Address
Step4
Paging + Security
SETUP
Step5
CALL
CONFIRMED
Context ($) ADD.request ($)
Establish Bearer +
Context (C1) ADD.reply ( T2)Change Through- Connection Step6
UP Init
UP Init Ack
Context (C1) NOTIFY.request( T2) Step7
Bearer Established
Context (C1) NOTIFY.reply (T2)


BACKWARD BEARER ESTABLISHMENT (CONTINUED)
GMSCS MGW A MSCS MGW B RNC/BSC UE
UMTS:

Prepare Bearer +
RAB ASSIGNMENT REQ Step8
Bearer
Establish.
and Iu UP
Initializa.
GSM:
Context (C1) ADD.request (T1)

Reserve Circuit +
Step9
ASSIGNMENT REQUEST
ASSIGNMENT COMPL
ALERTING
Address Complete
Address Complete
Context (C1) MOD.request ( T2) Step10
Send Tone (start providing a
Context (C1) MOD.reply (T2) ringing tone for a speech call)
CONNECT
Context (C1) MOD.request ( T1)
Change Through- Connection + Activate
Context (C1) MOD.reply (T1) Interworking Function (when applicable)
+ Activate Voice Processing Function
Context (C1) MOD.request (T2) (when applicable) Step11
Stop Tone (stop providing a ringing
Context (C1) MOD.reply (T2) tone for speech call) + Activate
Interworking Function (when
Answer applicable) + Activate Voice
Processing Function (when applicable)
Activate Voice Processing Function
Context (C2) MOD.reply (T3) (when applicable)
Activate Voice Processing Function

(when applicable) Step12
Answer
Process is described as follows:

1. Step 1
After GMSC Server receives IAM message sent from previous
node, it will request route information of called subscriber
from HLR. HLR requests roaming number from VLR, and
after HLR obtains roaming number from called subscriber, it
returns route information of called subscriber to GMSC
Server. GMSC Server selects MGW A and applies for
incoming office-side bearer terminal with MGW A. Because it
is backward bearer establishment, “Establish Bearer” process
is contained in ADD command, where also contains bearer
address, binding reference and bearer attribute provided by
previous node and contained in IAM message. “Change
Through-Connection” process requests the external
continuity attribute of the bearer terminal newly established
by the MGW A is bidirectional. After setting up incoming

office-side bearer terminal T4, MGW A returns a successful

message to the GMSC Server.
2. Step 2
T4 in MGW A initiatively requests bearer terminal in the
previous MGW to establish bearer. After initialization process
of user plane finishes that is bearer connection is set up,
MGW A sends a notification to GMSC Server.
3. Step 3
After GMSC Server successfully establishes incoming bearer,
it starts to set up outgoing office-side bearer terminal.
Because it is backward bearer establishment, “Prepare
Bearer” process is contained in ADD command. “Change
Through-Connection” process requests external continuity
attribute of bearer terminal newly established by MGW A is
bidirectional. After setting up incoming-side bearer terminal
T3, MGW A returns a successful message to GMSC Server
with the bearer address, binding reference and optional
bearer attribute of the T3 terminal.
4. Step 4
After GMSC Server applies for outgoing office bearer terminal
T3, it combines a new IAM, including bearer address, binding
reference and bearer attribute of outgoing office bearer
terminal of GMSC Server, to be sent to MSC Server/VLR,
where indicating bearer establishment mode of current call is
backward bearer establishment.
5. Step 5
MSCS Server/VLR receives IAM message and then sends a
paging message to called party. If there is radio channel
between the network and called party, called party will
directly return a paging response. If there is no radio channel,
UE will send a channel request message to RNS, and return
paging response message after RNS assigns channel. MSC
Server/VLR authenticates UE. If encryption is required, MSC
Server/VLR requests RNS to encipher air channel of this
subscriber. RNS sends an encryption command to MS. After
starting encryption mode, MS sends an encryption
completion message to RNS, and then RNS sends an
acknowledgement message to Server/VLR. MSC/VLR sends a
SETUP message to UE and then UE returns a CALL
CONFIRMED (call confirmation) message, indicating that UE
is ready.
6. Step 6
After receiving CALL CONFIRMED message of UE, MSCS
Server/VLR starts to set up incoming office-side bearer link,
and selects MGW B, and then sends ADD command to MGW
B. Because it is forward bearer establishment, “Establish
Bearer” process is contained with bearer address, binding
reference and bearer attribute of outgoing office-side bearer
terminal of GMSC Server. “Change Through-Connection”

process indicates external continuity attribute of newly

established bearer terminal is bidirectional. After MGW B sets
up incoming office-side bearer terminal T2 of MSC Server, it
returns a successful message to MSC Server.
7. Step 7
T2 in MGW B initiatively requests T3 bearer terminal in MGW
A to establish bearer. After the initialization process of user
plane finishes that is bearer connection is set up, MGW B
sends a notification to GMSC Server. If it is 3G subscriber
that accesses, transfer to Step 8; if 2G subscriber, transfer
to Step 9.
8. Step 8
After MSC Server completes incoming office-side bearer
connection setup, it starts to conduct the access-side bearer
connection setup. MSC Server sends ADD command to MGW
B, including “Prepare Bearer” process. “Change Through-
newly established bearer terminal is bidirectional. After
completing the access-side bearer terminal establishment,
MGW B sends a successful message to MSC Server. MSC
Server starts RAB assignment process. After RNC confirms
that bearer connection is set up and initialization process of
user plane is completed, it sends a message of successfully
assigning RAB to MSC Server. Then, skip to Step 10.
9. Step 9
After MSCS Server completes incoming office-side bearer
connection setup, it starts to conduct the access-side bearer
connection setup. MSCS Server sends ADD command to
MGW B, including “Reserve Circuit” process. “Change
Through-Connection” process indicates external continuity
attribute of newly established bearer terminal is bidirectional.
After completing access-side bearer terminal establishment,
MGW B sends a successful message to MSC Server. MSCS
Server starts to conduct the access channel setup process,
and RNC returns response of successfully setting up access
channel. Then, skip to Step 10.
10. Step 10
UE plays ring-back tone to subscriber, and sends “Alerting”
message to MSC Server. MSCS Server forwards ACM
message to GMSC Server, and starts to play ring-back tone
to calling subscriber. That is, MSC Server sends “Modify”
command to MGW B, including “Send Tone” process, and
informs T2 terminal to play ring-back tone.
11. Step 11
After called subscriber answers, UE sends “Connect”
message to MSC Server. It sends “Modify” command to MGW
B to request to modify attribute of the access terminal. For
example, “Change Through-Connection” process requests to
modify external continuity attribute of the access terminal to

bidirectional, or optional “Activate Interworking Function”

process requests the access terminal to activate gateway
requests to activate language processing function. Send
another “Modify” command to MGW B to request to modify
attribute of incoming office-side terminal. For example, “Stop
Tone” process requests to stop playing tone to calling
subscriber, or optional “Activate Interworking Function”
requests to activate language processing function. After
completing above terminal modification processes, MSC
Server forwards “Answer” message to GMSC Server.
12. Step 12
Once GMSC Server receives “Answer” message, it will modify
two terminals, corresponding to both “Modify” messages in
context it manages if language processing function needs to
be activated. Otherwise, it directly forwards “Answer”
message to the previous node.
Call Release Flow

Overview For efficient usage of radio frequency resources, non-compelled
mode is employed in mobile communication system. MS or its
peer party hooks on to start call release flow. Flow shows no
difference for calling on-hook or called on-hook. The following
gives flow description for MS on-hook and network-side on-hook.
MS On-hook MS on-hook flow is shown in Figure 125.

Flow

FIGURE 125 MS ON-HOOK FLOW
UE RNC/BSC MSCS MGW
DISCONNECT
Release
REL
Step1
RLC
UMTS:
IU RELEASE CMD
Bearer Release
IU RELEASE COMPLETE
Context (C1 ) SUB.request (T1)

Release
Context(C1) SUB.reply (T1) Termination
GSM:
CLEAR COMMAND
CLEAR COMPLETE
Step2-3
Context (C1 ) SUB.request (T1)
Release
Release Complete

Release Bearer +
Context (C1) MOD.reply (T2) Change Through- Connection
SUB.request
Context (C1)
(T2)
Release Termination
Context (C1) SUB.reply (T2)
Bearer Release
1. Step 1
UE hooks on during a call and sends a DISCONNECT
message to MSCS. MSCS sends a RELEASE message to UE,
and UE returns a release completion message to MSCS.
2. Step 2
If UE obtains access from RNC, network-side bearer and Iu
connection are released.
3. Step 3
If UE obtains access from BSC, network-side bearer and A
interface connection are released.
On-hook Flow Network-side on-hook flow is shown in Figure 126.
on the
Network Side

FIGURE 126 NETWORK-SIDE ON-HOOK FLOW
UE RNC/BSC MSCS MGW
Release
DISCONNECT

Release Bearer +
Context (C1) MOD.reply (T2) Change Through - Connection
Context (C1) SUB.request (T2)

Step1
Release Termination
Context (C1 ) SUB.reply (T2)
Release Complete
REL
Bearer Release
RLC
UMTS:
IU RELEASE CMD
Bearer Release
Step2
IU RELEASE COMPLETE

Release
GSM:
CLEAR COMMAND
CLEAR COMPLETE Step3

Release
Flow is described as follows:
1. Step 1
Called UE hooks on and sends a Release message to MSCS.
Upon receipt of message, MSCS sends a DISCONNECT
message to UE, indicating called hooks on. Meanwhile,
network-side bearer and terminal connection are released
through ReleaseBear and ReleaseTermination processes. UE
sends a release message to MSCS. Upon successful release
of resources, MSCS returns a release complete message to
UE.
2. Step 2
If UE obtains access from RNC, radio-side bearer and Iu
connection are released upon receipt of release complete.
3. Step 3
If UE obtains access from BSC, terrestrial circuit and A
interface connection are released upon receipt of release
complete.

Supplementary Services
Overview
Introduction Supplementary services are supplements and modifications to
basic services. Main function of them is to allow subscribers to
modify incoming/outgoing call processing by network according
to their own requirements, or to provide subscribers with some
kind of information via network, so that subscribers can make
use of some conventional services on an intelligent basis.
Category CS-related supplementary services in UMTS digital mobile
communications system contain 21 types of 9 categories, as
shown in Table 15.
TABLE 15 UMTS SUPPLEMENTARY SERVICES
No. Category Type Abbreviation

Calling line identification
1 CLIP
presentation
Calling line identification
2 CLIR
restriction
Number
identification Connected line
3 identification COLP
presentation
Connected line
4 COLR
identification restriction
Call forwarding
5 CFU
unconditional
6 Call forwarding on busy CFB
Call
Forwarding Call Forwarding on No
7 CFNRy
Reply
Call forwarding on mobile
8 CFNRc
subscriber not reachable
9 Call Call waiting CW
10 completion HOLD HOLD
Multiparty
11 Multiparty Service MPTY
Service
Closed user
12 Closed user group CUG
group
Advice of charge
13 AOCI
Advice of (information)
charge Advice of charge
14 AOCC
(charging)
Barring of All Outgoing
15 Call barring BAOC
Calls

No. Category Type Abbreviation

Barring of Outgoing
16 BOIC
International Calls
Barring of Outgoing
International Calls except
17 BOIC-Exhc
those directed to the
home PLMN
Barring of All Incoming
18 BAIC
Calls
Barring of Incoming Calls
19 when Roaming outside BIC-Roam
the home PLMN country
Explicit call
20 Explicit call transfer ECT
transfer
Call
21 Call deflection CD
deflection
Functional In MSCS, functional blocks involving supplementary services fall

blocks into two major categories. The first category refers to basic
operations of supplementary services such as provision and
register. The second category refers to supplementary and
modification functions to basic services by supplementary
services, including such functions as call-relevant supplementary
services, call-irrelevant supplementary services, and password
management.
Topics Page No.

Basic Operations 177
Supplementary Services Processing 182
Basic Operations
Overview Basic operations of supplementary services are mainly classified
into eight categories: “provision”, “withdrawal”, “register”,
“erase”, “activation”, “deactivation”, “Interrogate” and “invoke”.
In addition, password management flow is involved.
Provision Mobile subscriber subscribes with service provider (operator) to
provision of supplementary services, which must precede service
registration.
Withdrawal A supplementary service will be withdrawn either according to
subscriber’s application or by operator. After withdrawal,
operator no longer provides this supplementary service to
subscriber.

Both provision and withdrawal are completed through Agent

console. Use of all supplementary services is allowed only after
provision is completed.
Register Subscriber registers data related to supplementary services at

MSCS/VLR and HLR.
“Register” operation is applicable to call forwarding services,

involving the following cases:
1. CFU: registration request covers supplementary service code

(indicating CFU) and forwarding number.
2. Registration operation of CFB and CFNRc is same as that of
CFU, except that supplementary service code is CFB.
3. CFNRy, register request carries no reply timer time besides
supplementary service code and forwarding number.
Registration operation can be completed on Agent console or
originated by an MS. Service flow of latter is shown in Figure
127.
FIGURE 127 “REGISTER” OPERATION FLOW
1. Step A
“Register” operation of supplementary services is originated
by MS to MSCS/VLR. MSCS/VLR sends a “register” operation
request MAP_REGISRER_SS_ind to HLR.
2. Step B
After successful registration, HLR returns a response
message MAP_REGISRER_SS_rsp to MSCS/VLR.
Erase To erase data related to supplementary services registered on
MSCS/VLR and HLR.
“Erase” operation is applicable to call forwarding service. It can
be completed through Agent console or originated actively by an
MS. Flow of service originated by an MS is shown in Figure 128.

FIGURE 128 “ERASE” OPERATION FLOW
UE MSCS/VLR HLR
SS_Facility
Erase SS
MAP_Erase_SS
Step A
MAP_Erase_SS_Ack
Step B
SS_Facility_Ack
1. Step A
UE sends a supplementary service erase operation to
MSCS/VLR, and then MSCS/VLR sends an erase request to
HLR.
2. Step B
After HLR erases successfully, it sends an answer message to
MSCS/VLR, and MSCS/VLR will send an answer message to
UE.
Activation This is a service related to supplementary services, which are
used to activate supplementary services between MSCS/VLR and
HLR. It can be completed through Agent console or originated by
UE.
Activation operation is applicable to call forwarding, call waiting

and call barring services. To activate call barring service,
subscriber should provide password. As for other two
supplementary services, password is not required.
Service flow of activation operation originated by UE is shown in

Figure 129.

FIGURE 129 “ACTIVATION” OPERATION FLOW
1. Step A: UE initiates a supplementary service activation

request to MSCS/VLR. MSCS/VLR sends
MAP_ACTIVATE_SS_ind to HLR.
2. Step B: When activating call barring supplementary service,
HLR sends request to VLR to get subscriber password.
3. Step C: HLR receives response to subscriber password
obtaining request from VLR.
4. Step D: HLR returns a MAP_ACTIVATE_SS_rsp message to
VLR.
Deactivation As a service related to supplementary services, it is used to
deactivate supplementary services between MSCS/VLR and HLR.
In the same way, it can be implemented through Agent console
or originated by UE.
Deactivation supplementary service is applicable to call

forwarding, call waiting and call barring services. When
deactivating call barring, subscriber needs to provide password.
As for other two supplementary services, password is not
required. Service processing is the same as that of
supplementary service activation.
Interrogate To interrogate about data related to supplementary services. It

is applicable to CFU service and supplementary services of
incoming call barring. Interrogation of other supplementary
services is processed at VLR. Subscriber can make interrogation
through Agent console, or originate interrogation operation
through UE. Latter requires participation of MSCS/VLR. Service
flow is shown in Figure 130.

FIGURE 130 “INTERROGATE” OPERATION FLOW
MSCS/VLR HLR
MAP_INTERROGATE_SS_ind
Step A
MAP_INTERROGATE_SS_rsp
Step B
1. Step A: UE sends a supplementary service interrogation

request to MSCS/VLR. MSCS/VLR sends interrogating request
MAP_INTERROGATE_SS_ind to HLR.
2. Step B: HLR returns a response to VLR.
Invoke This is a service related to supplementary services. It is used by
MSCS/VLR to check whether mobile subscriber has subscribed to
a certain supplementary service so as to invoke this
supplementary service.
Register “Register password” operation only serves call barring
Password supplementary services. A mobile subscriber registers or
modifies passwords for call barring supplementary services
through “register password” operation to ensure that only
subscribers with due right can access this service.
“Register password” operation can be implemented through
Agent console or originated through UE. Latter requires
participation of MSCS/VLR. Service flow is shown in Figure 131.
FIGURE 131 “REGISTER PASSWORD” FLOW


1. Step A: UE sends a “register password” request to MSCS/VLR.
Then the MSCS/VLR sends a MAP_REGISTER_PASSWORD
message to HLR.
2. Step B: HLR sends a subscriber password obtaining request
to MSCS/VLR (UE has already registered password).
3. Step C: HLR receives response to get UE’s password from
MSCS/VLR.
4. Step D: HLR sends request to get subscriber’s password
(subscriber’s new password) to MSCS/VLR.
5. Step E: HLR receives response to get subscriber’s password
from MSCS/VLR.
6. Step F: HLR sends request to get subscriber’s password
(subscriber’s new password) to MSCS/VLR.
7. Step G: HLR receives response to get subscriber’s password
from MSCS/VLR.
8. Step H: HLR returns answer message
MAP_REGISTER_PASSWORD_rsp to VLR.
Get Password This is a service related to supplementary services, and it only
serves call barring supplementary services. Service
implementation is similar to that of “register password”.
Supplementary Services Processing

Number 1. Category
identification
Number identification supplementary services include
services
following four types:
Calling Line Identification Presentation (CLIP)
This service is originated by called subscriber. If a subscriber
that has subscribed to this service, the subscriber can
receive caller’s number when receiving incoming call.
Calling Line Identification Restriction (CLIR)
This service is of caller line originating service, making it
possible for caller to avoid calling line identification
representation on called line.
Connected Line Identification Presentation (COLP)
This service is originated by calling subscriber. If a mobile
subscriber is the caller, due to reason that the called
subscriber has activated call forwarding or other
supplementary services, the connected subscriber who
actually communicates with the caller is no longer the one
that the caller has called. In this case, network provides
connected number to mobile subscriber.

Connected Line Identification Restriction (COLR)

This service refers to the fact that network is prohibited to
provide caller with the number of connected subscriber when
connected subscriber receives a forwarding call.
2. Processing flow
Processing of each process is similar. Here, information
processing flow of CLIR is shown in Figure 132.
FIGURE 132 CLIR FLOW
UE MSCS A/VLR A MSCS B/LE
Set-up
(present CLIR)
IAM
SI PI=present restricted LI
In call setup, MSCS/VLR will interrogate information about

calling/called subscriber. MSCS/VLR originates corresponding
call according to information (whether calling number is to be
displayed). If CLIR is enabled, information of CLIR is
contained in IAM. If CLIR is not enabled, but called
subscriber has applied for CLIP service, information of CLIP is
contained in IAM.
Forwarding 1. Category
Services
Supplementary services of call forwarding involve following
four categories:
CFU
CFU means that when this supplementary service of mobile
subscriber is activated, all incoming calls to this subscriber
will be unconditionally forwarded to third subscriber
registered by this subscriber. The third party here might be a
mobile network, public network, or private network
subscriber, or it might be such an entity as voice mail box.
CFB
With this service of a mobile subscriber activated, when
subscriber is busy, all incoming calls to this mobile subscriber
will be forwarded to third subscriber registered by this
subscriber.
CFNRY

No reply means that called mobile subscriber does not hook

off after MS rings for a long time.
Incoming calls to mobile subscriber with CFNRy service
activated will be forwarded to third party if subscriber does
not reply.
CFNRC
CFNRc means that incoming calls to a mobile subscriber are
forwarded to a third subscriber if this mobile subscriber is
unreachable (in a blind area).
2. Registration and operation
Mobile subscriber can apply for different forwarding numbers
for different forwarding services. Except short message
service and emergency call service, forwarding service can
be applied to all or telecom services. Mobile subscribers
muse first perform “Provision” and “Register” operations in
advance. At time of “provision”, it is decided whether caller
or forwarding subscriber should be informed of the
forwarding number should be provided during the “Register”
operation. If forwarding number is within permitted range of
the network, mobile subscriber will receive information on
successful network registration.
When forwarding service is activated and operated, call
should be forwarded. Subscriber that receives forwarded call
must receive forwarding information and forwarding
conditions (if possible). If a call is forwarded for multiple
times, forwarded call is only related to previous forwarding
subscriber. Forwarding service does not influence the
capability of the caller. However, subscriber will get the
prompt for forwarding number for each time of call
forwarding. As an option, caller must get the prompt that call
is forwarded.
3. Processing flows of CFU and CFB
Processing flows of CFU and CFB are generally same, so they
will not be described one by one. Here, only CFB is set as an
example. Information processing flow of CFB is shown in
Figure 133.

FIGURE 133 CFB FLOW
MSa/TEa GMSCS HLR MSCS/VLRb MSb HLR MSCS/VLRc

Setup
Send_Routing_Information _Req
Send_Routing_Information_Ack
IAM STEP A
Or1 : n
Rel
Releas
STEP B
Send_Routing_Information_Req
Or1 : y
forward Send_Routing_Information_Ack
IAM
Or2 : y facility
Or3 : y
Progress
facility
STEP C
Note: Or1 means the call is forwarded; Or2 means the

forwarded subscriber is notified; Or3 means the caller is
notified.
i. Step A: GMSCS queries for route at HLR where subscriber
B is located, and sends a call Set-up message to MSCSb
where subscriber B is located.
ii. Step B: If subscriber is busy and no forwarding is
performed, call will be released.
iii. Step C: If subscriber B is busy, the MSCb will query for
route at HLRc where “forwarded-to” subscriber C is
located (that is, destination of call forwarding) and send a
call Set-up message to MSCSc. If CAMEL subscriber
selects, forwarding information can be provided to caller.
4. Processing flow of CFNRY
Processing flow of CFNRY is shown in Figure 134.

FIGURE 134 CFNRY FLOW
MSa/TEa GMSC HLR MSC/VLRb MSb HLR MSC/VLRc

setup
Send_Routing_Information
Send_Routing_Information ack
IAM
setup
call conf
Alerting
start timer STEP A
Or1 : n
timer espires
Rel impossible call completion
Releas
STEP B
Or1 : y
forwarding Send_Routing_Information ack
IAM
Or2 : y Facility
facility Progress
Or3 : y STEP C
Note: or1 means the call is forwarded; or2 means the

forwarded subscriber is notified; or3 means the caller is
notified.
i. Step A: GMSCS interrogates for route at HLR where
subscriber B is located and sends a call Set-up message
to MSCS/VLRb where subscriber B is located. Timer is
started when MS rings.
ii. Step B: If time expires and subscriber gives no reply,
MSCS/VLRb will interrogate about subscriber information.
If call is not forwarded, it will be released.
iii. Step C: If subscriber has subscribed to CFNRY service,
MSCS/VLRb queries route from HLRc where the
“forwarded-to” subscriber C is located and sends an IAM
to the MSCS/VLRc. Forwarding information can be
notified to the caller if CAMEL subscriber B selects the
option.
5. Processing flow of CFNRC
When called mobile subscriber is not reachable in MSCS/VLR,
the MSCS/VLR or HLR provides MSRN of forwarding
subscriber. In the following, we only illustrate the case that
MSCS/VLR provides MSRN, as shown in Figure 135.

FIGURE 135 PROVIDING FORWARDING NUMBER
MSa GMSCS HLR MSCS/VLRb HLRc MSCSc
set-up Send_Route_Information
Provide_Roaming_Number
Provide_Roaming_Number ack
IAM
Rel Or1:n
release Step A
Or1:y
Or2:y IAM
Progress
facility
Step B
Note: Or1 indicates call is forwarded; Or2 indicates to notify

caller.
Flow is described as follows (assuming that called subscriber
is subscriber B, and “forwarded-to” subscriber is subscriber
C):
i. Step A: (Send_Routing_Information,
Provide_Roaming_Number)
GMSCS interrogates for the route on HLR and MSCS/VLR
where subscribe B is located and sends an IAM to
MSCS/VLRb where subscriber B is located. MSCS/VLRb
interrogates about information for setting up incoming
call. If called subscriber is not reachable in MSCS/VLRb
and the call cannot be forwarded, call will be released.
ii. Step B: (Send_Routing_Information)
If call can be forwarded, the MSCS/VLRb will interrogate
for a route on HLRc where “forwarded-to” subscriber C is
located and set up the call.
Call 1. Overview
Completion
Both CW and HOLD services are collectively called the call
Services
completion service, and they are usually used in a combined
manner.
Call waiting service is used to notify called subscriber to wait
when an incoming call cannot get voice channel (at full or
half rate). Called subscriber may accept, reject, or ignore
this incoming call. Each call can accept at most one waiting
call.
CW service can be applied to all of the basic services except
emergency call.
Call hold service allows a subscriber to terminate a call
temporarily and reserve the RAB subscriber resources
assigned by current call. If necessary, reserved RAB
resources can be used to set up another call. Network can

only reserve one RAB transmission channel for each mobile

subscriber.
2. Processing flow of CW
CW service is completed by three conversation parties jointly:
Subscriber B: Subscriber B who has applied for CW service is
the controller of this service.
Subscriber C: Subscriber C originates call to subscriber B and
starts call waiting.
Subscriber A: Subscriber A who has the conversation with
subscriber B can be either the calling or called subscriber.
After CW service is invoked, subscriber B will receive a call
waiting announcement tone. At the same time, subscriber C
also receives announcement, indicating that this call has
been accepted.
After CW service is invoked, if subscriber A or B terminates
current call, subscriber B will be prompted that there is a
new call. At the same time, network will go on sending ring-
back tone to subscriber C, until the time T2 defined by
network is out. Subscriber B can also make use of CH service
to hold original call and access waiting call before T2 is out.
Information processing flow is shown in Figure 136, Figure
137 and Figure 138.
FIGURE 136 CALL WAITING FLOW (1)
UEa UEc MSCS/VLR UEb
Status 3
Hold
Facility A
(CallA-B hold by B)
Connect Waiting
Facility C
CWC -B Stop T2
Connect ack
Status 5

UEa UEc MSCS/VLR UEb
Status 3
or 5
disconnect Disc demand
（A-B）
Disc ack
（A-B ）
connect
Conn demand
（C-B ）
Conn ack
（C-B ）
Status 6
i. Status 1: If subscriber B has subscribed to CW service

and is talking with subscriber A. System will accept call
from subscriber C, deliver a Setup message to subscriber
B and set timer T1 to wait for “Call Confirm”.
ii. Status 2: Subscriber B waits for call and is in a state of
waiting for answer.
iii. Status 3: Subscriber B is in A-B active/C-B waiting status,
indicating the subscriber has an active call and a waiting
call at the same time.
iv. Status 4: Subscriber B is in A-B active/C-B waiting/D-B
held status, indicating that the subscriber has an active
call, a held call and a waiting call simultaneously.
v. Status 5: Subscriber B is in A-B held/C-B waiting status,
indicating that subscriber has a held call and a waiting
call at the same time.
vi. Status 6: Subscriber B is in C-B active status, indicating
subscriber only has one active call.
3. Call hold
This supplementary service is only applicable to telephone
services.
General Operations
f Hold request: The subscriber requests the network to
interrupt the current call and hold it.
f Call termination request: If a call is in holding status,
both caller and called can disconnect this call.
f Unidirectional of call hold operation: It means that, hold
operation only acts on one party of call, while other party
can still continue hold operation (without being affected
by another one). That is to say:
f Party A puts party B on hold. For party A, this call is on
hold, while for party B, this call is still in the active status.

f Both parties put each other on hold. For both parties, this
call is on hold.
Processing flow of call hold service
If subscriber enables a hold call and does not set up a new
call, there will be three operations: recovering hold call,
setting up a new call (original call is still held), and
terminating hold call. The message processing flow is shown
in Figure 139.
FIGURE 139 CALL HOLD FLOW
Note: or1 means the hold request

i. Status 1: Subscriber A is in A-B active status, indicating
that subscriber has only one active call.
ii. Status 2: Subscriber A is in A-B held status, indicating
that subscriber has only one held call.
iii. Status 3: Subscriber A is in A-B held}/A-C active status,
indicating that subscriber has one active call and one held
call.
Multi-party 1. Overview
Call (MPTY)
This service enables the subscriber to set up a call with
multiple parities at the same time.
Precondition for the multi-party conversation is that
subscriber has an activated call and an on-hold call, and both
calls have been replied. In this case, subscriber can request
network to start MPTY service. Once MPTY services of both
parities are activated, external call can be added,
disconnected or separated (that is, call is removed from

MPTY, however, connection with subscriber receiving service

is still held.
In a multi-party conversation, there should be no more than
five external calls.
When MPTY service is invoked, all of external calls will
receive indication. When a new call joins in MPTY, each of the
external calls will receive the indication.
This service is only applicable to telephone service.
2. General operations:
i. Originate an MPTY
When subscriber receiving service invokes the MPTY
service, network will add current active call and hold call,
to MPTY service so that they can communicate with each
other.
ii. Manage an activated MPTY
In an activated MPTY, served subscriber can perform the
following operations:
f Add another external call. Send a MPTY setup indication
to all external calls, and a restoration indication to all
held external calls.
f Set the connection with MPTY as the hold status. In this
case, all the external calls will receive an MPTY hold
instruction. Under this status, served subscriber can
originate a new call or process a call waiting request.
When MPTY is on hold, external calls can still
communicate in MPTY. Newly originated calls or accepted
waiting calls can be added to MPTY.
f Separate an external call. An external call is separated
from MPTY and put on hold. In this case, all external calls
will receive a Hold instruction. It is an ordinary call
between served subscriber and separated subscriber.
Leftover external calls can keep on communicating with
each other. Separated call can be released or reenter
MPTY.
f Terminate whole MPTY. When served subscriber is
released, whole MPTY is terminated.
f Terminate an external call. If there is no external call at
this time in MPTY, MPTY is terminated.
MPTY hold indication is originated by MS instead of
network.
iii. Manage an on-hold MPTY
During the period when an MPTY is on hold, served
subscriber can perform the following operations:
f Restore the on-hold MPTY to activated status.
f Originate a new call.

f Process a call waiting request.

f Terminate on-hold MPTY, and all of the calls belonging to
this MPTY will be released.
f Terminate a certain external call in the MPTY.
In this case, an external call cannot be restored.
iv. Manage a single call and an MPTY
f Single call activation
If served subscriber has an activated call and an on-hold
MPTY, then he can perform the following operations:
Disconnect the activated call.
Terminate the on-hold MPTY.
Terminate the activated call and the on-hold MPTY.
Adding active call to held MPTY to activate MPTY, and
meanwhile, an MPTY adding instruction is sent to all
external calls.
Changeover between the two.
f An activated MPTY and an on-hold call
If the served subscriber has an activated MPTY and an
on-hold call, he can make the following operations:
Terminate the activated MPTY.
Disconnect the on-hold call.
Terminate activated MPTY and disconnect on-hold call.
Adding held call to the MPTY so that MPTY is in active
status, and meanwhile sending an MPTY member adding
instruction to all external calls
Switch between the two.
In this status, served subscriber cannot separate an
external call, for this means that there will be two on-
hold calls, which are prohibited by HOLD service.
v. External call party in the MPTY
External call party in MPTY can make following operations:
f Set the connection with MPTY to the hold status.
f Terminate the connection with the MPTY.
Here, setup and disconnection of an MPTY call is set as an
example to illustrate MPTY call processing flow, as shown in
Figure 140:

FIGURE 140 MPTY CALL PROCESSING FLOW
Subscriber A originates an MPTY MSCS/VLRc

MSCS/VLRb
UEA MSCS/VLRa Held Active
Step 1
Facility
NotifyEvent(Retrieve)
( BuildMPTY A
-B) NotifyEvent ( MPTY)
NotifyEvent( MPTY)
Facility( BuildMPTYAck)
Step 2
Subscriber A terminates an MPTY

UEA MSCS/VLRa MSCS/VLRb MSCS /VLRc
Step 1
DisconnectEvent(B)
DisconnectEvent (C)
ReleaseEvent(B) ReleaseEvent (B)
ReleaseCmpEvent(B)
ReleaseEvent(C)
ReleaseEvent (C)
ReleaseCmpEvent(C)
ReleaseCmpEvent (B)
ReleaseCmpEvent (C)
Step2
MPTY call setup:

i. Step 1
Subscriber UEa sets up two steady calls (an active call
and a held call).
ii. Step 2
MSCS/VLRa receives MPTY setup request message from
chairman UEa, performs MPTY resource request and
timeslot connection, sends a restoration notification to
MSCS/VLRb and sends an MPTY setup instruction to all
peer MSCS/VLRb and MSCS/VLRc. Meanwhile,
MSCS/VLRa also returns a successful MPTY setup
indication to UEa and enters MPTY talking status. In this
case, UEa, UEb and UEc can talk with each other.
MPTY call release:
i. Step 1
MPTY is in talking status or hold status.
ii. Step 2
MSCS/VLRa receives release A-B call message of UEa,
performs call release processing of A-B MPTY members,
releases A-B MPTY resources and notifies MSCS/VLRb to
release call. Meanwhile, MSCS/VLRa receives A-C call
release message of UEa, performs call release processing
of A-C MPTY members, releases A-C MPTY resources and
notifies MSCS/VLRc to release the call.
Call Barring 1. Category

Call barring consists of two types: Barring of incoming call

and outgoing call.
2. Category of Barring of Outgoing Call (BOC)
BOC is a kind of barring to a subscriber when he calls
another subscriber.
This supplementary service is valid for all of the telecom
services except emergency call. Subscriber can select any
kind of barring listed below:
BAOC: Except emergency call, it is not allowed to call any
other subscribers.
BOIC: Calls can only be made to mobile subscribers (no
matter where they roam) within currently located PLMN and
to subscribers of the fixed telephone network in the country
where called is located. But it is not allowed to originate calls
to subscribers in other PLMNs even though those subscribers
roam to current PLMN where caller is located.
For the BOIC except those of the home PLMN and home
country telephone networks, calls can only be originated to
the following kinds of telephone subscribers.
f Mobile subscribers at the current PLMN where caller is
located.
f Fixed telephone network subscribers of the country where
caller is currently located.
f Mobile subscribers at the home PLMN of the caller.
f Subscribers of fixed telephone network in home country
of the caller.
3. Instructions of BOC
BOC provides subscribers with two options: CB type and CB
control.
Options of CB type: Subscriber can select one, two or three
of the above three call barring types.
Options of the CB control: The subscriber can select to
control by password himself or by administrator.
In any case, there can only be one type of valid BOC. When
one BOC type is activated, original type will be deactivated
automatically.
If subscriber selects to control by himself, he should provide
the following information to network during activation:
Password
Select the basic service that needs BOC.
Select the BOC type
If administrator control type is selected, subscriber has no
right to activate this supplementary service himself.

BOC type and status (activating or deactivating) can be

selected separately for any kind of basic services.
When subscriber originates a call and the called is within
BOC range, the call will be rejected, and subscriber will
receive a call rejected notification.
BOC does not influence the incoming call or emergency call.
4. Processing flow of BOC
Information processing flow of BOC is shown in Figure 141.
FIGURE 141 BOC SERVICE FLOW
UE MSCS/VLR MSCS/LE
Set-up
Step1
Call reject
OR1:Y
OR1:N
IAM
Step 2

i. Step 1
After receiving the call setup request, the MSCS/VLR
checks if there is BOC.
ii. Step 2
If there is BOC, MSCS will send a call rejection message
to MS. If there is no BOC, the call will be set up normally.
5. Category of Barring of Incoming Calls (BIC)
BIC is a barring when subscriber calls in.
This supplementary service is valid for all telecom services.
Subscriber can select any of the following barring types:
BAIC: At this time the subscriber can not receive calls from
other subscribers;
BIC-Roam: When the subscriber roams outside the home
PLMN country, the incoming call is barred.
6. Instructions of BIC
BIC provides subscribers with two options: CB type and CB
control.
Options of CB type: Subscriber can select one, two of the
above two call barring types.

Options of CB control: Subscriber can select to control by

password himself or by administrator.
At any time, there can only be one valid BIC type. When one
BIC type is activated, original type will be deactivated
automatically.
If called of a call is within the BIC range, this call will be
rejected, and caller will receive a call rejected notification.
BIC doesn't influence outgoing calls.
7. Service flow of BIC
BIC service flow is shown in Figure 142.
FIGURE 142 BIC SERVICE FLOW

i. Step 1
After receiving outgoing call setup request, MSCS/VLRa
sends a MAP_SEND_INFO_ FOR_OUTGOING_CALL
message to called HLR. After receiving the message, HLR
checks whether there is BIC for the called, and then
sends a response to MSCSa.
ii. Step 2
If there is BIC, MSCSa will send a call rejection message
to the MS; if there is no BIC, the call will be set up
normally.
CUG (Closed This supplementary service makes multiple users form a closed
User Group) user group. Both external incoming calls and internal outgoing
calls are barred. One user can be member of one or multiple
groups. Members of a closed group usually cannot communicate
with users outside the group.
Advice of Advice of charge supplementary service includes the Advice of
Charge Charge (Information) AOCI and Advice of Charge (Charging)
AOCC.

AOCI mean refers to the fact that network provides information

for mobile terminal to calculate basic service communication
charges.
Advice of charge (charging) means that the network provides
information for a mobile subscriber to calculate basic service
communication fees, so that mobile terminal can display service
communication fees.
Explicit call 1. Overview
transfer
Explicit Call Transfer (ECT) means that, for subscriber A with
two calls, each call can be an incoming call or an outgoing
call, and the ECT supplementary service can be invoked to
connect two calls to release its own connection of subscriber
A.
2. Category
ECT covers the following cases:
Both calls are in steady status. Where, call B is in Held status,
while call C is in Active status.
One of the two calls is in steady status, while other is in
ringing status (waiting for the Answer message). That is to
say, call B is in Held status, while call C is in WaitAnswer
status.
3. Processing flow
In the following, both calls in steady status are set as an
example to illustrate processing flow of ECT, as shown in
Figure 143:
FIGURE 143 ECT PROCESSING
On the precondition that UEa meets the requirements for two

steady calls (active and held calls), if the MSCS/VLRa
receives the ECT activation request from UEa, it will connect
the voice channel between the two calls, send a call recovery
instruction to the peer end of the party in held status, and
meanwhile will send an ECT setup instruction to the peer end
of each call.

After successful ECT operation, the MSCS/VLRa returns a

successful ECT operation indication to UEa through a release
message. After the setup of ECT, messages between the
peer UE ends are transferred according to the following line:
UEb <-> MSCS/VLRb <-> MSCS/VLRa <-> MSCS/VLRc <->
UEc.
Call Deflection 1. Overview
Call Deflection (CD) means that a subscriber can invoke the
CD service when a normal incoming call arrives, the network
will transfer this call to the subscriber specified by the
deflection number and clear call of this CAMEL subscriber.
This supplementary service is applicable to all subscribed or
applied service groups.
2. Subscription options
This service provides the following subscription options:
f A CAMEL subscriber configures such a subscription option
so that when a call is deflected, calling party can receive
the call deflection notification.
f A CAMEL subscriber configures such a subscription so
that when a call is deflected, deflection party can receive
CD service invoking notification.
f A CAMEL subscriber configures such a subscription so
that the deflection party can receive MSISDN of CAMEL
subscriber. If CD takes place for multiple times,
deflection cause and number received by deflection party
are the number of CAMEL subscriber who is latest one to
invoke CD service.
3. Processing flow
CD processing flow is shown in Figure 144:
FIGURE 144 CD PROCESSING
GMSCS MSCS/VLRa UEA HLR MSCS/VLRb
Setup
Setup
Facility( CD req)
Step 1
Send_Routing_Information_Ack
IAM
Facility( CD Ack)
Step 2

i. Step 1
When waiting for ringing message or answer message,
called mobile subscriber UEa may receive Facility (CD
Request) message from the MS. This message contains
deflection number (possibly also contains sub-address of
deflection subscriber).
ii. Step 2
After receiving CD setup request from UEa, MSCS/VLRa
will interrogate new route according to deflection number,
search for called MSCS/VLRb, return CD setup success or
failure indication to UEa and release call connection from
MSCS/VLRa to UEa.
Mobile Data Services

Background Most of the current mobile communications systems provide
voice services. With the advent of information age, people are in
urgent need for data services. Use of mobile communication
technology to provide data services will undoubtedly maximize
the application scope of this technology and better meet people’s
requirements for data services. ZTE ZXWN MSCS system
provides the data service function.
Mobile data service is implemented by adding IWU functional
processing unit to MGW, and MSCS invokes it based on provision
and subscriber-originated service. All data services can be
provided, covering G3/G4 fax, intelligent telegraph, videography,
computer data, etc. The system provides the circuit bearer
service required in the UMTS protocols. In addition, the system
also supports inter-working with all kinds of networks such as
PSTN, ISDN, CSPDN, PSPDN, DDN and Internet.
Category In a PLMN network, CS data services cover eight categories (see
3GPP TS22.002): 3.1 kHz audio, V.110, X.31 Flag Stuffing,
V.120, Bit Transparent Mode, PIAFS, Frame Tunneling Mode, and
multimedia call. Different data services need different bearer
capabilities. Bearer capability depends upon BCIE (Bearer
Capability Information Element) in Set-up message. According to
the requirements of 3GPP for circuit data services, the following
three types of bearer capabilities are needed: 3.1 kHz audio ex
PLMN, RDI and UDI.
Table 16 lists bearer capabilities necessary for circuit data
services:
TABLE 16 UMTS CIRCUIT DATA SERVICES
Service Bearer
Attribute FNUR
Name Capability
3.1 kHz Asynchronous/tra 3.1kHz
28.8 kbit/s
audio nsparent mode audio

Service Bearer
Attribute FNUR
Name Capability
Synchronous/tran
28.8 kbit/s
sparent mode
Synchronous/non- 9.6/14.4/19.2/28.8k
transparent mode bit/s
56 kbit/s
V.110 Transparent UDI/RDI
64 kbit/s
X.31 Flag Synchronous/non- 9.6/14.4/19.2/28.8/
UDI/RDI
Stuffing transparent 38.4/48/56kbit/s
9.6/14.4/19.2/28.8/
V.120 Non-transparent UDI/RDI
38.4/56kbit/s
Bit UDI 64 kbit/s
Synchronous/tran
Transpare
sparent RDI 56 kbit/s
nt Mode
Asynchronous/non
PIAFS UDI/RDI 32/64 kbit/s
-transparent
Frame
Asynchronous/non 9.6/14.4/19.2/28.8/
Tunneling UDI/RDI
-transparent 38.4/43.2/57.6kbit/s
Mode
3.1 kHz
28.8/33.6 kbit/s
audio
Multimedi Synchronous/tran
a call sparent RDI 56 kbit/s
UDI 32/64 kbit/s
Mobile Intelligent Service

Overview
Introduction The ZXWN MSCS system has the gsmSSF function, supports
CAMEL4 level and downward compatibility, and provides
abundant CAMEL services.
Topics Page No.

Introduction to Intelligent Network 201
Mobile Intelligent Service 206
Mobile Intelligent Service Flow 209

Introduction to Intelligent Network

Overview Intelligent Network (IN) is intended to serve all the
communications networks, that is, it can serve existing Public
Switched Telephone Network (PSTN), Packet Switched Public
Data Network (PSPDN) and Narrowband-Integrated Services
Digital Network (N-ISDN), as well as Broadband - Integrated
Services Digital Network (B-ISDN) and mobile communications
networks. It is not parallel to existing communications networks,
but serves and enhances telecom networks.
Applications Structure of application fields of IN is shown in Figure 145.
FIGURE 145 APPLICATION FIELDS OF IN
End-User
End-User
Service INTERNET Mobile
Provider PSPDN Network
SMS SCP DB
CCS7 NETWORK
SSP IP
N-ISDN
PSTN
B-ISDN
End-User
End-User End-User
Architecture IN is the “nerve center” of telecom networks. INCM (Intelligent

and Functions Network Conceptual Model) is a framework for the design and
description of intelligent system. This model defines system and
functions of IN from perspectives of different planes and objects,
including service plane, general function plane, distributed
function plane and physical plane, as shown in Table 17.
TABLE 17 ARCHITECTURE AND FUNCTIONS OF IN
Handling
Layer Name Oriented Objects
Objects
Service Plane Service user

1 SF/service
(SP) Network carrier
Global Function
2 Service designer SIB/GFL
Plane (GFP)
3 Distributed Software FEA/FE

Handling
Layer Name Oriented Objects
Objects
Function Plane developer
(DFP)
Physical Plane Equipment
4 PE/INAP/CAP
(PHP) manufacturer
Structure INCM structure is shown in Figure 146.
FIGURE 146 INCM STRUCTURE
1. Service plane
Service Plane (SP) describes IN from the aspects of service
user (network user) and service provider (network carrier),
highlighting concepts of service and service features. Service
is the capacity provided by network carrier or service
provider to meet users’ demands for communication.
Difference of services is embodied in most basic service unit
(that is, SF) that users can “sense”. One service can consist
of several SFs, and other required SFs can be selected to
enhance service function. By designing and combining
multiple SFs, network carrier can provide network users with
a variety of new services and give precise definitions of these
services. In complex design of new services, SFs and service
modules structured by SFs are regarded as basic structural
modules. For the sake of modularization and reuse, services
are sub-divided into the SFs. Modular design idea runs
through the following descriptions, which is the essence of
the intelligent network.
2. General function plane

General Function Plane (GFP), from the angle of service

designer, reflects the general functions of IN. Based on IN
services provided for users and from network-wide
perspective, GFP abstracts some functional modules
simulating network functions, thus to support and ensure
implementation of SFs on service plane. Abstracting
functional module is called Service Independent Building
Block (SIB). GFP processes such objects as SIB and General
Service Logic (GSL) that describes the logic relationship
between individual SIBs constructing services. Modularization
renders the flexibility for SIBs to construct SFs. According to
SF description and GSL, the service designer can create
distinctive value-added services by combining SIB chains.
3. Distributed function plane
Distributed Function Plane (DFP) processes Functional
Entities (FEs) and Information Flows (IFs). Software
developers face nine functional entities: Call Control Access
Function (CCAF), Call Control Function (CCF), Service
Switching Function (SSF), Specialized Resource Function
(SRF), Service Control Function (SCF), Service Data Function
(SDF), Service Management Function (SMF), Service
Management & Access Function (SMAF) and Service Creation
Environment Function (SCEF). IFs are transferred among
these functional entities, which jointly complete the functions
of SIB and GSL.
4. Physical plane
Objects processed by PHysical Plane (PHP) are Physical
Entities (PEs) that implement different types of functional
entities. Oriented to the equipment manufacturer, this plane
integrates logic functional entities of the DFP into concrete
PEs and materializes IFs between functional entities into
INAP (CAP for mobile IN). These physical entities should be
developed according to the following basic requirements:
All FEs in DFP should be able to correspond to the
corresponding PEs in PHP.
There can be one or more FEs in the same PE.
One FE cannot be distributed into two PEs.
Two identical FEs can correspond to different PEs.
All PEs can be grouped into a PE system.
Each PE should provide a standard interface.
Based on FE conversion and standard interfaces, all
manufacturers should be able to develop the PEs.
Manufacturers can support mature technologies and new
technologies, and apply them into the PEs in an effective way.
PEs are arranged on the basis of INCM. According to ITU-T
recommendations, SCF and SDF can be used to construct
Service Control Point (SCP) and Service Data Point (SDP) on
different PEs, or they can be integrated on a PE to form SDP.

Furthermore, SCF, SDF, SSF/CCF and SRF can be integrated

together onto one PE to construct physical node SN. SCEF
can be integrated on a PE to form an SCE. SMF and SMAF
can be integrated onto a PE to form an SMS (Service
Management System). SSF/CCF and CCAF can be integrated
onto one PE to form an SSP. To construct IN in a larger area,
SCF and SSF should be separated physically and connected
with each other through SS7 network.
Development CAMEL (Customized Applications for Mobile Network Enhanced
and Logic) is the expansion and development of IN in terms of
Advantages mobile services. With the development of Phase 1, Phase 2,
Phase 2+, GSM protocols have set up a comprehensive series of
standards and defined supplementary services such as: Call
barring, call forwarding, CLIP, CLIR, call waiting, call holding,
three party call service, closed user group, call transfer, call on
busy and preferred routing. GSM in Phase 2+ is constantly
challenged with the demands of new services and by the ever-
developing constitution of protocol standards. With the success
of IN in PSTN, ETSI brought forward, for first time, CAMEL Phase
1 in GSM Phase 2+ Release 96 version, and then CAMEL entered
CAMEL Phase 2 in GSM Phase 2+ Release 97. At present, 3GPP
R99 series of standards further expand CAMEL, and CAMEL
enters third phase (CAMEL Phase3). R5 protocol has formulated
standard of CAMEL Phase 4. Using concept of modularized IN
structure, CAMEL gains an incomparable advantage over the
traditional GSM networks in terms of service processing, service
creation, service management and charging mechanism.
Being a network feature, CAMEL is different from the
supplementary services in UTMS. Service processing mode of IN
is much different from traditional one. Supplementary service
processing and call processing of traditional GSM network are
collectively performed by MSCS, and service flow is fixed. To
provide new supplementary services, network carrier must
perform a network-wide upgrading for all the software versions
of related nodes on mobile networks, even containing software
in billing center. Version upgrading is unstable, risky and
expensive, and directly affects normal running of the network. In
IN, service processing and call processing are separated, and
network functions are modularized. Each switching node only
performs basic call processing, and service logic control is
completed by SCP. New services are created by Service Creation
Environment (SCE). SMP is responsible for service management
and submission of new services. IN constructs services with the
design concept of modularization. According to attributes of new
services, network carrier can obtain new services by using SIB
(Service Independent Block) to design service logic and form
SIB chains. Network carrier can conveniently and quickly create
competitive CAMEL_OSS value-added services that are different
from GSM standard services. Even if a mobile subscriber roams
out of HPLMN, OSS still can get service support. New services
can be commissioned less expensively and effectively. Services
cover the whole network, reducing the operation risks.

Network According to the description of the CAMEL functional structure in

Structure UMTS protocol, a mobile IN consists of following parts: HLR,
gsmSCF, GMSCS (with gsmSSF function), MSCS/VLR (with
gsmSSF function) and gsmSRF (independent intelligent IP
peripherals or integrated with MSCS/VLR). In CAMEL Phase 3,
GMLC (Gateway Mobile Location Center) will be introduced.
Implementation of mobile intelligent services needs information
exchange between VPLMN, IPLMN, HPLMN and CAMEL service
control (SCF). In HPLMN and VPLMN, additional notes are
required for records of mobile subscribers who register CAMEL
services.
Basic network structure is shown in Figure 147:
FIGURE 147 BLOCK DIAGR AM OF CAMEL
HLR: Stores subscriber-related CAMEL subscription information

such as O-CSI, D-CSI, T-CSI, VT-CSI, SMS-CSI, TIF-CSI, U-CSI
and SS-CSI, and also saves CAMEL subscription information for
UG-CSI to act on all subscribers. Where, O/D/VT-CSI SMS-CSI
and SS-CSI are transmitted to VLR during MS location update or
data change, O/D/T-CSI will be transmitted to GMSCS in routing
acknowledgement message, and CAMEL subscription information
such as TIF-CSI, U-CSI and UG-CSI are only stored in HLR.
VLR: Stores CAMEL subscription information of mobile

subscribers roaming in local VLR, such as O-CSI D-CSI, VT-CSI,
SMS-CSI and SS-CSI.
GMSC Server: Provides CCF (Call Control Function) in IN, as well

as a means for network users to establish and control bearer
services.
gsmSCF: GSM service control function provides service logic for

logic control of call request CAMEL OSS service and processes
service-related actions.

gsmSSF: GSM service switching function provides means to

recognize call request CAMEL OSS service processing and
interacts with call processing and call service logic.
gsmSRF Server: GSM specialized resource function, provides

interactions between all terminal users and network by
controlling DTMF receiver, speech reorganization function,
protocol conversion, announcement, voice processing and other
resources.
As a new service network in mobile communications industry,

mobile intelligent network system can provide mobile pre-paid
service to minimize such problems as arrears and malicious
overdraft which are afflicting entire telecommunications industry,
reduce business risks of telecom carriers and guarantee normal
business revenue. Furthermore, it can provides other value-
added services conveniently, flexibly, economically and
effectively, and also provide users with higher-quality, timely
and personalized services by integration with business system,
customer service center, short message center and banking
systems. All these merits have made mobile intelligent network
system a new service growth point for telecom carriers.
Mobile Intelligent Service

At present, ZXWN MSCS/SSP (V3.0) system is in accordance to
CAMEL Phase 3 specifications, providing the following functions:
1. Mobile Pre-Paid Service (MPPS)

This service is a typical form of “paying in advance and
getting service afterwards”. When a subscriber signs up for
MPPS, he will be allocated by network operator a unique
account corresponding to his own subscriber number. All call
charges of MPPS subscribers will be deducted from the
account. Once balance of account is insufficient or overdue,
network will stop providing communication services for
subscriber until account is recharged. This service can also
set maximum daily or monthly charge limit for subscriber, to
guarantee subscriber’s economic interests.
MPPS service makes use of mobile intelligent network to
provide real time control and fast charging function for
communication, which can effectively control benefit
damages brought about by fee owing or malicious overdraft
by those under-trustworthy subscribers and reduce operating
risks, guaranteeing normal operating incomes, and bring in
considerable deposited profits of call charges for telecom
carriers. Rational charge policy, if adopted, will attract
network service subscribers and increase network utilization
rate, thus bringing more benefits to operators and facilitating
earlier recouping of the network investment.

2. Mobile Virtual Private Network (MVPN)

This service provides subscriber on mobile network with
network service similar to PBX function and creates its own
trans-regional or even transnational VPN. Call charges of all
subscribers in MVPN are collected from same group account.
MVPN adopts independent numbering plan to enable
subscribers in the network to directly dial short numbers of
each other. Service enables MVPN administrator to manage
call authority of subscribers in the network and control call
charges, and provides detailed call records and statistic data
on a regular basis.
MVPN service provides group users with powerful
communication management by using flexible route
mechanism, conversation control mechanism and diversified
charging functions of IN. Through member call right
management (for example, on-net call only, off-net outgoing
call restriction, and off-net incoming call restriction) and call
charge control (for example, control for the upper limit of
monthly call charges), group can enhance internal
management, control the whole communication costs.
Through periodic call records and statistic data, group can
keep track of work status of members, save costs of the
enterprise in switch purchasing equipment upgrading and
maintenance, thus to reduce operation costs of group.
Network operator may adopt different charge rates for in-
network calls and out-network calls to attract group users
and use large traffic of group users to enhance network
utilization ratio, avoid wasting network resources, and
effectuate operation income. Meanwhile successful
development of MVPN group may help to bring about more
profits for the network operator.
3. Familiar Numbers Service (FNS)
This service creates a table of frequently dialed familiar
numbers for subscriber. When an FNS subscriber dials a
familiar number in table or when a friend with a familiar
number in table calls FNS subscriber, network will provide a
preferential charge rate. Familiar numbers table is connected
by service subscriber to service management center via
telephone or Internet for modification and maintenance.
Advantage of FNS is its preferential charge rate for
subscriber so that the subscriber, relieved of charge worries,
will use service more frequently. For network operator, FNS
means more network subscribers and higher network
utilization rate, hence greater profits.
4. Mobile ADvertising service (MAD)
This service provides the ad applicant (manufacturer) with an
ad access number and creates an ad customer account. All
mobile or fixed subscribers dialing ad access number can go
on to dial other subscribers free of charge after listening to
an ad of manufacturer, with specified call charge deducted

from ad customer account. To ensure effect of ad, a simple

test may be made after ad on dialing subscriber. Only
subscriber who has passed the test can go on to make
another call free of charge. Test results are counted by the
network.
MAD service introduces ads into mobile communications,
thus providing a new ad carrier. MAD may serve to conduct
activities on the network like surveys and questionnaire
feedback, and make respondents more interested in such
activities, thus improving the effect of activities. For ad
customer, MAD may help to popularize its products. For an
ordinary subscriber, MAD may provide free calls for a
specified time or charge. For network operator, MAD may
help to bring network resources into full play and bring about
sizable income from ad service.
5. Specialized Charging Service (SCS)
This service is typical in its use of “IN diversified charging
functions”. SCS provides subscriber with special charging
package options and specified preferences, including
premium rate based on call time segment, premium rate
based on conversation duration, premium rate based on call
zone, etc. SCS subscriber may subscribe for his favorite
charging package and enjoy preferences.
Launch of SCS at an appropriate time can provide diversified
discount services for subscribers, attract more network users,
enlarge communication market shares for carrier and
increase network operation income.
6. Multiple Subscriber Profile (MSP)
This service makes it possible for mobile subscriber to use
only one USIM card to enjoy multiple lines, each
corresponding to an MSISDN. Different profiles have different
subscription options, so that mobile subscribers can use their
mobile phones with different identities (as individuals or for
business purpose), which will be charged at different
charging rates. Service subscriber may choose any line to
start a call, and called MSISDN will determine a line to end
the call.
Another solution to realizing MSP service is to use incoming
call screening function of mobile IN to provide intelligent role
selection. This solution provides a single subscriber number
in order to save number resource, but restricts selection
range of other supplementary services that the subscriber
subscribes for.
MSP service brings many conveniences to mobile subscriber
on the network. Different roles entitle the subscriber to
different network services, thus winning over more network
users and increasing communications market share for
operator.
7. Mobile BanK Service (MBKS)

This service provides e-business interfaces between mobile

IN and private network of the bank, and realizes account
management through mobile phones, including password
management, account query, account transfer, etc.
Compared with the existing telephone bank, IN mode excels
in the following ways:
SCP is centralized in layout with a unified interface with the
bank, for the convenience of control and management.
Signaling mode is adopted to establish the data path
between the originating office and the private network of the
bank, saving circuit resources.
MBKS service enables the leading bank systems to provide a
unified bank access number province-wide or nationwide,
thus forming a unified bank interface to improve network
security and standardize various services of the banks.
8. Business Assistant Service (BAS)
This service provides various business tools and information
services and uses technologies like USSD and SMS to provide
important agenda record and prompt function, incoming call
recorded message function, conference bulletin function,
etiquette transfer function, public information query function,
etc.
Other mobile intelligent VASs include: mobile freephone (FPH),
outgoing call screening, subscriber dial tracing, call charge
instant query, etc. ZXWN mobile intelligent network system can
help carriers to develop and create different types of services,
enhance network functions and provide better services.
Mobile Intelligent Service Flow

Basic Call By means of advanced finite state mechanism, BCSM describes
Status Model actions necessary for CCF to set up and maintain communication
(BCSM) channels of subscribers. It specifies for CCF a group of basic
calls and connection actions (that is, the basic components of
BCSM), and indicates how these actions are combined to process
a basic call and connection. Specifically, BCSM in mobile
intelligent network specifies basic calls and connections such as
mobile originating call, call forwarding or mobile terminating call
in MSCS/GMSCS, as well as intervention points of mobile
intelligent logic in basic call processing.
BCSM separates descriptions of call originating and terminating
functions, and specifies uniqueness of the Detection Point (DP)
names: prefix “O” to originating DP and “T” to terminating DP.
Therefore, BCSM can be described in two parts: O-BCSM and T-
BCSM.
1. O-BCSM
Figure 148 shows O-BCSM.

FIGURE 148 O-BCSM
O_Null & Authorise_Origination_ O_Exception

Attempt_Collect_Info
O_Abandon
Collected_Info
invalid_information
Analyse_Information
Analysed_Informa
tion Route_Select_Fail
ure
Routing O_Busy
& Alerting O_No_Answer
O_routing_and_alerting_failure
O_Answer
O_active_failure
O_Active
O_Disconnect
Basic Call transition
O-BCSM describes basic calls and connections used in mobile

originated calls in MSCS or call forwarding in MSCS or
GMSCS. When call handling process moves to DP in O-BCSM
during call handling, call is temporarily suspended and its
handling condition is advised to gsmSSF, waiting for handling
instructions of gsmSSF.
3GPP defines eight DPs in the O-BCSM: DP2, DP3, DP4, DP5,
DP6, DP7, DP9 and DP10, covering static triggering point
TDP-R (that is, Trigger Detection Point-Request) and
dynamic event reporting points EDP-R (Event Detection
Point-Request) and EDP-N (Event Detection Point-
Notification).
DPs are described in Table 18.
TABLE 18 DESCRIPTION OF DPS IN THE O-BCSM
CAMEL DP DP TYPE Description

Indicates that the O-CSI is
DPCollected_Info TDP-R
analyzed
Indicates that the routing
DPAnalysed_Infor
TDP-R (note 2) address and address attributes
mation
are available


TDP-R
DPRoute_Select_ Indicates that the call
(note 3), EDP-
Failure establishment fails
N, EDP-R
Indicates that
- A busy signal is received from
the terminating party.
DPO_Busy EDP-N, EDP-R
- An unreachable event is
received from CAUSE IE of the
REL message of the ISUP.
Indicates that
- An application timer related
to O_No_Answer DP expires.
DPO_No_Answer EDP-N, EDP-R
- An unanswered event is
received in CAUSE IE of the
ISUP REL message.
Indicates that the call is
DPO_Answer EDP-N, EDP-R accepted and answered by the
terminating party
Indicates that a disconnect
indication is received from the
DPO_Disconnect EDP-N, EDP-R
terminating or the originating
party
Indicates that a disconnect
DPO_Abandon EDP-N, EDP-R
originating party during the call
establishment procedure
Note 1: These DPs are defined in ITU-T Recommendation

Q.1224.
Note 2: For TDP-R Analysed_Information, a new relation to
the gsmSCF will be set up.
Note 3: If relation with gsmSCF is not set up, DP
Route_Select_Failure will be reported as TDP-R; if the
relation with gsmSCF has been set up, DP
Route_Select_Failure will be reported as EDP.
With reference to CS-1 O-BCSM, among six “Points In Call
(PIC)” defined by ITU-T, “O_Null &
Authorise_Origination_Attempt” and “Collect_Info “ are
combined to form the five PICs in CAMEL Phase2 O-BCSM
model:
“O_Null&Authorise_Origination_Attempt_Collect_Info”,
“Analyse Information”, “Routing & Alerting”, “O_Active “ and
“O_Exception”.
O_Null & Authorise_Origination _Attempt_Collect_Info
When present call-handling instance is disconnected (O-
Disconnect) and originating end abandons call (O-Abandon)
at PIC “Analyse Routing & Alerting”, or when
gsmSSF/GMSCS completes its default abnormal handling and

detects other exceptions (O-exception), handling will move

into this PIC.
In the interval before a new call handling instance is
generated, model interface is null. When Setup message
from an MS is received, this PIC handling is started, covering
the following: checking MS outgoing call right (whether it is
an SS-BAOC or an ODB-BAOC) and performing
corresponding restriction; checking whether it is a CUG user
and its CUG right together with appropriate restrictions;
analyzing O-CSI subscription information.
After O-CSI is analyzed and approved, handling turns to DP2
(Collected_Info). If any abnormity arises during this PIC
handling, such as calling line disconnection, it will clear its
status and become null.
Analyze Information
After O-CSI analysis and DP2 (Collected Info) handling, call
handling process will move to this PIC. Moving into this PIC
in other circumstances belongs to non-basic call transfer. For
example, in DP4 (Route_Select_Failure), DP5 (O_Busy) and
DP6 (O_No_Answer) handling, gsmSSF instructs call
handling process to move to this PIC, or in DP9
(O_Disconnect) handling, gsmSSF instructs handling process
to move back to this PIC.
This PIC judges outgoing call right and other ODB restrictions
in first place. After judgment, related call information will be
analyzed according to the dialing plan. After judgment,
related call information will be analyzed according to dialing
plan.
Routing & Alerting
After passing “Analyze Information”, call handling process
enters this PIC and moves to T_BCSM. This PIC completes
corresponding signaling transfer and forwarding before
response from terminal.
If terminal makes response correctly, handling process will
move to DP7 (O_Answer). Before terminal responds, if
calling subscriber disconnects call, handling process will
move to DP10 (O_Abandon). If terminal indicates that call
fails to be established, process will move to DP4
(Route_Select_Failure). If terminal indicates that the
subscriber is busy or unreachable, process will move to DP5
(O_Busy). If terminal indicates that subscriber makes no
answer or discovers that subscriber response time expires,
process will move to DP6 (O_No_Answer). In other abnormal
cases, handling process moves to “O_Exception” PIC.
O_Active
After correct terminal response and DP7 (O_Answer)
handling, handling process will move to this PIC.

This PIC continues originating call handling, connecting

communication lines between caller and called, monitoring
calls and waiting for call release.
When either party of calling or called is disconnected,
handling process moves to DP9 (O_Disconnect); in other
abnormal cases, the process moves to “O_Exception” PIC.
O_Exception
In call handling instances, all abnormal cases that can
neither be handled normally nor defined with other handling,
the handling process will move to this PIC.
PIC winds up handling, covering performing default control,
releasing seized resources, ending conversation between
gsmSSF and gsmSCF, to guarantee that all O-BCSM
resources can be reused for new call handling instances.
After handling, the process will move to null status (O-NULL).
2. T-BCSM
T-BCSM is shown in Figure 149.
FIGURE 149 T-BCSM
T_Null T_Exception
T_Abandon
Terminating_Attempt_
Authorised
Terminating Call T_Busy

Handling
T_No_Answer
T_call_handling_failure
T_Disconnect
T_Answer T_active_failure
T_Active
Basic Call transition
T-BCSM describes basic calls and connections when

originating a mobile terminated call request in GMSCS. When
call handling process moves to a DP of T-BCSM, call is
temporarily suspended and its handling condition is advised
to gsmSSF, waiting for handling instructions of the gsmSSF.

3GPP defines six DPs in T-BCSM: DP12, DP13, DP14, DP15,

DP17 and DP18, covering static triggering point TDP-R and
dynamic event reporting points EDP-R and EDP-N.
DPs are described in Table 19.
TABLE 19 DESCRIPTION OF DPS (2)

DPTerminating_At Indicates that T-CSI/VT_CSI is
TDP-R
tempt_Authorised analyzed
Indicates that
- A busy indication is received
from the termination switch.
TDP-R - A busy event is received in
DPT_Busy (note 2), the VMSC
EDP-N, EDP-R
- An unreachable failure event
is received from the CAUSE IE
or HLR response of the ISUP
REL message
Indicates that
- An application timer related
TDP-R
to O_No_Answer DP expires.
DPT_No_Answer (note 2),
EDP-N, EDP-R - An unanswered event is
received in CAUSE IE of the
ISUP REL message;
Indicates that the call is
DPT_Answer EDP-N, EDP-R accepted and answered by the
terminating party
Indicates that A disconnect
DPT_Disconnect EDP-N, EDP-R
terminating or the originating
party
Indicates that A disconnect
DPT_Abandon EDP-N, EDP-R
originating party during the call
establishment procedure
Note 1: These DPs are defined in ITU-T Recommendation

Q.1224.
Note 2: If relation with gsmSCF is not set up, DP
T_NoAnswer and DP_T_Busy will be reported as TDP-R; if
relation with gsmSCF has been set up, DP
Route_Select_Failure will be reported as EDP.
ETSI defines four PICs in T-BCSM: “T_Null”, “Terminating
Call Handling”, “T_Active” and “T_Exception”.
T_Null
When present call handling instance is disconnected (T-
Disconnect) and originating end abandons call (T-Abandon)
at PIC “T-Abandon” or when gsmSSF/GMSC completes its

default abnormal handling and detects other exceptions (T-

exception), handling process will move to this PIC.
In the interval before a new call handling instance is
generated, the model interface is null. When an IAM
message is received from originating end, this PIC handling
will be started to analyze call information and send a routing
request message to HLR. HLR will complete the following
functions: checking MS incoming call right (whether it is an
SS-BAIC or an ODB-BAIC), and performing corresponding
restriction; checking whether it is a CUG user and CUG right,
together with appropriate restrictions. If MS subscribes to
the intelligent services, HLR transmits CSI information to
GMSCS for analysis.
After T-CSI analysis is received and approved, handling
process will move to DP12 (Terminating Attempt
AutIU_RELOCrised). If any abnormity arises during this PIC
handling, such as calling line disconnection, it will clear its
status and become null.
Terminating Call Handling
After T-CSI analysis and DP12 (Terminating Attempt
AutIU_RELOCrised), handling process will move to this PIC.
Moving to this PIC in other circumstances belongs to non-
basic call transfer. For example, in DP13 (T_Busy) and DP14
(T_No_Answer), gsmSSF instructs handling process to move
to this PIC again, while in DP17 (T_Disconnect) handling,
gsmSSF instructs to move back to this PIC.
If called party subscribes to intelligent services, this PIC will
send a secondary routing request to HLR, and judge
incoming call right and other ODB restrictions. After passing
above-mentioned Step, PIC will analyze corresponding call
information of HLR to select a network routing address and
move call processing to called VMSC. This PIC completes
corresponding signaling transfer and forwarding before any
response from terminal. It also originates call forwarding at
an appropriate time according to the conditions of UMTS
forwarding services.
If terminal answers normally, handling process will move to
DP15 (T_Answer). Before terminal answers, if calling party
disconnects call, handling process will move to DP18
(T_Abandon). If terminal indicates that subscriber is busy or
unreachable, handling process will move to DP13 (T_Busy).
If terminal indicates that subscriber does not answer or
discovers that subscriber response time expires, handling
process will move to DP14 (T_No_Answer). In other
abnormal cases, the handling will move to the “T_Exception”
PIC.
T_Active
After correct terminal response and DP15 (T_Answer)
handling, the handling process will move to this PIC.

This PIC continues the originating call handling, connecting

communication lines between caller and called, monitoring
the calls and waiting for call release.
When either party of calling line or called is disconnected,
handling process moves to DP17 (T_Disconnect); otherwise,
it moves to “T_Exception” PIC.
T_Exception
In call handling instances, all abnormal cases that can
neither be handled normally nor defined with other handling,
the handling process will move to this PIC.
PIC winds up handling, covering performing default control,
releasing seized resources, ending dialogues between
gsmSSF and gsmSCF, to ensure that all T-BCSM resources
can be reused for new call handling instances.
After handling, the handling process will move to null status
(T-NULL).
BCSM Call This part will describe how BCSM is embodied in UMTS.
Legend Introduction starts with logical units of this model in terms of
their distributed function plane. Segmentation of specific
physical entities will not affect the following functional
demonstration.
Mobile party A calls PSTN party B (or another subscriber).
Party A has O-CSI, which is detected and triggered.
Schematic diagram of originating BCSM of mobile subscriber
When mobile subscriber updates its location, O-CSI
subscription information is transmitted from HLR to VLR and
then saved in subscriber database. When mobile subscriber
originates a call request, gsmSSF will, at DP2, establish a
control relationship with gsmSCF, based on O-CSI analysis
and detection standards, and gsmSCF address and intelligent
ServiceKey in subscription message, as shown in Figure 150.
Subsequently gsmSCF controls or monitors this call service
handling at individual DPs according to service logic
requirements.

FIGURE 150 ORIGINATING BCSM OF MOBILE SUBSCRIBER
gsmSCF
(1)
CAMEL relationship
MSCS
gsmSSF/
CCF
O(A-B) T(A-B)
A-Party B-Party
PSTN party A (or another subscriber) calls mobile party B,

party B has T-CSI, which is detected and triggered.
Schematic diagram of terminating BCSM of mobile subscriber
Upon receiving a routing request message from GMSCS, HLR
detects that party B has T-CSI subscription information and
transmits it to GMSCS through a request acknowledgment
message. At DP12, gsmSSF will establish a control
relationship with gsmSCF (1) based on T-CSI analysis, and
gsmSCF address and intelligent ServiceKey in subscription
information, as shown in Figure 152. Subsequently, gsmSCF
(1) controls or monitors this call service handling at
individual DPs according to service logic requirements.
When call progresses to terminating VMSCS and if subscriber
is configured with VT-CSI subscription information, at DP12,
gsmSSF will establish a control relationship with gsmSCF (2)
based on T-CSI analysis, and gsmSCF address and intelligent
ServiceKey in subscription information, as shown in Figure
153. Subsequently, gsmSCF (2) controls or monitors this call
service handling at individual DPs according to service logic
requirements.
Note: gsmSCF (1) and gsmSCF (2) can be or may not be the
same SCP.

FIGURE 151 TERMINATING BCSM OF MOBILE SUBSCRIBER
PSTN party A (or another) calls party B. Party B has T-CSI

and is detected and triggered. Party B requests call to be
forwarded to PSTN party C (or another). Terminating call
forwarding of mobile subscriber is shown in Figure 152 and
Figure 153.
FIGURE 152 TERMINATING BCSM CALL FORWARDING OF MOBILE

SUBSCRIBER (1)
After HLR transmits T-CSI and O-CSI information of called

party B to GMSCS through routing request acknowledgment,
gsmSSF will establish a control relationship with gsmSCF(1),
based on the gsmSCF address and intelligent ServiceKey in
T-CSI subscription information (as CAMEL Relationship (1)).
Upon receiving the gsmSCF (1) instruction that the O-CSI is
available, gsmSSF will analyze O-CSI subscription
information and establish control relationship between
second service logic control and gsmSCF (2) based on the
analysis, (as CAMEL Relationship (2)). In their subsequent
handling, gsmSCF (1) and gsmSCF (2) will independently
control or monitor call service handling at individual DPs
based on their respective service logic requirements.

FIGURE 153 TERMINATING BCSM CALL FORWARDING OF MOBILE

SUBSCRIBER (2)
After HLR transmits T-CSI of party B to GMSCS through

routing request acknowledgment, according to gsmSCF
address and intelligent ServiceKey in T-CSI subscription
information, gsmSSF will establish a control relationship with
gsmSCF(1) (as the CAMEL Relationship (1) shown in Figure
153) and connect call to VMSCS where the called party is
located as required. If party B is busy or unreachable,
VMSCS will attempt to forward call control to GMSCS through
the call control recovery RCH request. This request contains
subscription information O-CSI of party B. After the
forwarding succeeds, the GMSCS establishes control
relationship with gsmSCF (2) (similar to that of Early Call
Forwarding). If forwarding fails, VMSC where party B is
located controls call, and establishes a control relationship
with gsmSCF (2) according to O-CSI subscription information.
In their subsequent handling, gsmSCF (1) and gsmSCF (2)
will independently control or monitor call service handling at
individual DPs based on their respective service logic
requirements.
Event DPs and According to BCSM, an event detection point (DP) is the key to
DP Criteria connecting basic call handling and intelligent call handling and is
an indispensable part in BCSM as well. DP is configured to advice
“intelligent service logic request”. If a DP is encountered, that is,
if any event is detected, gsmSSF will inform corresponding
gsmSCFs to establish control relationship and influence
subsequent call flows, or establish a monitoring relationship for
call action monitoring, otherwise, original call will be continued
without involving the gsmSCF. Detected events to be advised to
gsmSCF are measured by certain criteria (DP Criteria), that is, it
must be made clear that when such events can be called
detected events.
Detection points can be divided into statically configured DPs
and dynamically configured DPs. There are three kinds of DPs in
CAMEL: TDP_R (Trigger Detection Point-Request), EDP_R (Event
Detection Point-Request) and EDP_N (Event Detection Point-
Notification). Where, TDP_R is statically configured. If an event
is detected, a CAMEL control relationship is established, and call

process is paused, waiting for the instruction of gsmSCF. EDP_R

is dynamically configured according to contents in CAMEL control
relationship. If an event is detected, it pauses call process,
waiting for gsmSCF instruction. EDP_N is dynamically configured
according to contents in CAMEL control relationship. If an event
is detected, it informs the gsmSCF of the progress, while
continuing call process.
TDP_R: Trigger Detection Point-Request
EDP_R: Event Detection Point-Request
EDP_N: Event Detection Point-Notification
DP2 (Collect Info) is a statically configured, and subscription

information O-CSI indicates configuration of TDP_R. DP3
(Analyse Info) is a statically configured TDP_R, and subscription
of subscriber information D-CSI indicates configuration of TDP_R.
DP12 (Terminating Attempt AutIU_RELOCrised) is a statically
configured TDP_R, and subscription of subscriber information
T/VT-CSI indicates the configuration of TDP_R. TDP_R can be
configured or disarmed through subscription (“Provision”) or
deletion (“Erase”) of the O/D/T/VT-CSI at the Agent console. But
operations cannot influence service handling in progress in time.
In CAMEL Phase3, all DPs except DP2/DP3/DP12 are dynamically

configured EDP_R or EDP_N. According to requirements of
service handling logic, gsmSCF identifies EDP configuration in
the event reporting request operation of control relationship.
However, EDP disarming should follow the following principles:
1. If call service handling is released, all configured EDPs will be

disarmed.
2. If a call segment (Leg) is released, all related EDPs will be
disarmed.
3. Any EDP encountered during call service handling will be
disarmed after handling; and other EDPs with default
disarming relation with this EDP will be also disarmed.
4. gsmSCF, through event request report, defines EDPs that
should be disarmed but not yet.
DP disarming relations in the O-BCSM are shown in Table 20.
TABLE 20 DP DISARMING RELATIONS IN THE O-BCSM
Implying DPs to be Disarmed

DP DP9 DP9
Encountered DP1
DP4 DP5 DP6 DP7 Leg Leg 0
1 2
DP4
Route_Select_Fai X X X X X
lure

Implying DPs to be Disarmed

DP DP9 DP9
Encountered DP1
DP4 DP5 DP6 DP7 Leg Leg 0
1 2
DP5 O_Busy X X X X X
DP6
X X X X X
O_No_Answer
DP7 O_Answer X X X X X
DP9
O_Disconnect X X
Leg1
DP9
O_Disconnect X X X X X
Leg2
DP10 O_Abandon X X
DP disarming relations in the T-BCSM are shown in Table 21.
TABLE 21 DP DISARMING RELATIONS IN THE T-BCSM
DP Implying DPs to be Disarmed

Encou DP 17 DP 17
ntered DP 13 DP 14 DP 15 DP 18
Leg1 Leg2
DP13
X X X X
T_Busy
DP14
T_No_A X X X X
nswer
DP15
T_Answ X X X X
er
DP17
T_Disco
X X
nnect
Leg1
DP17
T_Disco
X X X X
nnect
Leg2
DP18
T_Aban X X
don
Detection criteria (Criteria) are prerequisites for gsmSSF to

establish dialogues with gsmSCF and to request instructions.
Only TDP_R has the Criteria.
As to MTCs (mobile terminated calls), HLR is responsible for
checking whether the criteria are met or not. HLR contains
triggering table of criteria for up to five types of basic services
(or basic service groups). When HLR detects that basic service of

a mobile call meets triggering condition, that is, requested basic

service is in triggering table of criteria or is a member of basic
service group in table, HLR will send the CAMEL subscription
information to GMSCS in routing request, otherwise, it will reject
transmission.
For VTCs, VLR checks whether criteria are satisfied. Check
method is similar to that of HLR.
As to MOCs (Mobile Originated Calls), VMSCS_gsmSSF is
responsible for checking whether the criteria are met. For
forward calls determined by HLR, HLR will check whether criteria
are met, and thereby decide whether to send O/D-CSI to GMSCS.
Criteria are different at different DPs.
For DP2 Collect Info, criteria contain destination number
triggering criteria, forward service triggering criteria and basic
service triggering criteria. Where, the first two are subdivided
into “enabling” and “inhibiting” statuses, which feature different
check handling. At most 10 destination numbers and/or three
number lengths are contained in destination number triggering
criteria, and there is no restriction to number address property
or numbering scheme. At most five basic service numbers or
basic service group numbers are contained in basic service
triggering criteria. Forwarding service triggering criteria contain
flags indicating whether CAMEL handling is triggered when UMTS
forwarding or CAMEL forwarding occurs.
For DP3 Analyse Info, criteria are number triggering principles: A
number table contains 1 to 10 destination numbers, and each
number corresponds to a gsmSCF address and a Servicekey.
Each TDP_R can have one or more criteria. But note that only
when all Criteria are met can the event be regarded as detected
events and dialogues with the gsmSCF are set up.
Comparison of 1. Basic call processing

Call Processing
This part introduces the traditional basic call processing flow
Flows
in UMTS mobile network system. With the combination of the
call processing flow of mobile IN, we can have a clear picture
of how CAMEL intelligent processing is different from basic
call processing, how it is introduced into UMTS network in
terms of technical mechanism.
Basic call processing in UMTS falls into three parts: basic call
MO processing, basic call route processing and basic call MT
processing.
MO processing flow of the basic call in the UMTS is shown in
Figure 154.

FIGURE 154 MO PROCESSING FLOW OF THE BASIC C ALL IN THE UMTS
MSa RNCa MSCSa VLRa

CM service Req
CM service Req
Process access Req
Authenticate
Authenticate
Authenticate
Authenticate Rsp
Authenticate Rsp
Authenticate Ack
Set Cipher mode
Process access Ack
Start Ciphering
Cipher Mod Cmd
Cipher Mod Comp
Cipher Mod Comp
Setup
SIFOC
Complete Call
Call Proceeding
RAB Assign Req

Assignment Cmd B Party
Assignment Comp
RABAssign Rsp
IAM
ACM
Alerting
ANM
Connect
Connect Ack
CONVERSATION
Disconnect
REL
Release
RLC
Release Comp
A mobile subscriber of UMTS initiates a call through a mobile

terminal that completes service access process in the first
place. CM_Service_Req message sent by MS contains service
type (for example, MO) and MS ID (such as IMSI and TMSI)
of this request. This message is forwarded by RNC and MSCS,
requesting network access service to VLR where subscriber
registers. After VLR initiates such operations as
authentication and encryption for subscribers and judges
them as passed, VLR will notify MS to allow service access.
Then MS sends a Setup message, transmitting information
(containing number dialed by subscriber) related to this call
directly to MSCS through A interface or Iu interface signaling
channel. MSCS will inform VLR of the outgoing call request of
this subscriber.
After receiving outgoing call request from subscriber, VLR
will first verify basic service right and outgoing call right of
this subscriber. Basic service right includes service rights
such as basic voice service, fax service and data service. If
the subscriber has not applied for any corresponding service,
this service request will be rejected. Judging outgoing call
right means checking whether operator bars all outgoing
calls (ODB-BAOC) from this subscriber and whether
subscriber has activated barring of all outgoing calls (SS-
BAOC). Generally, if subscriber is in arrears or his SIM is

reported as lost, operator will set ODB-BAOC for him. If

necessary, subscriber can also set SS-BAOC by activating
supplementary services to bar outgoing calls. If the
subscriber passes above check, VLR will check if this call is a
CUG call and CUG call right of subscriber, check and set
attributes of the subscriber number presentation restriction
and AOC attribute of this subscriber.
If subscriber subscribes to the O/D-CSI attribute of mobile IN
service, the VLR will launch intelligent call processing flow.
Otherwise, VLR will continue to check whether carrier has
determined to bar ODB-BOIC or ODB-BOIC_exHC from
subscriber, and whether subscriber has activated such call
barring as SS-BOIC or SS-BOIC_exHC. VLR will also process
some service restrictions defined by carrier, such as toll call
barring and IP call barring.
After completing and passing the check of all service rights,
VLR will send a CompleteCall message to MSCS, notifying
MSCS to provide services to this subscriber. MSCS notifies
MS that the call has been accepted for processing by sending
a Callproceeding message, and meanwhile sends an RAB
assignment request message to RNC requesting RNS to
establish a traffic channel connection between MS and MSCS.
After receiving RAB assignment response message indicating
that traffic channel is ready, MSCS will perform call route
processing based on the number dialed by subscriber. This
processing covers such contents: Sending IAM message to
subsequent end office (or tandem office) through No7
signaling network, forwarding ACM message from the
subsequent office to MS as an Alerting message, forwarding
ANM message to MS as a Connect message. After MS returns
a ConnectAck response, MSCS will connect call circuit. In this
way, calling MS and called MS can communicate with each
other.
After call is completed, subscribers hook on. Following the
release flow (Disconnect, Release and ReleaseCmp) of MS,
MSCS disconnects the call, records information related to call
and reports call records for billing center to sum up tickets
and calculate call charges.
Route processing flow of basic call in UMTS is shown in
Figure 155.

FIGURE 155 ROUTE PROCESSING FLOW OF THE BASIC CALL IN THE UMTS
A Party GMSCS HLRb VLRb MSCSb

IAM
SRI
PRN
PRN Ack
SRI Ack
IAM
ACM
ACM
ANC
ANM
CONVERSATION
REL
REL
RLC
RLC
Due to mobility of MS, before the network is connected to

called mobile subscriber, it is required to query current
location of subscriber from home HLR according to ISDN
number of this MS. This network function is called GMSCS
routing function. If caller is a mobile subscriber and shares
same operation network as the called subscriber, then
routing function is provided by originating MSCS; otherwise,
it will be provided by gateway MSCS on the operation
network to which the called subscriber belongs.
According to ISDN number of the mobile subscriber, GMSCS
sends SendRoutingInformation message to HLR of subscriber.
This message contains ISDN number, CUG information,
bearer information, GMSCS address (MAP2+) and CAMEL
capacity (MAP2+). After checking validity of SRI message
parameters, HLR will retrieve in the subscriber database. If
subscriber exists, HLR will check subscriber service right and
incoming call right, and check whether carrier determines to
bar all incoming calls (ODB-BAIC) and whether subscriber
has activated barring of all incoming calls (SS-BAIC).
Generally, if subscriber is in arrears or SIM is reported lost,
the carrier will set this subscriber to ODB-BAIC. If necessary,
subscriber can also set SS-BAIC by activating supplementary
service to bar incoming calls. If above check is passed, HLR
will check if this call is a CUG call and CUG call right of this
subscriber.
If subscriber subscribes to T-CSI attribute of mobile IN
services, HLR will initiate intelligent call processing flow.
Otherwise, HLR will continue to check whether the carrier will
determine to bar ODB-BIC_Roam for subscriber, and whether
the subscriber has activated SS-BIC_Roam.
After the check of all service authorities is completed and
passed, if subscriber activates CFU, HLR will request GMSCS
to forward this call and provide the forwarded number in the
SRI_Ack message. If the subscriber’s location is uncertain
and the CFNrc has not been subscribed or activated, HLR will

return absent error of the subscriber and GMSCS will release

the call. If subscriber has not subscribed to or activated CFU
service and its location is certain, the HLR will send
ProvideRoamingNumber request to VLR where the subscriber
is located according to VLR address registered in MS location
update, requesting the VLR to allocate a temporary
addressable roaming number MSRN to this subscriber and
return MSRN in PRN_Ack message. HLR sends in SRI_Ack
message IMSI number and MSRN to GMSCS.
GMSCS performs call route processing based on roaming
number. Such processing involves sending the IAM message
to subsequent end office (or tandem office) through No.7
signaling network, forwarding ACM and ANM messages from
subsequent office to the previous end office, and connecting
call circuit as required. In this way, calling and called mobile
subscribers can communicate with each other.
After the call is completed, the subscribers hook on. GMSCS
records call roaming information and reports call records for
billing center to sum up tickets and calculate call charges.
MT processing flow of basic calls in UMTS is shown in Figure
156.
FIGURE 156 MT PROCESSING FLOW OF BASIC CALLS IN THE UMTS
GMSC VLRb MSCSb RNCb MSb

IAM
SIFIC
Page MS
Page
Page
Chan Req
Imm Ass
Page Rsp
MS Conn Estab
Process access Req
Set Cipher Mode

Process access Ack
Start Ciphering
Cipher Mod Cmd
Cipher Mod Comp
Complete Call
Setup
Call Confirm
RAB Assign Req
Assignment Cmd
RAB Assign Rsp
Assignment Comp
Alerting
ACM
Connect
ANM
Connect Ack
Complete Call Ack
CONVERSATION
REL
Disconnect
RLC
Release
Release Comp

Mobile terminal exchange receives IAM message that

contains MSRN temporarily allocated to the called mobile
subscriber. MSCS informs VLR of the incoming call request of
MS through SIFIC message with MSRN. Since the
corresponding relationship between MSRN and called
subscriber has been established when VLR is allocating
roaming number, VLR can obtain correct information about
called subscriber once it receives SIFIC message. VLR begins
to page the MS; and MSCS forwards PAGING message to the
RNS, which instructs the paging of mobile terminal on radio
channel.
When MS detects the paging message for itself, it will
request the RBS to allocate a traffic channel immediately and
then send a paging acknowledgement message after
preparations. RNS reports to the MSCS that connection has
been established according to paging response message, and
starts access process of MS. This service access process is
similar to that of a mobile originated call.
After the service is accessed successfully, VLR sends a
CompleteCall message to MSCS, instructing MSCS to provide
services for this subscriber. MSCS sends a Setup message to
MS, carrying the bearer capability request of the traffic
channel of this call and waiting for the CallConfirm message
from MS. MS can contain the bearer capability information in
this message to indicate the capability negotiation result.
Then MSCS requests RNC to allocate a traffic channel as
required.
After returning CallConfirm message, MS can immediately
send alerting message and begin to ring, prompting the
subscriber of an incoming call. MSCS is responsible for
sending Alerting message to previous end office stage by
stage and providing ringing tone, so that the caller can hear
ringing from called subscriber. If called subscriber hooks off,
MS sends a Connect message to notify MSCS to connect the
call. MSCS returns a ConnectAck message, indicating
completion of the connection, and calling and called
subscribers can communicate with each other. Call is ended
if one party hooks on. MSCS records information related to
the call and reports call records for billing center to sum up
tickets and calculate call charges.
2. Intelligent call processing
According to BSCM, the BCSM splits basic call processing flow
into several parts: PIC, DP, transfer process and events, thus
to introduce intelligent control based on basic calls of UMTS.
When the call processing moves to DP, call control will be
taken over by intelligent processing module and call will be
invoked or forwarded to corresponding PIC for processing
according to the instructions of intelligent processing module.
This intelligent processing module uses DPs to trigger and
control call processing, and transfer process and events
make it possible to provide flexible intelligent control over

the service flow. PIC is used as a call functional module for

service combination.
Due to technical mechanism of intelligent call processing,

different intelligent services have different signaling flows for
different intelligent services. However, control mechanisms
of intelligent calls are similar. To better understand technical
mechanism of mobile intelligent calls, we describe signaling
flow by taking MPPS as an example. Thus, we can
understand functions of intelligent processing module and
differences in contrast to the processing flow of basic calls of
UMTS.
MO flow of MPPS is shown in Figure 157.
FIGURE 157 MO FLOW OF MPPS
MSa MSCSa VLRa MSCSa

/SSF
CM service Req Process access Req
Service processing flow (authentication and

encryption processing )
CM service Accept
Setup
SIFOC
Complete Call (O/D-CSI)
Call Proceeding
Assign service
Invoke
_gsmSSF
channels
gsmSSF_ Invoked
TDP _Collect _Info

IDP (To SCP1)
RRBE (From SCP1)
AC (From SCP1)
Int_Continue Conti(From SCP1)
Invoke_gsmSSF
gsmSSF_Invoked
TDP_Analyse_Info
IDP(To SCP 2)
Int_Connect Connect(From SCP2)
SIFOC_2
SIFOC_2_Ack
B Party
IAM
ACM
Alerting
ANM
Connect
Connect Ack
CONVERSATION
Release by the Int_EventReport

calling party ACR( To SCP1)
ERB(To SCP1)
Int _ReleaseCall RelCall(From SCP1)
REL
RLC
If a mobile intelligent service subscriber in UMTS originates a

call with a mobile terminal, service access process is
completely the same as that of an ordinary subscriber. When
VLR judges that the subscriber has subscribed to the O/D-
CSI attribute of the mobile intelligent service, VLR will send a

CompleteCall message (containing O/D-CSI information) to

MSCS, and then enter intelligent call processing flow, waiting
for second outgoing call request from MSCS.
After receiving O/D-CSI information of subscriber and
completing interaction with mobile phone and RNC, MSCS
will enter DP2 in the BCSM. At this DP, MSCS first activates
SSF functions (sending Invoke_gsmSSF message) of
intelligent processing module, and then the system waits for
instruction on interaction between SSF and intelligent
network SCF (provided by SCP1 functional entity).
After analysis of O-CSI information, MSCS/SSF intelligent
processing module judges that service logic control
relationship with SCP1 needs to be established. Therefore,
MSCS/SSF returns an activation acknowledgement to MSCS,
and also sends an InitialDP message to SCP1 that provides
services through SS7 system according to SCF address in O-
CSI. Message contains such call information as the sKEY,
caller’s ISDN number, caller’s IMSI, caller’s location
information, number dialed by the subscriber and service
type.
According to the information in IDP, SCP1 activates related
services, retrieves in the subscriber database, performs
service logic and provides service support. In PPS
specifications defined by China Mobile Communications
Corporation (CMCC), SCP analyzes caller’s account
immediately after receiving IDP message. If account is valid,
SCP will determine caller’s charging rate according to area
code (Location Number in IDP) of caller’s visitor location and
area code of called party, and then converts balance into call
duration. SCP1 will send a RequestReportBCSMEvent
message in turn and sets EDPs DP4//5/6/9, so that in such
events as route selection failure, called subscriber busy,
called subscriber’s no reply and called subscriber on-hook,
call flow can notify SCP1 and wait for instruction of SCP1.
Furthermore, SCP1 sends an ApplyCharging message to
inform SSF of maximum call duration available for subscriber,
hoping SSF to control the call time and report timeout events
to SCP1. In addition, SCP1 sends a Continue message to
instruct SSF to continue the call processing.
As SCP1 sets related intelligent control conditions in RRBE
and AC messages, SSF will establish triggering conditions,
report call conditions and monitor call duration in consequent
processing.
SSF forwards the Continue message to the MSC, requiring
the MSCS to analyze the PIC according to the normal
handling flow.
At the “Analyze Information” PIC, if subscriber has
subscribed to D-CSI at the same time, it is necessary to
decide whether to trigger at DP3 Analyse Info according to
related DP triggering criteria. If triggering conditions are
satisfied, SSF will send an IDP message to gsmSCF2 related

to this DP, permitting SCP2 to modify called address and

call-related information and to provide the charging
information. However, this dialogue does not allow SCP2 to
configure the DP and charging, to avoid that a BCSM is
controlled by two service logics at the same time. After
gsmSCF2 receives the Connect or Continue operation,
relationship with gsmSCF2 is ended. Call process enters
routing and “Routing & Alerting” PIC. MSCS sends second
outgoing call request to VLR, and VLR continues with the
judgment uncompleted in first outgoing call request,
covering such call barring as ODB-BOIC, ODB-BOIC_exHC,
SS-BOIC and SS-BOIC_exHC, as well as service restriction
defined by carrier, such as toll call barring and IP call barring.
After all these tests have been passed, VLR will return a
correct response to MSCS.
According to called number, MSCS performs call route
processing, that is, sending IAM message to subsequent end
office (or tandem office) through SS7 network, forwarding
ACM message from subsequent office to MS as the Alerting
message. Since SCP does not require to set the called on-
hook DP (that is, DP7), the MSCS directly begins “activating”
the PIC processing after receiving ANM message, and
forwards ANM message to MS as the Connect message. After
MS returns ConnectAck message, MSC connects the call
circuit. In this way, calling and called mobile subscribers can
communicate with each other. SSF is responsible for
monitoring the call duration periodically.
When any party of the call hooks on, MSCS enters the DP9,
informing SSF of the Disconnect event and waiting for its
instruction. Since SCP has configured DP9, the SSF is
responsible for reporting charging result
“ApplyChargingReport” and on-hook event of subscribers
(EventReportBCSM) to SCP, and also releases the call
according to ReleaseCall message issued by the SCP. SCP
calculates actual call charge based on ACR contents, and
deducts them from subscriber’s account. Meanwhile,
charging tickets are generated and reported to billing center.
When call is ended, MSCS disconnects the call circuit, records
call-related information and reports call records for billing
center to sum up tickets and check call charges.
Routing flow of MPPS is shown in Figure 158.

FIGURE 158 ROUTING FLOW OF THE MPPS
A Party GMSCS HLRb GMSCS/SSF VLRb MSCSb

IAM
SRI
PSI
PSI_Ack
SRI Ack(T_CSI)
Invoke_gsmSSF
gsmSSF_Invoked
TDP_TAA
IDP (To SCP)
RRBE(From SCP)
AC(From SCP)
Conti(From SCP)
Int_Continue
SRI(T_CSI Supp)
PRN
PRN_Ack
SRI Ack(MRSN)
IAM
ACM
ACM
ANC
ANM
CONVERSATION
REL
RLC
Int_EventReport
ACR(To SCP)
ERB(To SCP)
RC(From SCP)
Int_ReleaseCall
REL
RLC
As mentioned above, before being connected to called mobile

subscriber, the network needs to execute GMSCS routing
function. When HLR of subscriber receives SRI message, it
will determine call right of the subscriber. After that, if
subscriber has subscribed to T-CSI attribute of mobile
intelligent service, HLR will initiate the intelligent call flow.
If HLR is required to provide subscriber’s location and status
information in system configuration, HLR will send
ProvideSubscriberInformation message to current VLR of
subscriber, requesting VLR to feed location area of subscriber
login and busy/idle status back to HLR. HLR will send this
information and T-CSI contents in SRI-Ack message to
GMSCS. At this moment, HLR has not requested VLR to
allocate roaming number, which is different from the route
processing flow of basic calls in UMTS.
When GMSCS receives routing response with T-CSI
information, it will know that the called subscriber is a mobile
intelligent service subscriber; and call processing flow enters
the DP12. At this DP, the GMSCS first activates the SSF
functions of intelligent processing module (sending
Invoke_gsmSSF message), and system waits for the
instruction on interaction between SSF and SCF (provided by
SCP functional entity).

After analyzing T-CSI information, GMSCS/SSF intelligent

processing module decides that service logic control
relationship with SCP needs to be established. Therefore,
GMSCS/SSF returns an activation acknowledgement to MSCS,
and also sends an InitialDP message to SCP that provides
services through SS7 system according to SCF address in T-
CSI. Message contains call information extracted from V-CSI,
such as sKEY, caller’s ISDN number, caller’s IMSI, caller’s
location information, number dialed by subscriber and
service type.
According to the information in IDP, SCP activates related
services, retrieves in subscriber database, performs service
logic and provides service support. After receiving IDP
message, SCP first analyzes account of called subscriber. If
account is valid, SCP will define the charging rate according
to home location and actual location of called subscriber, and
then converts balance into call duration. The SCP will send
RequestReportBCSMEvent message in turn to configure EDPs
DP13/14/17, so that in such events as route selection failure,
called busy, called no reply and called on-hook, call flow can
notify the SCP and wait for instruction of the SCP.
Furthermore, the SCP sends ApplyCharging message and to
inform the SSF of maximum call duration available for the
subscriber, hoping SSP to control call time, report timeout
event to the SCP. In addition, SCP sends Continue message
to instruct SSF to continue call processing.
Since SCP sets related intelligent control conditions in RRBE
and AC messages, SSF will establish triggering conditions,
report call conditions and monitor call duration in subsequent
processing.
SSF forwards Continue message to GMSCS, requiring GMSCS
to enter “terminating call processing” PIC according to
normal processing flow. GMSCS sends the second routing
request to HLR, carrying the T-CSI suppression parameters
to distinguish from the first routing. HLR continues with the
judgment such as ODB-BIC_Roam and SS-BIC_Roam that
are not completed in the first routing request. After all these
tests are passed, HLR sends a PRN request to current VLR of
the subscriber, requiring VLR to allocate a temporary
addressable roaming number MSRN to this subscriber, and
return through PRN_Ack message. HLR sends in SRI_Ack
message the IMSI number and MSRN to GMSCS.
According to roaming number, the GMSCS performs call
route processing, that is, sending IAM message to the
subsequent end office (or tandem office) through SS7
network, and forwarding ACM message to the previous end
office. Since SCP does not require setting called off-hook
DP15, GMSCS directly begins “activating” PIC processing
after receiving ANM message, and connects the call circuit as
required. In this way, calling and called mobile subscribers
can communicate with each other. SSF is responsible for
monitoring call duration periodically.

When any party of call hooks on, MSCS enters DP17,

instruction. Since SCP has configured DP17, SSF is
(EventReportBCSM) to SCP, and also releases the call
according to ReleaseCall message issued by SCP. SCP
calculates actual call charge based on ACR contents, and
deducts them from the subscriber’s account. Meanwhile,
charging tickets are generated and reported to billing center.
GMSCS records the roaming information and reports call
records for billing center to sum up tickets and check call
charge.
MT flow of MPPS is shown in Figure 159.
FIGURE 159 CALLED SERVICE FLOW OF MPPS
GMSCS VLRb MSCSb RNCb MSb

IAM
SIFIC
Page MS
Page
Page
Chan Req
Imm Ass
Page Rsp
MS Conn Estab
Process access Req
Set Cipher Mode

Process access Ack
Start Ciphering
Cipher Mod Cmd
Cipher Mod Comp
Complete Call SSF
(VT-CSI) Invoke_gsmSSF
gsmSSF_Invoked SCP
TDP_TAA
IDP (To SCP)
RRBE(From SCP)
AC(From SCP)
Conti(From SCP
)
Int_Continue
Setup
Call Confirm
RAB Assign Req
Assignment Cmd
RAB Assign Rsp
Assignment Comp
Alerting
ACM
Connect
ANM
Connect Ack
Complete Call Ack
CONVERSATION
REL
SSF SCP
RLC
Int_EventReport
ACR(To SCP)
ERB(To SCP)
RC(From SCP)
Int_ReleaseCall
Disconnect
Release
Release Comp

As mentioned in MT call flow, mobile terminating office

receives IAM message that contains MSRN temporarily
allocated to called mobile subscriber. MSC inform VLR of the
incoming call request of the MS of MSRN through SIFIC
message. Since the corresponding relationship between
MSRN and the called subscriber has been established when
VLR is allocating the roaming number, VLR can obtain the
correct information about the called subscriber once it
receives SIFIC message. The VLR starts to page MS and
enters service access process. This process is similar to basic
call flow.
After successful service access, since this subscriber is a
CAMEL subscriber, VLR checks whether call meets triggering
conditions according to triggering criteria in VT-CSI of
subscriber. If call meets the triggering conditions, VLR will
send VT-CSI of the MS to the MSCS by means of a
CompleteCall message. After receiving the CompleteCall
message containing VT-CSI, MSCS will know that called
subscriber is a mobile intelligent service subscriber, so call
handling flow enters DP12. At this DP, GMSC first activates
the SSF functions of intelligent processing module (sending
Invoke_gsmSSF message), and the system waits for
instruction on interaction between SSF and SCF (provided by
SCP functional entity).
After analysis of T-CSI information, VMSC/SSF intelligent
processing module judges that service logic control
relationship with SCP needs to be established. Therefore,
GMSC/SSF returns an activation acknowledgement to MSCC,
and also sends an InitialDP message to SCP that provides
services through SS7 system according to SCF address in T-
CSI. message contains call information extracted from the T-
CSI, such as sKEY, caller’s ISDN number, caller’s IMSI,
caller’s location information, number dialed by subscriber and
service type.
According to the information in IDP, SCP activates related
services, retrieves in subscriber database, performs service
logic and provides service support. After receiving IDP
message, SCP first analyzes account of called subscriber. If
the account is valid, SCP will define charging rate according
to the home location and actual location of the called
subscriber, and then converts the balance into call duration.
SCP will send the RequestReportBCSMEvent message in turn
to configure EDPs DP13/14/17, so that in such events as the
route selection failure, called busy, called no reply and called
on-hook, call flow can notify SCP and wait for the instruction
of the SCP. Furthermore, the SCP sends the ApplyCharging
message and to inform the SSF of maximum call duration
available for the subscriber, hoping SSP to control call time,
report timeout event to the SCP. In addition, SCP sends the
Continue message to instruct the SSF to continue call
processing.

Note: A mobile called process possibly will trigger CAMEL

service in the GMSCS and VMSCS independently, and the two
services may be on the same SCP or on different SCPs, so
the carrier must consider how to implement charging in
service configuration; otherwise, repeated charging may be
caused.
Since SCP sets the related intelligent control conditions in
RRBE and AC messages, SSF will establish the triggering
conditions, report call conditions and monitor call duration in
subsequent processing.
SSF forwards Continue message to VMSCS, and MSCS
continues the processing according to basic call flow. MSCS
sends a Setup message to MS, carrying bearer capability
request of traffic channel of this call and waiting for
CallConfirm message from MS. MS can contain bearer
capability information in this message to indicate the
capability negotiation result. Then MSCS requests RNC to
allocate a traffic channel as required.
After returning CallConfirm message, MS can immediately
send alerting message and begin to ring, prompting the
subscriber of an incoming call. MSCS is responsible for
sending the Alerting message to the previous end office
stage by stage and providing ringing tone, so that the caller
can hear ringing from the called subscriber. If the called
subscriber hooks off, MS sends the Connect message to
notify MSCS to connect the call. MSCS returns a ConnectAck
message, indicating the completion of the connection, and
calling and called subscribers can communicate with each
other.
When any party of the call hooks on, MSCS enters DP17,
instruction. Since SCP has configured the DP17, SSF is
(EventReportBCSM) to SCP, and also releases call according
to the ReleaseCall message issued by SCP. SCP calculates
actual call charge based on ACR contents, and deducts them
from subscriber’s account. Charging tickets are generated
and reported to billing center. VMSC records roaming
information and reports call records for charging center to
sum up tickets and check call charge.
Introduction of BCSM enables service processing of mobile
intelligent services to be integrated into basic call processing
of UMTS, providing enough processing flexibility. Although
flow is introduced with PPS as an example, the processing
modes of other mobile intelligent services are almost the
same. Most apparent difference is the CAP interface
operation combination and corresponding operation
parameters.

Short Message Service

Overview
Introduction 1. Category
SMS falls into two parts: Point-to-point SMS and broadcast
SMS. However, only point-to-point SMS is involved in mobile
switching center.
Point-to-point SMS is a service to transmit length-limited
messages between UMTS PLMN mobile stations and Short
Message Entity (SME) through a Service Center (SC). SC can
store and forward messages, constituting a short message
processing entity that integrates storing, exchanging and
trunk functions. However, function of UMTS PLMN is to
support short message transfer between SC and MSs.
Point-to-point SMS falls into mobile-originated short message
(SM MO) and mobile-terminated short message (SM MT). SM
MO means MS sends short messages to SC, and these
messages may also be sent to other MSs or subscribers of
fixed network. SM MT means the SC forwards short
messages to MS, and these messages may come from MS
(SM MO), voice channel, telegraph, or fax.
2. Point-to-point SMS processing flow
Point-to-point SMS processing flow are divided into three
parts:
SM MO processing flow SM
MT processing flow
Transmission of alert messages
Topics Page No.

SM MO Processing Flow 236
SM MT Processing Flow 237
Alerting Message Processing Flow 239
SM MO Processing Flow
Flow Chart SM MO processing flow is shown in Figure 160.

FIGURE 160 SM MO PROCESSING FLOW
Descriptions of 1. STEP1
the Flow
To send a short message, MS needs to first set up an MM
connection and send a CM_SER_REQ service request
message to the MSCS/VLR. MSCS/VLR returns a
CM_SER_RSP message or a CM_SER_RJT message to the MS.
If MSCS/VLR has sent service response message, it will
authenticate MS.
2. STEP 2
MS sends a short message CPDATA to MSCS/VLR. After
receiving message, MSCS/VLR checks whether the short
message service is restricted or barred by the supplementary
service. If SM processing is not barred, MSCS/VLR will send
it to IWMSC (inter-working MSC), the interface with SC.
3. STEP3
After SC receives short message sent from MS, it will return
the processing result to the MS. After receiving Delivery
Report message, MSCS/VLR will send an acknowledgement
message to the MS.
SM MT Processing Flow
Flow Chart SM MT processing flow is shown in Figure 161.

FIGURE 161 SM MT PROCESSING FLOW
SC IW/GMSC HLR MSC/VLR MS

MESSAGE_TRANSFER
SEND_ROUTING_INFO
FOR_SHORT_MSG
FORWARD_SHORT_MESSAGE
STEP1
PAGE
PAGE_RSP
STEP2
CPDATA(RPDATA)
CPDATA(RPACK)
STEP3
DELIVERY REPORT
DELIVERY REPORT
DELIVERY REPORT
STEP4
Descriptions of 1. STEP1:
the Flow
If short message that SC receives is destined for a mobile
subscriber, SC will send it to the ingress GMSCS that short
message belongs to. Ingress GMSCS then sends a route
request message to HLR. And HLR finds out MSCS/VLR route
and then sends routing information to the GMSCS. According
to the routing information, GMSCS finds out MSCS/VLR to
which the MS belongs, and sends short message to
MSCS/VLR.
2. STEP 2
After receiving Forward_short_message, the MSCS/VLR will
directly returns a delivery failure message to the GMSCS if
VLR does not have any data related to MS, and will send a
PAGE message to MS if the VLR contains data related to MS.
After MS returns a PAGE-RSP message, SC will perform
authentication to verify whether the subscriber is legal.
3. STEP 3
After subscriber is proved legal, MSCS/VLR will send a short
message to MS. After receiving short message, MS will
return processing result to MSCS/VLR: If processing is
successful, returned result is an acknowledgement message,
otherwise, it is the cause of the failure. If MS has no enough
space to store short message, it will inform the SC of storage
capacity shortage in the failure cause.
4. STEP4
After receiving acknowledgement message from MS,
MSCS/VLR will convert the message into MAP signaling and
sends it to GMSCS, and then GMSCS will forward it to SC.

Alerting Message Processing Flow

Overview There are two flags for short messages in HLR: MNRF (MS
unreachable flag as in VLR) and MCEF (unavailable MS storage
capacity). If the two flags are set to 1s, SC will send no
messages to MS. Therefore, when MS is reachable or there is
available memory capacity, MSCS/VLR will send alert message
to HLR to initiate a series of operations.
Case 1 (In When MNRF in HLR is set to 1 while the MCEF is not set to 1,
Both the HLR and MS is reachable, the MSCS/VLR will send a notification
and VLR, MNRF message to HLR. And HLR will think the SC can send short
Is Set to 1, and messages to MS, and thus sending an alert message to SC.
MCEF in HLR Service flow is shown in Figure 162.
Ss not Set to 1)
FIGURE 162 ALERT MESSAGE FLOW (1)
SC SMS_IWMSC HLR MSCS/VLR MS
Ready For SM
Alert Service Center
When the MSCS/VLR discovers that the MS responds to a call or

the PAGE message of other services (that is, the subscriber is
reachable), it will send a “Ready For SM” notification message to
the HLR.
1. When the HLR receives the notification message, it modifies
the MNRF and checks the MCEF. If MCEF is not set to 1, it
means the mobile phone has available capacity, and the HLR
will send the alert message to the SC, alerting the SC that it
can send the short message to the MS.
Case 2 (In the MCEF bit exists only in HLR. When MS has available memory
HLR, the MCEF capacity, it will automatically send a notification message to
Is Set to 1, MSCS/VLR, and then MSCS/VLR will send a notification message
while MNRF Is to HLR. Service flow is shown in Figure 163.
not Set to 1)

FIGURE 163 ALERT MESSAGE FLOW (2)
SC SMS_IVVMSC HLR MSCS/VLR MS
Ready For SM Req
Ready For SM
Alert Service Center CPDATA （ RPACK ）
1. When MS has available memory capacity, it will send a

notification message to the MSCS/VLR.
2. After receiving this notification message, MSCS/VLR will send
a notification message to HLR and send a response message
to MS.
3. HLR modifies the MCEF and checks the MNRF. If it detects
that MNRF is not set to 1, it will send an alert message to SC.
4. MCEF and MNRF are set to 1
Case 3 (Both If both the MNRF and MCEF in HLR are set to 1, when HLR
the MNRF and receives a notification message from MSCS/VLR, HLR only
MCEF in HLR modifies corresponding flag bit. HLR will send an alert message
Are Set to 1) to the SC only when both flag bits are set to 0.
Operation and Maintenance

Service
Introduction This section will introduce four types of common operation and
maintenance services.
Topics Page No.

Subscriber Tracing 240
Equipment Tracing 241
Deleting an MS 242
Querying IMSI according to ISDN 242
Subscriber Tracing
Purpose PLMN administrator can use the subscriber tracing function to
observe the following circumstances for tracing purpose.

Subscriber’s complaints: If a subscriber keeps complaining

about a service or performance, in this case, subscriber
tracing can be enabled to observe whether this subscriber
and related equipment are normal on the network.
Tracing upon the requirements of the police: Police may
require a suspect to be traced in order to find out his location
and activities.
Subscriber After an HLR receives a subscriber tracing command from OMC,
Tracing in it notifies the MSCS/VLR where subscriber is located to activate
HLR/VLR or deactivate subscriber tracing. Local OMC of MSCS/VLR can be
set to trace a subscriber. Operation flow is shown in Figure 164.
FIGURE 164 SERVICE FLOW OF ACTIV ATING/DEACTIV ATING SUBSCRIBER

TRACING
VLR HLR
MAP_ACTIVE_TRACE_MODE
(a)
MAP_ACTIVE_TRACE_MODE_Ack
MAP_DEACTIVE_TRACE_MODE
(b)
MAP_DEACTIVE_TRACE_MODE_Ack

1. After receiving a message requesting to activate subscriber
tracing from the OMC, HLR sends Active_Trace_Mode_Req to
VLR where the subscriber is located. After VLR activating
subscriber tracing function, it will send an acknowledgement
message to the HLR.
2. After receiving request of deactivating the subscriber tracing
message from OMC, HLR sends Deactive_Trace_Mode_Req to
the VLR where subscriber is located. After deactivating
subscriber tracing, VLR will send an acknowledgement
message to HLR.
Equipment Tracing
Illegal equipment can be traced according to IMEI upon
subscribers’ requirements. When subscriber equipment tracing is
enabled, if a subscriber initiates an access request, IMEI may be
invalid. In this case, VLR should send an MAP_OBTAIN_IMEI
request to MSC. Once acquiring the IMEI, the VLR will save it
and judge whether IMEITRaceFlag is set, and whether to send

subscriber equipment tracing activation request to MSC directly

based on IMEITRaceFlag.
Deleting an MS
Overview Deleting an MS means deletion of MS record from VLR/HLR,
covering data deletion initiated by HLR and data deletion
notification initiated by VLR.
Operation 1. When a subscriber roams to a new VLR, HLR receives

location update message from VLR and then initiates
operation of deleting MS to original VLR to delete subscriber
data in original VLR. When system administrator conducts
such operations as deleting MS, deleting MS location
information and modifying SIM attribute through O&M center
of HLR, HLR will also initiate operation of deleting MS.
2. Since subscriber does not perform any operation for a long
time (24 hours in general, or a flexible time set by system
administrator) or the system administrator requires the
invalid subscriber records to be deleted in VLR through OMC,
VLR will delete the data of this subscriber and notify HLR.
Querying IMSI according to ISDN

Overview In OMC of VLR, subscriber’s MSISDN can be used to query
subscriber’s IMSI. If there is no information about this
subscriber’s IMSI in VLR, the VLR will initiate a request to HLR to
query subscriber’s IMSI.
Flow When the VLR initiates a request for querying the subscriber
IMSI to the HLP, the flow is shown in Figure 165.
FIGURE 165 IMSI-SENDING SERVICE FLOW
VLR HLR
MAP_SEND_IMSI
(a)
MAP_SEND_IMSI_Ack
(b)

1. After VLR receives a message from OMC requesting IMSI
number, it will send a Send_IMSI_Req message to HLR. This
message carries the subscriber’s MSISDN.

2. HLR obtains IMSI number according to subscriber MSISDN

number, and sends a response message to VLR. Message
carries the IMSI of this subscriber.
Interception Services
Overview
This section includes the following topics:
Topics Page No.

China 2G Interception 245
China 3G Interception 247
ETSI Interception 250
Russia Interception 250
Introduction to Interception Services

1. Overview
Interception services refers to performing real-time trace and
interception on all the activities of specified subscribers
according to some special requirements. Generally, only
special government agencies such as police and National
Security Agency are authorized to use interception services.
2. Specification
Different countries have different requirements for
interception services, so the specifications may be different.
ZXWN supports the following interception specifications:
ETSI Interception
Russia Interception
China 2G Interception, China 3G Interception and ETSI
Interception are called Common Interception as there service
flows are similar.
Comparing with the common interception, Russia
interception has many differences, so it will be separately
introduced.
3. Networking modes

Common Interception service has two kinds of network

modes. Both modes connect interception center to USI board
through interception server.
Networking mode adopting DT link
Figure 166 shows the first network mode where inter-office
links of three interfaces between interception center and
MSCS use DT link, and signal is transferred through MGW.
FIGURE 166 NETWORK MODE ADOPTING DT LINK
Networking mode adopting SPB link

Figure 167 shows the other network mode where three
interfaces between interception center and MSCS adopt SPB
links and directly connected through E1 lines, and the signal
needs not to be transferred through MGW.

FIGURE 167 NETWORK MODE ADOPTING SPB LINK
4. Hardware requirements
Table 22 shows the hardware required for ZXWN MSCS to
implement Common Interception service.
TABLE 22 HARDWARE REQUIRED FOR COMMON INTERCEPTION
Name Quantity Remarks

PC with Windows Operating
PC 1
System running on it.
Network card 2 Installed on interception server.
USI 1 Used together with the old USI.
It is recommended to use
SMP 1
separate interception module.
Functions China 2G interception is used for performing real-time trace and
interception on all activities (traffic as well as non-traffic) of a
specific number. These activities includes MS power-on and
power-off, outgoing and incoming calls, handoff and location
update during the call, short message receiving/sending of MS,
data communication and fax receiving/sending and other special
services. For traffic activities, corresponding MS activity report
and traffic contents are sent as an output. For non-traffic
activities, only MS activity report is sent as an output.
Connection Connection relationship between Lawful Information Center (LIC)
Schematic and other NEs of cellular network is shown in Figure 168.
Diagram

FIGURE 168 CONNECTION BETWEEN LIC AND NETWORK ELEMENTS
Interface Functions for the three interfaces of China 2G interception are as

Description follows:
IF1 interface is used to input and respond to operation
commands, and input and output data includes:
f Connection and release requests of IF1 interface
f Authentication on LIC access
f Authentication on operation commands of the interface
f Input operation commands for interface
f Output response to corresponding operation commands
IF2 interface is used to output activity reports of the
controlled MS, short messages and alarm information of
lawful software. Input and output data includes:
f Output the activity reports of the controlled MS
f Output short messages sent and received by the
controlled MS
f Output alarm information of lawful software installed on
the NE
IF3 interface is used to output contents of the calls, data
communication and their mapping IDs. Input and output
data includes:
f Establish signal connection to different type of terminals
(including LIC, MS and fixed phone)
f Output call contents of controlled MS

f Output fax contents of controlled MS

f Output data communication contents of controlled MS
f Output mapping ID corresponding to IF2 interface report
Networking Networking mode adopted by ZXWN MSCS for implementing
Mode and China 2G Interception is shown in Figure 166 and Figure 167,
Hardware and required hardware is shown in Table 22.
Requirements
Function China 3G interception is used for performing real-time trace and
interception on all activities (traffic as well as non-traffic) of a
specific number with the condition that it does not affects any
services or security of the cellular network. These activities
includes MS power-on and power-off, outgoing and incoming
calls, MS handoff and location update during the call, short
message receiving/sending of MS, special services of MS, data
communication, fax, attachment and detachment of MS, route
update, PDP activation and deactivation, PDP context update,
multi-media services and packet data services. For traffic
activities, corresponding MS activity report and traffic contents
are sent as an output. For non-traffic activities, only MS activity
report is sent as an output.
Interface Schematic diagram of lawful interface in the WCDMA mobile
Description network is shown in Figure 169.
FIGURE 169 SCHEM ATIC DIAGRAM OF LAWFUL INTERFACE
LIC distinguishes NEs connected with LIC through existing

network equipment IDs. Also, each LIC has an exclusive ID,
which must be defined at initialization of preliminary data at
lawful interface. To prevent unauthorized LIC from accessing the
NE and from the NE reporting information to unauthorized LIC,
dual-way ID authentication must be performed between LIC and
the NEs. Also, authentication on LIC and that on each NE must
be mutually separated. X1 and X2 interfaces must have
encryption function and data used for authentication and
encryption must not be transferred with plain codes on the
lawful interface.

Connection Connection relationship between LIC and NEs is shown in Figure

Schematic 170.
Diagram
FIGURE 170 CONNECTION BETWEEN LIC AND NES
Functions and Functions and interface protocol for X1, X2 and X3 interfaces are
Protocol of the shown in Table 23.
Interface
TABLE 23 FUNCTIONS OF CHINA 3G INTERCEPTION INTERFACES
Interface Functions Protocol

Used to establish the From the physical
X1 Interface
connection. side, X1 interface can
adopt existing
Used to release the common man-
connection. machine
Used to set the communication
controlled target. control interface, but
it must have high
Used to modify the speed and reliability.
controlled target. Interface should adopt
Used to cancel the TCP/IP, and its work
controlled target. protocol stack is
ISO/IEC 802.2 and
Used to query the ISO/IEC 802.3.
information of target. Lawful interface
Used to query the between one LIC and
parameters of the one TNE has only one
controlled target X1 interface, only one

Interface Functions Protocol

Used to display the X1 connection and
controlled targets. one TCP connection
for bearing X1
Used to query time of connection.
the NE.
Used to locate position
of the target.
From the physical
side, X2 interface can
adopt the existing
common man-
machine
X2 interface is used to
communication
report the activities of
control interface, but
subscriber, including
X2 interface interface must have
power-on, ringing and
high speed and
DTMF, messages, and
reliability. Interface
alarm information.
should adopt TCP/IP,
and its work protocol
stack is TCP/IP
ISO/IEC 802.2 and
ISO/IEC 802.3.
Physical interface
between X3 interface
and LIC is 2048
Kbits/s (with 155
Mbits/s being
optional) digital
interface, and
interface parameters
X3 interface is used to should accord with the
implement bearer GB7611-87
establishment, and Specification. Signal
X3 interface output contents of the mode of the digital
calls and data interface should be
communication and ISUP mode of No.7
their associated IDs. signal at least, and
accord with the
existing standard in
China. Signaling flow
of X3 interface is
same with that of
common call,
adopting ISUP
signaling.

Mode and China 3G Interception is shown in Figure 166 and Figure 167,
Hardware and required hardware is shown in Table 22.
Requirements

ETSI Interception
Overview Network for ETSI interception service is shown in Figure 168. H1
interface is mainly used to set interception task; H2 interface is
mainly used to report the events of monitored object to
interception center, such as location update of subscriber; and
H3 interface is mainly used to report service data of monitored
object to interception center, such as call contents.
Connection The connection schematic diagram for the ETSI interception
Schematic service is shown in Figure 171.
Diagram
FIGURE 171 CONNECTION SCHEM ATIC DIAGRAM FOR ETSI INTERCEPTION
SERVICE
Monitoring Center
H1 Interface H2 Interface H3 Interface

TCP/IP
Monitoring
MGW
Server
TCP/ IP
MSCSERVER

Mode and ETSI Interception is shown in Figure 166 and Figure 167, and
Hardware required hardware is shown in Table 22.
Requirements
Russia Interception
Overview Russia Interception only requires the MSC to tell intercepted
circuit number to interception center, so that the interception
center can listen to voice call. Therefore, no outgoing/incoming
signaling is required for X3 interface function. Russia
Interception adopts TDM bearer while TFO needs not be
activated.
Connection Structure of Russia Interception system is shown in Figure 172.
Schematic
Diagram

FIGURE 172 RUSSIA INTERCEPTION SERVICE
Connection Interception center only provides E1 lines that are connected

Relationship to MGW. Slots 30 and 31 on PCM are specified to transfer the
Description intercepted signaling, and 1~15 and 17~29 are specified to
transfer the intercepted voice.
Intercepted signaling is configured on semi-permanent
connection of MGW. Semi-permanently connect slots 30 and
31 in PCM system connected with interception center to
same slot of another PCM system.
Connect PCM connecting signaling to corresponding S20 port
that exports messages in same E1 slot to telephone line, and
connect telephone line to Modem.
Modem converts signal in the telephone line to serial line
signal, and telephone line is connected to X.25 card of the
interception server.
Finally, interception server is connected to USI board of
MSCS through IP network cable, and transfers signal to
foreground.
Hardware Table 24 shows the hardware required for ZXWN MSCS to
Requirements implement Russia Interception service.
TABLE 24 HARDWARE REQUIRED FOR RUSSIA INTERCEPTION SERVICE

PC with Windows OS
PC 1
running on it.
Installed on the
Network card 1
Installed on the
X.25 card (eicon c91) 2


Modem (tailnet
2 -
T288C)
S20 1 -
Used together with
USI 1
old USI.
It is recommended to
SMP 1 use separate
interception module.
Location Service
Functions supported by ZXWN-MSCS are as follows:
1. MS-terminated location request (MT-LR)

When an external LCS Client requests location of an MS to
network, the network will check ID of LCS Client and
subscription information, and then obtain IMSI (or MSISDN)
and QoS of requested MS according to request and
subscription information. Network will get location
information of MS through location operations and then
report information to LCS Client.
For details, refer to MS-Terminated Location Request.
2. MS-originated location request (MO-LR)
MS originates location request to the network.
For details, refer to MS-Originated Location Request.
3. Network initiated location request (NI-LR)
Network can initiate a request for an MS’s location at any
time if necessary, for example, during an emergent call to
MS.
For details, refer to Network-Initiated Location Request.
4. MS-terminated deferred location request (MT-Deferred-LR)
Network can initiate deferred MS location request at any time
when necessary. Receiving deferred location request,
MSCS/SGSN will set MS to corresponding flag. If MSC/SGSN
detects request event, it will originate MS locating, report
location information to GMLC, and then report to LCS Client
after the GMLC receives information.
For details, refer to Deferred MS-Terminated Location
Request.

MS-Terminated Location Request

Flow Chart As shown in Figure 173, external LCS Client originates locating
request, assuming that target MS passes IMSI or MSISDN
verification.
FIGURE 173 MS-TERMINATED LOCATION REQUEST (MT-LR)
Client GMLC HLR MSCS SRNC/LMU UE
1. LCS Service
Request 2. Map Send Routing
Info For LCS Req
3. Map Send Routing

Info For LCS Ack
4. Map Provide Subscriber

Location Req 5. Paging, Authentication, Security Command
6. LCS Location Notification Invoke
7. LCS Location Notification Return Result
8 Location Report Control
9 Measurement 、Calculation
10 Location Report
11. Map Provide
Subscriber Location Rsp
12. LCS Service
Response
Descriptions of 1. Step 1
the Flow
External LCS Client originates request to obtain location of
target MS. GMLC verifies the ID and subscription information
of LCS Client, and then gets IMSI (or MSISDN) and location
QoS of the target MS according to request and subscription
information of LCS Client. For call-related locations, GMLC
obtains and then verifies called number of the LCS Client. If
location request requires location of multiple MSs or the
request is periodical, repeat Steps 2 to 12.
2. Step 2
If GMLC learns IMSI and VMSCS that correspond to target
MS’s MSISDN (from a completed location request, for
example), it will send a Provide_Subscriber_Location_Req
message to VMSCS without executing Step 2. Otherwise, it
will originate LCS route request to the HLR of the target MS.
Target MS can be identified with IMSI or MSISDN.
3. Step 3
HLR verifies SCCP calling address of GMLC, and returns
current VMSCS/SGSN address and the IMSI or MSISDN (if
unavailable in Step 2) of target MS.
4. Step 4

GMLC sends a Provide_Subscriber_Location_Req message to

VMSCS provided by HLR. Message contains location type,
MS’s IMSI, location QoS information (such as precision and
response time), LCS Client ID, and LCS Client Override
capability. For call-related location request, message also
contains called party number of LCS Client.
5. Step 5
If GMLC is in another PLMN or in another country, VMSCS
first decides whether location request to the PLMN or country
is permitted. If not, an error response will be returned. If
target MS sets up a non-voice circuit field call, location
request can be rejected and an error response will be
returned. Then, VMSCS checks LCS barring restrictions
subscribed by the MS in the VLR subscriber data. At this time,
any barred part or any unsatisfied barring or condition will
render the whole location request is barred. If LCS is barred
without notifying target MS, or LCS Client accessing GMLC is
incapable of overriding, an error response will be returned.
Otherwise, if MS is in idle mode, VLR perform paging,
authentication and encryption. For GPRS-attached MS, the
MSCS can page the MS via the Gs, A or Iu interface
according to Gs interface configuration. This process will get
the current cell ID or some location information of MS.
6. Step 6
If location request is from a LCS Client subscribing value-
added services, subscription data indicates requested MS
should be informed or be informed of privacy authentication,
and MS support LCS notifications, a DTAP LCS Location
Notification Invoke message will be sent to MS to indicate
the location request type, LCS Client ID or whether privacy
authentication is necessary. For call-related location requests,
if LCS Client is not indicated by the GMLC, the LCS Client ID
will be set to the called number of the LCS. As an option,
VMSC can begin location operation (Step 8) after sending a
Location Notification Invoke message, with no need to wait
for DTAP LCS Location Notification Return Result message in
Step 7.
7. Step 7
Target MS notifies location request user. If privacy
authentication is necessary, MS will notify request user
whether the location is allowed or not allowed, whether
response is an absent response, or whether request is
waiting for a approval or a rejection, and MS returns a DTAP
LCS Location Notification message.
8. Step 8
MSCS requests for MS location information to RNC.
9. Step 9
RNC (SMLC) calculates the location of MS by measuring
signals between the MS and MLU.

10. Step 10
If location information meets the required request type and
QoS, RNC (SMLC) will return a location report message
(including location information) to VMSCS.
11. Step 11
If VMSC does not originate the privacy identification
processing in Step 6, VMSC will return the location
information and corresponding time to GMLC. If VMSC has
originated the privacy identification processing in Step 6, and
received the DTAP LCS Location Notification Return Result
message that indicates permission, the VMSC will return only
the location information. If received DTAP LCS Location
Notification Return Result message indicates no permission
or MS response, and privacy indicates position should be
denied when there is no response, VMSC will return an error
response to GMLC. If RNC (SMLC) does not return a success
coordinate, but privacy authentication in Steps 5 to 7 is
successful, and what LCS Client request is current or
previous position of MS, VMSC can return previous location
of the MS. If the MS is idle previously, VLR should release MS
mobility management connection and the VMSC records
charging information.
12. Step 12
GMLC returns location of MS to the LCS Client.
MS-Originated Location Request

Flow Chart Location request processing originated by MS (MO-LR) is shown
in Figure 174.

FIGURE 174 MS-ORIGINATED LOCATION REQUEST (MO-LR)
Client GMLC MSCS SRNC/LMU UE
1. CM Service Req
2. Complete Layer 3
（ CM Service Req ）
3: Authentication, Security mode command

or DTAP CM Service Accept
4: DTAP LCS MO -LR Invoke
5 Location Report Control
6 Measurement, Calculation
7 Location Report
8: MAP Subscriber Location Report
10. Location
9: MAP Subscriber Location Report Ack
Information
10 : DTAP LCS MO- LR Return Result
11: Release CM
、MM 、RR Connections
the Flow
If MS is in an idle mode, it sends a CM service request, a
supplementary service request not related to calls, to VMSCS
via RNC.
2. Step 2
RNC sends a CM Service Req message to MSCS. If MS is in a
dedicated mode, MS will send a CM Service Req message on
existing Iu connection.
3. Step 3
If MS is in an idle mode, VMSCS will originate authentication
and encryption process. If the MS is in dedicated channel
mode, VMSCS will return a DTAP CM Service Accept message.
4. Step 4
MS sends a DTAP MO-LR message to VMSCS.
5. Step 5
MSCS sends a location request message to RNC (SMLC).
Message indicates whether the location information or
location auxiliary data is requested. If location information is
requested, the message contains requested location
information type and QoS. If location auxiliary data is
requested, message contains auxiliary data type.
6. Step 6
RNC (SMLC) calculates the location of MS through signals
measured between MS and MLU.
7. Step 7

When location measured according to QoS is obtained or

required location auxiliary data has been transmitted to MS,
RNC (SMLC) will return a location report message to VMSCS.
8. Step 8
If MS requires transmitting its location information to
another LCS Client, VMSCS will sends a MAP Subscriber
Location Report message to the GMLC after a successful
estimation of location.
9. Step 9
If GMLC serves the same LCS Client, and client is accessible,
GMLC will confirm reception of location estimation.
10. Step 10
GMLC will transmit location information to LCS Client
immediately or upon his request.
11. Step 11
VMSCS returns a DTAP MO-LR Return Result message to MS,
including location estimation, crypto-key, or confirmation
that location estimation has been successfully transmitted to
GMLC.
12. Step 12
If MS was idle previously, VMSCS should release CM, MM and
wireless connection to MS, and VMSCS records charging
information.
Network-Initiated Location Request

Flow Chart Process of network-initiated location request (NI-LR) is shown in
Figure 175.

FIGURE 175 NETWORK-INITIATED LOCATION REQUEST (NI-LR)
the Flow
MS in idle mode originates a request for SDCCH channels,
and RNC sends a DTAP CM Service Request message to
VMSCS, indicating an emergent call service request.
2. Step 2
RNC transmits CM Service Request to core network via Iu
interface (wireless connection should be set up before the CM
connection). MS can use TMSI, IMSI or IMEI as the identifier.
3. Step 3
VMSCS, RNC, and the MS proceed until normal emergent call
originating process on the corresponding client end.
4. Step 4
VMSCS can originate the processes to obtain MS location.
These processes can proceed together with emergent call
originating process, or emergent call originating process can
be hold temporarily to delay call establishment message to
PSTN. VMSCS can directly send a Location Report Control
message of RANAP to RNC (SMLC) that connects current
location of MS.
5. Step 5
RNC (SMLC) calculates location of MS through signals
measured between MS and MLU.
6. Step 6
Once getting location estimation that meets required QoS,
RNC (SMLC) returns a location report message to VMSCS. If
getting no location estimations, it will put failure cause in the
location execution response message.

7. Step 7
VMSCS can send a MAP Subscriber Location Report message
to GMLC that connects the emergent service provider for MS
location report.
8. Step 8
GMLC returns an acknowledgement message after receiving
the location information.
9. Step 9
GMLC can forward the information obtained in Step 7 to
emergent service LCS Client (optional).
10. Step 10
Emergent call service is released.
11. Step 11
For emergent call services in North America, MSC will send
another MAP Subscriber Location Report message to the
GMLC. Message contains the same parameters previously
mentioned except location estimations and emergent call
terminating instructions.
12. Step 12
GMLC returns an acknowledgement message to MSC, and
releases all stored information for the emergent call.
Deferred MS-Terminated Location

Request
Flow Chart Process of deferred MS-terminated location request (DEFERED-
MT-LR) is shown in Figure 176.

FIGURE 176 DEFERRED MS-TERMINATED LOCATION REQUEST (DEFERED-

MT-LR)
the Flow
External LCS Client originates deferred location request to
the GMLC to obtain location of the target MS. If location
involves multiple MSs, repeat Step 2 to 12.
2. Step 2
If the GMLC knows the corresponding IMSI and VMSCS
location of MS’s MSISDN (from a completed location request,
for example), it will originate directly a
Provide_Subscriber_Location_Req to the VMSCS, and then
execute Step 4. Otherwise, the GMLC originates the request
to get the LCS route to the HLR of the target MS, which can
be identified with the IMSI or MSISDN.
3. Step 3
HLR verifies the SCCP calling address of GMLC, and then
returns current VMSCS/SGSN address of the target MS, as
well as the IMSI or MSISDN of MS that is unavailable in Step
2.

4. Step 4
GMLC sends a Provide_Subscriber_Location_Req message to
VMSCS provided by the HLR. Note that the deferred location
can be concurrent with conventional MTLR.
5. Step 5
If MSCS/SGSN does not support deferred location of
requested event (temporarily or permanently), it will return
an appropriate error response to GMLC. MSCS/SGSN shall
check whether client end allows locating the MS based on
subscription information. If not, MSCS/SGSN will return an
appropriate failure cause to GMLC. If MSCS/SGSN supports
deferred location of request event, and privacy inspection is
passed, a Provide_Subscriber_Location_Ack message
containing no location information will be returned to GMLC,
and a timer will be set.
6. Step 6
After receiving the message, GMLC returns a LCS Service
Response message to LCS Client, informing the client end
whether deferred location request is accepted or not.
7. Step 7
SGSN/MSCS verifies request event or immediately call the
event. If the request event does not exist, SGSN/MSCS will
wait until occurrence of the event or the timer times out.
During the waiting, if SGSN/MSCS receives an event that
indicates the UE has moved to another SGSN/MSCS, then an
MS location report with the received reference number will
be returned directly to GMLC. Receiving the report, GMLC will
re-trigger deferred location for the new SGSN/MSCS.
8. Step 8
If requested event is detected, and MS is in idle mode,
VMSCS will originate the authentication and encryption
process.
9. Step 9
SGSN/MSCS gets the location of the MS, and sends a LCS
Location Notification Invoke message to the UE.
10. Step 10
UE return a Location Notification Return Result message to
indicate permissions.
11. Step 11
MSCS sends a location request message to the RNC (SMLC).
message indicates whether location information or the
location auxiliary data is requested. If the location
information is requested, the message contains the location
information type, and the requested QoS. If location auxiliary
data is requested, the message contains the auxiliary data
type.

12. Step 12
RNC (SMLC) calculates location of MS through signals
measured between the MS and the MLU.
13. Step 13
After getting location estimations that meet required QoS, or
after transmitting the required location auxiliary data to MS,
RNC (SMLC) returns a location report message to VMSCS.
14. Step 14
MSCS sends the location information to GMLC through a
Provide_Subscriber_Location_Req message.
15. Step 15
GMLC returns an acknowledgement message, indicating the
reception of location information.
16. Step 16
Upon receiving, GMLC returns a LCS Service Response
message to the LCS Client.
17. Step 17
LCS Client can cancel deferred location request, or GMLC can
also generate a cancel message.
18. Step 18
GMLC originates a Provide_Subscriber_Location_Req to
SGSN/MSCS to cancel deferred location. Message contains
the reference number allocated when the deferred location is
activated.
19. Step 19
Completing cancel process, SGSN/MSCS returns a
Provide_Subscriber_Location_Ack message containing no
location information to the GMLC.
20. Step 20
GMLC informs LCS Client of the successful canceling.
Region System Function

Overview A region system is that one MSCS controls multiple local
networks. To realize that one physical MSCS can perform billing
for basic services and intelligent services, routing, roaming
number allocation, and enable different services for different
local networks, it is required to implement the virtual MSCS
function. That is, one physical MSCS is allocated with multiple
virtual MSC/VLR numbers, and this physical MSCS can be
logically considered as multiple virtual MSCS.
In the R99, one local network can have one or more MSC NEs,
which just manages the resources of one local network. In the

R4, thanks to the improvement of the processing capability of

the MSC Server, one MSC Server can manage the resources of
multiple local networks. In addition, during maintaining the
MSCS in big local networks, each local network can maintain its
own virtual MSCS, and the billing, performance statistics and
configuration management can embody the concept of having
multiple local networks. The alarm can be reported to the
software/hardware alarm box of the local network maintenance
point according to the virtual MSCS. This is the authority division
and area division function.
Networking The networking mode is shown in Figure 177.
Diagram
FIGURE 177 REGION-SYSTEM NETWORKING MODE
Implementatio For the virtual MSC function, the system architecture of the
n Method background system is shown in Figure 178.
FIGURE 178 NETWORKING RESOURCE P ARTITION OF THE REGION SYSTEM
MSCSNE
Common Part
Virtual MSCS 1
Virtual MSCS 2
Virtual MSCS n

The background OMC system partitions the resources of the

MSCS into the common part and the virtual MSCS part. The
common part has physical configuration, signaling link
configuration and other configurations. Each user sets the
VMSCS managing the current operations within its own authority
range after logging in the background system through authority
division and area division function.
Dual-homing Disaster
Recovery Function
Overview To ensure that the network can safely and reliably run, add a
backup MSC Server for the MSC Server running in the network.
In normal cases, the active MSC Server processes signaling and
services. When the active MSC Server fails, the backup MSC
Server can totally undertake the work of the active MSC Server
to ensure the normal running of the mobile network.
The dual-homing scheme provides the MSC Server system with
the disaster recovery function. For two MSC Servers mutually
backing up each other, when one MSC Server fails and cannot
provide services, the other one will undertake the services of the
faulty MSC Server to ensure the continuity of subscriber services.
When the previous active MSC Server recovers to the normal
status, the services will be switched over to it.
Work Mode The dual-homing work modes include:
1+1 active/standby mode
In this mode, the active MSCS is responsible for processing
all the services, and the standby one is idle without
processing any service. The standby MSCS monitors the
status of the active one all the time, will immediately take
over the services of the active one when there is something
wrong with the active one, and will become the active MSCS.
1+1 mutual backup mode
In this mode, two MSC Servers process services during
normal working. Both MSC Servers monitor the status of
each other all the time, and are ready to take over the
services of the other NE in case the other NE is faulty and
processes its own services at the same time.
N+1 active/standby mode
In this mode, the disaster recovery MSCS monitors the
statuses of N active ones all the time. If there is something
wrong with any active MSCS, the disaster recovery MSCS will
immediately take over the services of the faulty MSCS.
During the normal running of the network, the disaster
recovery MSCS does not process services.
N+1 mutual-backup mode

In this mode, the disaster recovery MSCS processes the

services of the local office, and monitors the statuses of N
active MSCSs. If any of these active MSCSs fails, the disaster
recovery MSCS will immediately take over the services of the
faulty MSCS.
Networking Application of 1+1 active/standby mode
Description
The MSC Server in the 1+1 active/standby mode works in
the active/standby mode. That is, one MSC Server is active,
while the other one is standby. The disaster recovery scheme
in 1+1 active/standby mode is shown in Figure 179.
FIGURE 179 1+1 ACTIVE/STANDBY-MODE NETWORKING
MSC server 1 MSC server 2
Heartbeat link
Active control channel

MGW
Standby control channel
In Figure 179, MSC server1 and MSC server2 are a pair of

softswich systems working in the 1＋1 active/standby mode,
where MSC server2 works as the standby server. When
working normally, MSCS server1 completes all the service
functions; MSC server2 detects the status of MSC server1
through the heartbeat link. When MSCS server1 fails, the
MGW is registered to MSCS server2. MSCS server2 activates
the service data to take over the subsequent services.
During the normal running process, the external links of the
standby MSCS server2 except the heartbeat link to the active
MSCS server1 are all inactivated. When the active MSCS
server1 fails, the standby MSCS server2 will activate all its
external links to take over the services. At the same time,
the external links of MSCS server1 automatically become
inactive, and all the services are provided by MSCS server2.
Application of 1+1 mutual-backup mode
In the normal case, two MSC Servers bear their own traffic.
They detect the status of each other through the heartbeat
link. When one MSC Server fails, the other one will active the
service data of the faulty MSC Server configured on this MSC
Server, and take over the services of the faulty one. The
networking mode is shown in Figure 180.

FIGURE 180 1+1 MUTUAL-BACKUP-MODE NETWORKING
MSC server 1 MSC server 2
Heartbeat link
MGW1 MGW 2
In Figure 180, each MSC Server is the active MSC Server,

and is also the disaster recovery MSC Server of the other
MSC Server at the same time.
Application of N+1 active/standby mode
In the N+1 disaster recovery scheme, one MSC Server
serves as the standby MSCS, the rest N MSCSs server as
active MSCSs. The standby MSCS serves as the redundant
backup system of the others. The networking is shown in
Figure 181.
FIGURE 181 N+1 ACTIVE/STANDBY-MODE NETWORKING
MSC server 1 MSC server2 MSC server3
Heartbeat Heartbeat
link link
MGW 1 MGW 2 MGW3

In Figure 181, MSC server1, MSC server2 and MSC server3

work in the N+1 active/standby mode (where N＝2), where
MSC server2 works as the standby server of MSC server1
and MSC server3. In normal case, MSC server2 does not

process traffic. When MSC server1 or MSC server3 fails, MSC

server2 will activate the corresponding service data to take
over the subsequent services.
Application of N+1 mutual-backup mode
In the N+1 mutual-backup mode, the disaster recovery
MSCS process the services of the local office, and monitors
the statuses of N MSCSs. If any of them fails, the disaster
recovery MSCS will immediately take over the services of the
faulty MSCS. The networking mode is shown in Figure 182.
FIGURE 182 N+1 MUTUAL-BACKUP-MODE NETWORKING
TMSC server1 TMSC server2 TMSC server3
Heartbeat Heartbeat
link link
TMGW1 TMGW 2 TMGW 3 TMGW 4

In Figure 182, MSC server1, MSC server2 and MSC server3 work
in the N+1 mutual-backup mode (where N ＝ 2), where MSC
server2 works as the backup server of MSC server1 and MSC
server3. In normal case, three MSC servers process their own
services. When MSC server1 or MSC server3 fails, MSC server2
will activate the corresponding service data to take over the
subsequent services.
Load Control Function

Overview
Description When abrupt large traffic occurs, the load control function is
used to discard partial traffic beyond the system processing
capability to avoid the breakdown of modules or even the whole
system. By reducing the system load, the system can run safely
and stably to protect the services from interruption.

Concept The load control function of ZXWN MSCS divided into service
control (based on traffic) and congestion control.
Service control (based on traffic) is responsible for
controlling the service overload within the service period. It
is implemented by setting the traffic allowed to pass in a unit
time.
The service period is an equivalent time slice by dividing the
entire running duration of the system. Service overload
means that the service amount exceeds a fixed threshold in
a unit time (or a service period). This threshold is calculated
based on a fixed traffic model with reference to the office
capacity configuration of the system.
Congestion control is responsible for controlling the overload
condition of the A interface, Iu interface, MAP interface, and
NNI interface according to predefined discarding policy.
Contents This section includes the following topics:
Topics Page No.

Principle 268
Function Implementation 270
Principle
Principle of According to the quantity of each type of service message
Service Control procedures and the time slice occupied by each service
(Based on procedure, a “service weight value” is set for each type of
Traffic) messages to indicate the load caused by one times of this type
of services. The “service weight value” is set according to the
CPU consumption of each type of services.
Service load is the sum of the products of each type of service
and the corresponding service weight value under the attributes
of a certain office. The service load control process adds the
total number of the current received services to its
corresponding weight every time after receiving one service
message of this type. When the total number of service
messages received in a service period is greater than the rated
maximum service load of this module, some messages will
discarded to release the system load till the next service period
where the total number of received service messages is less
than the rated maximum service load of this module.
Principle of The OL (Over Load) process on the SMP calculates the
Congestion current load level of A interface, Iu interface, MAP interface,
Control and NNI interface by timely querying the resource occupancy
and CPU occupancy of each interface module
(BSSAP/RANAP/TCAP) with a certain algorithm.
The OL process on the OMP calculates the current load level
of A interface, Iu interface, MAP interface, and NNI interface
of the local office according to the load condition of these

interfaces reported by each SMP module with a certain

algorithm.
If the calculated congestion level of each interface of the
local office is not consistent with that previously
synchronized to each module, then the system synchronizes
the congestion level of the corresponding interface of the
local office to the OL process of each SMP.
OL processes save the congestion levels of A interface, Iu
interface, MAP interface, and NNI interface for congestion
control and load control of interfaces.
Figure 183 shows the congestion control flow.
FIGURE 183 CONGESTION CONTROL FLOW
Each module calculates the

congestion level of its SMP
module
Report
OMP calculates the global

congest level according to
the congestion level of each
SMP module
Synchronize
OMP synchronizes the local

congestion level to all SMPs
Perform congestion control

according to specified
throughput rate of different
congestion levels
The system respectively performs the following congestion

control according to the congestion level of each interface:
The system sends the OVERLOAD message to the RNC
office based on the congestion level of the Iu interface.
The system sends the OVERLOAD message to the BSC
office based on the congestion level of the A interface.
The load control level of MAP interface of the local office is
sent to the SCCP process for completing the load control
function.
The congest level of the NNI interface is used in the REL
message of the Signaling System 7 (SS7) for telling the
corresponding office to reduce the message quantity to the
local office.

Function Implementation
Overview This section introduces how to implement service control and
congestion control.
Service Control Work flow
(Based on
i. The OL module obtains the current time. If the difference
Traffic)
between the current time and the start time of the
service control period is greater than the product of 60
and the service period, then all of the statistics (total
traffic and single traffic) are cleared, and the current time
is regarded as the start time of the service control period.
ii. Judge whether the total traffic is greater than the product
of the total service amount allowed per second and the
configured service period. If it is, the control on current
traffic is necessary. For the Short Message Service (SMS),
it is required to check whether the single traffic of MT/MO
SMS is greater than “Total service amount allowed per
second × Allowed percentage of MT/MO SMS in the total
traffic × Configured service period”.
Classification of services
f Supplementary service
f SMS
f Call service
f Handover service
f Mobility management service
f Inter-office incoming call service
Congestion The work flow of congestion control is as follows:
Control
1. The load control regularly (the interval is 5s by default, but it
can be set) queries the CPU occupancy and resource
occupancy of each interface, as shown in Figure 184.
FIGURE 184 SETTING THE MP LOAD STATISTICS INTERVAL
2. If the CPU occupancy or the data area occupancy of each

interface is greater than the threshold set for the
corresponding congestion level (as shown in Figure 185), the
load level of the system will be determined according to a
certain algorithm. The CPU load level is the only evaluating
index of the NNI interface.

FIGURE 185 THRESHOLD SETTING OF E ACH CONGESTION LEVEL
3. The system discards the overload services according to the

throughout rate of each type of services under different
congestion levels. Thus, the congestion control is
implemented.
R2 Function
Overview The R2 signaling is a kind of Channel Associated Signaling (CAS).
It is the international standard signaling based on the E1 digital
network. Its time slot 16 is reserved for transferring the
signaling of the voice channel, that is, the signaling cannot be
separated from the voice channel, and they are transferred on
the same E1.
The R2 system was widely used in Europe, Latin America, China
and some developing countries. But in the R2 CAS system,
general signaling faults and voice channel faults are easy to
locate because the signaling and the voice channel are on the
same PCM, while voice channel faults are hard to locate, and
even are masked by the signaling in the Common Channel
Signaling (CCS) system. Therefore, the CAS is gradually
replaced. But the R2 system is still used in some cases, and has
more applications in the international communication industry.
To provide abundant signaling interfaces, both the ZXWN MSCS
and the ZXWN MGW supports the R2 signaling.
Networking The supported networking mode at present is shown in Figure
Mode 186. The straight line between NEs indicates R2 signaling.

FIGURE 186 NETWORKING MODE
MSCSERVER MSCSERVER
E1 E1
MGW MGW PSTN
Implementatio Same with the CCS ISUP and TUP, the CAS R2 is a kind of inter-
n Description office signaling. The R2 signaling is divided into line signaling
(that is intercepted signaling, used to detect the line status,
such as occupied and idle) and signaling between registers
(register signaling for short, used to transfer the address
number information). The R2 is characterized by the signaling
transferred with the voice channel.
3G implements the call independent of bearer in the R4 system.
The MSC Server with call control function has no physical
connection with the voice channel, so it cannot directly receive
or control the R2 signaling; the MGW providing and managing
the media resources has actual voice channel connection, but it
has no signaling and call control functions. Therefore, the R2
signaling is transferred to the MSC Server through the interface
between the MSC Server and the MGW, so the Mc interface
between the MSC Server and the MGW and its H.248 protocol
need to complete the transferring function of the signaling. For
this purpose, the H.248 specially defines the related packet,
such as BCAS, ICAS and CBLK packets used for the line signaling,
and the ICASC packet (ENBLOC signal mode) and the ICASO
packet (OVERLAP signal mode).
The ZXCN V3 R2 signaling module is generated by implementing
the R2 signaling under the R4 system structure. It is a relatively
independent module in the signaling subsystem from the logical
side, and its status and location are similar with those of ISUP,
TUP and BICC; while from the physical side, it is divided into two
independent sub-modules (called as MSCSR2 and MGWR2),
which are located on the MGW and the MSCS respectively. The
MGWR2 independently introduces and generates the R2 protocol
signaling under the control of the MGW, and interact with the
MSC Server; the MSCSR2 completes call control according to the
R2 signaling reported by the MGW. The functions that the ZXCN
V3 R2 signaling module should complete includes providing the
R2 signaling interface between the 3G CN and the PSTN, and the
PLMN; implementing incoming call control, outgoing call control
and tandem call control (this case is relatively less) by
cooperating with other signaling systems (such as No.7TUP,
ISUP and BICC); and providing relatively complete test and
maintenance measures, billing and other functions.

The R2 provides two kinds of incoming signaling processing

modes (Overlap and Enblock) and one kind of outgoing signaling
processing mode (Overlap). The incoming signaling processing
modes can be set.
If the incoming number receiving mode is set to the en－bloc
signal mode, it indicates that the MGW packs the number into a
packet after receiving the whole number, transfers it to the
corresponding R2 module of the MSCS for processing through
the R2-related module of the Mc interface.
If the incoming number receiving mode is set to the Overlap
signal mode, it indicates that the MGW receives the called
number digit by digit. Every time when the MGW receives a digit
of the number, it will transfer it to the MSCS for analysis until
the number analysis result is got. According to the number
analysis result, the MGW receives the number to the minimum
number stream length for one time, and then directs the call to
the local office or finds out the outgoing semi-call. If the call is
transferred by the local office, and the called number is not
completed received (less than the maximum number stream
length configured in the number analysis), the R2 incoming call
side will continue receive the number digit by digit, and transfer
one digit to the outgoing side every time when one digit is
received.
Roaming Pool Function

Overview The previous MSRN allocation plan is static. When the traffic on
each module is not even, it is possible that the MSRNs of some
modules have been used up, which will cause call failure; and
that other modules still have MSRNs unallocated, which cannot
be used.
The roaming pool function introduces the concept of the
common module allocating the MSRN to resolve the problem
that the MSRN cannot be fully used. To be specific, when the
MSRN resource of the service processing module is used up, the
common MSRN can be applied for to the module configured with
common MSRNs. In this way, the service module with more
loads can apply for more common MSRN resources, which can
fully use the MSRN resources.
Implementatio When configuring the MSRN load, MSRN number sections can be
n Method allocated to each VLR module, and one module can be specified
to be configured with the common MSRN number sections to be
used by all service modules.
After receiving the PRN message from the HLR, the system finds
the corresponding VLR module according to the IMSI in the
message. The VLRMAP invokes the local module database to
apply for an MSRN by the process invoking mode. If there are
idle MSRNs in the local module database, an idle MSRN will be
allocated to the VLRMAP; if there is no idle MSRN in the local

module database, a failure message will be returned, and the

VLRMAP will send a message to the database subsystem of the
module configured with common MSRNs to ask for a common
MSRN. The database subsystem of the module configured with
common MSRNs directly returns a MSRN to the VLR module.
After the MSRN is sent to the office, and if the MSRN is allocated
by the VLR module, the database will immediately return the
module number; and if the MSRN is allocated by the database
subsystem of the module configured with common MSRNs, the
database of the incoming module will return the failure
information and will inquire of the database subsystem of the
module configured with common MSRNs about the
corresponding VLR module of the MSRN. The database
subsystem of the module configured with common MSRNs
directly sends the service module information to the
corresponding incoming module.
After receiving the incoming call request, the VLR invokes the
database interface through procedure invoking mode based on
the MSRN to get the related information (including IMSI) of this
MSRN. If this IMSI is not a common IMSI, the VLR will directly
get information; otherwise, the database will return failure
information and inquire of the database subsystem of the
module configured with common MSRNs about the related
information of this MSRN. The database subsystem of the
module configured with common MSRNs directly sends the
related information (including IMSI) of this MSRN to the VLR.
After receiving the IMSI of the subscriber based on the MSRN,
the VLR finds the subscriber data through the IMSI. Then the
VLR invokes the database of the local module interface by using
the procedure invoking mode to release the MSRN. If the MSRN
is allocated by the local module, the database will directly
release it; if the MSRN is a common MSRN allocated by the
database subsystem of the module configured with common
MSRNs, the database subsystem needs to request the module
configured with common MSRNs to release the common MSRN.
Multi-EIR Function
Overview The ZXWN MSCS adopts the EIR mutual-aid networking mode,
and each virtual MSC supports multiple (at most 255) EIRs
configured.
Networking The networking mode is shown in Figure 187.
Mode

FIGURE 187 MULTI-EIR NETWORKING MODE
MAP EIR1
MSC
Server
EIR2
MGW
EIR n
Functions The specific functions are as follows:

1. The EIR mutual-aid networking mode is allowed to be
adopted, and each virtual MSC supports multiple (at most
255) EIRs configured. The proportion of the loading sharing
for processing IMEI can be specified for the EIR connected
with each MSCS.
2. If the link between the MSC and the EIR is interrupted, the
following processing methods can be selected.
i. It is allowed to initiate a Check IMEI procedure to another
EIR;
ii. The related services of this IMEI continue;
iii. The related services of this IMEI are forbidden.
3. For the user in the grey list can select the following
processing methods:
i. The services of the user in grey list are allowed to
continue;
ii. The UE is forbidden to continue the related services, and
whether to generate the “IMEI check failure” alarm can
be selected at the same time.
M2PA Networking Function

Overview Introduction of the M2PA is because there is a requirement for
transferring Switched Circuit Network (SCN) signaling protocol or
the IP signaling point on the IP network, including from the
signaling gateway to the Media Gateway Controller (MGC). The
SCN signaling point can adopt non-NO.7 signaling link to access
the database and other equipments in the IP network domain.
The M2PA protocol can enable the No.7 signaling node to
process the MTP3 message and perform signaling network
management function through the IP network. The IP Signaling
Point (IPSP) is the NO.7 signaling node with the IP network

connection. The functions of the IPSP are same with those of the
NO.7 signaling node, and the difference is that it uses the IP
network connection instead of NO.7 signaling link. The M2PA is
used to support the operations on the peer layer of the MTP3
protocol on the IP network connection, the MTP2/MTP3 interface
border, SCTP transfer association replacing the MTP2 link and
the traffic management, and reporting status changes
asynchronously to the management system.
Networking The networking diagram is shown in Figure 188. In this
Mode networking mode, the M2PA protocol is adopted between MSC-
Servers, or between the MSC-Server and the MGW.
FIGURE 188 M2PA NETWORKING MODE
Implementatio The structure of the SCN signaling transferring on the IP

n Method network consists of multiple components, including IP, SCTP and
an adaptation model. Under this frame structure, one SCN
adaptation model applied to transfer the MTP3 message of the
No.7 signaling is defined, as shown in Figure 189. The MTP3 is
adapted to the SCTP layer by using the M2PA layer. The M2PA
supports all the primitives between the MTP3 layer and the MTP2
layer. The SCTP association can be considered as the No.7
signaling link between IPSPs.

FIGURE 189 ADAPTATION MODEL
Interworking Services
between the IMS and the
CS/PSTN
1. Overview
The MGCF is the network entity for interworking between the
IMS and the CS/PSTN and other networks. Mainly processing
the call control plane, the MGCF controls the IM-MGW to
support call services and the related supplementary services
with the IMS network terminal.
2. Functions
The specific functions include:
The terminal subscriber in the IMS domain calls the
subscriber in the CS domain/PSTN. For details, please refer
to The Terminal Subscriber in the IMS Domain Calling the
Subscriber in the CS Domain/PSTN;
The subscriber in the CS domain/PSTN calls the terminal
subscriber in the IMS domain. For details, please refer to The
Subscriber in the CS Domain/PSTN Calling the Terminal
Subscriber in the IMS Domain.

The Terminal Subscriber in the IMS

Domain Calling the Subscriber in the
CS Domain/PSTN
Flow Chart The flow chart of the terminal subscriber in the IMS domain
calling the subscriber in the CS domain/PSTN is shown in Figure
190.
FIGURE 190 FLOW CHART OF THE TERMINAL SUBSCRIBER IN THE IMS

DOM AIN CALLING THE SUBSCRIBER IN THE CS DOM AIN/PSTN
Terminating Network
PSTN/
MGCF MGW CS domain
1. INVITE
2. 100 Trying
3. H.248 interaction to create

connection
4. IAM
5. Bearer related negotiation (in case BICC is used)

6. 183 Session Progress
7. PRACK
8. 200 OK
9. H.248 interaction to modify

connection to reserve resources
10. Resource
Reservation
11. UPDATE
12. 200 OK
13. COT/IAM
14. ACM / CPG
15. 180
16. PRACK
17. 200 OK
18. ANM
19. H.248 interaction to modify

connection to start media flow
20. 200 OK
21. ACK

Flow The flow is described as follows:

Description
1. STEP1: The MGCF receives call setup request “INVITE” from
the IMS domain;
2. STEP2: The MGCF returns a “100 try” response to the IMS
domain to inform that the “INVITE” has been received;
3. STEP3: The MGCF interact with the IM-MGW to create the
connection with the terminal at the IMS side;
4. STEP4: The MGCF sends an IAM message to the CS
domain/PSTN side to request for call setup;
5. STEP5: BICC/ISUP signaling negotiation;
6. STEP6: According to the SDP response result of the IM- MGW,
the MGCF constructs an SDP Answer, and sends it to the IMS
through a SIP 183 Progress message;
7. STEP7/STEP8/STEP9/STEP10: After receiving the PRACK
message from the terminal in the IMS domain, the MGCF
judges whether the SDP information has been modified. If it
has been modified, the MGCF invokes the bearer modification
procedure to ask the IM-MGW to modify the bearer. After
receiving the response from the IM-MGW, the MGCF returns
a “200 OK (PRACK)” message to the terminal in the IMS
domain;
8. STEP11/ STEP12/ STEP13: After receiving the UPDATE
message from the terminal in the IMS domain, the MGCF
sends a COT message to the callee, indicating that the
bearer of the calling side has been completely established,
and sends a “200 (UPDATE)” message to the calling side at
the same time.
9. STEP14/STEP15/STEP16/STEP17: After receiving the ACM
message from the called side in the CS domain/PSTN, the
MGCF sends a 180 Ringing message to the calling terminal in
the IMS domain, and will receive a PRACK message from the
calling terminal in the IMS domain. Then the MGCF sends a
200 (PRACK) message to the calling terminal in the IMS
domain.
10. STEP18/STEP19/STEP20/STEP21: After receiving the ANM
message from the called side in the CS domain/PSTN, the
MGCF sets the terminal in the IMS domain as dual-pass.
After receiving the response from the IM-MGW, the MGCF
sends a 200 (INVITE) message to the terminal in the IMS
domain, and will receive an ACK message from the terminal
in the IMS domain.

The Subscriber in the CS

Domain/PSTN Calling the Terminal
Subscriber in the IMS Domain
Flow Chart The flow chart of the subscriber in the CS domain/PSTN calling
the terminal subscriber in the IMS domain is shown in Figure
190.
FIGURE 191 FLOW CHART OF THE SUBSCRIBER IN THE CS DOM AIN/PSTN

CALLING THE TERMINAL SUBSCRIBER IN THE IMS DOM AIN
Home Network
CS Networks/PSTN
MGW MGCF
1. IAM
2. H.248 interaction
to create connection
3. INVITE
4. 100 Trying
5. 183 Session
Progress
6. Bearer related negotiation(if any)
7. PRACK
8. 200 OK
9. H.248 interaction
to modify connection
10. Resource to reserve resources
Reservation
11. COT
12. UPDATE
13. 200 OK
14. 180 Ringing

15. PRACK
16. 200 OK
17. ACM
18. 200 OK
19. ANM
20. H.248 interaction to

modify connection to
start media flow
21. ACK
Flow The flow is described as follows:

Description
1. STEP1: The MGCF receives call setup request “IAM” from
the CS domain/PSTN;

2. STEP2: The MGCF interact with the IM-MGW to create the

connection with the terminal at the IMS side;
3. STEP3: The MGCF sends an INVITE message to the IMS
domain;
4. STEP4: The MGCF receives a “100 try” response from the
IMS domain, which inform that the “INVITE” has been
received;
5. STEP5: The MGCF receives a SIP 183 Progress message;
6. STEP6: BICC/ISUP signaling negotiation;
7. STEP7/STEP8/STEP9/STEP10: The MGCF sends a PRACK
message to the IMS domain. After receiving the 200 OK
(PRACK) message from the terminal in the IMS domain, the
MGCF judges whether the SDP information has been
modified. If it has been modified, the MGCF invokes the
bearer modification procedure to ask the IM-MGW to modify
the bearer;
8. STEP11/ STEP12/ STEP13: After the MGCF receives the COT
message from the CS side, and sends a UPDATE message to
the terminal in the IMS domain, it indicates the bearer of the
calling side has been completely established. The MGCF
receives the “200 (UPDATE)” message from the terminal in
the IMS domain.
9. STEP14/STEP15/STEP16/STEP17: After receiving the 180
Ringing from the called terminal in the IMS domain, the
MGCF sends an ACM message to the calling side in the CS
domain, and sends a PRACK message to the terminal in the
IMS domain. The MGCF receives a 200 (PRACK) message
from the terminal in the IMS domain.
10. STEP18/STEP19/STEP20/STEP21: After receiving the 200
(INVITE) message from the terminal in the IMS domain, the
MGCF interacts with the IM-MGW to set the terminal in the
IMS domain as dual-pass. After receiving the response from
the IM-MGW, the MGCF sends an ANM message to the CS
domain/PSTN, and will send an ACK message to the terminal
in the IMS domain later.

Function of Detecting and

Restricting Cheaters
Overview
This section includes the following topics:
Topics Page No.

Introduction to Detecting and Restricting Cheaters 282
Generating Call Attempt CDRs 284
Restricting the Call Originating Service of Cheaters 285
False Billing Function 285
Restricting the SMS of Cheaters 286
Location Update Restriction Function 286
Periodically Enabling the Function of Restricting 287
Cheaters
Sorting Call Attempt CDRs 287
Sorting SM CDRs 287
Configuring Cheater Detection Policy 287
Default Restriction Policy Configuration 288
Cheater Detection Function 288
Cheater List Maintenance Function 289
Introduction to Detecting and

Background The cheaters use the SM group sender to send cheat messages
to subscribers in the same number section of each operator, or
originate group calls to them. They tempt the subscribers to dial
back, and then will play the cheat message to the subscribers.
The cheaters bring much negative influence on the network
security and the business income. When there is heavy traffic,
the switch may fail. Aiming at this cheat action, ZXWN MSCS
provides the function of detecting and restricting the cheaters.
Function MSC Server generates the call attempt CDR, the billing server
Implementation filters the CDR, and then the anti-cheat monitoring server will
analyze the CDR and find the cheater according to the pre-set
policies. When the cheater is detected, the corresponding
restriction policies will be generated automatically according to
the roaming type of the cheater.

The detailed method is: create, modify and query the

configuration of the cheater according to the MML interface
provided to the anti-cheat detection server by the OMM server,
and transfer the configuration information of the cheater to the
foreground. The foreground performs service restriction
according to the restriction policy. The service restriction is
performed in different ways according to the roaming types,
including local roaming, intra-province roaming, inter-province
roaming, and international roaming.
The system flowchart of implementing the function of detecting
cheaters and performing service restriction is shown in Figure
192.
FIGURE 192 FLOWCHART OF DETECTING CHEATERS AND PERFORMING

SERVICE RESTRICTION
Call attempt
CDR
MSC Server SMS CDR Billing server
Network List of Anti-cheat

management cheaters detection server
server
The MSC Server completes the following functions:

Generates call attempt CDRs and SM CDRs. For the details,
refer to Generating Call Attempt CDR.
Restricts the call originating service of cheaters. For the
details, refer to Restricting the Call Originating Service of
Cheaters.
Restricts the SMS of cheaters. For the details, refer to
Restricting the SMS of Cheaters.
Performs the false billing for the calls originated by cheaters
according to the set proportion. For the details, refer to False
Billing Function.
Restricts the location update of cheaters according to their
configuration information. For the details, refer to Location
Update Restriction Function.

Configures the interval when to the function of restricting

cheaters is enabled. For the details, refer to Periodically
Enabling the Function of Restricting Cheaters.
The billing server completes the following functions:
Sorts call attempt CDRs. For the details, refer to Sorting Call
Attempt CDR.
Sorts SM CDRs. For the details, refer to Sorting SM CDRs.
The anti-cheat monitoring server completes the following
functions:
Configures the policy of identifying cheaters, including call
attempt times, called number and originating cell.
Periodically sorts call attempt CDRs, and detects the cheaters
according to the configured identification policy.
Configures the default restriction policy for cheaters with
different roaming types.
Periodically sorts SM CDRs, and detects the SM cheaters
according to the configured identification policy.
Sets the malicious subscriber to taking effect on the
foreground of MSC Server through the network management
interface.
Queries, deletes and modifies the list of malicious subscribers.
Periodically deletes the malicious subscribers and configures
different deleting periods according to different roaming
types.
Saves the restriction records of malicious subscriber for at
least 3 months.
The OMC server completes the following functions:
Provides the MML command line in the cheater restriction
configuration.
Synchronizes the list of cheaters to MSC Server.
Generating Call Attempt CDRs

Description For unsuccessful call attempts, the switch generates call attempt
CDRs (which are the CDRs of the unsuccessful calls occupying
the trunk).
Function In the MOC, MTC, MCF, GATE, TRUNK and TRANSIT CDR
Implementation interfaces, add a flag field (bTerminationCause =
UnsuccCallAttempt_M. The value is 3) to identify the call attempt
CDR. On MCC/MCF/NNI modules, add the processing of
generating call attempt CDRs based on the current billing
processing. It is only required to set the call attempt CDR flag.
The processing flowchart is shown in Figure 193.

FIGURE 193 FLOWCHART OF GENERATING CALL ATTEMPT CDRS
MCC/MCF/NNI Billing Process
Call Release
Generating call
attempt CDRs
In order to reduce the configured call attempt CDRs, the types

of call attempt CDRs configured in MCC/NNI determine the types
of the call attempt CDRs generated. At the same time, the
following information determines whether to generate the call
attempt CDR (the following information only controls the MOC
and MTC call attempt CDRs):
Incoming/outgoing trunk group
Incoming/outgoing office direction
Originating/terminating cell (requirement of GSM networks)
Originating/terminating location area
Restricting the Call Originating

Service of Cheaters
After VLRMAP receives the outgoing call request, it will obtain
the MSISDN of the subscriber, judge whether the calling party is
a cheater according to the database interface, and return the
call restriction proportion. If it is required to restrict the current
call through the calculation, mcvSndInfOutCallNegRsp will be
returned to reject the current call.
False Billing Function

After VLRMAP receives the outgoing call request, it will query the
database according to the MSISDN of the subscriber and obtain
the false answer proportion of the cheater. For the normal
originated calls of cheaters, whether to add the false billing flag
for new subscribers in CompleteCall depends on the configured
proportion.

After CC receives the CompleteCall message, and if it is required

to perform the false billing, CC will send a Connect message to
the mobile phone after receiving the Alerting message sent by
the called party, and start performing billing on the calling party.
The processing flowchart is shown in Figure 194.
FIGURE 194 PROCESSING FLOWCHART
Restricting the SMS of Cheaters

After VLRMPA receives the MO SM request, it will obtain the
MSISND of the subscriber and judge whether the calling
subscriber is a cheater according to the database interface. It
will also judge whether it is required to restrict the SMS of this
subscriber. If it is, VLRMPA will return the error message to
reject the SMS of the subscriber.
Location Update Restriction Function

After VLRMAP receives the access request, it will obtain the IMSI
of the subscriber and judge whether the subscriber is a cheater
according to the database interface. It will also judge whether to
restrict the internet access authority of the subscriber. If it is
required to restrict the authority, VLRMAP will return the error
“illegal ME” to reject the access of the subscriber.

Periodically Enabling the Function of

MSC Server can periodically enable the function of restricting
cheaters according to the configured intervals. Three intervals
can be configured.
Sorting Call Attempt CDRs

To ensure that the call attempt CDR does not affect the normal
billing, the billing server should be configured with a directory
for storing call attempt CDRs. The billing server saves the
received call attempt CDRs to the separate directory. It also
filters out the added call attempt flag from the original CDR
during the normal billing according to the configuration.
Sorting SM CDRs
In general, SM CDRs generated by the MSC are not used to
charge the subscribers. During the actual office commissioning,
it is not required to generate SM CDRs. Normal SM CDRs and
CDRs are saved in the same file, so it is required to add some
configuration on the billing server to save the SM CDR
separately (in case the billing center does not need SM CDRs),
or copy the SM CDRs to a new billing file (in case the billing
center needs to SM CDRs). Thus, the anti-cheat monitoring
server does not need to process all the CDRs generated in the
foreground, so the requirement on the processing capability of
the server is reduced.
Configuring Cheater Detection Policy

Description The anti-cheat monitoring server provides the cheater detection
policy configuration. It allows the subscriber to manually
configure the cheater detection policy function, so that it can
cope with the changed actions of cheaters, adjust the detection
policy in real time, improve the detection efficiency, and reduce
the misjudgment rate.
Judging For the voice call, the following fields are provided:
Cheaters
The number of call-attempts per unit time (the minimum
Based on Calls
statistics period is 15 minutes)
Call release reason

Range of called numbers (whether they are the local

subscribers and whether they belong to the same number
section)
Originating cell/location area list
The total number of call attempts in 24-hours
Among the above information, the “the number of call-attempts
per unit time” field is the most important. If it exceeds the
threshold, it is quite possible that this subscriber is a cheater.
However, to reduce the misjudgment rate, it is required to add
the “range of called numbers” (judge whether the called
numbers belong to the same kilobit number section),
“Originating cell” filed (the geographic locations of the cheater
are relatively centralized), and “the total number of call attempts
in 24-hours” fields (cope with the situation where the cheater
originates calls with multiple cards at the same time, and the
number of call attempts of a single card is not high).
Judging For the SMS, at least the following fields are provided:
Cheaters
The number of MO SMs per unit time (the minimum statistics
Based on SMs
period is 5 minutes)
Characteristics of the called numbers (judge whether they
belong to the same number section)
Among the above information, the operator mainly distinguishes
cheaters according to the “the number of MO SMs per unit time”
field. However, to reduce the misjudgment (mistaking normal
group message sending for cheating actions) rate, the
“Characteristics of the called numbers” field is added. If the
number sections of the short message receivers are the same, it
means that the sender is a cheater.
Default Restriction Policy

Configuration
The anti-cheat monitoring server provides the default restriction
policy configuration for cheaters. It allows the subscriber to
customize the default restriction policy according to types of
cheaters and roaming types. After a cheater is detected, the
restriction policy will be generated automatically according to
the type of the cheater. Then the operator set it to taking effect
in the MSC Server in real time through the MML command in the
OMC server.
Cheater Detection Function

The anti-cheater monitoring server automatically sorts the SM
CDRs and the call attempt CDRs provided by the billing server

according to the set period. It obtains the cheater list according

to the set detection policy. It also sets the default restriction
policy according to the type of the cheater, and sets the policy to
taking effect in MSC Server through the MML command interface
of the OMC server. The anti-cheat monitoring server saves the
detection log for each cheater, and records the detailed
information, such as the detection time and detection reason.
Cheater List Maintenance Function

The anti-cheat monitoring server saves the cheater list, and
provides the manual maintenance function. The operator can
modify the restriction policies by manual. The server also
provides other functions, such as adding, querying, modifying,
deleting, importing/exporting the cheater list.
The anti-cheat monitoring server also can maintain the cheater
list automatically. The operator can set different automatic
deleting periods for different types of cheaters (mainly based on
the roaming types of cheaters). After a cheater is added to the
cheater list, it will be deleted automatically after a period of time.
Rerouting Function
Overview When there are multiple routes between the source switch and
the terminal switch, and one route is faulty or congested, the
Automatic ReRouting (ARR) function enables the source switch
to select another route to the terminal switch according to the
returned failure reason returned by the terminal switch.
Function There are multiple routes between the source switch and the
Implementatio terminal switch. When one route is faulty or congested (for
n example, in Figure 195, the route between the triggering switch
and the terminated office fails), the source switch with the ARR
function can select another route to reach the terminal switch
according to REL (ISUP\BICC) or UBM (TUP) signaling, and the
specific REL failure reason (ISUP\BICC) or the specific UBM
message type (TUP). The ARR function is shown in Figure 195.

FIGURE 195 ARR FUNCTION
) Triggering
T UP switch
P/
I SU
C/
IC REL
M (B
IA
Terminal
Source switch
switch (terminating
IA office)
M(
BI
CC
/I S
UP
/T
UP
)
New
subsequent
switch
Dynamically Selecting
Routes Based on Load of IP
Bearer Network and QoS
Overview Controlled by the MSC Server, the MGW performs quality audit
on the IP bearer network, and performs a series of call loss
reducing functions, including traffic control, and ARR.
Function 1. The system or operator originates a test call, and performs
Implementatio QoS audit on the IP bearer network for the test call.
n
2. Dynamically select a code/decode with higher priority for the
voice call according to the obtained result of QoS audit on
the IP bearer network.
3. Dynamically select an outgoing route for the voice call
according to the obtained result of QoS audit on the IP
bearer network.
Bidirectional Forwarding
Detection Function
Overview In the IP network, the Bidirectional Forwarding Detection (BFD)
function greatly improves the fault detection and recovery speed.
BFD is a standard draft of Internet Engineering Task Force
(IETF). It provides a simple and abstract method of detecting
the network link capability and the system communication
forwarding function. It also defines a simple and specific method
of detecting links or the traffic forward function of the system.

Function When the softswitch equipment accesses the IP bearer network,

Implementatio or when the softswitch equipment is interconnected with each
n other, the BFD function can quickly detect link statuses. It can
quickly find faults on links, and tells the detection initiating
equipment to quickly process the faults on the bearer path. The
typical networking mode is shown in Figure 196.
FIGURE 196 TYPICAL NETWORKING DIAGRAM OF BFD
Compatibility Function with

2G
The ZXWN MSCS system provides the following compatibility
functions with 2G:
Grading access based on half rate. For details, refer to
Grading Access Based on Half Rate;
Determining whether to authenticate the User Equipment
(UE) according to the IMSI. For details, refer to Determining
Whether to Authenticate the UE according to the IMSI;
Judging the type of an incoming call according to the
Forward call indicators (FOCIN) information in the ISUP/BICC
signaling. For details, refer to Judging the Type of An
Incoming Call according to the FOCIN Information in the
ISUP/BICC Signaling;
PSTN subscribers access EGSM. For details, refer to PSTN
Subscribers Accessing EGSM;
Not generating SM acknowledgment CDRs. For details, refer
to Not Generating SM Acknowledgment CDRs;

Adjusting separate IP addresses. For details, refer to

Adjusting Separate IP Addresses;
Restricting the number of Unstructured Supplementary
Service Data (USSD) dialogs through security variables. For
details, refer to Restricting the Number of USSD Dialogs
through Security Variables;
Playing a separate tone for number incomplete. For details,
refer to Playing a Separate Tone for Number Incomplete.
Grading Access Based on Half Rate

Definition Grading access of subscribers refers to that all the mobile
subscribers in an operator are classified, and each class of
subscribers enjoy a priority. According to the requirements, the
subscribers are classified to two grades during the grading
access based on half rate. Grade 1 subscribers use full-rate
channels all the time no matter whether the load is high or low,
while grade 2 subscribers use half-rate channels when the load
is high.
The grading access based on half rate is shown in Figure 197.
FIGURE 197 GRADING ACCESS BASED ON HALF RATE
Judges whether channels

are idle and allocates
half-rate channels based
HLR VLR on subscriber grades
during calls
Complete Call
(MS category)
Response to inserting
subscriber data
(MS category) MSCS BSC MS
Subscriber
grade
subscription
Assignment request (Channel rate and type)
The subscriber grade is subscribed in the HLR
The subscriber grade is carried to the CC when the call is complete.
The subscriber grade is translated into “ channel speed and type”, and
then transferred to the RNC
The RNC performs half-rate channel allocation and handover processing
There is no conflict between the grading access based on half

rate and the grading access. The grading access function
implements the priority difference of subscribers in getting radio
resources, while the grading access based on half rate
implements the difference of subscribers in selecting full-rate
channels or half-rate channels.

Features of During the grading access based on half rate, the MSCS has the
Grading Access following functions:
Based on Half
1. A new status parameter is set in the MSCS to control
Rate
whether to activate the differential function based on half
rate. Set this status parameter to activate this function.
2. The MSCS/VLR can receive messages from the HLR during
the location update, containing the grades of subscribers.
3. The MSCS/VLR can analyze subscriber grades and terminal
capability, and send the “channel rate and type” parameter
to the BSC through the A interface.
4. When a subscriber with priority in one network roams to
another network, the local MSCS/VLR does not judge the
grade of the subscriber no matter which grade the subscriber
is of in the message sent from the HLR to the MSCS/VLR.
Reference For the related specifications of the grading access based on half
Standard rate, refer to Chapter 2 in China Mobile GS M Target Network
Upgrade Project-Radio Access Part (v7.0).
Features of After implementing the grading access function and the grading
Grading Access access based on half rate, the grading access of the whole
of the Whole system has the following features:
System
Grade 1: the highest priority. Grade 1 subscribers use full-
rate channels all the time no matter whether the load is high
or low. In the areas with heavy traffic, the radio system
reserves some dedicated resources for these subscribers.
When a grade 1 subscriber roams to an area with heavy
traffic, the system first allocate the reserved radio resource
to him/her. If the resource is exhausted, he/she will share
the public resources with subscribers of other grades, but
preferably occupy the public resources. In addition, when the
system resources are insufficient, the system can hand some
grade 3 subscribers over to other adjacent cells, and allocate
the unoccupied resources to grade 1 subscribers.
Grade 2: Grade 2 subscribers use full-rate channels all the
time no matter whether the load is high or low. The system
does not reserve dedicated resources for these subscribers.
They share the public resources with subscribers of other
grades. The resource occupation priority is less than that of
grade 1 subscribers. In similar manner, when the system
resources are insufficient, the system can hand some grade
3 subscribers over to other adjacent cells, and allocate the
unoccupied resources to grade 2 subscribers.
Grade 3: Grade 3 subscribers use half-rate channels when
the load is high. The system does not reserve dedicated
resources for these subscribers. They share the public
resources with subscribers of other grades. The resource
occupation priority is less than that of the subscribers of
other grades. When the system resources are insufficient,
the system can hand some grade 3 subscribers over to other

adjacent cells, and allocate the unoccupied resources to

subscribers of other grades.
Determining Whether to Authenticate

the UE according to the IMSI
UE authentication means authenticating the validity of the EIR
number of the mobile terminal, setting a blacklist of stolen
terminals to disable them, and restricting the sham terminals.
UE authentication is performed based on operators. UE
authentication is performed through the EIR database. In
general, the implementation range is in an operator in a
country/region. For international roaming subscribers, the UE
authentication function is generally not enabled because it is
hard to judge whether their IMEIs are in the blacklist.
UE authentication can be controlled through security variables.
This function is disabled by default.
UE authentication can be set through the VLR. This function is
triggered during location updates, calls, SMS, and
supplementary services.
UE authentication in international roaming, and national inter-
network roaming is shown in Figure 198.
FIGURE 198 UE AUTHENTICATION IN INTERNATIONAL ROAMING, AND

NATIONAL INTER-NETWORK ROAMING

Judging the Type of An Incoming

Call according to the FOCIN
Information in the ISUP/BICC
Signaling
For an ISUP/BICC incoming call, when the calling number is
empty, the system judges whether the call is a national call or
an international call according to the FOCIN information in the
signaling.
The solution of 2G is adding the FOCIN field to the incoming
trunk CDR (gatein and trunkin CRDs) to indicate that the call is a
national call or an international call. This field in the outgoing
trunk CDR (gateout and trunkout CDRs) is invalid.
The FOCIN field is defined as:
255: invalid
0: national call
1: international call
The networking diagram of judging the type of an incoming call
according to the FOCIN information in the ISUP/BICC signaling is
FIGURE 199 JUDGING THE TYPE OF AN INCOMING CALL ACCORDING TO THE

FOCIN INFORM ATION IN THE ISUP/BICC SIGNALING

PSTN Subscribers Accessing EGSM

Overview When low-rate PSTN subscribers access the GSM network, they
only use EGSM frequency points as access frequency points, but
are not allowed to occupy the resources of high-rate mobile
subscribers. Therefore, each sector is configured with one EGSM
frequency point. Even if this frequency point is all occupied,
PSTN subscribers are not allowed to access the 900M frequency
points. However, if mobile phones support EGSM, they can
access EGSM when the 900M frequency points are all occupied.
This service is a non-standard service. The MSC and BSC
determine whether to support this service through parameter
control.
Implementatio The essence of this function is grading of subscribers. Different
n Method grades of subscribers are allocated with different air channel
resources.
Classify mobile subscribers and PSTN subscribers. Different
categories of subscribers are allocated with different priorities.
The “Category” of subscribers obeys ITU Q.767 specification.
The HLR carries the “Category” value to the VLR during the
subscriber location update, and the MSC allocates the priority
according to the “Category” value during circuit assignment. The
radio network allocates radio resources to subscribers based on
the principle that the subscribers with priority 12 only use the
EGSM frequency point as the access frequency point, and that
the subscribers with priority 14 can access EGSM when 900M
frequency points are all occupied if their mobile phones support
EGSM.
The schematic diagram of PSTN subscribers accessing EGSM is

FIGURE 200 PSTN SUBSCRIBERS ACCESSING EGSM
Not Generating SM
Acknowledgment CDRs
The SM acknowledgment function enables the SC to return a
success or failure result when a subscriber sends a SM. The
success or failure triggering acknowledgement is set by the SC.
A typical application is “meeting people at airports”. When a
friend or relative visit a subscriber by air, the subscriber can
send a message to the passenger in the plane, and ask for an
acknowledgement about successful sending. Usually the
passenger is asked to power off his/her mobile phone after going
aboard. When he/she powers on the mobile phone after landing,
the SC will immediately send the SM, and will send an
acknowledgment to the calling subscriber after the SM is
successfully sent.
Adjusting Separate IP Addresses

In 2G, Special Resource Function (SRF) judges this (security
variable) flag during perform ETC operations. If the flag is set to
1, adjust separate IP addresses. For an international number,
remove the country code, and add the toll prefix. For a national
number, add the toll prefix. If the flag is set to 0, keep them
unchanged.

The separate IP addresses are adjusted to be of the following

format: Toll prefix + National valid number (Area code +
Subscriber number).
The flowchart of adjusting separate IP addresses is shown in
Figure 201.
FIGURE 201 FLOWCHART OF ADJUSTING SEPAR ATE IP ADDRESSES
Restricting the Number of USSD

Dialogs through Security Variables
Overview The threshold number of USSD dialog IDs is controlled through
security variables. In V1, the USSD dialog ID is used by the VLR
module. In V3, the MSC module is combined with the VLR
module, so the TM dialog ID is used by the MSCMAP, CAP, and
VLRMAP.
Definition of The USSD dialog ID restriction level is divided into level 1, 2,
USSD in 2G and 3, with level 3 as the default value.
Where,
1: USSD restriction level 1, 1500 dialogs;
2: USSD restriction level 2, 800 dialogs;
3: USSD restriction level 3, 300 dialogs.
Definition of The maximum number of dialogs in 3G is 7500, which is used by
USSD in 3G multiple services. USSD services may be performed in the
VLRMAP or MSCMAP, and the number of data areas in them is
different. Therefore, in 3G, the percentage of dialog IDs is set,
which ranges from 0 to 100, with 30 as the default value.
Flow of USSD The flow of USSD service load control initiated by the HLR is
Service Load shown in Figure 202.
Control
Initiated by
the HLR

FIGURE 202 FLOW OF USSD SERVICE LOAD CONTROL INITIATED BY THE HLR
TCAP TM MAP
MSG_TC_BEGIN_IND
In case of USSD messages, compare

the level set through security
variables with the current used data
areas to see whether the current
used data areas exceed the level
mlUAbortREvent
Perform load mmMAP_OpenIndEvent

control, and
release TCAP Do not perform load
control, and send the
message to MAP
Flow of USSD The flow of USSD service load control initiated by the local office
Service Load is shown in Figure 203.
Control
Initiated by FIGURE 203 FLOW OF USSD SERVICE LOAD CONTROL INITIATED BY THE
the Local LOCAL OFFICE
Office
TCAP TM MAP
MSG_MAP_OPEN_REQ
In case of USSD messages, compare

the level set through security
variables with the current used data
areas to see whether the current
used data areas exceed the level
Do not perform
load control, set
the timer, and waif
for the definition mmMAP_OpenCnfEvent
message
Perform load
control, and release
the MAP dialog
Playing a Separate Tone for Number

Incomplete
At present, when a PSTN subscriber dials an incomplete mobile
number, he/she usually hears that “the number you dialed does
not exist”. According to the special requirement, the tone “the
number you dialed is incomplete” can be played.


Abbreviations
Abbreviations Full Name

A
ACK Acknowledgement
ACM Accumulated Call Meter
ACM Address Complete Message
AE Application Entity
APB ATM Process Board
AoC Advice of Charge
AoCC Advice of Charge Charging supplementary service
Advice of Charge Information supplementary
AoCI
service
ASE Application Service Element
ASIG Analog Signaling
AuC Authentication Centre
B
Barring of All Incoming Calls supplementary
BAIC
service
Barring of All Outgoing Calls supplementary
BAOC
service
BCCH Broadcast Control Channel
BCTL Back Control
BCSN Backplane of Circuit Switch Network
BDT Back Digital Trunk
BCTC Backplane of Control Center
BFBI Back Fiber Bus Interface
BHCA Busy hour Calling Attempt
Barring of Incoming Calls when Roaming outside
BIC-Roam
the home PLMN country supplementary service
BNET Back Network
BO all Barring of Outgoing call supplementary services
Barring of Outgoing International Calls
BOIC
supplementary service


Barring of Outgoing International Calls except
BOIC-exHC those directed to the home PLMN Country
BPSN Backplane of Packet Switch Network
BS Basic Service （group）
BS Bearer Service
BSG Basic Service Group
BTS Base Transceiver Station
BUSN Backplane of Universal Switch Network
C
CAI Charge Advice Information
CB Cell Broadcast
CBC Cell Broadcast Centre
CBCH Cell Broadcast Channel
CBK Clear Back signal
CC Country Code
Call Control
CCF Conditional Call Forwarding
The International Telegraph and Telephone
CCITT
Consultative Committee
Cct Circuit
CF all Call Forwarding services
Call Forwarding on mobile subscriber Busy
CFB
Call Forwarding on mobile subscriber Not
CFNRc
Reachable supplementary service
Call Forwarding on No Reply supplementary
CFNRy
service
Call Forwarding Unconditional supplementary
CFU
service
CG Charging Gateway
CGC Circuit Group Congestion signal
CI Cell Identity
CUG Index
CLKG CLOCK Generator
CLKI CLOCK Interface
CLI Calling Line Identity
Calling Line Identification Presentation
CLIP

Abbreviations

Calling Line Identification Restriction
CLIR
CM Connection Management
CMD Command
CMP Control Main Processor
COLI Connected Line Identity
Connected Line identification Presentation
COLP
Connected Line identification Restriction
COLR
D
DTB Digital Trunk Board
G
Connected Line identification Presentation
COLP
GLI GE Line Interface
GERAN GSM Enhanced Radio Access Network
I
IMAB IMA Board
IPB IP Process Board
IPI IP bearer Interface
IWFB IWF Board
M
MNIC Multi-service Network Interface Card
MONB Monitor Board
MPB Main Process Board
MRB Media Resource Board
O
OMP Operation Main Processor
P
PLI POS Line Interface
PSN Packet Switch Network
PWRD POWER Distributor
S
SDHB SDH Board
SDTB Sonnet Digital Trunk Board
SDU Selection and Distribution Unit
SMP Signal Main Processor


SPB Signaling Process Board
T
TFI TDM Fiber Interface
TSNB TDM Switch Network Board
U
UIM Universal Interface Module
V
VTC Voice Trancoder Card

Glossary
3G 3G refers to next generation of mobile communication systems.

These offer enhanced services, such as multimedia and video.
Main 3G technologies include UMTS and CDMA2000.
3GPP 3GPP was formed in December 1998 as a collaboration
agreement bringing together a number of telecommunication
standards bodies. These standards bodies are referred to as
Organizational Partners. Aim of 3GPP was to produce globally
applicable technical specifications for third generation mobile
systems based on evolved GSM Core Networks and the radio
access technology Universal Terrestrial Radio Access (UTRAN).
3GPP2 3GPP2 is a sister project to 3GPP and is a collaboration
agreement regarding third generation mobile networks. It is
comprised of five Standards Development Organizations similar
to Organizational Partners in 3GPP. 3GPP2 mainly deals with the
following five areas: A-interface system, CDMA2000, American
National Standards Institute-41 (ANSI-41), wireless packet data
inter-working, and services & systems aspects.
Access Point An Access Point is a network device which provides the point of
interconnection between wireless station (laptop computer, PDA)
and wired network.
Bearer Service Bearer Service is a type of telecommunication service that
provides the capability for transmission of signals between
access points.
Broadband Broadband in radio systems identifies a type of communication
channel capable of carrying a large portion of electromagnetic
spectrum. It may also be applied to fixed communication
systems when referring to bearers capable of carrying high
volumes of traffic.
FTP A client server application protocol using well known ports 20
and 21. It uses the services of Transmission Control Protocol
(TCP) to provide reliability in the transfer of data files between
network nodes. FTP was first defined as a standard in Request
for Comments (RFC 959).
GE Gigabit Ethernet (GE) is the Ethernet standard offering Gigabit
services and typically employs fibre. This technology has been
used for backbone networks and desktops for high end servers
and intensive graphical applications.

Handoff or A Handoff, or Handover, is the process in which a cellular phone

Handover is handed from one cell to the next in order to maintain a radio
connection with the network
IMEI International Mobile Equipment Identity is a unique identifier

allocated to each Mobile Equipment (ME). It consists of a Type
Approval Code (TAC), a Final Assembly Code, Serial Number
(SNR) and a Spare Digit.
IMSI International Mobile Subscriber Identity is a unique identifier
allocated to each mobile subscriber in a GSM and UMTS network.
It consists of a Mobile Country Code (MCC), a Mobile Network
Code (MNC) and a Mobile Station Identification Number (MSIN).
ISUP ISDN User Part is part of the SS7 protocol layer and used in
setting up, management, and release of trunks that carry voice
and data between calling and called parties.
Iu-CS This is the interface in UMTS which links the Radio Network
Controller with MSC Server.
Iu-PS This is the interface in UMTS which links the RNC with SGSN.
LAI Location Area Identity uniquely identifies a Location Area (LA)
within any Public Land Mobile Network (PLMN). It is comprised of
the Mobile Country Code (MCC), Mobile Network Code (MNC)
and the Location Area Code (LAC).
MAC Address MAC address refers to hardware address and uniquely identifies
a device within a defined network area.
MSISDN Mobile Station ISDN (MSISDN) Number is the standard
international telephone number used to identify a given
subscriber. MSISDN is based on the International
Telecommunications Union-Telecommunication Standardization
Sector (ITU-T) E.164 standard.
MSRN Mobile Station Roaming Number is an E.164 defined telephone
number used to route telephone calls in a mobile network from a
Gateway Mobile Switching Centre (GMSC) to the target MSC.
MTP Message Transfer Part forms part of the SS7 protocol stack and
provides reliable routing usually within a network.
Network A set of procedures, software, equipment etc in order to keep a
Management network operating in an efficient manner. ITU-T have developed
a series of standards for Network Management which are
referred to as the Telecommunication Management Network
(TMN). This sub-divides Network Management into the following
five categories; Fault, Configuration, Performance, Accounting
and Security.
Node B Node B is the function within the UMTS network that provides
physical radio link between User Equipment (UE) and the
network.
Physical A physical channel supports physical media, usually in an
Channel encoded format. This may be pulses of light, a modulated
voltage or radio waves.

Glossary
Protocol Stack Conceptual model of layered architecture of communication

protocols in which, layers within a station are represented in
hierarchical order. Each layer in the protocol stack is defined in
generic terms describing functionality and mode of operation.
QoS Performance of a communications channel or system is usually
expressed in terms of Quality of Service (QoS). Depending upon
the communication system, QoS may relate to service
performance, Signal to Noise Ratio (SNR), Bit Error Ratio (BER),
maximum and mean throughput rate, reliably, priority and other
factors specific to each service.
Radio Access Radio Access Network (RAN) performs the radio functionality of
Network network, as well providing connection to Core Network. RAN
typically includes a controller Radio Network Controller (RNC) in
3GPP and BSC in 3GPP2 and several transmitter/receivers Node
B in 3GPP, BTS in 3GPP2.
RANAP Radio Access Network Application Part (RANAP) is used in a
UMTS system on the Iu interface. It is responsible for function
including setting up of a Radio Access Bearer (RAB) between the
Core Network and RNC.
SCCP Signalling Connection Control Part is used to provide a means for
the transfer of messages between any two signalling points in
the same or different SS7 networks.
SCTP Streaming Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of IP. It provides
acknowledged error free non duplicated transfer of data. STCP
also detects data corruption, loss of data and duplication of data
by using checksums and sequence numbers.
Signaling A Signaling Gateway is used to support the transport of
Gateway signalling traffic received from one network and passed into
another network.
TMSI In order to ensure subscriber identity confidentiality VLR and
SGSN may allocate Temporary Mobile Subscriber Identities
(TMSI) to visiting mobile subscribers. VLR and SGSN must be
capable of correlating an allocated TMSI with IMSI of MS to
which it is allocated. A MS may be allocated two TMSI, one for
services provided through VLR, and the other known as the
Packet TMSI (P-TMSI) services provided through the SGSN.
TUP Telephone User Part was an earlier implementation of SS7 that
did not allow for data type applications, hence the introduction
of ISDN User Part (ISUP).
UMTS A 3G mobile communications system which provides an
enhanced range of multimedia services. UMTS will speed
convergence between telecommunications, IT, media and
content industries to deliver new services and create fresh
revenue generating opportunities. UMTS will deliver low cost,
high capacity mobile communications offering data rates as high
as 2Mbps under stationary conditions with global roaming and
other advanced capabilities. The specifications defining UMTS
are formulated by 3GPP.

VCI The identifier in ATM cell header that identifies to which virtual
channel the cell belongs.
WAP A standard designed to allow the content of Internet to be
viewed on the screen of a mobile device such as mobile phones,
personal organisers and pagers. WAP also overcomes the
processing limitation of such devices. Information and services
available are stripped down to their basic text format.

Figures
Figure 1 Structure of the R4 CN............................................3

Figure 2 Interfaces in 3GPP R4 PLMN.....................................4
Figure 3 Interfaces between NEs in the CS Domain .................5
Figure 4 Structure of the R5 CN............................................6
Figure 5 Interfaces of the MGCF and the IM-MGW ...................7
Figure 6 Main Interfaces of the ZXWN MSCS System ............. 10
Figure 7 Protocol Stack of the Iu-CS Interface Control Plane ... 12
Figure 8 Protocol Stack of the A Interface Control Plane ......... 13
Figure 9 Mc Interface Protocol Stack ................................... 14
Figure 10 Protocol Stack of the Nc Interface ......................... 14
Figure 11 Protocol Stack of the Mn Interface ........................ 15
Figure 12 Protocol Stack of the MAP Interface....................... 16
Figure 13 Protocol Stack of the CAP Interface ....................... 16
Figure 14 Protocol Stack of the Gs Interface ......................... 17
Figure 15 Protocol Stack of the Mj/Mg Interface .................... 18
Figure 16 Billing Interface.................................................. 18
Figure 17 O&M Interface Protocol Architecture ...................... 19
Figure 18 Position of the Corba Interface ............................. 20
Figure 19 Structure of the Lawful Interface .......................... 21
Figure 20 Position of the SNMP Interface.............................. 22
Figure 21 Narrowband No.7 Signaling Protocol Stack ............. 24
Figure 22 MSU of Narrowband No.7 Signaling ....................... 25
Figure 23 LSSU of Narrowband No.7 Signaling ...................... 25
Figure 24 FISU of Narrowband No.7 Signaling....................... 25
Figure 25 Format of SF...................................................... 26
Figure 26 MTP3 Architecture .............................................. 28
Figure 27 Structure of the SCCP Protocol ............................. 30
Figure 28 Layered Structure of the TCAP.............................. 35
Figure 29 Protocol Stack of the Broadband Signaling System .. 37

Figure 30 SAAL Structure .................................................. 38

Figure 31 SIGTRAN Protocol Stack ...................................... 41
Figure 32 Structure of the SCTP ......................................... 42
Figure 33 Functional Modules of SCTP ................................. 44
Figure 34 Functional Structure of M3UA ............................... 48
Figure 35 Separated Gateway Model ................................... 51
Figure 36 Application of the H.248 protocol .......................... 52
Figure 37 H.248/MEGACO Protocol Connection Model............. 53
Figure 38 BICC Protocol Model ........................................... 60
Figure 39 Structure of the BICC Protocol Based on the IP
Transport Network............................................................ 64
Figure 40 Structure of the BICC Protocol Based on the ATM
Figure 41 Structure of the BICC Protocol Based on the TDM
Figure 42 Gs Interface Protocol Stack .................................. 71
Figure 43 Location Update of the Non-GPRS Service .............. 72
Figure 44 Paging Procedure of the Non-GPRS Service ............ 72
Figure 45 Alert Procedure of the Non-GPRS Service ............... 73
Figure 46 Explicit IMSI Detach Procedure of the GPRS Service 73
Figure 47 Explicit IMSI Detach Procedure of the Non-GPRS
Service ........................................................................... 74
Figure 48 Implicit IMSI Detach Procedure of the Non-GPRS
Service ........................................................................... 74
Figure 49 VLR/SGSN Reset Procedure.................................. 75
Figure 50 MS Information Procedure ................................... 75
Figure 51 CAP System....................................................... 77
Figure 52 Operation Description ......................................... 78
Figure 53 Format of the SIP Request Message ..................... 85
Figure 54 Format of the SIP Response Message ................... 86
Figure 55 Processing Flow without Need of Location Update to
HLR ................................................................................ 97
Figure 56 Processing Flow Needing Location Update Initiation to
HLR ................................................................................ 98
Figure 57 GPRS Location Update Service Flow .................... 100
Figure 58 Joint Location Update Service Flow...................... 101
Figure 59 VLR Requesting Data Deletion Flow ..................... 102
Figure 60 UMTS → UMTS Network Model before Intra-office
Subscriber Handover....................................................... 103

Figures
Figure 61 UMTS → UMTS Network Model during Intra-office

Figure 62 UMTS → UMTS Network Model after the Intra-office
Figure 63 UMTS → UMTS Intra-office Relocation Flow .......... 105
Figure 64 UMTS → UMTS Intra-office Relocation Flow (Continued)
................................................................................... 106
Figure 65 UMTS → UMTS Network Model before the Inter-office
Handover ...................................................................... 107
Figure 66 UMTS → UMTS Network Model during the Inter-office
Handover ...................................................................... 108
Figure 67 UMTS → UMTS Network Model after the Inter-office
Handover ...................................................................... 108
Figure 68 UMTS → UMTS Inter-office Handover Flow ........... 109
Figure 69 UMTS → UMTS Inter-office Handover Flow (Continued)
................................................................................... 110
Figure 70 UMTS → GSM Network Model before Intra-office
Handover ...................................................................... 112
Figure 71 UMTS → GSM Network Model during Intra-office
Handover ...................................................................... 112
Figure 72 UMTS → GSM Network Model after Intra-office
Handover ...................................................................... 113
Figure 73 UMTS → GSM Intra-office Handover Flow ............. 114
Figure 74 UMTS → GSM Inter-office Handover Flow (Continued)
................................................................................... 115
Figure 75 UMTS → GSM Network Model before Inter-office
Handover ...................................................................... 116
Figure 76 UMTS → GSM Network Model during Inter-office
Handover ...................................................................... 117
Figure 77 UMTS → GSM Network Model after Inter-office
Handover ...................................................................... 117
Figure 78 UMTS → GSM Inter-office Handover Flow ............. 118
Figure 79 UMTS → GSM Inter-office Handover Flow (Continued)
................................................................................... 119
Figure 80 GSM → UMTS Network Model before the Intra-system
Handover ...................................................................... 121
Figure 81 GSM → UMTS Network Model during the Intra-system
Handover ...................................................................... 122
Figure 82 GSM → UMTS Network Model after the Intra-system
Handover ...................................................................... 122
Figure 83 GSM → UMTS Intra-system Handover Flow........... 123

Figure 84 GSM → UMTS Network Model before Inter-office

System Handover ........................................................... 125
Figure 85 GSM → UMTS Network Model during Inter-office
System Handover ........................................................... 125
Figure 86 GSM → UMTS Network Model after the Inter-office
System Handover ........................................................... 125
Figure 87 GSM → UMTS Inter-office System Handover Flow.. 126
Figure 88 GSM → UMTS Inter-office System Handover Flow
(Continued) ................................................................... 127
Figure 89 GSM → GSM Network Model before Intra-office System
Handover ...................................................................... 129
Figure 90 GSM → GSM Network Model during Intra-office System
Handover ...................................................................... 129
Figure 91 GSM → GSM Network Model after Intra-office System
Handover ...................................................................... 130
Figure 92 GSM → GSM Intra-office System Handover Flow ... 131
Figure 93 GSM → GSM Intra-office System Handover Flow
(Continued) ................................................................... 132
Figure 94 GSM → GSM Network Model before Inter-office System
Handover ...................................................................... 133
Figure 95 GSM → GSM Network Model during Inter-office System
Handover ...................................................................... 134
Figure 96 GSM → GSM Network Model after Inter-office System
Handover ...................................................................... 134
Figure 97 GSM → GSM Inter-office System Handover Flow ... 135
Figure 98 GSM → GSM Inter-office System Handover Flow
(Continued) ................................................................... 136
Figure 99 Generation of Authentication Parameters in AUC ... 140
Figure 100 Generation of Authentication Parameters in USIM 140
Figure 101 Normal Authentication Process.......................... 140
Figure 102 Generation OF AUTHENTICATION Resynchronization
Parameter AUTS in USIM ................................................. 142
Figure 103 Generation OF AUTHENTICATION Resynchronization
Parameter AUTS in AUC .................................................. 143
Figure 104 Ciphering Process ........................................... 144
Figure 105 Integrity Protection Process.............................. 145
Figure 106 Flow of INSERTING SUBSCRIBER Data............... 147
Figure 107 Service Flow of Deleting Subscriber Data ........... 148
Figure 108 VLR Restart Service Flow ................................. 149
Figure 109 HLR Restart Flow ............................................ 150

Figures
Figure 110 Structure of the Mobile Call Service Processing

Module.......................................................................... 151
Figure 111 Network Structure of the UE Originated Call ....... 153
Figure 112 Signaling Flow of the UE Originated Call ............. 153
Figure 113 Network Structure of the UE Terminated Call ...... 155
Figure 114 Signaling Flow of the UE Terminated Call with the
Paging Procedure ........................................................... 156
Figure 115 Network Model of Originated Call ...................... 158
Figure 116 Originated Call Setup Time Sequence in Case of
Forward Bearer Establishment .......................................... 159
Forward Bearer Establishment (Continued) ........................ 159
Backward Bearer Establishment........................................ 161
Backward Bearer Establishment (Continued) ...................... 162
Figure 120 Network Model of Terminated Call ..................... 163
Figure 121 Terminated Call Setup Time Sequence in Case of
Forward Bearer Establishment .......................................... 164
Forward Bearer Establishment (Continued) ........................ 165
Backward Bearer Establishment........................................ 169
Backward Bearer Establishment (Continued) ...................... 170
Figure 125 MS On-hook Flow............................................ 174
Figure 126 Network-side On-hook Flow.............................. 175
Figure 127 “Register” Operation Flow ................................ 178
Figure 128 “Erase” Operation Flow ................................... 179
Figure 129 “Activation” Operation Flow .............................. 180
Figure 130 “Interrogate” Operation Flow ............................ 181
Figure 131 “Register Password” Flow ................................. 181
Figure 132 CLIR Flow ...................................................... 183
Figure 133 CFB Flow ....................................................... 185
Figure 134 CFNRY Flow ................................................... 186
Figure 135 Providing Forwarding Number........................... 187
Figure 136 Call Waiting Flow (1) ....................................... 188
Figure 139 Call Hold Flow ................................................ 190

Figure 140 MPTY Call Processing Flow................................ 193

Figure 141 BOC Service Flow ........................................... 195
Figure 142 BIC Service Flow ............................................ 196
Figure 143 ECT Processing............................................... 197
Figure 144 CD Processing ................................................ 198
Figure 145 Application Fields of IN .................................... 201
Figure 146 INCM Structure .............................................. 202
Figure 147 Block Diagram of CAMEL .................................. 205
Figure 148 O-BCSM ........................................................ 210
Figure 149 T-BCSM......................................................... 213
Figure 150 Originating BCSM of Mobile Subscriber............... 217
Figure 151 Terminating BCSM of Mobile Subscriber ............. 218
Figure 152 Terminating BCSM Call Forwarding of Mobile
Subscriber (1)................................................................ 218
Figure 153 Terminating BCSM Call Forwarding of Mobile
Subscriber (2)................................................................ 219
Figure 154 MO Processing Flow of the Basic Call in the UMTS 223
Figure 155 Route Processing Flow of the Basic Call in the UMTS
................................................................................... 225
Figure 156 MT Processing Flow of Basic Calls in the UMTS .... 226
Figure 157 MO Flow of MPPS ............................................ 228
Figure 158 Routing Flow of the MPPS ................................ 231
Figure 159 Called Service Flow of MPPS ............................. 233
Figure 160 SM MO Processing Flow ................................... 237
Figure 161 SM MT Processing Flow .................................... 238
Figure 162 Alert Message Flow (1) .................................... 239
Figure 163 Alert Message Flow (2) .................................... 240
Figure 164 Service Flow of Activating/Deactivating Subscriber
Tracing ......................................................................... 241
Figure 165 IMSI-Sending Service Flow............................... 242
Figure 166 Network Mode Adopting DT Link ....................... 244
Figure 167 Network Mode adopting SPB Link ...................... 245
Figure 168 Connection between LIC and network elements... 246
Figure 169 Schematic Diagram of Lawful Interface .............. 247
Figure 170 Connection between LIC and NEs ...................... 248
Figure 171 Connection Schematic Diagram for ETSI Interception
Service ......................................................................... 250
Figure 172 Russia Interception Service .............................. 251

Figures
Figure 173 MS-Terminated Location Request (MT-LR) .......... 253

Figure 174 MS-Originated Location Request (MO-LR) ........... 256
Figure 175 Network-Initiated Location Request (NI-LR)........ 258
Figure 176 Deferred MS-Terminated Location Request
(DEFERED-MT-LR) .......................................................... 260
Figure 177 Region-System Networking Mode ...................... 263
Figure 178 Networking Resource Partition of the Region System
................................................................................... 263
Figure 179 1+1 Active/standby-mode Networking ............... 265
Figure 180 1+1 Mutual-backup-mode Networking ............... 266
Figure 181 N+1 Active/standby-mode Networking............... 266
Figure 182 N+1 Mutual-backup-mode Networking ............... 267
Figure 183 Congestion Control Flow .................................. 269
Figure 184 Setting the MP Load Statistics Interval ............... 270
Figure 185 Threshold Setting of Each Congestion Level ........ 271
Figure 186 Networking Mode............................................ 272
Figure 187 Multi-EIR Networking Mode .............................. 275
Figure 188 M2PA Networking Mode ................................... 276
Figure 189 Adaptation Model ............................................ 277
Figure 190 Flow Chart of the Terminal Subscriber in the IMS
Domain Calling the Subscriber in the CS Domain/PSTN ........ 278
Figure 191 Flow Chart of the Subscriber in the CS Domain/PSTN
Calling the Terminal Subscriber in the IMS Domain.............. 280
Figure 192 Flowchart of Detecting Cheaters and Performing
Service Restriction.......................................................... 283
Figure 193 Flowchart of Generating Call Attempt CDRs ........ 285
Figure 194 Processing Flowchart ....................................... 286
Figure 195 ARR Function ................................................. 290
Figure 196 Typical Networking Diagram of BFD ................... 291
Figure 197 Grading Access Based on Half Rate.................... 292
Figure 198 UE Authentication in International Roaming, and
National Inter-network Roaming ....................................... 294
Figure 199 Judging the Type of An Incoming Call according to
the FOCIN Information in the ISUP/BICC Signaling .............. 295
Figure 200 PSTN Subscribers Accessing EGSM .................... 297
Figure 201 Flowchart of Adjusting Separate IP Addresses ..... 298
Figure 202 Flow of USSD Service Load Control Initiated by the
HLR .............................................................................. 299

Figure 203 Flow of USSD Service Load Control Initiated by the

Local Office ................................................................... 299

Tables
Table 1 Chapter Summary ................................................... ii

Table 2 Typographical Conventions ....................................... ii
Table 3 Mouse Operation Conventions .................................. iii
Table 4 Functions of China 2G Interception Interfaces............ 22
Table 5 Capabilities Supported by BICC for Basic Call ............ 61
Table 6 Generic Signaling Procedures, Supplementary Services
and Some Additional Functions/Services Supported by BICC ... 63
Table 7 CAP Operations Associated with CS .......................... 79
Table 8 CAP Operations Associated with SMS........................ 80
Table 9 Category of Response Messages ............................. 87
Table 10 List of Common 1xx Messages ............................... 87
Table 15 UMTS Supplementary Services ............................ 176
Table 16 UMTS Circuit Data Services ................................. 199
Table 17 Architecture and Functions of IN .......................... 201
Table 18 Description of DPs in the O-BCSM ........................ 210
Table 19 Description of DPs (2) ........................................ 214
Table 20 DP Disarming Relations in the O-BCSM ................. 220
Table 21 DP Disarming Relations in the T-BCSM.................. 221
Table 22 Hardware required for Common Interception ......... 245
Table 23 Functions of China 3G Interception Interfaces ........ 248
Table 24 Hardware Required for Russia Interception Service . 251


Index
active status....... 189, 190, 192 M3UA12, 14, 15, 16, 17, 41, 42,
Active/standby 68, 70, 265, 266 47, 48, 49, 55
authentication ...42, 67, 76, 77, MAC address .................... 306
88, 96, 97, 138, 139, 140, mapping22, 39, 48, 49, 81, 246,
141, 142, 144, 145, 146, 247
157, 160, 162, 223, 238, Mobility management .....93, 94
247, 254, 255, 256, 261 MTP .12, 14, 37, 39, 40, 48, 55,
Backplane ................. 301, 302 56, 78, 306
Clock running mode MTP313, 14, 16, 17, 27, 28, 36,
free ............... 207, 208, 307 40, 47, 48, 49, 50, 275, 276
hold ....38, 80, 81, 187, 188, Networking mode ..2, 243, 244,
189, 190, 191, 192, 193, 247, 249, 250, 263, 265,
258 267, 271, 272, 274, 275,
trace 68, 241, 243, 245, 247 276
conference call.................... 81 No.7 link ......................... 147
configuration management . 263 number section ................ 273
Congestion....................... 302 Office
Control plane... 10, 12, 13, 103, local office .. 49, 67, 69, 267,
107, 112, 116, 121, 124, 273
129, 133, 152, 277 PCM .................... 24, 251, 271
Equipment commissioning Performance
process Performance statistics.... 263
Handover 67, 70, 94, 95, 96, Physical configuration ........ 264
103, 104, 106, 107, 108, Power failure.................... 149
109, 110, 111, 112, 113, Power off ............. 20, 245, 247
114, 115, 116, 117, 118, Power on 20, 53, 245, 247, 249
119, 120, 121, 122, 123, registration ... 54, 76, 101, 139,
124, 125, 126, 127, 128, 177, 178, 184
129, 130, 131, 132, 133, SC ... 9, 11, 236, 237, 238, 239,
134, 135, 136, 137, 306 240
FTAM................................. 18 Signaling
FTP ............................18, 305 No.7 signaling 11, 24, 47, 48,
IP address.................... 43, 46 56, 226, 275, 276
label.................................. 46 signaling point... 29, 30, 48, 50,
link . 15, 24, 25, 27, 28, 29, 38, 67, 69, 275
39, 40, 50, 151, 171, 244, Supplementary service 76, 176,
265, 275, 276, 306 183, 204
signaling link25, 29, 50, 264, switchover .............. 29, 39, 40
275, 276 System architecture .......28, 37
Local office configuration...... 49

sjzl20082259-ZXWN MSCS MSC Server Technical Description PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

sjzl20082259-ZXWN MSCS MSC Server Technical Description PDF

Hochgeladen von

Copyright:

Verfügbare Formate

ZXWN MSCS

Copyright © 2006 ZTE CORPORATION.

The ultimate right to interpret this product resides in ZTE CORPORATION.

Date Revision No. Serial No. Reason for Issue

Your evaluation Accessibility:

About This Manual ............................................................ i

Declaration of RoHS Compliance..................................... v

Interfaces and Communication ....................................... 9

Security Management .................................................. 138

Abbreviations ............................................................... 301

Tables ........................................................................... 317

Index ............................................................................ 319

Confidential and Proprietary Information of ZTE CORPORATION i

Prerequisite Skill and Knowledge

What Is in This Manual

TABLE 1 CHAPTER SUMM ARY

ii Confidential and Proprietary Information of ZTE CORPORATION

Mouse TABLE 3 MOUSE OPERATION CONVENTIONS

How to Get in Touch

Confidential and Proprietary Information of ZTE CORPORATION iii

This page is intentionally blank.

iv Confidential and Proprietary Information of ZTE CORPORATION

To minimize the environmental impact and take more

The ZXWN MSCS manufactured by ZTE CORPORATION meet the

Confidential and Proprietary Information of ZTE CORPORATION v

This page is intentionally blank.

vi Confidential and Proprietary Information of ZTE CORPORATION

Topics Page No.

Features of the R99 Version

Confidential and Proprietary Information of ZTE CORPORATION 1

 The Core Network (CN) is divided into Circuit Switched (CS)

Features of the R4 Version

Features of the R5 Version

2 Confidential and Proprietary Information of ZTE CORPORATION

Features of the R6 Version

UMTS R4 Network Structure

Note: Heavy lines mean bearer interfaces, while dashed lines

Confidential and Proprietary Information of ZTE CORPORATION 3

media services. The CS domain is composed of (G) MSC

Note 1: Heavy black lines mean bearer interfaces, while dashed

4 Confidential and Proprietary Information of ZTE CORPORATION

FIGURE 3 INTERFACES BETWEEN NES IN THE CS DOMAIN

Signalling and Data Transfer Interface

The CN is the CS domain is composed of (G) MSC Server, VLR

Confidential and Proprietary Information of ZTE CORPORATION 5

realize bearer independent of control. The Mc interface adopts

UMTS R5 Network Structure

Note: Heavy lines mean bearer interfaces, while dashed lines

6 Confidential and Proprietary Information of ZTE CORPORATION

FIGURE 5 INTERFACES OF THE MGCF AND THE IM-MGW

IP Multimedia Networks Legacy mobile

MRFP MRFC P-CSCF

The descriptions of the interfaces of the MGCF and IM-MGW are

Confidential and Proprietary Information of ZTE CORPORATION 7

This page is intentionally blank.

8 Confidential and Proprietary Information of ZTE CORPORATION

Sections Page No.

Confidential and Proprietary Information of ZTE CORPORATION 9

 SSP: responsible for accessing the mobile Intelligent Network

Interface As shown in Figure 6, the ZXWN MSCS implements the functions

10 Confidential and Proprietary Information of ZTE CORPORATION

Based on the narrowband No.7 signaling interface, this

Confidential and Proprietary Information of ZTE CORPORATION 11

The Core Network (CN) is divided into Circuit Switched (CS)

SSP: responsible for accessing the mobile Intelligent Network

One is the ATM cell transmission mode, with the protocol

The IP signaling transmission mode can adopt either

Narrowband SS7 signaling transmission mode, based on

C interface (interface between the GMSC server and the HLR)

Narrowband SS7 signaling transmission mode, which adopts

Interface between the SSP and the SCP (Completing mobile

Narrowband SS7 signaling transmission mode, which adopts

Narrowband SS7 signaling transmission mode, which adopts

The N interface describes such application protocols as

Q3 interface is between NMS modules such as LMF, LAF and

Features All O&M interfaces are application layer interfaces. They

RANAP protocol: For details, refer to RANAP Protocol.

The format of the LSSU is shown in Figure 23.

The format of the FISU is shown in Figure 24.