You are on page 1of 336

ZXWN MSCS

MSC Server

Technical Description
Version 3.09.21

ZTE CORPORATION
NO. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: (86) 755 26771900
Fax: (86) 755 26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn

LEGAL INFORMATION
Copyright 2010 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
Revision No.

Revision Date

Revision Reason

R1.0

Feb. 28, 2010

First edition

Serial Number: SJ-20100211152857-002

Contents

About This Manual............................................. I


Declaration of RoHS Compliance ....................... I
Basic Knowledge ...............................................1
Introduction to 3GPP Standard ......................................... 1
Network Structure of UMTS R99 ....................................... 3
Network Structure of UMTS R4 ......................................... 4
Network Structure of UMTS R5 ......................................... 5
Network Structure of UMTS R6 ......................................... 7
Introduction to Network Interfaces.................................... 9
Interfaces in R4 CN..................................................... 9
Interfaces in R5 IMS-domain Network ..........................11

Interface ......................................................... 13
Introduction to Interfaces ...............................................13
Iu-CS Interface .............................................................15
A Interface ...................................................................16
Mc Interface .................................................................17
Nc Interface..................................................................18
Mn Interface .................................................................18
MAP Interface ...............................................................19
CAP Interface................................................................20
Gs Interface..................................................................20
Mj/Mg Interface.............................................................21
Billing Interface.............................................................21
O&M Interface...............................................................22
CORBA Interface ...........................................................23
SNMP Interface .............................................................24
Interception Interface ....................................................26
3G Interception Interface ...........................................26
2G Interception Interface ...........................................27
ETSI Interception Interface .........................................28
Russia Interception Interface ......................................28

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

Signaling Protocol ........................................... 31


Narrowband SS7 ...........................................................31
Application in the MSCS..............................................31
Introduction to Narrowband No.7 Signaling ...................32
MTP1 Protocol ...........................................................32
MTP2 Protocol ...........................................................33
MTP3 Protocol ...........................................................35
SCCP Protocol ...........................................................37
TCAP Protocol ..........................................................41
TUP Protocol .............................................................43
ISUP Protocol ............................................................43
Broadband SS7 .............................................................43
Application in the MSCS..............................................43
Introduction to Broadband No.7 Signaling .....................44
SAAL .......................................................................45
SSCOP Protocol .........................................................46
SSCF Protocol ...........................................................47
SAAL-LM ..................................................................48
MTP3B Protocol .........................................................48
B-SCCP Protocol ........................................................49
SIGTRAN Protocol Suite..................................................49
Application in the MSCS..............................................49
Introduction to SIGTRAN Protocol ................................50
SCTP .......................................................................50
M3UA Protocol...........................................................55
IUA Protocol .............................................................57
M2UA/M2PA ..............................................................58
SUA Protocol.............................................................58
H.248 Protocol ..............................................................59
Introduction to H.248 Protocol.....................................59
Functions of H.248 Protocol ........................................60
H.248 Connection Model .............................................61
H.248 Descriptor .......................................................61
H.248 Command .......................................................62
H.248 Transaction .....................................................62
H.248 Message Transfer .............................................63
H.248 Packages.........................................................63
BICC Protocol................................................................64
Introduction to BICC Protocol ......................................64
BICC-Related Terms ...................................................65

II

Confidential and Proprietary Information of ZTE CORPORATION

BICC Protocol Model...................................................67


BICC-Supported Capabilities .......................................69
BICC Protocol Stack ...................................................72
Relationship between BICC and ISUP............................73
Gs Interface Protocol .....................................................74
Gs Interface Protocol Stack .........................................74
Applications of Gs Interface Protocol ............................75
SIP ..............................................................................79
Functions of SIP ........................................................79
Five Aspects of Multi-Media .........................................79
Advantages of SIP .....................................................80
Main Concept Model of SIP..........................................80
Main Response Codes of SIP .......................................84
RANAP Protocol .............................................................90
Introduction to RANAP Protocol ...................................90
Function of RANAP Management Module .......................91
Function of RANAP Service Processing Module ...............91
Network Management Service Function of the
RANAP .............................................................93
Multi-Module Management Function .............................93
BSSAP Protocol .............................................................93
Introduction to BSSAP Protocol....................................93
Function of BSSAP Management Module........................94
Function of BSSAP Service Processing Module................94
Service Report Function..............................................95
Multi-Module Management Function .............................95
MAP Protocol.................................................................96
Function of MAP Signaling...........................................96
MAP Signaling Procedure ............................................96
CAP Protocol .................................................................97
Introduction to CAP Protocol .......................................97
System Structure of CAP Protocol ................................97
CAP Operations .........................................................99

Basic Functions ............................................. 103


Introduction to Basic Functions...................................... 103
Mobility Management Function ...................................... 103
Introduction to Mobility Management Function ............. 103
Location Update ...................................................... 104
Introduction to Location Update ........................ 104
General Location Update .................................. 104

Confidential and Proprietary Information of ZTE CORPORATION

III

ZXWN MSCS Technical Description

Periodic Location Update .................................. 109


IMSI Attachment/ Detachment.......................... 109
Relocation and Handover .......................................... 110
Introduction to Relocation and Handover ............ 110
UMTSUMTS Intra-office Intra-system
Relocation ........................................... 111
UMTSUMTS Inter-office Intra-system
Relocation ........................................... 115
UMTSGSM Intra-office Inter-system
Handover ............................................ 119
UMTSGSM Inter-office Inter-system
Handover ............................................ 123
GSMUMTS Intra-office Inter-system
Handover ............................................ 128
GSMUMTS Inter-office Inter-system
Handover ............................................ 131
GSMGSM Intra-office System Handover ........... 136
GSMGSM Inter-office Intra-system
Handover ............................................ 139
Security Management Function...................................... 143
Introduction to Security Management Function ............ 143
Authentication......................................................... 143
Functions and Features of Authentication ........... 143
Generation and Composition of Authentication
Parameters ......................................... 144
Normal Authentication Procedure ...................... 145
Resynchronization Procedure ............................ 146
Encryption .............................................................. 147
Integrity Protection.................................................. 148
TMSI Allocation/Release ........................................... 149
IMEI Check ............................................................. 150
VLR Management Function............................................ 150
Introduction to VLR Management Function .................. 150
Subscriber Data Management.................................... 151
Error Recovery Processing ........................................ 152
Operation and Maintenance Function .............................. 154
Introduction to Operation and Maintenance
Function ......................................................... 154
Subscriber Tracing ................................................... 154
Equipment Tracing ................................................... 155

IV

Confidential and Proprietary Information of ZTE CORPORATION

Deleting an MS........................................................ 155


Querying IMSI according to ISDN .............................. 156

Basic Services ............................................... 157


Introduction to Basic Services ....................................... 157
Mobile Call Service....................................................... 157
Introduction to Mobile Call Service ............................. 157
Radio Channel Assignment Flow of the Basic Call of the
UE ................................................................. 159
Radio Channel Assignment Flow of the UE Terminated
Call................................................................ 161
Originated-Call Flow................................................. 164
Terminated-Call Flow................................................ 168
Call Release Flow..................................................... 177
Mobile Data Services.................................................... 179
Short Message Service ................................................. 181
Introduction to Short Message Service........................ 181
SM MO Processing Flow ............................................ 181
SM MT Processing Flow............................................. 182
Alerting Message Processing Flow .............................. 183
Supplementary Services ............................................... 185
Introduction to Supplementary Services ..................... 185
Number Identification Service ................................... 187
Forwarding Services................................................. 188
Call Completion Services .......................................... 191
MPTY Call ............................................................... 194
Call Barring ............................................................ 197
CUG....................................................................... 200
Advice of Charge ..................................................... 200
Explicit Call Transfer................................................. 200
Call Deflection......................................................... 201
Basic Operations ..................................................... 202

Special Functions .......................................... 207


Intelligent Service ....................................................... 207
Introduction to Intelligent Network ............................ 207
Mobile Intelligent Service.......................................... 213
Mobile Intelligent Service Flow .................................. 215
BCSM ............................................................ 215
BCSM Call Legend ........................................... 222
Event DPs and DP Criteria ................................ 225
Comparison of Call Processing Flows.................. 228

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

Interception Services ................................................... 241


Introduction to Interception Services.......................... 241
China 2G Interception .............................................. 242
China 3G Interception .............................................. 244
ETSI Interception .................................................... 246
Russia Interception .................................................. 247
Location Service .......................................................... 249
Introduction to the Location Service ........................... 249
Location Service Flow............................................... 250
MS-Terminated Location Request....................... 250
MS-Originated Location Request........................ 252
Network-Initiated Location Request ................... 254
Deferred MS-Terminated Location Request.......... 256
Interworking Services between the IMS and the
CS/PSTN ............................................................ 258
Introduction to Interworking Services between the IMS
and the CS/PSTN ............................................. 258
The Terminal Subscriber in the IMS Domain Calling the
Subscriber in the CS Domain/PSTN .................... 259
The Subscriber in the CS Domain/PSTN Calling the
Terminal Subscriber in the IMS Domain .............. 261
Function of Detecting and Restricting Cheaters ................ 263
Introduction to Detecting and Restricting
Cheaters ........................................................ 263
Generating Call Attempt CDRs ................................... 265
Restricting the Call Originating Service of
Cheaters ........................................................ 266
False Billing Function................................................ 266
Restricting the SMS of Cheaters................................. 267
Location Update Restriction Function .......................... 267
Periodically Enabling the Function of Restricting
Cheaters ........................................................ 267
Sorting Call Attempt CDRs ........................................ 268
Sorting SM CDRs ..................................................... 268
Configuring Cheater Detection Policy .......................... 268
Default Restriction Policy Configuration ....................... 269
Cheater Detection Function ....................................... 269
Cheater List Maintenance Function ............................. 269
Rerouting Function ...................................................... 270
Region System Function ............................................... 270

VI

Confidential and Proprietary Information of ZTE CORPORATION

Dual-homing Disaster Recovery Function ........................ 272


Traffic and Load Control Function ................................... 275
Flexible Traffic Control Function ................................. 275
Load Control Concept ............................................... 276
Service Control ............................................... 276
Congestion Control.......................................... 277
Application Description of Traffic and Load Control ......... 277
R2 Function ................................................................ 278
Roaming Pool Function ................................................. 280
Multi-EIR Function ....................................................... 281
M2PA Networking Function............................................ 281
Dynamically Selecting Routes Based on Load of IP Bearer
Network and QoS ................................................ 283
Bidirectional Forwarding Detection Function .................... 283
Compatibility Function with 2G ...................................... 284
Grading Access Based on Half Rate ............................ 285
Determining Whether to Authenticate the UE according
to the IMSI ..................................................... 287
Judging the Type of An Incoming Call according
to the FOCIN Information in the ISUP/BICC
Signaling ........................................................ 288
PSTN Subscribers Accessing EGSM ............................. 289
Not Generating SM Acknowledgment CDRs.................. 290
Adjusting Separate IP Addresses ............................... 290
Restricting the Number of USSD Dialogs through
Variable Control............................................... 291
Playing a Separate Tone for Number Incomplete .......... 292
Iu_CS over IPV6 Function ............................................. 293
NITZ Function ............................................................. 293
Link Breaking Function of Iu Interface ............................ 294
SCUDIF Call Function ................................................... 294
VMGW Function ........................................................... 295
Multi-IP-domain Function.............................................. 296
Enhanced IMEI Check Function ...................................... 298
Rf Offline Billing Function.............................................. 299
Overview................................................................ 299
Function Implementation .......................................... 300
EPLMN Expansion Function............................................ 302
Overview................................................................ 302
Function Implementation .......................................... 302

Confidential and Proprietary Information of ZTE CORPORATION

VII

ZXWN MSCS Technical Description

Figure............................................................ 305
Table ............................................................. 313
Index ............................................................ 315
Glossary ........................................................ 317

VIII

Confidential and Proprietary Information of ZTE CORPORATION

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.
The ZXWN MSCS system is designed for the UMTS system at the
core network control level. It supports the GSM core network,
UMTS protocols in the R99/R4/R5 stage and relevant functions at
the same time, and provides the carriers with an overall solution
to the evolution from the GSM core network to the 3GPP R99 and
then to the 3GPP R5.
The ZXWN MSCS system completes the functions of the Mobile
Switching Center Server and the Visitor Location Register (VLR)
together, and provides the Service Switching Point (SSP) functions
of intelligent calls. The ZXWN MSCS system supports the MGCF
function, and the coexistence of the MGCF and GMSCS. It also can
smoothly upgrade to the MGCF.
The purpose of writing this manual is to help operators fully master
the basic knowledge, interfaces and protocols, and service functions of ZXWN MSCS.

Intended
Audience

Prerequisite Skill
and Knowledge
What Is in This
Manual

This document is intended for:

Communication engineers who have mastered principles of


mobile communications.

Engineers who need to know the basic knowledge of the CS,


and the basic functions of ZXWN MSCS.

To use this document effectively, users should have a general understanding of wireless telecommunications technology.
This manual contains the following chapters:
Chapter

Summary

Chapter 1, Basic Knowledge

Describes features of CN in each version


of 3GPP, and the network structures in
R4, R5 and R6 versions

Chapter 2, Interfaces

Describes the external signaling


interfaces provided by ZXWN MSCS

Chapter 3, Signaling
Protocol

Describes the signaling protocols


supported by ZXWN MSCS

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

FCC Compliance
Statement

Chapter

Summary

Chapter 4, Basic Functions

Describes the basic functions supported


by ZXWN MSCS

Chapter 5, Basic Services

Describes the basic services supported


by ZXWN MSCS

Chapter 6, Special
Functions

Describes the special functions


supported by ZXWN MSCS and the
related descriptions

This device complies with part 15 of the FCC Rules. Operation is


subject to the following two conditions.
1. This device may not cause harmful interference.
2. This device must accept any interference received, including
interference that may cause undesired operation.
Changes or modifications not expressly approved by the party responsible for compliance could void the user's authority to operate
the equipment.

Conventions

ZTE documents employ the following 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.

CAPS

Keys on the keyboard and buttons on screens and


company name.
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 operation conventions are listed as follows:

II

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.

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 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 (PBBs)

PolyBrominated Diphenyl Ethers (PBDEs)

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

ZXWN MSCS Technical Description

This page is intentionally blank.

II

Confidential and Proprietary Information of ZTE CORPORATION

Chapter

Basic Knowledge
Table of Contents
Introduction to 3GPP Standard .............................................
Network Structure of UMTS R99 ...........................................
Network Structure of UMTS R4 .............................................
Network Structure of UMTS R5 .............................................
Network Structure of UMTS R6 .............................................
Introduction to Network Interfaces........................................

1
3
4
5
7
9

Introduction to 3GPP
Standard
The 3GPP standard has multiple releases. The following briefly
introduces the features of R99, R4, R5, and R6.
Features of R99

Features of R4

R99 is the first release of 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.

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.

R4 is the second release of UMTS, and its main features are as


follows:

The CS domain introduces the soft switch technology, supporting the of bearer independent of control. The MSC is split to the

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

MSC Server and the MGW. The R4 version makes the call control part totally independent of the transmission 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.

Features of R5

Features of R6

The CS domain supports multiple bearer modes: IP, ATM and


TDM.

Enhances the location service capability.

Supports TD-SCDMA.

R5 is the third release of UMTS, and its main features are as follows:

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 MGCF.

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 Server + MGW/SGSN) nodes.

R6 is the fourth release of UMTS, and its main features are as


follows:

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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1 Basic Knowledge

Network Structure of UMTS


R99
Network Structure
Diagram

The network structure of UMTS R99 is shown in Figure 1.


FIGURE 1 NETWORK STRUCTURE OF UMTS R99

Structure
Description

The Core Network (CN) is divided into Circuit Switched (CS) domain and Packet Switched (PS) domain. The CS domain consists
of MSC and GMSC, processing voice services. The PS domain consists of SGSN and GGSN, processing packet services.
The ATM-based Iu-CS interface is the interface between the MSC
and the RNS, which is used to transfer RNS management, call processing, and mobility management messages.
he ATM-based Iu-PS interface is the interface between the SGSN
and the RNC, which is used to transfer session management and
mobility management messages.
One RNS includes one RNC and one or more Node B.

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

Network Structure of UMTS


R4
Network Structure
Diagram

The network structure of the 3GPP R4 is shown in Figure 2.


FIGURE 2 NETWORK STRUCTURE OF UMTS R4

Note:
Heavy lines mean bearer interfaces, while dashed lines mean signaling interfaces.
Structure
Description

In the R4 phase, the UMTS system is divided into the CN and the
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 UE, 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 UE, such as Internet connection services, VPN
services and PS-based SMS. The PS domain is composed of
SGSN and GGSN.

The CN in UMTS R4 has the following functional entities:

MSCS
The MSCS provides call control, mobility management, authentication, encryption and other functions in the CS domain.

MGW
As the bearer equipment of the voice service, multi-media service and the narrowband data service, the MGW completes service flow format conversion between different networks and
bearer processing.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1 Basic Knowledge

HLR
The HLR provides subscription information storage, new service supporting, enhanced authentication and other functions.

SGSN
The SGSN completes network access control, packet routing
and transmission, mobility management, logic link management (when providing Gb interface access), radio resource
management, network management and other functions in
the PS domain.

GGSN
The GGSN completes routing, security control, network access
control and other functions in the PS domain.

Network Structure of UMTS


R5
Network Structure
Diagram

The network structure of the 3GPP R5 is shown in Figure 3.


FIGURE 3 NETWORK STRUCTURE OF UMTS R5

Note:
Heavy lines mean bearer interfaces, while dashed lines mean signaling interfaces.
Structure
Description

The IMS domain is added, which provides the IP multimedia 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

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

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.
The CN in UMTS R4 has the following functional entities:

Home Subscriber Server (HSS)


The HSS is the centralized subscriber database system, storing subscriber authentication information, service information,
and roaming information.

IM-MGW
Under the control of the MGCF, the IM-MGW completes resource control. Through the echo canceler and the transcoder,
the IM-MGW implements media conversion and frame protocol conversion, converting media from one format to another
format (in the UMTS, formats are PCM format of the PSTN and
IP-based coding/decoding format in general).

MGCF
The MGCF selects CSCF according to called numbers and incoming calls, and completes call control protocol conversion
between the PSTN and the IMS. The main purpose is to convert IP messages to ISUP or Megaco messages.

Subscription Locator Function (SLF)


The SLF is the location function entity of the subscriber subscription place. When the network is configured with multiple
HSSs, the SLF needs to be configured. The SLF is a simple
database, mapping the subscriber address to the HSS. The
subscriber address serves as the input of the SLF, while the
obtained HSS containing the subscriber configuraiton information serves as the output.

P-CSCF
The P-CSCF is the first access point from the access network
to the IMS network. After receiving SIP registration and session establishment messages from the User Agent (UA) from
the access network, the P-CSCF forwards them to the I-CSCF
in the home domain, and the I-CSCF sends them to the corresponding S-CSCF.

I-CSCF
The I-CSCF is the first connection point in the home network.
The I-CSCF is responsible for contacting the HSS to confirm
the S-CSCF location of the specific subscriber.

S-CSCF
The S-CSCF is used to control the call status of SIP subscribers.

Breakout Gateway Control Function (BGCF)

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1 Basic Knowledge

The BGCF implements call routing function, selecting the network connected with the handoff point of the PSTN/CS domain,
and selecting the proper PSTN interface point for calls after receiving requests from the S-CSCF. If the BGCF finds that this
interface point is in the same network with it, it selects a MGCF
that is responsible for interacting with the PSTN. If the BGCF
finds that this interface point is in another network, it forwards
session signaling to the corresponding BGCF in another network.

Note:
According the CSCF location in the network, it implements different functions. It divides into P-CSCF, I-CSCF, and S-CSCF.
The logic entities of P-CSCF, I-CSCF, S-CSCF, and BGCF can be
physically combined to one.

MRFC
The MRFC controls the media resources in the MRFP, analyzing
the messages from the AS or S-CSCF.

MRFP
The MRFP provides resources channels, such as mixing media
streams, initiating media stream, and processing signal.

Network Structure of UMTS


R6
Network Structure
Diagram

The network structure of the UMTS R6 is shown in Figure 4.


FIGURE 4 NETWORK STRUCTURE OF UMTS R6

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

Structure
Description

The network in UMTS R6 has the following new parts:

WLAN Access Gateway (WAG)


The WAG is located between the WLAN and the 3GPP network.
When subscribers are roaming, it is located in the 3GPP visitor
network. It provides filtering, management, and billing functions for the data steams between the WLAN and the 3GPP
network.

Packet Data Gateway (PDG)


The PDG provides access of WLAN subscribers to the packet
switching network. When subscribers are accessed to the
home network, the PDG is located in the home network. When
subscribers are accessed to the local network, the PDG is
located in the visitor network.

AAA Server
The AAA server is used for equipment access, and service authentication and authorization of WLAN subscribers.

WLAN
The WLAN interconnects computers by using wireless communication technology, constructing the network system boasting
intercommunication and resource sharing. The essential feature of the WLAN is abandoning communication cables, and
thus it is more flexible to construct and move the network.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1 Basic Knowledge

Introduction to Network
Interfaces
Interfaces in R4 CN
Interface
Schematic
Diagram

Interfaces between NEs in the 3GPP R4 CN are shown in Figure 5.


FIGURE 5 INTERFACES IN UMTS R4 CN

Heavy black lines mean bearer interfaces, while dashed lines mean
signaling interfaces.

In Figure 5, 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). One (G) MSC Server and its associated CS-MGW
can be integrated into one node: the (G)MSC.

Confidential and Proprietary Information of ZTE CORPORATION

ZXWN MSCS Technical Description

Interface
Description

The interfaces in UMTS R4 CN are described as shown in Table 1.


TABLE 1 INTERFACES IN UMTS R4 CN
Interfaces

Connected Entities

Signaling and Protocols

MSCSBSC

BSSAP

Iu-CS

MSCSRNC

RANAP

MSCSVLR

Internal protocol

(G)MSCSHLR

MAP

VLRHLR

MAP

MSCSMSC/SMC

MAP

MSCSEIR

MAP

VLRVLR

MAP

Gs

MSCSSGSN

BSSAP+

HLRAUC

Internal protocol

MSCSPSTN/ISDN/

TUP/ISUP

PSPDN

10

Ga

SGSN/GGSNCG

GTP'

Gb

SGSNBSC

BSSGP

Gc

GGSNHLR

MAP

Gd

SGSNSMGMSC/IWMSC

MAP

Ge

SGSNSCP

CAP

Gf

SGSNEIR

MAP

Gi

GGSNPDN

TCP/IP

Gp

GGSNGGSN (Inter
PLMN)

GTP

Gn

GGSNGGSN (Intra
PLMN)

GTP

Gr

SGSNHLR

MAP

Iu-PS

SGSNRNC

RANAP

Mc

(G)MSCSMGW

H.248

Nc

MSCSGMSCS

ISUP/TUP/BICC

Nb

MGWMGW

ALCAP

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1 Basic Knowledge

Interfaces in R5 IMS-domain Network


Interface
Schematic
Diagram

Interface
Description

The interfaces in R5 IMS-domain network are shown in Figure 6.


FIGURE 6 INTERFACES IN R5 IMS-DOMAIN NETWORK

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


follows:

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:

Mb interface between the UE and the IM-MGW: used for the


IMS UE to implement media interworking with the oppositeend entities through the IM-MGW.
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.
Mb interface between the MRFP and the UE: used when the
MRFP is required to perform the media plane processing.

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.

Ai interface: interface between the MGCF/IM-MGW and the


PSTN, adopting the ISUP/TUP protocol.

Nb interface: interface between the IM-MGW and the MGW,


adopting the CodeC/NbUP/RTP/IP protocol.

Nc interface: interface between the MGCF and the MSCS,


adopting the BICC/ISUP protocol.

Confidential and Proprietary Information of ZTE CORPORATION

11

ZXWN MSCS Technical Description

12

Mp interface:
interface between the MRFC and the
MRFP, adopting the H248/M3UA/SCTP/IP protocol or the
H248/SCTP/IP protocol.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter

Interface
Table of Contents
Introduction to Interfaces ...................................................13
Iu-CS Interface .................................................................15
A Interface .......................................................................16
Mc Interface .....................................................................17
Nc Interface......................................................................18
Mn Interface .....................................................................18
MAP Interface ...................................................................19
CAP Interface....................................................................20
Gs Interface .....................................................................20
Mj/Mg Interface.................................................................21
Billing Interface.................................................................21
O&M Interface...................................................................22
CORBA Interface ...............................................................23
SNMP Interface .................................................................24
Interception Interface ........................................................26

Introduction to Interfaces
Function
Description

The ZXWN MSCS system is embedded with the VLR and SG 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.

Confidential and Proprietary Information of ZTE CORPORATION

13

ZXWN MSCS Technical Description

Interface
Schematic
Diagram

The main interfaces of the ZXWN MSCS system in the mobile communication network are shown in Figure 7.
FIGURE 7 MAIN INTERFACES OF THE ZXWN MSCS SYSTEM

Interface
Description

As shown in Figure 7, the ZXWN MSCS implements the functions


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.

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.

Mc interface: Interface between the MSCS and the MGW


This interface applies for, releases and changes MGW bearer
resources.

Mn interface: Interface between the MGCF and the IM-MGW


This interface controls the bearer resources of the IM-MGW.

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.

MAP Interface: Interface between the MSCS/VLR and the HLR


Based on the narrowband No.7 signaling interface, this interface implements location update, subscriber data insertion,
supplementary service processing and MT call routing.

CAP and MAP I interfaces:


MSCS/VLR/SSP and the SCP

Interfaces

between

the

Based on the narrowband No.7 signaling interface, this interface implements intelligent service access and control, supplementary service invoking notification, and mobility management notification.

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.

14

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 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.

Mj/Mg interface:
BGCF/CSCF

Interface between the MGCF and the

This interface negotiates call parameters of the call between


the IMS and the CS, and controls bearer resources.

Billing interface (not shown in Figure 7)


This interface sends the CDRs of the MSCS to the billing center.

O&M interface (not shown in Figure 7)


Based on TCP/IP, this interface implements centralized maintenance, monitoring and network management for the MSCS.

CORBA interface (not shown in Figure 7)


This interface implements the interworking between the NMC
(network management center of the operator) and the OMC
provided by equipment manufactures.

SNMP interface (not shown in Figure 7)


This interface implements the interworking between the NMC
(network management center of the operator) and the OMC
provided by equipment manufactures.

Interception interface (not shown in Figure 7)


This interface traces and monitors all the traffic and non-traffic
actions of the controlled number in real time. ZXWN supports
multiple interface specifications, including 3G interception interface, 2G interception interface, ETSI interception interface,
and Russia interception 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
planeprocessing, 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 8.

Confidential and Proprietary Information of ZTE CORPORATION

15

ZXWN MSCS Technical Description

FIGURE 8 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 8, 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.

A Interface
Application

Protocol Stack

16

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, processing of call service and SMS service. This interface
is physically based on E1 or IP.
Figure 9 shows the protocol stack of the A interface.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 Interface

FIGURE 9 PROTOCOL STACK OF THE A INTERFACE CONTROL PLANE

As shown in Figure 9, the protocol stack of the A interface can


adopt two modes:

Narrowband SS7 signaling transmission mode, with the protocol stack as BSSAP/SCCP//MTP2.

SIGTRAN mode, with the protocol stack as BSSAP/SCCP/M3UA/SCTP/IP.

Mc Interface
Application
Protocol Stack

The interface between the MSC Server and the MGW is Mc interface. This interface can be based on ATM or IP.
Figure 10 shows the protocol stack of the Mc interface:
FIGURE 10 MC INTERFACE PROTOCOL STACK

Confidential and Proprietary Information of ZTE CORPORATION

17

ZXWN MSCS Technical Description

Note:
1. For pure IP links, H.248/SCTP/IP
H.248/M3UA/SCTP/IP is optional.

is

preferred,

and

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 10, 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
H.248/MTP3B/SSCF/SSCOP/AAL5.

mode

can

adopt

Nc Interface
Application
Protocol Stack

The interface between MSC Servers is Nc Interface. This interface


can be based on ATM, IP or E1.
Figure 11 shows the protocol stack of the Nc interface.
FIGURE 11 PROTOCOL STACK OF THE NC INTERFACE

As shown in Figure 11, 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
BICC/M3UA/SCTP/IP

ATM signaling transmission mode, based on BICC/MTP3B/SSCF-NNI/SSCOP/AAL5

transmission

mode,

based

on

Mn Interface
Application
Protocol Stack

18

The Mn interface between the MGCF and the IM-MGW is based on


IP transmission.
Figure 12 shows the protocol stack of the Mn interface.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 Interface

FIGURE 12 PROTOCOL STACK OF THE MN INTERFACE

Note:
For pure IP links,
H.248/SCTP/IP
H.248/M3UA/SCTP/IP is optional.

is

preferred,

and

As shown in Figure 12, 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 13 shows the protocol stack of the MAP interface.


FIGURE 13 PROTOCOL STACK OF THE MAP INTERFACE

As shown in Figure 13, the signaling protocol stack of the MAP


interface falls into two modes:

Confidential and Proprietary Information of ZTE CORPORATION

19

ZXWN MSCS Technical Description

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

Protocol Stack

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).

Figure 14 shows the protocol stack of the CAP interface.


FIGURE 14 PROTOCOL STACK OF THE CAP INTERFACE

As shown in Figure 14, the signaling protocol stack of the CAP


interface also falls into two modes:

Narrowband SS7 signaling transmission mode, which adopts


CAP/TCAP/SCCP/MTP3/MTP2

SIGTRAN signaling transmission mode, which is based on


CAP/TCAP/SCCP/M3UA/SCTP/IP.

Gs Interface
Application

Protocol Stack

20

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.
Figure 15 shows the protocol stack of the Gs interface.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 Interface

FIGURE 15 PROTOCOL STACK OF THE GS INTERFACE

As shown in Figure 15, the signaling protocol stack of the Gs interface falls into two modes:

Narrowband SS7 signaling transmission mode, which adopts


BSSAP+/SCCP/MTP3/MTP2

SIGTRAN signaling transmission mode, which is based on


BSSAP+/SCCP/M3UA/SCTP/IP.

Mj/Mg Interface
Application

Protocol Stack

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.
Figure 16 shows the protocol stack of the Mj/Mg interface.
FIGURE 16 PROTOCOL STACK OF THE MJ/MG INTERFACE

As shown in Figure 16, 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 17.

Confidential and Proprietary Information of ZTE CORPORATION

21

ZXWN MSCS Technical Description

FIGURE 17 BILLING INTERFACE

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

Protocol
Architecture

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.

Figure 18 shows the protocol architecture of the O&M interface.


FIGURE 18 O&M INTERFACE PROTOCOL ARCHITECTURE

Features

22

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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 Interface

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

CORBA is a communication interface supported by the CORBA


technology. It is located in the communication network management system. As the interface between the NMC of the
operator and the OMC provided by the equipment manufactures,
it implements the multi-layer management for the communication
network.

Network Structure

The position of the CORBA interface in the network management


network. The CORBA interface is the IF2 interface in Figure 19.
FIGURE 19 POSITION OF THE CORBA INTERFACE IN THE NETWORK
MANAGEMENT NETWORK

Specifications
Features

At present, the CORBA interface supports CMCC TD v1.0.0, CMCC


v3.0.0, UNICOM (TDM), UNICOM (IP), and UNICOM (WCDMA).
The CORBA interface has the following features.

The CORBA interface boasts expansible frame and powerful


service supporting capability. It is easy to adjust the information model and management flow, which facilitates the management of large-scale and complex equipment.

The CORBA interface boasts widely supporting capability, such


as Sun, IBM and ORACLE.

The CORBA interface eliminates fine-grained complexity of Q3.

The 3GPP protocol defines the CORBA specification.

Confidential and Proprietary Information of ZTE CORPORATION

23

ZXWN MSCS Technical Description

Connection
Between CORBA
Interface and
Upper-level
Network
Management

The connection between the CORBA interface and the upper-level


network management usually adopts the naming service mode and
the IOR file mode. If the naming service mode is adopted, it is required to provide the upper-layer network management with the
IP address used for the interconnection between the upper-layer
network management and the ZTE 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.

SNMP Interface
Definition

The SNMP interface is the interface between the NMC (network


management center of the operator) and the OMC provided by the
equipment manufactures.

Application

The SNMP interface is the IF2 interface in Figure 20. The upper-level network management system 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

Features

24

The SNMP interface has the following features.

The SNMP provides get, set, and trap commands, and the corresponding message flow, but it does not define other equipment management proxy commands. The most important operations of the SNMP are configuration and query operations,
but it cannot implement complex instruction operation function.

The SNMP involves the three lower layers of the OSI model,
while network management activities are related with all the
seven layers. Thus the supporting capability of the SNMP on
the upper layers is restricted.

The SNMP suffers from poor security, so it may be invaded by


network invaders. The network management system is usu-

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 Interface

ally installed in a relatively large-scale network environment,


including various networks and network equipment. To divide
management responsibility, divide the whole network into several user areas. The SNMP does not provide encryption function based on the authentication model of areas, and does not
guarantee that the area information avoids being copied from
the network during the course of SNMP data packet switching.

The SNMP is an open and free product, so it is hard to perform


unified management

The SNMP is a connectionless protocol, so it does not support


such special connection as TELNET or FTP.

The advantages of the SNMP are simple, and easy to be implemented, so it is applied to the network equipment with simple
function, such as routers and Ethernet switches.
The disadvantages of the SNMP are having less instruction sets,
not supporting complex instruction operations, and suffering from
poor security.
Functions

1. Getting the version No. of ALARM IRP


This function enables the upper-layer network management
system to query the version No. of the ALARM IRP object.
2. Getting the version No. of CS IRP
This function enables the upper-layer network management
system to query the version No. of the CS IRP object.
3. Getting the current heartbeat value
This function enables the upper-layer network management
system to monitor and manage the links to the lower-layer
network management to get the current heartbeat value.
4. Setting a new heartbeat value
This function enables the upper-layer network management
to monitor and manage the links to the upper-link 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 reported 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.
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.

Confidential and Proprietary Information of ZTE CORPORATION

25

ZXWN MSCS Technical Description

Interception Interface
Concept of the
Lawful Service

Interception services refers to performing real-time tracing and 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
Interception
Interface

The interception interface is between the MSCS NE and the Lawful


Information Center (LIC).
ZXWN supports the following interception specifications:

China 2G Interception

China 3G Interception

ETSI Interception

Russia Interception

3G Interception Interface
The connection relationship between the LIC and the NEs in the
mobile communication system is shown in Figure 21.

26

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 Interface

FIGURE 21 STRUCTURE OF THE INTERCEPTION INTERFACE

As shown in Figure 21, the interception 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 Interception Interface
The China 2G interception interface has three types, as shown in
Table 2.
TABLE 2 FUNCTIONS OF CHINA 2G INTERCEPTION INTERFACES
Interface
Name

Interface Functions

Interface Protocols

IF1

Used to input operation


commands related with
the lawful software, and
output the corresponding
responses

X.25 or TCP/IP protocol,


and its working protocol
stack is X.25 ISO/IEC,
ISO/IEC 8208; TCP/IP
ISO/IEC 802.2, ISO/IEC
802.3

IF2

Used to output activity


reports of the controlled
MS, short messages and
alarm information of lawful
software

X.25 or TCP/IP protocol,


and its working protocol
stack is X.25 ISO/IEC,
ISO/IEC 8208; TCP/IP
ISO/IEC 802.2, ISO/IEC
802.3

Confidential and Proprietary Information of ZTE CORPORATION

27

ZXWN MSCS Technical Description

Interface
Name

Interface Functions

Interface Protocols

IF3

Used to output contents


of the calls, data
communication and
their mapping IDs. The
mapping ID is used to
associate the activity
reports of the controlled
MS output by the IF2
interface in the same call

2048kbit/s digital
interface. The interface
parameters should comply
with the specifications
of GB7611-87, and the
signal mode of the digital
interface should have the
TUP mode or the ISUP
mode of the NO.7 signal
at least

ETSI Interception Interface


The ETSI interception interface has three types, as shown in Table
3.
TABLE 3 FUNCTIONS OF ETSI INTERCEPTION INTERFACES
Interface
Name

Interface Functions

Interface
Protocols

H1

Operation and management interface

TCP/IP protocol

H2

Intercept Related Information (IRI)


report interface, outputting activity
reports of the controlled MS, and
short messages

TCP/IP protocol

H3

Content of Communication (CC)


report interface, outputting contents
of the calls, data communication and
their mapping IDs. The mapping ID is
used to associate the activity reports
of the controlled MS output by the H2
interface in the same call

TCP/IP protocol

Russia Interception Interface


The Russia interception interface has three types, as shown in
Table 4.

28

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 2 Interface

TABLE 4 FUNCTIONS OF RUSSIA INTERCEPTION INTERFACES


Interface
Name

Interface Functions

Interface
Protocols

X1

Used to control and manage


subscriber numbers. The messages
transmitted through the X1 interface
divide into two types: Command
from the LIC to the CN, and Message
from the CN to the LIC feeding back
the execution result of Command

X.25 protocol

X2

Used to output activity reports of


the controlled MS from the mobile
network to the LIC. The messages
transmitted through the X2 interface
can only be transmitted in one way,
reporting various activities of the
controlled MS

X.25 protocol

X3

Used to output contents of the calls,


and data from the mobile network to
the LIC

E1 connection,
and no interoffice signaling is
required

Confidential and Proprietary Information of ZTE CORPORATION

29

ZXWN MSCS Technical Description

This page is intentionally blank.

30

Confidential and Proprietary Information of ZTE CORPORATION

Chapter

Signaling Protocol
Table of Contents
Narrowband SS7 ...............................................................31
Broadband SS7 .................................................................43
SIGTRAN Protocol Suite......................................................49
H.248 Protocol ..................................................................59
BICC Protocol....................................................................64
Gs Interface Protocol .........................................................74
SIP ..................................................................................79
RANAP Protocol .................................................................90
BSSAP Protocol .................................................................93
MAP Protocol.....................................................................96
CAP Protocol .....................................................................97

Narrowband SS7
Application in the MSCS
In the MSCS, the narrowband SS7 is mainly responsible for the
interworking with the traditional No.7 signaling network.
The MSCS usually adopts SS7 to interwork with the following NEs:

HLR
The MSCS is directly connected with the HLR through the narrowband SS7 for interworking. The MAP protocol is applied to
the upper layer, while the TCAP, SCCP, and MTP protocols are
applied to the bottom layer.

SMC
The MSCS is directly connected with the SMC through the narrowband SS7 for interworking. The MAP protocol is applied to
the upper layer, while the TCAP, SCCP, and MTP protocols are
applied to the bottom layer.

SCP
The MSCS is directly connected with the SCP through the narrowband SS7 for interworking. The CAP protocol is applied to
the upper layer, while the TCAP, SCCP, and MTP protocols are
applied to the bottom layer.

2G MSC

Confidential and Proprietary Information of ZTE CORPORATION

31

ZXWN MSCS Technical Description

There are two modes for the MSCS to interwork with the
2G MSC, the direct-connection mode and the MGW-switched
mode. The MSCS usually adopts the narrowband SS7 to
directly connect with the 2G MSC. The TUP protocol and ISUP
protocol are applied to the upper layer, while the MTP protocol
is applied to the bottom layer.

Other NEs using the narrowband SS7


The MSCS can communicate with other NEs that use the
narrowband SS7, such as the PSTN, and the private network
switch. The MTP protocol is applied to the bottom layer, while
the TUP protocol or the ISUP protocol is applied to the upper
layer.

Introduction to Narrowband No.7


Signaling
Protocol Stack

Figure 22 shows the narrowband No.7 protocol stack of ZXWN


MSCS.
FIGURE 22 NARROWBAND NO.7 SIGNALING PROTOCOL STACK

Protocol
Composition

The narrowband No.7 protocol stack includes the following protocols:

MTP1 protocol

MTP2 protocol

MTP3protocol

SCCP protocol

TCAP protocol

TUP protocol

ISUP protocol

MTP1 Protocol
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.

32

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

MTP2 Protocol
Application

Message Transfer Part Level 2 (MTP2) implements the signalinglink-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-linklevel 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 oneto-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 64 k signaling links and 2M high-speed signaling links.

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 23.


FIGURE 23 MSU OF NARROWBAND NO.7 SIGNALING

The format of the LSSU is shown in Figure 24.


FIGURE 24 LSSU OF NARROWBAND NO.7 SIGNALING

The format of the FISU is shown in Figure 25.


FIGURE 25 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)

Confidential and Proprietary Information of ZTE CORPORATION

33

ZXWN MSCS Technical Description

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 26.
FIGURE 26 FORMAT OF SF

The codes of CBA are as follows:

000 indicates Status Indicator-Out of alignment (SIO).

001 indicates Status Indicator-Normal (SIN).

010 indicates Status Indicator-Emergency (SIE).

011 indicates Status Indicator- Out of Service (SIOS).

100 indicates
(SIPO).

101 indicates Status Indicator-Busy (SIB).

Status

Indicator-Processor

Outage

vii. Fields FSN/FIB and BSN/BIB: signal unit sequence number


and indicator bit

34

Forward Sequence Number (FSN) is the sending sequence number of this message, which is encoded
based on modulo 128.

Forward Indicator Bit (FIB) is inverted to indicate retransmission of a message at the local end.

Backward Sequence Number (BSN) indicates the last


in-sequence signal unit received correctly by the peer
end.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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 23~Figure 26 indicate the sending
sequence of messages.
Functions

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
Structure Diagram

The Message Transfer Part Level 3 (MTP3) system structure is


shown in Figure 27.

Confidential and Proprietary Information of ZTE CORPORATION

35

ZXWN MSCS Technical Description

FIGURE 27 MTP3 ARCHITECTURE

Composition

MTP3 is split into two main modules: Signaling Message Handling


(SMH) and Signaling Network Management (SNM).
1. 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 27.

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.

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.

36

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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.

2. 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 27.

Signaling Service Management


This part completes switchover, switchback, forced rerouting, controlled rerouting, signaling point restart, flow control, management blocking and unblocking.

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.

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
Application

The SCCP protocol 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.

Service Class

The SCCP can provide users with connectionless and connectionoriented services, including the following four classes:

Structure Diagram

Class 0: Basic connectionless service

Class 1: Sequenced connectionless service

Class 2: Basic connection-oriented service

Class 3: Flow control connection-oriented service

The structure of the SCCP protocol is shown in Figure 28.

Confidential and Proprietary Information of ZTE CORPORATION

37

ZXWN MSCS Technical Description

FIGURE 28 STRUCTURE OF THE SCCP PROTOCOL

Functional Module

The SCCP consists of four functional modules as follows:


1. 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.
2. 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.

38

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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 ManaGement (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.
3. 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.

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 upperlayer 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.

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

Confidential and Proprietary Information of ZTE CORPORATION

39

ZXWN MSCS Technical Description

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).

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.

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.

4. 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:

Signaling point status management


Signaling point status management updates the SCCP address translation table and the node status, and modifies

40

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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.

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
Application

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.

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 29.

Confidential and Proprietary Information of ZTE CORPORATION

41

ZXWN MSCS Technical Description

FIGURE 29 LAYERED STRUCTURE OF THE TCAP

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-toone 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.

42

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

TUP Protocol
TUP Protocol

TUP implements the following functions:

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
ISUP Protocol

ISUP implements the following functions:

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 SS7
Application in the MSCS
In the MSCS, the broadband No.7 signaling system is mainly used
for Iu-CS and Nc interfaces that are newly added in the R4 network. In general, the MSCS is connected with the RNC through the
signaling gateway built in the MGW, and the MSCS does not directly
use the broadband No.7 signaling system. In the broadband No.7
signaling system, the bottom layer adopts ATM for transferring sig-

Confidential and Proprietary Information of ZTE CORPORATION

43

ZXWN MSCS Technical Description

naling. After the signaling is adapted through the ATM adaptation


layer, the MTP3B message is transferred. The interfaces using the
broadband No.7 signaling are as follows:

Iu-CS interface: interface between the MSCS and the RNC.


When the MSCS is directly connected with the RNC, the broadband No.7 signaling system will be used. In general, the MSCS
is not directly connected with the RNC, while they are connected through the MGW that implements the signaling gateway function. In this case, the broadband No.7 signaling system is used between the MGW and the RNC, while the signaling of the Iu-CS interface between the MSCS and the MGW is
switched to the MSCS through the Sigtran signaling. Thus the
MSCS does not use the broadband No.7 signaling system

Nc interface: interface between MSCSs. When the backbone


transmission network adopts the ATM network, the Nc interface
will use the broadband No.7 signaling system. At present, the
transmission network usually adopts the IP network for transmission, so the broadband No.7 signaling system is seldom
used on the Nc interface.

Introduction to Broadband No.7


Signaling
Comparison with
Narrowband No.7
Protocol

The main difference between broadband NO.7 protocols and narrowband NO.7 protocols is changes in MTP layers. The MTP-1 and
MTP-2 are changed to the Signaling ATM Adaptation Layer (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

SSCOP

SSCF

MTP3b

Broadband-Signaling Connection Control Part (B-SCCP)

Its protocol stack is shown in Figure 30.

44

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

FIGURE 30 PROTOCOL STACK OF THE BROADBAND SIGNALING SYSTEM

Protocol
Composition

The broadband No.7 protocol stack includes the following protocols:

SSCOP

SSCF protocol

SAAL-LM

MTP3B protocol

BSCCP protocol

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 AAL5, and is mainly composed of Convergence


Sub-layer (CS) and SAR sub-layer. The CS consists of SSCS and
CPCS. The SSCS consists of SSCF, SSCOP and Layer Management
(LM).
The SAAL structure is shown in Figure 31.

Confidential and Proprietary Information of ZTE CORPORATION

45

ZXWN MSCS Technical Description

FIGURE 31 SAAL STRUCTURE

SSCOP Protocol
Application

Structure

The SSCOP uses the non-verified data transmission service


provided by the ATM-CPCS and SAR, and provides Users (that
is, SSCF) with reliable variable-length Service Data Units (SDUs)
transmission services.
Figure 32 shows the functional structure of the SSCOP entities.
FIGURE 32 FUNCTIONAL STRUCTURE OF SSCOP ENTITIES

Functions

The SSCOP layer implements the following functions.


1. SD PDU sequence control: Guarantee the continuity and integrity of the SD PDU sequence. The SSCOP is a connection-oriented protocol, supporting the reliable point-to-point
transmission connection.
2. Error correction and retransmission: Uses the SD PDU sequence number to judge whether the information is lost, and
then retransmits the lost data.

46

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

3. Flow control: Through the sliding window mechanism, the receiver can control the data transmission rate of the sender, and
report errors to the layer management part.
4. Link hold: If no data is transmitted between two SSCOP users
in a longer period of time, the SSCOP can periodically send
POLL PDU to confirm whether the link is still in connection status. The maximum interval between two POLL-PDUs is determined through the Keep-Alive Timer.
5. Local data retrieval: The user SSCF of the SSCOP can use this
function to retrieve the data in a sending queue or in the sending buffer. The SSCOP entity should be able to store the unacknowledged data to be transmitted and retrieve data to be
retransmitted.
6. Connection control: It is used for connection setup and release,
and performs re-synchronization upon connection fault. It is
used to set up and remove the connection between SSCOPs.
If any error is detected in the connection process, the receiving and sending parties can negotiate about the transmission
parameters and buffer size (that is, the re-synchronization is
performed).
7. User information transfer: Allows the SSCOP subscriber data to
be transmitted through SSCOP. Three selections are available:

Acknowledged data transmission

Unacknowledged data transmission

Management data transmission

8. The SSCOP layer detects and recovers errors in the implementation of the SSCOP. It reports any error in the transmission
process to the LM entity.
9. The SSCOP layer exchanges status information between the
receiver and sender.

SSCF Protocol
SSCF-NNI
Functions

SSCF-NNI assists SSCOP in completing the link-level functions,


and has the following functions.
1. Link establishment: Includes the location process and certification process (optional).
2. Data transmission: Provides the signaling transmission channel for MTP3B.
3. Link release: Releases the connection so that the link cannot
provide reliable data transfer for MTP3B any more.
4. SDU access: After the link is disabled, MTP3B performs the link
switchover and gets back those messages that have been sent
but not received by the opposite end.
5. Unacknowledged transmission: The message can be transmitted in any status, but no confirmation is made for the transmission.

Confidential and Proprietary Information of ZTE CORPORATION

47

ZXWN MSCS Technical Description

6. Signaling link error monitoring: Cooperates with the LM to implement the link monitoring, which is distributed among different processing procedures.
SSCF-UNI
Functions

SSCF-UNI implements the services requested by layer 3 signaling users, negotiates between services provided by SSCOP, and
provides the primitive mapping between upper/lower layer protocol modules (including upper/lower layer data forwarding, SSCOP
signaling link establishment and release), so that specific layer 3
service users are independent of the SSCOP module. Its main
functions include:
1. Supporting for point-to-point and point-to-multi-point unacknowledged data transmission.
2. Supporting point-to-point reliable data transfer, including connection establishment and release.

SAAL-LM
Application

Functions

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 pointto-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 Protocol
In addition to narrowband MTP3 function, MTP3B modifies the following contents:

48

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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 Protocol
Besides having the functions of the narrowband SCCP, the 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


Application in the MSCS
In the MSCS, the SIGTRAN protocol stack is responsible for transporting the signaling messages over the IP bearer on the bottom
layer.
There are the following interfaces using the SIGTRAN protocol
stack to communicate with the MSCS.

Mc interface
The H.248 protocol serves as the upper-layer protocol between
the MSCS and the MGW, while the lower-layer protocol is the
SIGTRAN protocol stack, which can be the M3UA/SCTP/IP protocol, or the SCTP/IP protocol.

Nc Interface
When the IP bearer is adopted between MSCSs, the BICC
servers as the upper-layer protocol, while the M3UA/SCTP/IP
servers as the lower-layer bearer. When the IP channel is
the voice channel between MGWs, the Nc interface adopts
the BICC protocol, while the lower layer adopts the SIGTRAN
protocol stack.

Confidential and Proprietary Information of ZTE CORPORATION

49

ZXWN MSCS Technical Description

Other interfaces
When other adjacent offices support the SIGTRAN protocol
stack, the signaling interworking with other NEs on the lower
layer can be implemented by using the SIGTRAN protocol
stack, such as the PSTN, HLR, and SMC.

Introduction to SIGTRAN Protocol


Application

The 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.

Protocol Stack

The structure of the SIGTRAN protocol stack is shown in Figure 33.


FIGURE 33 SIGTRAN PROTOCOL STACK

As shown in Figure 33, the SIGTRAN protocol stack is composed


of the following three parts:

Signaling adaptation sub-layer, including:

M3UA

M2UA/M2PA

SUA

IUA

SCTP

Standard IP transport protocol

SCTP
Application

50

The 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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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.
Transfer Mode

The SCTP provides reliable message transferring services between


two SCTP users through the association established between two
SCTP endpoints. Moreover, the SCTP 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 34.
FIGURE 34 STRUCTURE OF THE SCTP

Features

Related Terms

SCTP functions to:

Transmit user message packets

Ensure that user messages are transferred orderly or disorderly


in the stream.

Establish multiple streams in one association, without mutual


interference in the data transmission between streams.

Support the multi-homing function at one or two ends of the


association to improve the reliability of the association.

Require COOKIE authentication during the association establishment, ensuring the security of the association.

Provide the real-time path fault test function.

The related terms of the SCTP are introduced as follows:


1. 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

Confidential and Proprietary Information of ZTE CORPORATION

51

ZXWN MSCS Technical Description

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.
2. 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.
3. Association and stream

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.
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.


4. TSN and SSN

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.
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.
5. Other

52

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.
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

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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.
Functional
Structure

Functional modules of the SCTP to implement service transmission


are shown in Figure 35.
FIGURE 35 FUNCTIONAL MODULES OF SCTP

Functions of functional modules

Association set up and release


Association setup is started upon SCTP users 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 users
request. Meanwhile, an abnormal abort program is provided
as well which can be started based on users request or actively
performed by the SCTP.

Orderly Delivery of Messages


Streams in the SCTP are used to indicate users 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.

Confidential and Proprietary Information of ZTE CORPORATION

53

ZXWN MSCS Technical Description

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 users 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 in-

54

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

dicates 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 Differences
between SCTP and
TCP

The SCTP is similar to the TCP protocol in the Internet, but it has
considerable improvement in functions compared with the TCP. The
main differences between the SCTP and the 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 Protocol
Function

Related Terms

The 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 realtime basis.

AS
An 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

Confidential and Proprietary Information of ZTE CORPORATION

55

ZXWN MSCS Technical Description

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 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 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.

Functional
Structure

The functions of the M3UA protocol are shown in Figure 36.


FIGURE 36 FUNCTIONAL STRUCTURE OF M3UA

Functions of
Sub-functional
Modules

56

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

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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 Protocol
Application

Functions

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.

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.

Confidential and Proprietary Information of ZTE CORPORATION

57

ZXWN MSCS Technical Description

M2UA/M2PA
Application

Functions

Comparison
between M2UA
and M2PA

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.

Supports the boundary interface between MTP3 and MTP2


primitive function;

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.

1. Same points between M2PA and M2UA

They are both signaling adaptation protocols in the Sigtran


protocol suite, using the services provided by the SCTP.
Supporting primitive interfaces between MTP2 and MTP3,
they both can transfer MTP3 messages.
They both can be used by the MGC for interworking with
the narrowband No.7 signaling network through the SG.

2. Differences between M2PA and M2UA are as follows:

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).
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.
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.
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 Protocol
Application

58

SUA defines how to transfer SCCP user messages between two signaling points through IP. SUA implements interworking between

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

No.7 signaling and IP through the SG, and implements interworking between IPSPs in the IP network as well.
Functions

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.

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.

H.248 Protocol
Introduction to H.248 Protocol
This section introduces the following contents about the H.248 protocol:

Background

Functions of H.248 protocol

H.248 connection model

H.248 descriptor

H.248 command

H.248 transaction

H.248 message transfer

H.248 is ITU-T specified MGCP. It has been specified in conjunction with IETF. ITU-T calls it H.248, while IETF calls it MGCP titled
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 37, 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.

Confidential and Proprietary Information of ZTE CORPORATION

59

ZXWN MSCS Technical Description

FIGURE 37 SEPARATED GATEWAY MODEL

In the UMTS system, the H.248 protocol is used on the Mc interface.

Functions of H.248 Protocol


Application

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 38.
FIGURE 38 APPLICATION OF THE H.248 PROTOCOL

Functions

60

The H.248 protocol 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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

H.248 Connection Model


Connection Model

As shown in Figure 39, the H.248 connection model describes the


logical entities and objects in the MG, which can be controlled by
the MGC.
FIGURE 39 H.248/MEGACO PROTOCOL CONNECTION MODEL

Description of
Connection Model

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, the context (implicit) will be deleted.

H.248 Descriptor
Description
Category

H.248 uses descriptors to describe features of terminations. Each


type of termination has its own features.
The features divides into four types:

Property: Falls into termination status feature and media


stream feature. Former indicates service status of a termina-

Confidential and Proprietary Information of ZTE CORPORATION

61

ZXWN MSCS Technical Description

tion (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.

H.248 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.

H.248 Transaction

62

Description

To transmit multiple commands concurrently and improve transmission efficiency of protocol, H.248 adopts transaction communication mode to transmit commands.

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

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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.
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

H.248 Message Transfer


Description

Multiple transactions can be combined into a message. H.248 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.

R4 Bottom-layer
Transmission
Mode

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 Packages
Description

The service types supported by H.248 are embodied in the H.248


packages. The MSC Server and the MGW can provide the services
(may be specific services) that match their own requirements. In
this case, for the interoperability between the MSC Server and the
MGW, the parameters describing specific services (such as Events,
Signals, Properties, Methods, and Statistics) are defined to a package. If the MSC Server and the MGW identify the same package,
they can support the same service. The operators can make use
of it to define the packages with their own features, and provide
subscribers with more features and personalized services.

Confidential and Proprietary Information of ZTE CORPORATION

63

ZXWN MSCS Technical Description

Package Type

For example, the MSC Server and the MGW in R4 support the following packages for the implementation of 3G services.
1. Generic package ID: g.
2. Tone generation package ID: tonegen.
3. Basic DTMF generation package ID: dg.
4. DTMF detection package ID: dd.
5. Call progress tone generation package ID: cg.
6. BCP bearer feature package ID: BCP.
7. BNCT bearer network connection package ID: BNCT.
8. GB generic bearer connection package ID: GB.
9. Bearer control tunnel package ID: BT.
10. Basic call progress tone generation package ID with direction
indication: BCG.

BICC Protocol
Introduction to BICC Protocol
This section introduces the following contents about the H.248 protocol:

BICC-related terms

BICC protocol model

BICCsupported capabilities

BICC protocol stack

Relationship between BICC and ISUP

Description

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-toend 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.

Development

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:

64

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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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).

BICC-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

Confidential and Proprietary Information of ZTE CORPORATION

65

ZXWN MSCS Technical Description

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
control of the bearer switching function, the communication
capability with its associated call service function (CSF),
and the signaling capability necessary to establish and release of the backbone network connection to its peer (BCFN).
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
control of the bearer switching function, the communication
capability with its associated call service 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 relay-

66

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

ing signaling between CSF-N peers and invoking the Bearer


Control Transit Functions (BCF-T) necessary to transport
the narrowband bearer service 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) necessary to
transport the narrowband bearer service 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 Model


Protocol Model

The BICC protocol model is shown in Figure 40.

Confidential and Proprietary Information of ZTE CORPORATION

67

ZXWN MSCS Technical Description

FIGURE 40 BICC PROTOCOL MODEL

Model Description

In the BICC protocol model shown in Figure 40, interaction 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 upperlayer 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.

68

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

BICC-Supported Capabilities
Call Capabilities

Table 5 lists the 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

Multirate connection types are


264, 384, 1,536 and 1,920
kbit/s

N64 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

Confidential and Proprietary Information of ZTE CORPORATION

69

ZXWN MSCS Technical Description

70

Function/Service

Remark

Receipt of unreasonable signaling


information

Compatibility procedure (BICC


and BAT APM user application)

ISDN User Part signaling


congestion control

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

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

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

Generic Signaling
Procedures,
Services and
Functions

Table 6 lists the generic signaling procedures, services and functions supported by BICC.
TABLE 6 GENERIC SIGNALING PROCEDURES, SERVICES AND FUNCTIONS
Function/Service

Remark

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)

Confidential and Proprietary Information of ZTE CORPORATION

71

ZXWN MSCS Technical Description

Function/Service

Remark

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 (MLPP)

Only transiting of 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 Stack

72

Description

The BICC protocol can be used in any network to transfer 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 41.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

FIGURE 41 STRUCTURE OF THE BICC PROTOCOL BASED ON THE IP


TRANSPORT NETWORK

Protocol Stack
Based on ATM

The structure of the BICC protocol based on the ATM transport


network is shown in Figure 42.
FIGURE 42 STRUCTURE OF THE BICC PROTOCOL BASED ON THE ATM
TRANSPORT NETWORK

Protocol stack
based on TDM

The structure of the BICC protocol based on the TDM transport


network is shown in Figure 43.
FIGURE 43 STRUCTURE OF THE BICC PROTOCOL BASED ON THE TDM
TRANSPORT NETWORK

Relationship between BICC and


ISUP
The relationship between BICC and ISUP is described as follows:
1. Bearer independent of control

Confidential and Proprietary Information of ZTE CORPORATION

73

ZXWN MSCS Technical Description

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.

Gs Interface Protocol
Gs Interface Protocol Stack
Application
Protocol Stack

74

The Gs interface is between the VLR and the SGSN, coordinating


interaction between the MSCS/VLR and the SGSN.
The protocol stack is shown in Figure 44.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

FIGURE 44 GS INTERFACE PROTOCOL STACK

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.

Applications of Gs Interface Protocol


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.

Implementation
of CSRelated
Services

Through the Gs interface, the SGSN can implement some CS-related services, including:
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
45.
FIGURE 45 LOCATION UPDATE OF THE NON-GPRS SERVICE

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.

Confidential and Proprietary Information of ZTE CORPORATION

75

ZXWN MSCS Technical Description

The paging procedure of the non-GPRS service is shown in


Figure 46.
FIGURE 46 PAGING PROCEDURE OF THE NON-GPRS SERVICE

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
47.
FIGURE 47 ALERT PROCEDURE OF THE NON-GPRS SERVICE

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 48.

76

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

FIGURE 48 EXPLICIT IMSI DETACH PROCEDURE OF THE GPRS SERVICE

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 is
shown in Figure 49.
FIGURE 49 EXPLICIT IMSI DETACH PROCEDURE OF THE NON-GPRS
SERVICE

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 is
shown in Figure 50.

Confidential and Proprietary Information of ZTE CORPORATION

77

ZXWN MSCS Technical Description

FIGURE 50 IMPLICIT IMSI DETACH PROCEDURE OF THE NON-GPRS


SERVICE

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 51.
FIGURE 51 VLR/SGSN RESET PROCEDURE

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 52.

78

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

FIGURE 52 MS INFORMATION PROCEDURE

SIP
This section introduces the following contents about the SIP:

Functions of SIP

Five aspects of multi-media

Advantages of SIP

Main concept model of SIP

Main response codes of SIP

Functions of SIP
SIP is the IP telephone/multi-media conference protocol proposed
by IETF based on text coding. The 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 Multi-Media


Five Aspects of multi-media communication supported by the SIP
protocol are as follows:
1. Subscriber location: confirms the terminal system used for
communication;

Confidential and Proprietary Information of ZTE CORPORATION

79

ZXWN MSCS Technical Description

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 SIP
The SIP has the following advantages:
1. Least status: one conference call or common call can 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 Model of SIP


Entity model

The SIP protocol defines two types of main entities: User 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

80

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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:
1. The Register Server is mainly used to register the current location of the packet terminal and the original data of the location
service.
2. 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.
3. 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.
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 multipoint 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 addrspec 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

Confidential and Proprietary Information of ZTE CORPORATION

81

ZXWN MSCS Technical Description

domains. In addition, the isomorphic requests must contain


the same Request-URI.

Main messages

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 multimedia 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.

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.
1. 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.
2. 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.
3. SIP message format: Both request messages and responses
messages include the SIP message head field and the SIP message body field.

82

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

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 FORMAT OF THE SIP REQUEST MESSAGE

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 54.

Confidential and Proprietary Information of ZTE CORPORATION

83

ZXWN MSCS Technical Description

FIGURE 54 FORMAT OF THE SIP RESPONSE MESSAGE

Main Response Codes of SIP


Description

Category

84

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

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

TABLE 7 CATEGORY OF RESPONSE MESSAGES

Description of
Each type of
Messages

Status
Codes

Types of Response
Messages

Categories of 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

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:
1. 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 8 shows the list of common 1xx messages.
TABLE 8 LIST OF COMMON 1XX MESSAGES
Status
Codes

Meanings

100

Trying: The call-related operation (such as visiting


the database) is being performed, but the callee is
not located yet

180

Ringing: The callee agent has obtained the location of


the callee, and is alerting the callee

181

Call Is Being Forwarded: The proxy server can use


this status code to indicate that the call is being
forwarded to other destination

182

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 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

2. 2xx messages
The 2xx message indicates that the request has been received,
processed and successfully accepted.

Confidential and Proprietary Information of ZTE CORPORATION

85

ZXWN MSCS Technical Description

200: OK--the request is successful.


3. 3xx messages
The 3xx message indicates that the response gives information
about the new location of the subscriber and other optional
services.
Table 9 shows the list of common 3xx messages.
TABLE 9 LIST OF COMMON 3XX MESSAGES
Status
Codes

Meanings

300

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 contain the list of locations and
resources available for users or user agents, and
available addresses should be listed in the Contact
head domain

301

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 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

302

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 indicates the expiration date of the
re-direction. If no expiration date is specified, the
re-direction is only valid for the current call

305

Use Proxy: The resources requested by the client


must be visited through the agent given by the
Contact head domain. The Contact domain gives the
URI of the agent. This response can only be sent by
the UAS

380

Alternate Service: The call is unsuccessfully, but


other services (such as email and voice box) can be
selected. The message body of this response gives
the descriptions of available services

4. 4xx messages
The 4xx message indicates that the request message contains
grammar errors or that the SIP server cannot completely
process the request message.
Table 10 shows the list of common 4xx messages.

86

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

TABLE 10 LIST OF COMMON 4XX MESSAGES


Status
Codes

Meanings

400

Bad Request: The request has grammar errors, so


the server cannot understand it

401

Unauthorized: The request needs user


authentication

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

Confidential and Proprietary Information of ZTE CORPORATION

87

ZXWN MSCS Technical Description

Status
Codes

88

Meanings

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

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

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

Status
Codes

Meanings

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

5. 5xx messages
The 5xx message indicates that the SIP server cannot correctly
process the request message because it is faulty.
Table 11 shows the list of common 5xx messages.
TABLE 11 LIST OF COMMON 5XX MESSAGES
Status
Codes

Meanings

500

Server Internal Error: The server is exceptional , so


it cannot process the request

501

Not Implemented: The server does not support the


functions required for completing the request

502

Bad Gateway: As a gateway or an agent, the server


receives an invalid response from other server when
processing the request

503

Service Unavailable: Due to temporary overloading


or being maintained, the server cannot process the
request

504

Gateway Timeout: As a gateway, the server does not


receive responses from other servers (such as the
location server) in time when processing the call

505

Version Not Supported: The server cannot or refuses


to support the version used by the request message

6. 6xx messages
The 6xx message indicates that the request message contains
grammar errors or that the SIP server cannot completely
process the request message.
Table 12 shows the list of common 6xx messages.

Confidential and Proprietary Information of ZTE CORPORATION

89

ZXWN MSCS Technical Description

TABLE 12 LIST OF COMMON 6XX MESSAGES


Status
Codes

Meanings

600

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 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

603

Decline: The called terminal has been successfully


connected, but the subscriber is busy and clearly
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

604

Does Not Exist Anywhere: The subscriber specified by


the To head domain in the request does not exist

606

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 be accepted. This response indicates that the
user want to set up communication, but cannot fully
support the session described in the request

RANAP Protocol
Introduction to RANAP Protocol
Description

Signaling
Functions

90

Located at the bottom of the network layer, the 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.
The signaling functions of the RANAP protocol fall into:

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 multimodule management.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

Function of RANAP Management


Module
The main functions of the management module are as follows:

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.

Function of RANAP Service


Processing Module
Main functions of the service processing module are as follows:

RAB assignment
Responsible for assignment of service data bearer in call
process.

Relocation
If the RNC or UE detects that service quality degrading and
determines to initiate relocation after measurement of the peer
RNC, the RNC will initiate this relocation process and the CN will
control it to hand over voice channel to RNC with high service
quality. Relocation involves intra-system handover and intersystem 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

Confidential and Proprietary Information of ZTE CORPORATION

91

ZXWN MSCS Technical Description

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.

92

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

Network Management Service


Function of the RANAP
Functions

The main NM service function of the RANAP is the service report


function.
Service report function involves normal service report and abnormal service report.

Normal service report


When normal service occurs, such as the Iu interface connection establishment and release, the normal service report is
reported to the background.

Abnormal service report


When abnormal service occurs, such as the Iu connection abnormality, the Iu release abnormality, and the RAB release abnormality, the abnormal service report is reported to the background.

Office Reset and


Resource Reset
Procedure

If an office fails, the background can initiate an inter-office reset


procedure. The RANAP reports the activity test results to the background, and the background judge whether the voice channel is
suspended according to related conditions and reset the resources
of the suspended connection.

Multi-Module Management Function

Signaling synchronization function: The management module


conducts unified management over individual modules and implements signaling synchronization among modules.

Active/standby changeover: Active/standby changeover protects the Iu connection going into the conversation status,
which coordinates with service layer to prevent resource suspension upon changeover.

BSSAP Protocol
Introduction to BSSAP Protocol
Application

The 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.

Confidential and Proprietary Information of ZTE CORPORATION

93

ZXWN MSCS Technical Description

Signaling
Functions

The BSSAP mainly processes A interface signaling procedures related with calls, mobility management and resource management,
including:

Management function

Service processing function

Service report function

Multi-module processing function

Active/standby changeover.

Function of BSSAP Management


Module
The management module maintains terrestrial circuits of the A interface, and blocks/unblocks and resets circuits according to the
actual needs. In addition, the module needs to implement office
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.

Resetting circuit messages: Operation performed when local


or peer office needs to reset some circuit resources.

Blocking/unblocking messages: Covers OMC/BSC blocking/unblocking message reception and blocking/unblocking response
message of BSC.

Function of BSSAP Service


Processing Module
The service processing module transfers and processes messages
between MSCS and BSC, and also transmits 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 manage-

94

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

ment, 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


Functions

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 Management Function


Signaling synchronization function: The management module
conducts unified management over individual modules and 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.

Confidential and Proprietary Information of ZTE CORPORATION

95

ZXWN MSCS Technical Description

MAP Protocol
Function of MAP Signaling
Description

Main Functions

The 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.

Setting up dialogues between MSCS/VLR and entities such as


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 Procedure


The MAP signaling procedures related to the MSCS/VLR cover:
1. Location registration and deletion
2. 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.
3. 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.
4. Relocation: Supports basic relocation and subsequent relocation.
5. 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.

96

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

6. 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.
7. IMEI management: Defines signaling process when MSCS
queries EIR for MS equipment validity.
8. 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
Introduction to CAP Protocol
The 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.
This section introduces the following contents about the CAP protocol:

System structure of the CAP protocol

CAP operations

System Structure of CAP Protocol


System Structure

The CAP protocol is a Remote Operation Service Element (ROSE)


user protocol, and its protocol system is shown in Figure 55.

Confidential and Proprietary Information of ZTE CORPORATION

97

ZXWN MSCS Technical Description

FIGURE 55 CAP SYSTEM

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 55 is adopted; if the physical entity is
associated with multiple physical entities, the left diagram is used.
SACF/MACF Rules

INAP

98

SACF/MACF rules involve two aspects:

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.

the 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 56.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

FIGURE 56 OPERATION DESCRIPTION

CAP can address with SCCP GT, MTP SPC or SSN . At present, it is
specified that CAP SSN is equal to 146 in UMTS.

CAP Operations
Application

CAP operations are similar to INAP operations, and only 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.

Specific
Operations

Table 13 and Table 14 describe operations.


TABLE 13 CAP OPERATIONS ASSOCIATED WITH CS
CAP Operation Name

Operation Explanation

ActivityTest

Activity test: Tests whether dialogue


between CAP entities is activated

ApplyCharging

Applying charging: SCP requires SSP for


charging control

ApplyChargingReport

Applying charging report: Indicates result


of applying charging operation of SSP to
SCP

AssistRequestInstructions

Assistant request instructions: Assists in


setting up dialogues between SSP and SCP

CallInformationRequest

Call information request: Used for SCP to


monitor call information

Confidential and Proprietary Information of ZTE CORPORATION

99

ZXWN MSCS Technical Description

100

CAP Operation Name

Operation Explanation

CallInformationReport

Call information report: Indicates response


of SSP to call information request

Cancel

Cancellation: Used for SCP to cancel


previously sent operation

CallGap

Call gap: Used for SCP to restrict call


volume of SSP

Connect

Connection: Used for SCP to set up a


connection with party B

ConnectToResource

Connecting to resource: Used to set up a


connection with SRF and subsequently play
announcement tone

Continue

Continuity: Used to set up a connection


without changing call information

ContinueWithArgument

Continuity with argument: Used to set up


a connection with some call information
changed (except called number)

DisconnectForwardConnection

Disconnecting forward connection: Used to


disconnect connection with SRF

EstablishTemporaryConnection

Establishing temporary connection: Used


to set up a connection to an independent
IP and play subsequent announcement

EventReportBCSM

BCSM event report: When SSP meets a DP


point, if this DP point is monitored, event
will be reported to SCP

FurnishChargingInformation

Furnishing charging information: Used for


SCP to send to SSP in need of charging

InitialDP

Initiating DP: Used for SSP to enable


dialogue with SCP

ReleaseCall

Releasing call: Used for SCP to release SSP


connection

RequestReportBCSMEvent

Requesting BCSM event report: Used for


SCP to monitor or cancel DP point

ResetTimer

Resetting timer: Used for SCP to ask SSP


to reset hold timer, to prevent SSP timer
timeout

SendChargingInformation

Sending charging information: Used for


AOC service

PlayAnnouncement

Playing announcement: Used for SCP to


play announcement to subscribers

PromptAndCollectUserInformation

Prompting and collecting user information:


Used for SCP to collect user information

SpecializedResourceReport

Specialized resource report: Used for SSP


to report to SCP after PA operation

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 3 Signaling Protocol

TABLE 14 CAP OPERATIONS ASSOCIATED WITH SMS


CAP Operation Name

Operation Explanation

ConnectSMS

Connecting to SMS: Used to set up a


connection with SMS of party B

ContinueSMS

Continuing SMS: Used for SMS connection


without changing information

EventReportSMS

SMS event report: When SMS transaction


meets a DP point, if DP point is monitored,
event will be reported to SCP

FurnishChargingInformationSMS

Furnishing charging information: Used for


SCP to furnish charging information to SSP

InitialDPSMS

Initiating DP SMS: Used to enable dialogue


between SSP and SCP

ReleaseSMS

Releasing SMS: Used to release SMS


transaction

RequestReportSMSEvent

Requesting SMS event report: Used to


monitor or cancel SMS DP point

ResetTimerSMS

Resetting timer: Used for SCP to ask SSP


to reset hold timer, to prevent SSP timer
timeout

Confidential and Proprietary Information of ZTE CORPORATION

101

ZXWN MSCS Technical Description

This page is intentionally blank.

102

Confidential and Proprietary Information of ZTE CORPORATION

Chapter

Basic Functions
Table of Contents
Introduction to Basic Functions.......................................... 103
Mobility Management Function .......................................... 103
Security Management Function.......................................... 143
VLR Management Function................................................ 150
Operation and Maintenance Function .................................. 154

Introduction to Basic
Functions
Having powerful functions, ZXWN MSCS system can implement
the following main functions:

Mobility management function

Security management function

VLR management function

Operation and maintenance function

Mobility Management
Function
Introduction to Mobility Management
Function
The main purposes of mobility management include:

Tracing the location information of subscribers;

Reporting the lawful information of subscribers;

Transmitting the service list information of subscribers.

Confidential and Proprietary Information of ZTE CORPORATION

103

ZXWN MSCS Technical Description

ZXWN MSCS system mainly provides the following mobility management functions

Location update

Relocation and handover

Location Update
Introduction to Location Update
Function

The 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.

Category

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.

General Location Update


Category

VLR Location
Update

104

Different location updates are identified by location update category information in location update request messages. Processing
flows are almost the same. General location update falls into:

VLR location update

GPRS location update

Combined location update

If Location Area (LA) changes when subscriber roams, MS will 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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

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 57.
FIGURE 57 PROCESSING FLOW WITHOUT NEED OF LOCATION UPDATE
TO HLR

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 subscribers 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 au-

Confidential and Proprietary Information of ZTE CORPORATION

105

ZXWN MSCS Technical Description

thentication 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 subscribers
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 58.
FIGURE 58 PROCESSING FLOW NEEDING LOCATION UPDATE INITIATION
TO HLR

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.

106

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

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:

Subscriber starts the system for the first time.

Subscriber roams across the MSCS/VLR system.

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 subscribers 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
Update

SGSN initiates location update to HLR, and the process is similar 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 59.

Confidential and Proprietary Information of ZTE CORPORATION

107

ZXWN MSCS Technical Description

FIGURE 59 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
Location Update

108

If there is Gs interface connection, SGSN will notify VLR to originate location update after GPRS location update is completed. This
is called combined location update, as shown in Figure 60.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

FIGURE 60 COMBINED LOCATION UPDATE SERVICE FLOW

This location update service flow is the same with the general location update service flow.

Periodic Location Update


Function

When an MS is powered off, the MSCS may fail to know this event
due to poor radio transmission quality or some other reasons, and
the MSCS still regards the MS as in attach status. Alternatively,
the MS is powered on but has roamed beyond service coverage,
that is, the MS is in a blind area, and the GSM system cannot
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, the MSCS takes measures of
forced registration. That is, the MSCS requires the MS to register
at regular intervals, which is called periodic location update.

Flow

The periodic location update process is the same with the 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 the 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 the MSCS/VLR where subscriber is located. If current MSCS/VLR has no record of this
subscriber, it will request the HLR for subscriber data according
to subscriber IMSI. The HLR records subscribers current location
(recording current MSCS/VLR number) and sends subscriber data
to the MSCS/VLR. The MSCS/VLR will set subscriber status to attach.
If the MSCS/VLR has subscriber data, it need not ask the HLR for
data. The MSCS/VLR just originates location update and then sets
subscriber status to attach.

Confidential and Proprietary Information of ZTE CORPORATION

109

ZXWN MSCS Technical Description

When the MS is powered off, it will send a message to the


MSCS/VLR. When the network receives this message, it regards
the MS as power off and sets subscriber status as detach.

Relocation and Handover


Introduction to Relocation and Handover
Function

During a conversation, when a mobile subscriber move from one


serving cell to another serving cell, the link between the original
BS and the mobile subscriber is replaced by that between the new
BS and the mobile subscriber to guarantee uninterrupted conversation. This process is called 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 MSC/VLR and perform
relocation, to sustain existing service.

Related Concepts

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.

Category (Based
on System type of
Handover)

Category (Based
on Whether
the Circuit Is
Established)

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 interoffice 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 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

110

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

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.

UMTSUMTS Intra-office Intra-system


Relocation
UMTS
UMTS
Intra-office
Intra-system
Relocation
Network Models

Network models as shown in Figure 61, Figure 62 and Figure 63


indicate calling control signaling and bearer control signaling before, during and after the relocation. Here, actual lines indicate
control plane signaling and virtual lines indicate bearer plane control signaling.

Note:
Terminal T1 orients RNC A side and the T2 orients other MGWs.
T3 orients RNC B side.

UMTS NETWORK MODEL BEFORE INTRA-OFFICE


FIGURE 61 UMTS
RELOCATION

Confidential and Proprietary Information of ZTE CORPORATION

111

ZXWN MSCS Technical Description

UMTS NETWORK MODEL DURING INTRA-OFFICE


FIGURE 62 UMTS
RELOCATION

UMTS NETWORK MODEL AFTER THE INTRA-OFFICE


FIGURE 63 UMTS
RELOCATION

UMTS
UMTS
Intra-office
Intra-system

112

The UMTSUMTS intra-office intra-system relocation message


flow is shown in Figure 64 and Figure 65.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

Relocation
Message Flow

UMTS INTRA-OFFICE INTRA-SYSTEM RELOCATION


FIGURE 64 UMTS
FLOW

Confidential and Proprietary Information of ZTE CORPORATION

113

ZXWN MSCS Technical Description

UMTS INTRA-OFFICE INTRA-SYSTEM RELOCATION


FIGURE 65 UMTS
FLOW (CONTINUED)

Flow Descriptions:
1. Step 1
When an RNS decides to originate relocation, RNSA (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

114

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

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.

UMTSUMTS Inter-office Intra-system


Relocation
UMTS
UMTS
Inter-Office
Intra-system
Relocation
Network Model

Network models shown in Figure 66, Figure 67, and Figure 68 indicate call control signaling and bearer control signaling before,
during, and after relocation respectively. Here, actual lines 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.
2. In MGW B, terminal T4 orients RNC B and terminal T5 orients
MGW A.

UMTS NETWORK MODEL BEFORE THE INTER-OFFICE


FIGURE 66 UMTS
INTRA-SYSTEM RELOCATION

Confidential and Proprietary Information of ZTE CORPORATION

115

ZXWN MSCS Technical Description

UMTS NETWORK MODEL DURING THE INTER-OFFICE


FIGURE 67 UMTS
INTRA-SYSTEM RELOCATION

UMTS NETWORK MODEL AFTER THE INTER-OFFICE


FIGURE 68 UMTS
INTRA-SYSTEM RELOCATION

UMTS
UMTS
Inter-office
Intra-system

116

The UMTSUMTS inter-office intra-system relocation message


flow is shown in Figure 69 and Figure 70.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

Relocation
Message Flow

UMTS INTER-OFFICE INTRA-SYSTEM RELOCATION


FIGURE 69 UMTS
FLOW

Confidential and Proprietary Information of ZTE CORPORATION

117

ZXWN MSCS Technical Description

UMTS INTER-OFFICE INTRA-SYSTEM RELOCATION


FIGURE 70 UMTS
FLOW (CONTINUED)

Flow Descriptions:
1. Step 1
When an RNS decides to originate relocation, RNSA (RNC 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
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

118

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

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 Change 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 Termi
nation to MGW A to release endpoint T1.

UMTSGSM Intra-office Inter-system Handover


GSM
UMTS
Intra-office
Inter-system
Handover
Network Model

Network models shown in Figure 71, Figure 72, and Figure 73 indicate call control signaling and bearer control signaling before,
during, and after handover respectively. Here, solid lines indicate
control plane signaling and dotted lines indicate bearer plane control signaling (no bearer control signaling on port A).

Confidential and Proprietary Information of ZTE CORPORATION

119

ZXWN MSCS Technical Description

Note:
Terminal T1 orients the RNC A side and T2 orients other MGWs.
The T3 orients the BSC B side.

GSM NETWORK MODEL BEFORE INTRA-OFFICE


FIGURE 71 UMTS
INTER-SYSTEM HANDOVER

GSM NETWORK MODEL DURING INTRA-OFFICE


FIGURE 72 UMTS
INTER-SYSTEM HANDOVER

120

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

GSM NETWORK MODEL AFTER INTRA-OFFICE


FIGURE 73 UMTS
INTER-SYSTEM HANDOVER

GSM
UMTS
Intra-office
Inter-system
Handover Flow

The UMTSGSM intra-office inter-system handover flow is shown


in Figure 74 and Figure 75.
GSM INTRA-OFFICE INTER-SYSTEM HANDOVER FLOW
FIGURE 74 UMTS

Confidential and Proprietary Information of ZTE CORPORATION

121

ZXWN MSCS Technical Description

GSM INTRA-OFFICE INTER-SYSTEM HANDOVER FLOW


FIGURE 75 UMTS
(CONTINUED)

Flow Descriptions:
1. Step 1
When an RNS decides to originate relocation, RNSA (RNC 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.
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 applied wireless resources.
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.

122

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

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.

UMTSGSM Inter-office Inter-system Handover


GSM
UMTS
Inter-office
Inter-system
Handover
Network Model

Network models shown in Figure 76, Figure 77, and Figure 78 indicate call control signaling and bearer control signaling before,
during, and after handover respectively. Here, actual lines indicate control plane signaling and virtual lines indicate bearer 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.
2. In MGW B, terminal T4 orients BSC B and terminal T5 orients
MGW A.

GSM NETWORK MODEL BEFORE INTER-OFFICE


FIGURE 76 UMTS
INTER-SYSTEM HANDOVER

Confidential and Proprietary Information of ZTE CORPORATION

123

ZXWN MSCS Technical Description

GSM NETWORK MODEL DURING INTER-OFFICE


FIGURE 77 UMTS
INTER-SYSTEM HANDOVER

GSM NETWORK MODEL AFTER INTER-OFFICE


FIGURE 78 UMTS
INTER-SYSTEM HANDOVER

GSM
UMTS
Inter-office

124

The UMTSGSM inter-office inter-system handover flow is shown


in Figure 79 and Figure 80.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

Inter-system
Handover Flow

GSM INTER-OFFICE INTER-SYSTEM HANDOVER FLOW


FIGURE 79 UMTS

Confidential and Proprietary Information of ZTE CORPORATION

125

ZXWN MSCS Technical Description

GSM INTER-OFFICE INTER-SYSTEM HANDOVER FLOW


FIGURE 80 UMTS
(CONTINUED)

Flow Descriptions:
1. Step 1
When an RNS decides to originate relocation, RNSA 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, 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, carrying
information brought by MAP Prepare Handover Req for applying
for wireless resource.
4. Step 4

126

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

After applying for wireless resource, BSC B sends message A


Handover 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 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 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 Change 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, BSC B
will send the message A Handover 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
the access side. MSCS A sends command Release Bearer
Termination to MGW A to release endpoint T1.

Confidential and Proprietary Information of ZTE CORPORATION

127

ZXWN MSCS Technical Description

GSMUMTS Intra-office Inter-system Handover


UMTS
GSM
Intra-office
Inter-system
Handover
Network Model

Network models shown in Figure 81, Figure 82, and Figure 83 indicate call control signaling and bearer control signaling before,
during, and after handover respectively. Here, solid lines 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.

UMTS NETWORK MODEL BEFORE THE INTRA-OFFICE


FIGURE 81 GSM
INTER-SYSTEM HANDOVER

UMTS NETWORK MODEL DURING THE INTRA-OFFICE


FIGURE 82 GSM
INTER-SYSTEM HANDOVER

128

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

UMTS NETWORK MODEL AFTER THE INTRA-OFFICE


FIGURE 83 GSM
INTER-SYSTEM HANDOVER

UMTS
GSM
Intra-office

The GSMUMTS intra-office inter-system handover flow is shown


in Figure 84.

Confidential and Proprietary Information of ZTE CORPORATION

129

ZXWN MSCS Technical Description

Inter-system
Handover Flow

UMTS INTRA-OFFICE INTER-SYSTEM HANDOVER FLOW


FIGURE 84 GSM

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 re-

130

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

lationships 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 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
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 Termination to MGW to release terminal T1.

GSMUMTS Inter-office Inter-system Handover


UMTS
GSM
Inter-office
Inter-system
Handover
Network Model

Network models shown in Figure 85, Figure 86, and Figure 87 indicate call control signaling and bearer control signaling before,
during, and after handover respectively. Here, solid lines indicate
control plane signaling and dotted lines indicate bearer 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.
2. In MGW B, terminal T4 orients BSC B and terminal T5 orients
MGW A.

Confidential and Proprietary Information of ZTE CORPORATION

131

ZXWN MSCS Technical Description

UMTS NETWORK MODEL BEFORE INTER-OFFICE


FIGURE 85 GSM
INTER-SYSTEM HANDOVER

UMTS NETWORK MODEL DURING INTER-OFFICE


FIGURE 86 GSM
INTER-SYSTEM HANDOVER

UMTS NETWORK MODEL AFTER INTER-OFFICE


FIGURE 87 GSM
INTER-SYSTEM HANDOVER

132

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

UMTS
GSM
Inter-office
Inter-system
Handover Flow

The GSMUMTS inter-office inter-system handover flow is shown


in Figure 88 and Figure 89.
UMTS INTER-OFFICE INTER-SYSTEM HANDOVER FLOW
FIGURE 88 GSM

Confidential and Proprietary Information of ZTE CORPORATION

133

ZXWN MSCS Technical Description

UMTS INTER-OFFICE INTER-SYSTEM HANDOVER FLOW


FIGURE 89 GSM
(CONTINUED)

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
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 the 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 the access side.
4. Step 4

134

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

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 this 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 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
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 Change 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 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 the A Clear Command to BSC A to release bearer at
the access side. MSCS A sends command Release Bearer
Termination to MGW A to release endpoint T1.

Confidential and Proprietary Information of ZTE CORPORATION

135

ZXWN MSCS Technical Description

GSMGSM Intra-office System Handover


GSM
GSM
Intra-office
System Handover
Network Model

Network models as shown in Figure 90, Figure 91 and Figure 92


indicate calling control signaling and bearer control signaling before, during and after handover. Here, the solid lines indicate control plane signaling and dotted lines indicate bearer plane control
signaling.

Note:
Terminal T1 orients the BSC A side and T2 orients MGW. T3 orients
BSC B side.

GSM NETWORK MODEL BEFORE INTRA-OFFICE


FIGURE 90 GSM
INTRA-SYSTEM HANDOVER

GSM NETWORK MODEL DURING INTRA-OFFICE


FIGURE 91 GSM
INTRA-SYSTEM HANDOVER

136

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

GSM NETWORK MODEL AFTER INTRA-OFFICE


FIGURE 92 GSM
INTRA-SYSTEM HANDOVER

GSM
GSM
Intra-office
System Handover
Flow

GSMGSM intra-office system handover flow is shown in Figure


93 and Figure 94.
GSM INTRA-OFFICE INTRA-SYSTEM HANDOVER FLOW
FIGURE 93 GSM

Confidential and Proprietary Information of ZTE CORPORATION

137

ZXWN MSCS Technical Description

INTRA-OFFICE SYSTEM HANDOVER FLOW


FIGURE 94 GSM
(CONTINUED)

Flow Descriptions:
1. Step 1
BSC A judges that handover is needed, and it sends handover
request message A Handover Required to MSCS. 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 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 message A Handover Command to BSC A carrying applied wireless resources.
5. Step 5
When BSC B receives access message of UE/MS, it sends message A Handover Detect to MSCS. MSCS sends command C
hange 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 Termination to MGW to release terminal T1.

138

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

GSMGSM Inter-office Intra-system Handover


GSM
GSM
Inter-office
Intra-system
Handover
Network Model

Network models shown in Figure 95, Figure 96, and Figure 97 indicate call control signaling and bearer control signaling before,
during, and after handover respectively. Here, solid lines indicate
control plane signaling and dotted lines indicate bearer plane control signaling.

Note:
1. In MGW A, terminal T1 orients BSC A, terminal T2 orients MGW
and terminal T3 orients MGW B.
2. In MGW B, terminal T4 orients BSC B and terminal T5 orients
MGW A.

GSM NETWORK MODEL BEFORE INTER-OFFICE


FIGURE 95 GSM
INTRA-SYSTEM HANDOVER

GSM NETWORK MODEL DURING INTER-OFFICE


FIGURE 96 GSM
INTRA-SYSTEM HANDOVER

Confidential and Proprietary Information of ZTE CORPORATION

139

ZXWN MSCS Technical Description

GSM NETWORK MODEL AFTER INTER-OFFICE


FIGURE 97 GSM
INTRA-SYSTEM HANDOVER

GSM
GSM
Inter-office
Intra-system
Handover Flow

140

GSMGSM inter-office system handover flow is shown in Figure


98 and Figure 99.
GSM INTER-OFFICE INTRA-SYSTEM HANDOVER FLOW
FIGURE 98 GSM

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

GSM INTER-OFFICE INTRA-SYSTEM HANDOVER FLOW


FIGURE 99 GSM
(CONTINUED)

Flow Descriptions:
1. Step 1
BSC A judges that handover is needed and it sends the handover request message A Handover Required to MSCS. 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
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 Reserve Circuit procedure to apply for terminal T4 to MGW B and requests MGW to
provide binding reference BNC ID and the MGW address.

Confidential and Proprietary Information of ZTE CORPORATION

141

ZXWN MSCS Technical Description

3. Step 3
MSCS B sends message A Handover Request to BSC B, carrying
information brought by MAP Prepare Handover Req 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 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,
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
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 A Handover Command to BSC A to
bring new wireless resource to UE/MS.
8. Step 8
When BSC B receives access message of UE/MS, it sends message A Handover Detect to MSCS B. MSCS B sends message
MAP Process Access Signaling Req to MSCS A, carrying UE/MS
access message.
9. Step 9
After receiving message MAP Process Access Signaling Req,
MSCS A sends command Change 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, BSC B
will send the message A Handover 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 to connect speech
channel.
12. Step 12
After receiving message MAP Send End Signal Req, MSCS A
sends A Clear Command to BSC A to release bearer at the
access side. MSCS A sends command Release Bearer Termi
nation to MGW A to release endpoint T1.

142

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

Security Management
Function
Introduction to Security Management
Function
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.

Protecting subscriber privacy via encryption and integrity protection.

Preventing subscriber IMSI from being stolen, which is implemented via TMSI allocation.

Preventing subscriber mobile phone from being used without


authorization, which is implemented via IMEI check.

Authentication
Functions and Features of Authentication
Functions

Authentication is to protect legal subscribers against intrusion 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.

Features

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.

Confidential and Proprietary Information of ZTE CORPORATION

143

ZXWN MSCS Technical Description

Generation and Composition of Authentication


Parameters
Functions of
Authentication
Parameters

Generation
of Quintuple
Parameters

Subscriber authentication needs authentication quintuple provided


by system. Quintuple is generated in AUC.
During 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.
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
100.
FIGURE 100 GENERATION OF AUTHENTICATION PARAMETERS IN AUC

Generation process of XMAC-A, RES, CK and IK in USIM is shown


in Figure 101.

144

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

FIGURE 101 GENERATION OF AUTHENTICATION PARAMETERS IN USIM

Normal Authentication Procedure


Procedure
Diagram

For the normal authentication procedure, see Figure 102.


FIGURE 102 NORMAL AUTHENTICATION PROCEDURE

Procedure
Description

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

Confidential and Proprietary Information of ZTE CORPORATION

145

ZXWN MSCS Technical Description

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.

Resynchronization Procedure
Application

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 procedure
to resynchronize sequence number of MS and that in HLR/AUC.

Procedure
Description

1. 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.
2. 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.
3. 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.
4. VLR/SGSN reinitiates an authentication flow. Processing is
same as that in a normal authentication process.

Generation of
AUTS

146

Generation of authentication resynchronization parameter AUTS in


USIM is shown in Figure 103.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

FIGURE 103 GENERATION OF AUTHENTICATION RESYNCHRONIZATION


PARAMETER AUTS IN USIM

MAC-S Verification
Procedure

During authentication resynchronization, MAC-S


process in HLR/AUC is shown in Figure 104.

verification

FIGURE 104 GENERATION OF AUTHENTICATION RESYNCHRONIZATION


PARAMETER AUTS IN AUC

Encryption
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 Method

Figure 105 illustrates how to use ciphering algorithm f8 to obtain


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).

Confidential and Proprietary Information of ZTE CORPORATION

147

ZXWN MSCS Technical Description

FIGURE 105 CIPHERING PROCESS

Input Parameters
of Ciphering
Algorithm

COUNT-C: With a length of 32 bits, each logical RLC AM channel and each RLC UM channel have a COUNT-C value, and all
logical channels in transparent RLC mode (and logical 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
Protection Method

Figure 106 illustrates use of integrity protection algorithm f9 to


verify data integrity of signaling messages.

148

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

FIGURE 106 INTEGRITY PROTECTION PROCESS

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 Parameters
of Integrity
Algorithm

COUNT-I: With a length of 32 bits, each logical signaling channel has one COUNT-I. COUNT-I value consists of two parts:
short serial number and long serial number.

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

Conditions for
TMSI Allocation

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.

When a subscriber updates its location, system should encrypt


ID and data of subscriber.

RestartNum in TMSI is inconsistent with record in current system.

Confidential and Proprietary Information of ZTE CORPORATION

149

ZXWN MSCS Technical Description

Conditions for
TMSI Release

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 subscribers
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 subscribers 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.

VLR receives acknowledgement information of subscriber for


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 Function


Introduction to VLR Management
Function
The ZXWN MSCS office is embedded with the VLR NE function,
providing the VLR management function, and mainly including:

150

Subscriber data management

Error recovery processing.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

Subscriber Data Management


Overview

Synchronization
Mode

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.
There are two synchronization modes:
1. Inserting subscriber data
2. Deleting subscriber data
These two types of messages have message retransmission mechanism, which are described as follows:

Inserting
Subscriber Data

To add or modify subscriber subscription information, HLR performs subscriber data insertion, and service flow is shown in Figure
107.
FIGURE 107 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.

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

Confidential and Proprietary Information of ZTE CORPORATION

151

ZXWN MSCS Technical Description

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
Subscriber Data

If it is necessary to delete subscriber subscription information, HLR


deletes subscriber data. Service flow is shown in Figure 108.
FIGURE 108 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:

152

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 109.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

FIGURE 109 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 subscribers 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 is shown in Figure
110.

Confidential and Proprietary Information of ZTE CORPORATION

153

ZXWN MSCS Technical Description

FIGURE 110 HLR RESTART FLOW

Operation and Maintenance


Function
Introduction to Operation and
Maintenance Function
This section will introduce four types of common operation and
maintenance functions.

Subscriber Tracing

Equipment Tracing

Deleting an MS

Querying IMSI according to ISDN

Subscriber Tracing
Purpose

Subscriber Tracing
in HLR/VLR

154

PLMN administrator can use the subscriber tracing function to observe the following circumstances for tracing purpose.

Subscribers 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.

After an HLR receives a subscriber tracing command from OMC, it


notifies the MSCS/VLR where subscriber is located to activate or
deactivate subscriber tracing. Local OMC of MSCS/VLR can be set
to trace a subscriber. Operation flow is shown in Figure 111.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 4 Basic Functions

FIGURE 111 SERVICE FLOW OF ACTIVATING/DEACTIVATING SUBSCRIBER


TRACING

Flow is described as follows:


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

Confidential and Proprietary Information of ZTE CORPORATION

155

ZXWN MSCS Technical Description

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, subscribers MSISDN can be used to query subscribers IMSI. If there is no information about this subscribers
IMSI in VLR, the VLR will initiate a request to HLR to query subscribers IMSI.

Flow

When the VLR initiates a request for querying the subscriber IMSI
to the HLP, the flow is shown in Figure 112.
FIGURE 112 IMSI-SENDING SERVICE FLOW

Flow is described as follows:


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 subscribers 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.

156

Confidential and Proprietary Information of ZTE CORPORATION

Chapter

Basic Services
Table of Contents
Introduction to Basic Services ........................................... 157
Mobile Call Service........................................................... 157
Mobile Data Services........................................................ 179
Short Message Service ..................................................... 181
Supplementary Services ................................................... 185

Introduction to Basic
Services
This chapter introduces the following basic services:

Mobile call service

Mobile data service

Short message service

Supplementary service

Mobile Call Service


Introduction to Mobile Call Service
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.

Confidential and Proprietary Information of ZTE CORPORATION

157

ZXWN MSCS Technical Description

Basic Call
Procedure

In the R4 network, 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 113.
FIGURE 113 STRUCTURE OF THE MOBILE CALL SERVICE PROCESSING
MODULE

The following sections describe multiple types of service flows in


details.
Functions of Each
Module

158

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:

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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.

Radio Channel Assignment Flow of


the Basic Call of the UE
Network Structure

The network structure of the UE originated call is shown in Figure


114.
FIGURE 114 NETWORK STRUCTURE OF THE UE ORIGINATED CALL

Involved NEs
Signaling Flow

The call originated by the UE involves the following NEs: UE, RNC,
VMSCS, VLR and the target switch.
The basic signaling flow is shown in Figure 115.

Confidential and Proprietary Information of ZTE CORPORATION

159

ZXWN MSCS Technical Description

FIGURE 115 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.

160

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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 Structure

The network structure of the UE terminated call is shown in Figure


116.

Confidential and Proprietary Information of ZTE CORPORATION

161

ZXWN MSCS Technical Description

FIGURE 116 NETWORK STRUCTURE OF THE UE TERMINATED CALL

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 Figure
117.
FIGURE 117 SIGNALING FLOW OF THE UE TERMINATED CALL
WITH THE PAGING PROCEDURE

The flow is described as follows:

162

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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.

Confidential and Proprietary Information of ZTE CORPORATION

163

ZXWN MSCS Technical Description

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 118 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 118 NETWORK MODEL OF ORIGINATED CALL

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
Establishment

Originated call time sequence of forward bearer establishment


mode is shown in Figure 119 and Figure 120.

164

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 119 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE


OF FORWARD BEARER ESTABLISHMENT

FIGURE 120 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE


OF FORWARD BEARER ESTABLISHMENT (CONTINUED)

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

Confidential and Proprietary Information of ZTE CORPORATION

165

ZXWN MSCS Technical Description

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

166

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

(such as echo suppression function). After all processes finish,


MSC Server sends CONNECT message to MS, and calling
party starts to talk.
Backward Bearer
Establishment

Originated call time sequence of backward bearer establishment


mode is shown in Figure 121 and Figure 122.
FIGURE 121 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE
OF BACKWARD BEARER ESTABLISHMENT

FIGURE 122 ORIGINATED CALL SETUP TIME SEQUENCE IN CASE


OF BACKWARD BEARER ESTABLISHMENT (CONTINUED)

Confidential and Proprietary Information of ZTE CORPORATION

167

ZXWN MSCS Technical Description

Description of the process:


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

168

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 123 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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 123 NETWORK MODEL OF TERMINATED CALL

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
Establishment

Terminated call time sequence of forward bearer establishment


mode is shown in Figure 124 and Figure 125.
FIGURE 124 TERMINATED CALL SETUP TIME SEQUENCE IN CASE
OF FORWARD BEARER ESTABLISHMENT

Confidential and Proprietary Information of ZTE CORPORATION

169

ZXWN MSCS Technical Description

FIGURE 125 TERMINATED CALL SETUP TIME SEQUENCE IN CASE


OF FORWARD BEARER ESTABLISHMENT (CONTINUED)

Description of the process:


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

170

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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-Connection
process indicates external continuity attribute of 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

Confidential and Proprietary Information of ZTE CORPORATION

171

ZXWN MSCS Technical Description

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 ThroughConnection 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 process requests access terminal to activate gateway function, or optional Active Voice Processing Function
requests to activate language processing function. After completing above terminal modification processes, MSCS Server
forwards Answer message to GMSC Server.

172

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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
Establishment

Terminated call time sequence of backward bearer establishment


mode is shown in Figure 126 and Figure 127.
FIGURE 126 TERMINATED CALL SETUP TIME SEQUENCE IN CASE
OF BACKWARD BEARER ESTABLISHMENT

Confidential and Proprietary Information of ZTE CORPORATION

173

ZXWN MSCS Technical Description

FIGURE 127 TERMINATED CALL SETUP TIME SEQUENCE IN CASE


OF BACKWARD BEARER ESTABLISHMENT (CONTINUED)

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

174

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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.

Confidential and Proprietary Information of ZTE CORPORATION

175

ZXWN MSCS Technical Description

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-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
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 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 process requests access terminal to activate gateway function, or optional Active Voice Processing
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

176

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

activated. Otherwise, it directly forwards Answer message to


the previous node.

Call Release Flow


Overview

MS On-hook Flow

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 flow is shown in Figure 128.
FIGURE 128 MS ON-HOOK FLOW

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

Confidential and Proprietary Information of ZTE CORPORATION

177

ZXWN MSCS Technical Description

If UE obtains access from BSC, network-side bearer and A interface connection are released.
On-hook Flow on
the Network Side

Network-side on-hook flow is shown in Figure 129.


FIGURE 129 NETWORK-SIDE ON-HOOK FLOW

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, networkside 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.

178

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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 peoples 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 15 lists bearer capabilities necessary for circuit data services:

Confidential and Proprietary Information of ZTE CORPORATION

179

ZXWN MSCS Technical Description

TABLE 15 UMTS CIRCUIT DATA SERVICES


Service Name

Attribute

Bearer
Capability

Supported
Rates

3.1 kHz audio

Asynchronous/transparent mode

3.1kHz audio

28.8 kbit/s

V.110

Synchronous/transparent mode

28.8 kbit/s

Synchronous/nontransparent
mode

9.6/14.4/19.2/
28.8kbit/s

Transparent

UDI/RDI

56 kbit/s
64 kbit/s

180

X.31 Flag
Stuffing

Synchronous/nontransparent

UDI/RDI

9.6/14.4/19.2/
28.8/38.4/48/5
6kbit/s

V.120

Nontransparent

UDI/RDI

9.6/14.4/19.2/
28.8/38.4/56kb
it/s

Bit Transparent
Mode

Synchronous/transparent

UDI

64 kbit/s

RDI

56 kbit/s

PIAFS

Asynchronous/nontransparent

UDI/RDI

32/64 kbit/s

Frame
Tunneling Mode

Asynchronous/nontransparent

UDI/RDI

9.6/14.4/19.2/
28.8/38.4/43.2
/57.6kbit/s

Multimedia call

Synchronous/transparent

3.1 kHz audio

28.8/33.6
kbit/s

RDI

56 kbit/s

UDI

32/64 kbit/s

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

Short Message Service


Introduction to Short Message
Service
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.

Point-to-point
SMS Processing
Flow

Point-to-point SMS processing flows are divided into three parts:

SM MO processing flow SM
For details, refer to SM MO Processing Flow.

MT processing flow
For details, refer to SM MT Processing Flow.

Transmission of alert messages


For details, refer to Alerting Message Processing Flow.

SM MO Processing Flow
Flow Chart

SM MO processing flow is shown in Figure 130.

Confidential and Proprietary Information of ZTE CORPORATION

181

ZXWN MSCS Technical Description

FIGURE 130 SM MO PROCESSING FLOW

Descriptions of the Flow


1. STEP1
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

182

SM MT processing flow is shown in Figure 131.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 131 SM MT PROCESSING FLOW

Descriptions of the Flow


1. STEP1:
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.

Confidential and Proprietary Information of ZTE CORPORATION

183

ZXWN MSCS Technical Description

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 Both
the HLR and VLR,
MNRF Is Set to 1,
and MCEF in HLR
Ss not Set to 1)

When MNRF in HLR is set to 1 while the MCEF is not set to 1, and
MS is reachable, the MSCS/VLR will send a notification message
to HLR. And HLR will think the SC can send short messages to MS,
and thus sending an alert message to SC. Service flow is shown in
Figure 132.
FIGURE 132 ALERT MESSAGE FLOW (1)

Descriptions of the flow:


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
HLR, the MCEF Is
Set to 1, while
MNRF Is not Set to
1)

MCEF bit exists only in HLR. When MS has available memory capacity, it will automatically send a notification message to MSCS/VLR,
and then MSCS/VLR will send a notification message to HLR. Service flow is shown in Figure 133.
FIGURE 133 ALERT MESSAGE FLOW (2)

Descriptions of the flow:


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.

184

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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 the
MNRF and MCEF in
HLR Are Set to 1)

If both the MNRF and MCEF in HLR are set to 1, when HLR receives
a notification message from MSCS/VLR, HLR only modifies corresponding flag bit. HLR will send an alert message to the SC only
when both flag bits are set to 0.

Supplementary Services
Introduction to Supplementary
Services
Description

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 16.
TABLE 16 UMTS SUPPLEMENTARY SERVICES
No.

Type

Abbreviation

Calling line
identification
presentation

CLIP

Calling line
identification
restriction

CLIR

Connected line
identification
presentation

COLP

Connected line
identification
restriction

COLR

Category

Number
identification

Confidential and Proprietary Information of ZTE CORPORATION

185

ZXWN MSCS Technical Description

No.

Category

Type

Abbreviation

Call forwarding
unconditional

CFU

Call forwarding on
busy

CFB

Call Forwarding on
No Reply

CFNRy

Call forwarding on
mobile subscriber
not reachable

CFNRc

Call waiting

CW

Call Forwarding

9
10

Call completion

HOLD

HOLD

11

Multiparty Service

Multiparty Service

MPTY

12

Closed user group

Closed user group

CUG

Advice of charge
(information)

AOCI

Advice of charge
(charging)

AOCC

15

Barring of All
Outgoing Calls

BAOC

16

Barring of Outgoing
International Calls

BOIC

17

Barring of Outgoing
International Calls
except those
directed to the
home PLMN

BOIC-Exhc

18

Barring of All
Incoming Calls

BAIC

19

Call barring

Barring of Incoming
Calls when Roaming
outside the home
PLMN country

BIC-Roam

20

Explicit call transfer

Explicit call transfer

ECT

21

Call deflection

Call deflection

CD

13
14

Functional blocks

186

Advice of charge

In MSCS, functional blocks involving supplementary services fall


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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

Number Identification Service


Category

Number identification supplementary services include 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
callers 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.

Processing Flow

All processing flows are similar. Here, the processing flow of CLIR
is shown in Figure 134.
FIGURE 134 CLIR FLOW

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.

Confidential and Proprietary Information of ZTE CORPORATION

187

ZXWN MSCS Technical Description

Forwarding Services
Category

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).

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.

Processing Flows
of CFU and CFB

188

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 135.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 135 CFB FLOW

Note:
Note: Or1 means the call is forwarded; Or2 means the forwarded
subscriber is notified; Or3 means the caller is notified.
The flow is described as follows:
1. 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.
2. Step B: If subscriber is busy and no forwarding is performed,
call will be released.
3. 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.

Confidential and Proprietary Information of ZTE CORPORATION

189

ZXWN MSCS Technical Description

Processing Flow
of CFNRY

The processing flow of CFNRY is shown in Figure 136.


FIGURE 136 CFNRY FLOW

Note:
Note: or1 means the call is forwarded; or2 means the forwarded
subscriber is notified; or3 means the caller is notified.
The flow is described as follows:
1. 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.
2. 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.
3. 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.
Processing Flow
of CFNRC

190

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 137.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 137 PROVIDING FORWARDING NUMBER

Note:
Note: Or1 indicates call is forwarded; Or2 indicates to notify caller.
The flow is described as follows (assuming that called subscriber
is subscriber B, and forwarded-to subscriber is subscriber C):
1. 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.
2. 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 Completion Services


Description

Both CW and HOLD services are collectively called the call 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

Confidential and Proprietary Information of ZTE CORPORATION

191

ZXWN MSCS Technical Description

call. Network can only reserve one RAB transmission channel for
each mobile subscriber.
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.
The information processing flow is shown in Figure 138, Figure 139
and Figure 140.
FIGURE 138 CALL WAITING FLOW (1)

FIGURE 139 CALL WAITING FLOW (2)

192

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 140 CALL WAITING FLOW (3)

The flow is described as follows:


1. 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.
2. Status 2: Subscriber B waits for call and is in a state of waiting
for answer.
3. 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.
4. 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.
5. 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.
6. Status 6: Subscriber B is in C-B active status, indicating subscriber only has one active call.
Call Hold

1. Related concepts

Hold request: The subscriber requests the network to interrupt the current call and hold it.
Call termination request: If a call is in holding status, both
caller and called can disconnect this call.
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:

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.

Both parties put each other on hold. For both parties,


this call is on hold.

2. 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 141.

Confidential and Proprietary Information of ZTE CORPORATION

193

ZXWN MSCS Technical Description

FIGURE 141 CALL HOLD FLOW

or1 means the hold request

The flow is described as follows:


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.

MPTY Call
Description

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.

194

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

Related
Operations

1. 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.
2. Manage an activated MPTY
In an activated MPTY, served subscriber can perform the following operations:

Add another external call. Send a MPTY setup indication


to all external calls, and a restoration indication to all held
external calls.
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.
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.
Terminate whole MPTY. When served subscriber is released,
whole MPTY is terminated.
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.


3. Manage an on-hold MPTY
During the period when an MPTY is on hold, served subscriber
can perform the following operations:

Restore the on-hold MPTY to activated status.

Originate a new call.

Process a call waiting request.

Terminate on-hold MPTY, and all of the calls belonging to


this MPTY will be released.
Terminate a certain external call in the MPTY.

In this case, an external call cannot be restored.


4. Manage a single call and an MPTY

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.

Confidential and Proprietary Information of ZTE CORPORATION

195

ZXWN MSCS Technical Description

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.

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.

5. External call party in the MPTY


External call party in MPTY can make following operations:

Set the connection with MPTY to the hold status.

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 142:
FIGURE 142 MPTY CALL PROCESSING FLOW

MPTY call setup:


a) Step 1

196

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

Subscriber UEa sets up two steady calls (an active call


and a held call).
b) 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:


a) Step 1
MPTY is in talking status or hold status.
b) 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
Category

Call barring consists of two types: Barring of incoming call and


outgoing call.

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.

Mobile subscribers at the current PLMN where caller is located.


Fixed telephone network subscribers of the country where
caller is currently located.
Mobile subscribers at the home PLMN of the caller.

Confidential and Proprietary Information of ZTE CORPORATION

197

ZXWN MSCS Technical Description

Instructions of
BOC

Subscribers of fixed telephone network in home country of


the caller.

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.
Processing Flow
of BOC

The information processing flow of BOC is shown in Figure 143.


FIGURE 143 BOC SERVICE FLOW

The flow is described as follows:


1. Step 1
After receiving the call setup request, the MSCS/VLR checks if
there is BOC.
2. 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.

198

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

Category of
Barring of
Incoming Calls
(BIC)

Instructions of
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.

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.
Service Flow of
BIC

The BIC service flow is shown in Figure 144.


FIGURE 144 BIC SERVICE FLOW

The flow is described as follows:


1. 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.
2. 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.

Confidential and Proprietary Information of ZTE CORPORATION

199

ZXWN MSCS Technical Description

CUG
This supplementary service makes multiple users form a CUG.
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 Charge
Advice of charge supplementary service includes the AoCI and
AoCC.
AOCI mean refers to the fact that network provides information for
mobile terminal to calculate basic service communication charges.
AOCC 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 Transfer


Description

Category

Processing Flow

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.
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.

In the following, both calls in steady status are set as an example


to illustrate processing flow of ECT, as shown in Figure 145:
FIGURE 145 ECT PROCESSING

200

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

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
Description

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.

Subscription
Options

Processing Flow

This service provides the following subscription options:

A CAMEL subscriber configures such a subscription option so


that when a call is deflected, calling party can receive the call
deflection notification.

A CAMEL subscriber configures such a subscription so that


when a call is deflected, deflection party can receive CD
service invoking notification.

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.

The CD processing flow is shown in Figure 146.


FIGURE 146 CD PROCESSING

Confidential and Proprietary Information of ZTE CORPORATION

201

ZXWN MSCS Technical Description

1. 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).
2. 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.

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 subscribers 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 147.

202

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 147 REGISTER OPERATION FLOW

Flow is described as follows:


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 148.
FIGURE 148 ERASE OPERATION FLOW

Flow is described as follows:


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.

Confidential and Proprietary Information of ZTE CORPORATION

203

ZXWN MSCS Technical Description

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 149.
FIGURE 149 ACTIVATION OPERATION FLOW

Flow is described as follows:


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

204

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
150.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 5 Basic Services

FIGURE 150 INTERROGATE OPERATION FLOW

Flow is described as follows:


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 Password

Register password operation only serves call barring 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 151.
FIGURE 151 REGISTER PASSWORD FLOW

Flow is described as follows:


1. Step A: UE sends a register password request to MSCS/VLR.
Then the MSCS/VLR sends a MAP_REGISTER_PASSWORD
message to HLR.

Confidential and Proprietary Information of ZTE CORPORATION

205

ZXWN MSCS Technical Description

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 UEs password from
MSCS/VLR.
4. Step D: HLR sends request to get subscribers password (subscribers new password) to MSCS/VLR.
5. Step E: HLR receives response to get subscribers password
from MSCS/VLR.
6. Step F: HLR sends request to get subscribers password (subscribers new password) to MSCS/VLR.
7. Step G: HLR receives response to get subscribers password
from MSCS/VLR.
8. Step H: HLR returns answer message MAP_REGISTER_PASSWORD_rsp to VLR.
Get Password

206

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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter

Special Functions
Table of Contents
Intelligent Service ........................................................... 207
Interception Services ....................................................... 241
Location Service .............................................................. 249
Interworking Services between the IMS and the
CS/PSTN ........................................................................ 258
Function of Detecting and Restricting Cheaters .................... 263
Rerouting Function .......................................................... 270
Region System Function ................................................... 270
Dual-homing Disaster Recovery Function ............................ 272
Traffic and Load Control Function ....................................... 275
R2 Function .................................................................... 278
Roaming Pool Function ..................................................... 280
Multi-EIR Function ........................................................... 281
M2PA Networking Function................................................ 281
Dynamically Selecting Routes Based on Load of IP Bearer Network and QoS ................................................................. 283
Bidirectional Forwarding Detection Function ........................ 283
Compatibility Function with 2G .......................................... 284
Iu_CS over IPV6 Function ................................................. 293
NITZ Function ................................................................. 293
Link Breaking Function of Iu Interface ................................ 294
SCUDIF Call Function ....................................................... 294
VMGW Function............................................................... 295
Multi-IP-domain Function.................................................. 296
Enhanced IMEI Check Function.......................................... 298
Rf Offline Billing Function.................................................. 299
EPLMN Expansion Function ............................................... 302

Intelligent Service
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 (NISDN), 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.

Confidential and Proprietary Information of ZTE CORPORATION

207

ZXWN MSCS Technical Description

Applications

Structure of application fields of IN is shown in Figure 152.


FIGURE 152 APPLICATION FIELDS OF IN

Architecture and
Functions

IN is the nerve center of telecom networks. INCM (Intelligent


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
Layer

Name

Oriented Objects

Handling Objects

Service user

Structure

208

Service Plane (SP)

Network carrier

SF/service

Global Function
Plane (GFP)

Service designer

SIB/GFL

Distributed
Function Plane
(DFP)

Software
developer

FEA/FE

Physical Plane
(PHP)

Equipment
manufacturer

PE/INAP/CAP

INCM structure is shown in Figure 153.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

FIGURE 153 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

Confidential and Proprietary Information of ZTE CORPORATION

209

ZXWN MSCS Technical Description

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 and
Advantages

210

CAMEL (Customized Applications for Mobile Network Enhanced


Logic) is the expansion and development of IN in terms of 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

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 Structure

According to the description of the CAMEL functional structure in


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 154 .

Confidential and Proprietary Information of ZTE CORPORATION

211

ZXWN MSCS Technical Description

FIGURE 154 BLOCK DIAGRAM 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.

212

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 subscribers
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 transregional 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.

Confidential and Proprietary Information of ZTE CORPORATION

213

ZXWN MSCS Technical Description

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.

214

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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


BCSM
By means of advanced finite state mechanism, BCSM describes
actions necessary for CCF to set up and maintain communication
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,

Confidential and Proprietary Information of ZTE CORPORATION

215

ZXWN MSCS Technical Description

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 155 shows O-BCSM.
FIGURE 155 O-BCSM

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.

216

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

TABLE 18 DESCRIPTION OF DPS IN THE O-BCSM


CAMEL DP

DP TYPE

Description

DPCollected_Info

TDP-R

Indicates that the O-CSI is


analyzed

DPAnalysed_Information

TDP-R (note2)

Indicates that the routing


address and address
attributes are available

DPRoute_Select_Failure

TDP-R (note3),
EDP-N, EDP-R

Indicates that the call


establishment fails

DPO_Busy

EDP-N, EDP-R

Indicates that

DPO_No_Answer

EDP-N, EDP-R

A busy signal is received


from the terminating
party.

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.

An unanswered event is
received in CAUSE IE of
the ISUP REL message

DPO_Answer

EDP-N, EDP-R

Indicates that the call is


accepted and answered by
the terminating party

DPO_Disconnect

EDP-N, EDP-R

Indicates that a disconnect


indication is received from
the terminating or the
originating party

DPO_Abandon

EDP-N, EDP-R

Indicates that a disconnect


indication is received from
the originating party during
the call establishment
procedure

Note:
i.

These DPs are defined in ITU-T Recommendation Q.1224.

ii. For TDP-R Analysed_Information, a new relation to the


gsmSCF will be set up.
iii. 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.

Confidential and Proprietary Information of ZTE CORPORATION

217

ZXWN MSCS Technical Description

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.

218

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 156.
FIGURE 156 T-BCSM

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.

Confidential and Proprietary Information of ZTE CORPORATION

219

ZXWN MSCS Technical Description

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)
CAMEL DP

DP TYPE

Description

DPTerminating_Attempt_Authorised

TDP-R

Indicates that T-CSI/VT_CSI


is analyzed
Indicates that

DPT_Busy

A busy indication is
received from the
termination switch.

A busy event is received


in the VMSC.

An unreachable failure
event is received from
the CAUSE IE or HLR
response of the ISUP REL
message

TDP-R
(note2),
EDP-N,
EDP-R

Indicates that

An application timer
related to O_No_Answer
DP expires.

An unanswered event is
received in CAUSE IE of
the ISUP REL message

DPT_No_Answer

TDP-R
(note2),
EDP-N,
EDP-R

DPT_Answer

EDP-N,
EDP-R

Indicates that the call is


accepted and answered by
the terminating party

EDP-N,
EDP-R

Indicates that A disconnect


indication is received from the
terminating or the originating
party

EDP-N,
EDP-R

Indicates that A disconnect


indication is received from the
originating party during the
call establishment procedure

DPT_Disconnect

DPT_Abandon

Note:
i.

These DPs are defined in ITU-T Recommendation Q.1224.

ii. 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.

220

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 nonbasic 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.

Confidential and Proprietary Information of ZTE CORPORATION

221

ZXWN MSCS Technical Description

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 Legend


This part will describe how BCSM is embodied in UMTS. 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 is shown in
Figure 157.
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 157. Subsequently
gsmSCF controls or monitors this call service handling at individual DPs according to service logic requirements.

222

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

FIGURE 157 ORIGINATING BCSM OF MOBILE SUBSCRIBER

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 is shown in
Figure 158.
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 159. 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 160.
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.

Confidential and Proprietary Information of ZTE CORPORATION

223

ZXWN MSCS Technical Description

FIGURE 158 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 159 and Figure 160.
FIGURE 159 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.

224

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

FIGURE 160 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 160) 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 DP Criteria


According to BCSM, an event detection point (DP) is the key to
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,

Confidential and Proprietary Information of ZTE CORPORATION

225

ZXWN MSCS Technical Description

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 Encountered

DP4

DP5

DP6

DP7

DP4 Route_S
elect_Failure

DP5 O_Busy

DP6 O_No_A
nswer

DP7
O_Answer

DP9 O_Disco
nnect Leg1

226

Confidential and Proprietary Information of ZTE CORPORATION

DP9
Leg1

DP9
Leg2

DP1
0

X
X

Chapter 6 Special Functions

Implying DPs to be Disarmed


DP Encountered

DP4

DP5

DP6

DP7

DP9 O_Disco
nnect Leg2

DP9
Leg1

DP9
Leg2

DP1
0

DP10 O_Aba
ndon

DP disarming relations in the T-BCSM are shown in Table 21.


TABLE 21 DP DISARMING RELATIONS IN THE T-BCSM
Implying DPs to be Disarmed
DP Encountered

DP 13

DP 14

DP 15

DP13
T_Busy

DP14 T_No_
Answer

DP15
T_Answer

DP17 T_Disc
onnect Leg1
DP17 T_Disc
onnect Leg2
DP18 T_Aba
ndon

DP 17
Leg1

DP 17
Leg2

X
X

DP
18

X
X

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 trig-

Confidential and Proprietary Information of ZTE CORPORATION

227

ZXWN MSCS Technical Description

gering 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 Call Processing Flows


1. Basic call processing
This part introduces the traditional basic call processing flow
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.

228

MO processing flow of the basic call in the UMTS is shown


in Figure 161.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

FIGURE 161 MO PROCESSING FLOW OF THE BASIC CALL IN THE


UMTS

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 (SSBAOC). 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 at-

Confidential and Proprietary Information of ZTE CORPORATION

229

ZXWN MSCS Technical Description

tributes 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 162.
FIGURE 162 ROUTE PROCESSING FLOW OF THE BASIC CALL IN THE
UMTS

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

230

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 subscribers 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


163.

Confidential and Proprietary Information of ZTE CORPORATION

231

ZXWN MSCS Technical Description

FIGURE 163 MT PROCESSING FLOW OF BASIC CALLS IN THE UMTS

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

232

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 164.

Confidential and Proprietary Information of ZTE CORPORATION

233

ZXWN MSCS Technical Description

FIGURE 164 MO FLOW OF MPPS

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, callers ISDN number,

234

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

callers IMSI, callers 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 callers account immediately after receiving
IDP message. If account is valid, SCP will determine callers
charging rate according to area code (Location Number in
IDP) of callers 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 subscribers 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 in-

Confidential and Proprietary Information of ZTE CORPORATION

235

ZXWN MSCS Technical Description

struction. 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 subscribers 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 165.


FIGURE 165 ROUTING FLOW OF THE MPPS

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 subscribers 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.

236

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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, callers ISDN number, callers IMSI,
callers 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 re-

Confidential and Proprietary Information of ZTE CORPORATION

237

ZXWN MSCS Technical Description

ceiving 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, informing SSF of the Disconnect event and waiting for its
instruction. Since SCP has configured DP17, 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 SCP. SCP calculates actual call charge
based on ACR contents, and deducts them from the subscribers 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 166.


FIGURE 166 CALLED SERVICE FLOW OF MPPS

As mentioned in MT call flow, mobile terminating office receives IAM message that contains MSRN temporarily allo-

238

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

cated 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, callers ISDN
number, callers IMSI, callers 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.

Confidential and Proprietary Information of ZTE CORPORATION

239

ZXWN MSCS Technical Description

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,
informing SSF of the Disconnect event and waiting for
its instruction.
Since SCP has configured the DP17,
SSF is responsible for reporting charging result ApplyChargingReport and on-hook event of subscribers
(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 subscribers 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.

240

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Interception Services
Introduction to Interception Services
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.

Specification

Different countries have different requirements for interception


services, so the specifications may be different. ZXWN supports
the following interception specifications:

China 2G Interception

China 3G Interception

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.
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 167 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 167 NETWORK MODE ADOPTING DT LINK

Confidential and Proprietary Information of ZTE CORPORATION

241

ZXWN MSCS Technical Description

Networking mode adopting SPB link


Figure 168 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 168 NETWORK MODE ADOPTING SPB LINK

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

PC with Windows Operating System


running on it.

Network card

Installed on interception server.

USI

Used together with the old USI.

SMP

It is recommended to use separate


interception module.

China 2G Interception
Functions

242

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.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Connection
Schematic
Diagram

Connection relationship between Lawful Information Center (LIC)


and other NEs of cellular network is shown in Figure 169.
FIGURE 169 CONNECTION BETWEEN LIC AND NETWORK ELEMENTS

Interface
Description

Functions for the three interfaces of China 2G interception are as


follows:

IF1 interface is used to input and respond to operation commands, and input and output data includes:

Connection and release requests of IF1 interface

Authentication on LIC access

Authentication on operation commands of the interface

Input operation commands for interface

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:

Output the activity reports of the controlled MS


Output short messages sent and received by the controlled
MS
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:

Establish signal connection to different type of terminals


(including LIC, MS and fixed phone)

Confidential and Proprietary Information of ZTE CORPORATION

243

ZXWN MSCS Technical Description

Networking Mode
and Hardware
Requirements

Output call contents of controlled MS

Output fax contents of controlled MS

Output data communication contents of controlled MS

Output mapping ID corresponding to IF2 interface report

Networking mode adopted by ZXWN MSCS for implementing China


2G Interception is shown in Figure 167 and Figure 168, and required hardware is shown in Table 22.

China 3G Interception
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
Description

Schematic diagram of lawful interface in the WCDMA mobile network is shown in Figure 170.
FIGURE 170 SCHEMATIC 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.

244

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Connection
Schematic
Diagram

Connection relationship between LIC and NEs is shown in Figure


171.
FIGURE 171 CONNECTION BETWEEN LIC AND NES

Functions and
Protocol of the
Interface

Functions and interface protocol for X1, X2 and X3 interfaces are


shown in Table 23.
TABLE 23 FUNCTIONS OF CHINA 3G INTERCEPTION INTERFACES
Interface

Functions

Protocol

X1 Interface

Used to establish the


connection.

From the physical side, X1


interface can adopt existing
common man-machine
communication control
interface, but it must have
high speed and reliability.
Interface should adopt
TCP/IP, and its work protocol
stack is ISO/IEC 802.2 and
ISO/IEC 802.3.

Used to release the


connection.
Used to set the
controlled target.
Used to modify the
controlled target.
Used to cancel the
controlled target.
Used to query the
information of target.

Lawful interface between one


LIC and one TNE has only
one X1 interface, only one
X1 connection and one TCP
connection for bearing X1
connection.

Used to query the


parameters of the
controlled target

Confidential and Proprietary Information of ZTE CORPORATION

245

ZXWN MSCS Technical Description

Interface

Functions

Protocol

Used to display the


controlled targets.
Used to query time of
the NE.
Used to locate position
of the target.

Networking Mode
and Hardware
Requirements

X2 interface

X2 interface is used to
report the activities of
subscriber, including
power-on, ringing and
DTMF, messages, and
alarm information.

From the physical


side, X2 interface can
adopt the existing
common man-machine
communication control
interface, but interface
must have high speed and
reliability. Interface should
adopt TCP/IP, and its work
protocol stack is TCP/IP
ISO/IEC 802.2 and ISO/IEC
802.3.

X3 interface

X3 interface is used
to implement bearer
establishment, and
output contents of
the calls and data
communication and
their associated IDs.

Physical interface between


X3 interface and LIC is
2048 Kbits/s (with 155
Mbits/s being optional)
digital interface, and
interface parameters should
accord with the GB7611-87
Specification. Signal mode
of the digital interface should
be ISUP mode of No.7 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.

Networking mode adopted by ZXWN MSCS for implementing China


3G Interception is shown in Figure 167 and Figure 168, and required hardware is shown in Table 22.

ETSI Interception
Overview

246

The LIC of ESTI Interception is connected with the MSCS through


the H1 and H2 interfaces, while it is connected with the MGW
through the H3 interface. The H1 interface is mainly used to set
interception task. The H2 interface is mainly used to report the
events of monitored object to interception center, such as location
update of subscriber. The H3 interface is mainly used to report
service data of monitored object to interception center, such as
call contents.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Connection
Schematic
Diagram

The connection schematic diagram for the ETSI interception service is shown in Figure 172.
FIGURE 172 CONNECTION SCHEMATIC DIAGRAM FOR ETSI INTERCEPTION
SERVICE

Networking Mode
and Hardware
Requirements

Networking mode adopted by ZXWN MSCS for implementing ETSI


Interception is shown in Figure 167 and Figure 168, and required
hardware is shown in Table 22.

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.

Confidential and Proprietary Information of ZTE CORPORATION

247

ZXWN MSCS Technical Description

Connection
Schematic
Diagram

Connection
Relationship
Description

Hardware
Requirements

Structure of Russia Interception system is shown in Figure 173.


FIGURE 173 RUSSIA INTERCEPTION SERVICE

Interception center only provides E1 lines that are connected


to MGW. Slots 30 and 31 on PCM are specified to transfer the
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.

Table 24 shows the hardware required for ZXWN MSCS to implement Russia Interception service.
TABLE 24 HARDWARE REQUIRED FOR RUSSIA INTERCEPTION SERVICE

248

Name

Quantity

Remarks

PC

PC with Windows OS running


on it.

Network card

Installed on the interception


server.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Name

Quantity

Remarks

X.25 card (eicon


c91)

Installed on the interception


server.

Modem (tailnet
T288C)

S20

USI

Used together with old USI.

SMP

It is recommended to
use separate interception
module.

Location Service
Introduction to the Location Service
Overview

The Location Services (LCS) is a kind of standardized processing


capability to facilitate developing the location-based services on
the network. The LCS service can get the geographic location information of the MS at a certain moment and the information accuracy through the interaction among the LCS client, LCS server,
and the target MS. Under the support of the electronic map platform, the LCS service is one of value-added services providing the
corresponding service for the subscribers.
The great charm of the location-based service is to send the correct information to the correct person at the correct time and correct place. The locationbased services enable to develop various applications, such as the information service application (such
as the nearby service, mobile yellow pages, and traffic information), the game application (such as the Positional Fighting, and
the Sharp-shooter), the industry application (such as the physical
distribution, public security, fire protection, and transportation),
and the track and navigation. As a relatively service, the LCS service is a characteristic service on the mobile network with great
commercial value and variety.
Due to the improved locating accuracy and its open system structure, the LCS, with its conspicuous attraction, is possibly regarded
as the representative application in the 3G field.

Functions

ZXWN MSCS supports the following functions:

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.

MS-originated location request (MO-LR)

Confidential and Proprietary Information of ZTE CORPORATION

249

ZXWN MSCS Technical Description

MS originates the location request to the network.

Network initiated location request (NI-LR)


Network can initiate a request for an MSs location at any time
if necessary, for example, during an emergent call to MS.

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.

Location Service Flow


MS-Terminated Location Request
Flow Chart

As shown in Figure 174, external LCS Client originates locating


request, assuming that target MS passes IMSI or MSISDN verification.
FIGURE 174 MS-TERMINATED LOCATION REQUEST (MT-LR)

Descriptions of the Flow


1. Step 1
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

250

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 MSs
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,
MSs 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

Confidential and Proprietary Information of ZTE CORPORATION

251

ZXWN MSCS Technical Description

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

252

Location request processing originated by MS (MO-LR) is shown in


Figure 175.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

FIGURE 175 MS-ORIGINATED LOCATION REQUEST (MO-LR)

Descriptions of the Flow


1. Step 1
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.

Confidential and Proprietary Information of ZTE CORPORATION

253

ZXWN MSCS Technical Description

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 176.
FIGURE 176 NETWORK-INITIATED LOCATION REQUEST (NI-LR)

Descriptions of the Flow


1. Step 1

254

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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.

Confidential and Proprietary Information of ZTE CORPORATION

255

ZXWN MSCS Technical Description

Deferred MS-Terminated Location Request


Flow Chart

Process of deferred MS-terminated location request (DEFEREDMT-LR) is shown in Figure 177.


FIGURE 177 DEFERRED MS-TERMINATED LOCATION REQUEST
(DEFERED-MT-LR)

Descriptions of the Flow


1. Step 1
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 MSs 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

256

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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

Confidential and Proprietary Information of ZTE CORPORATION

257

ZXWN MSCS Technical Description

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.

Interworking Services
between the IMS and the
CS/PSTN
Introduction to Interworking Services
between the IMS and the CS/PSTN
Description

Functions

258

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.
The specific functions include:

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

The terminal subscriber in the IMS domain calls the subscriber


in the CS domain/PSTN.

The subscriber in the CS domain/PSTN calls 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 178.

Confidential and Proprietary Information of ZTE CORPORATION

259

ZXWN MSCS Technical Description

FIGURE 178 FLOW CHART OF THE TERMINAL SUBSCRIBER IN THE IMS


DOMAIN CALLING THE SUBSCRIBER IN THE CS DOMAIN/PSTN

Flow Description

The flow is described as follows:


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.

260

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 179.

Confidential and Proprietary Information of ZTE CORPORATION

261

ZXWN MSCS Technical Description

FIGURE 179 FLOW CHART OF THE SUBSCRIBER IN THE CS DOMAIN/PSTN


CALLING THE TERMINAL SUBSCRIBER IN THE IMS DOMAIN

Flow Description

The flow is described as follows:


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;

262

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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
Introduction to Detecting and
Restricting Cheaters
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
Implementation

MSC Server generates the call attempt CDR, the billing server 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

Confidential and Proprietary Information of ZTE CORPORATION

263

ZXWN MSCS Technical Description

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 180.
FIGURE 180 FLOWCHART OF DETECTING CHEATERS AND PERFORMING
SERVICE RESTRICTION

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:

264

Sorts call attempt CDRs. For the details, refer to Sorting Call
Attempt CDR.

Sorts SM CDRs. For the details, refer to Sorting SM CDRs.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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
Implementation

In the MOC, MTC, MCF, GATE, TRUNK and TRANSIT CDR 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 181.

Confidential and Proprietary Information of ZTE CORPORATION

265

ZXWN MSCS Technical Description

FIGURE 181 FLOWCHART OF 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

266

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

called party, and start performing billing on the calling party. The
processing flowchart is shown in Figure 182.
FIGURE 182 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


Restricting Cheaters
MSC Server can periodically enable the function of restricting
cheaters according to the configured intervals. Three intervals
can be configured.

Confidential and Proprietary Information of ZTE CORPORATION

267

ZXWN MSCS Technical Description

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

Judging Cheaters
Based on Calls

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.
For the voice call, the following fields are provided:

The number of call-attempts per unit time (the minimum 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

268

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

at the same time, and the number of call attempts of a single card
is not high).
Judging Cheaters
Based on SMs

For the SMS, at least the following fields are provided:

The number of MO SMs per unit time (the minimum statistics


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

Confidential and Proprietary Information of ZTE CORPORATION

269

ZXWN MSCS Technical Description

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
Implementation

There are multiple routes between the source switch and the terminal switch. When one route is faulty or congested (for example,
in Figure 183, 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 183.
FIGURE 183 ARR FUNCTION

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

270

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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
Diagram

The networking mode is shown in Figure 184.


FIGURE 184 REGION-SYSTEM NETWORKING MODE

Implementation
Method

For the virtual MSC function, the system architecture of the background system is shown in Figure 185.
FIGURE 185 NETWORKING RESOURCE PARTITION OF THE REGION SYSTEM

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.

Confidential and Proprietary Information of ZTE CORPORATION

271

ZXWN MSCS Technical Description

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
Description

272

Application of 1+1 active/standby mode


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 186.

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

FIGURE 186 1+1 ACTIVE/STANDBY-MODE NETWORKING

In Figure 186, 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 187.

Confidential and Proprietary Information of ZTE CORPORATION

273

ZXWN MSCS Technical Description

FIGURE 187 1+1 MUTUAL-BACKUP-MODE NETWORKING

In Figure 187, 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 188.
FIGURE 188 N+1 ACTIVE/STANDBY-MODE NETWORKING

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


work in the N+1 active/standby mode (where N2), 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

274

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 189.
FIGURE 189 N+1 MUTUAL-BACKUP-MODE NETWORKING

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


work in the N+1 mutual-backup mode (where N2), 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.

Traffic and Load Control


Function
Flexible Traffic Control Function
Flexible traffic control is responsible for analyzing traffic statistical data and equipment running status, manually or automatically
setting the corresponding traffic control instructions on the background under the predefined conditions or regulations, and transmitting data to the foreground. The foreground implements the
traffic control according to traffic control instructions, to dredge
normal traffic effectively and alleviate the impact of excess traffic
on the network.

Confidential and Proprietary Information of ZTE CORPORATION

275

ZXWN MSCS Technical Description

Load Control Concept


Concept

When unexpected strong traffic abruptly occurs, load control is responsible for discarding partial traffic beyond the system processing capability so as to avoid the breakdown of modules or even
entire system. By reducing the system load, the system can run
safely and stably to protect the services from interruption.

Category

Based on different load types, the load control functions of ZXWN


MSCS are as follows.

Control
Mechanism

Service control (based on service traffic)

Congestion control

Figure 190 shows the control mechanisms of the MSCS. Five control mechanisms (including Traffic control (total), traffic control
(single), MP congestion control, singleservice traffic control, and
other NE congestion control) are all running on the CMP. The link
congestion control mechanism is running on the SMP. Because
there is no service running on the OMP, the OMP is not responsible for load control.
FIGURE 190 MSCS LOAD CONTROL MECHANISM

Service Control
Overview

Service control (based on traffic control) is a process of controlling


the service overload condition during the service cycle. It is implemented by setting the traffic allowed within a time unit. By dividing
the entire running duration of the system into several equivalent
time slices, one time slice is the service cycle.
Service overload means that the number of service processing
units exceeds a fixed threshold in a time unit (or a service cycle). This threshold is calculated synthetically based on fixed traffic model with reference to the office capacity configuration of the
system . Service control is mainly used to ensure the system stability of the CN when it suffers from abrupt and large capacity
service traffic.

Incoming Service
Control

It specifies the total service traffic allowed within a service cycle


(two seconds). You may set this service cycle as required. This
method can ensure the security of the MSCS.

276

Traffic control (total)

Traffic control (single)

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Due to the total traffic control, services may borrow resources


mutually. To ensure that some abrupt service will not bring
great influence on other services (for example, abrupt short
messages may affect call service). You may set the passing
times per second of different services. Passing times of single
service Equivalent CPU consumption of each service Total
CPU resources of total traffic control.
Outgoing Service
Control

Single service traffic control


It provides a method to control the times of a single service going
to the HLR, SMC and SCP to alleviate the impact of abrupt traffic
to other NEs. This method can not only control the times of services going to the HLR, SMC and SCP, but also control the times of
services going to a specific target based on the GT configuration.
The purpose of this method is to protect other NEs.

Congestion Control
Overview
Incoming
Congestion
Control

Congestion control includes incoming congestion control and outgoing congestion control.

CMP congestion control


When the CMP is congested, the system will restrict the accessed services.

Link congestion control


The incoming link congestion control is to restrict the accessed
services when the SMP is congested so as to alleviate the congestion conditions of the SMP. It mainly controls the CR messages at the A/Iu interface and the TC_BEGIN_REQ messages
at the TCAP.

Outgoing
Congestion
Control

Congestion control of other NEs


When the system finds that other NE is congested, it will control
the services to this NE.

Link congestion control


The outgoing link congestion control is to release the overload
condition of outgoing associations and links. It contains the
congestion control under the conditions of SMP overload and
association/link overload.

Application Description of Traffic and


Load Control
The traffic is unbalanced during the running of the network, especially in different periods of time. For example, at the peak
traffic on holidays, heavy traffic takes place on the office with relatively large capacity and higher network position, such as the
exchange with large capacity, gateway exchange, and tandem exchange. During this period, the exchange load is much heavier
than that at ordinary time, accompanied with high CPU occupancy
and a large number of CDRs. With extremely heavy traffic, the
traffic overflow and congestion may occur. To ensure safe and

Confidential and Proprietary Information of ZTE CORPORATION

277

ZXWN MSCS Technical Description

stable running of the system and smooth communication of the


network when heavy traffic occurs, the necessary traffic control
and load control should be implemented based on the actual condition of each exchange so as to dredge the traffic equitably.
Traffic and load control are widely adopted to prevent the impact
of heavy traffic on holidays. Two control methods can protect the
safe running of the system effectively when heavy traffic occurs.
The difference lies in that the traffic control aims to bring the processing capability of the network into full play, put through, and
dredge the traffic under the basic condition of protecting the equipment safety. While the load control aims to control the system load
under the impact of large traffic so as to protect the system safety.

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 Mode

The supported networking mode at present is shown in Figure 191.


The straight line between NEs indicates R2 signaling.
FIGURE 191 NETWORKING MODE

Implementation
Description

278

Same with the CCS ISUP and TUP, the CAS R2 is a kind of inter-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).

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 enbloc 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.

Confidential and Proprietary Information of ZTE CORPORATION

279

ZXWN MSCS Technical Description

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.

Implementation
Method

When configuring the MSRN load, MSRN number sections can be


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

280

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

subsystem needs to request the module configured with common


MSRNs to release the common MSRN.

Multi-EIR Function
Overview
Networking Mode

The ZXWN MSCS adopts the EIR mutual-aid networking mode, and
each virtual MSC supports multiple (at most 255) EIRs configured.
The networking mode is shown in Figure 192.
FIGURE 192 MULTI-EIR NETWORKING MODE

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

Confidential and Proprietary Information of ZTE CORPORATION

281

ZXWN MSCS Technical Description

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 Mode

The networking diagram is shown in Figure 193. In this networking mode, the M2PA protocol is adopted between MSC-Servers, or
between the MSC-Server and the MGW.
FIGURE 193 M2PA NETWORKING MODE

Implementation
Method

The structure of the SCN signaling transferring on the IP 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 194. 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 194 ADAPTATION MODEL

282

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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
Implementation

1. The system or operator originates a test call, and performs QoS


audit on the IP bearer network for the test call.
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

IP networks were not designed to repair failures in sub-second


intervals, but applications such as VoIP increasingly are driving the
need for rapid failure detection and correction. Traditional routing
infrastructure has been limited in meeting the failure-resolution
requirements of real-time applications such as voice. It is very
important to avoid long-time interruption in the routing network.
If the IP network supports voice, video, dedicated line, ATM or
other high-value applications, it is very necessary to shorten the
fault clearance time to within 1s.
A new protocol, Bidirectional Forwarding Detection (BFD), is helping to overcome these limitations and increase the speed of failure
detection and recovery. As an IETF draft standard, BFD 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. In other words, it can detect
errors in the forwarding path in a very short time, and trigger the
switchover to standby route, interface, or even the whole network.

BFD is sufficiently abstracted from underlying transport technologies so that it can detect failures at many layers. It can be
used to monitor the validity of Ethernet networks, Multi-protocol Label Switching (MPLS) label-switched paths, Generic Routing Encapsulation or IPSec tunnels, or virtually any other type
of transport.

At its heart, BFD is a high-speed stand-alone hello protocol


(similar to those used in routing protocols such as Open Shortest Path First or Intermediate System-to-Intermediate System

Confidential and Proprietary Information of ZTE CORPORATION

283

ZXWN MSCS Technical Description

that can be associated with a link, interface, tunnel, route or


other network forwarding component).

Function
Implementation

BFD neighbor systems negotiate a peer relationship, and each


monitors the flow of BFD packets coming from the other systems at the negotiated rate. This can be specified in sub-millisecond increments. When a peer system misses receipt of
a certain preconfigured number of packets, it infers the failure of the BFD-protected software or hardware infrastructure,
whether it be a label-switched path, a tunnel of some other
type or a switched Ethernet network.

BFD is implemented in the control plane of routers and other


systems. A network failure detected by BFD can be corrected
by the forwarding plane (for instance, in MPLS fast reroute), or
by the control plane (for example, when BFD is used to speed
up the operation of routing protocols).

When the softswitch equipment accesses the IP bearer network, or


when the softswitch equipment is interconnected with each 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 195.
FIGURE 195 TYPICAL NETWORKING DIAGRAM OF BFD

Compatibility Function with


2G
The ZXWN MSCS system provides the following compatibility functions with 2G:

284

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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 variable control. For details, refer
to Restricting the Number of USSD Dialogs through Variable;

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 196.

Confidential and Proprietary Information of ZTE CORPORATION

285

ZXWN MSCS Technical Description

FIGURE 196 GRADING ACCESS BASED ON HALF RATE

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
Grading Access
Based on Half
Rate

During the grading access based on half rate, the MSCS has the
following functions:
1. A new status parameter is set in the MSCS to control 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
Standard

For the related specifications of the grading access based on half


rate, refer to Chapter 2 in China Mobile GS M Target Network Upgrade Project-Radio Access Part (v7.0).

Features of
Grading Access of
the Whole System

After implementing the grading access function and the grading


access based on half rate, the grading access of the whole system
has the following features:

286

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 re-

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

source 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
The IMSI number can be distinguished as local number, national
roaming number, or international roaming number through the
system configuration. UE authentication can be performed according to the roaming attribute through variable control. In this
way, operators can flexibly control whether some subscribers encounter UE authentication. 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 variable control. 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 197.

Confidential and Proprietary Information of ZTE CORPORATION

287

ZXWN MSCS Technical Description

FIGURE 197 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
shown in Figure 198.

288

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

FIGURE 198 JUDGING THE TYPE OF AN INCOMING CALL ACCORDING TO THE


FOCIN INFORMATION 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.

Implementation
Method

The essence of this function is grading of subscribers. Different


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.

Confidential and Proprietary Information of ZTE CORPORATION

289

ZXWN MSCS Technical Description

The schematic diagram of PSTN subscribers accessing EGSM is


shown in Figure 199.
FIGURE 199 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 (variable control) 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.

290

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

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
200.
FIGURE 200 FLOWCHART OF ADJUSTING SEPARATE IP ADDRESSES

Restricting the Number of USSD


Dialogs through Variable Control
Overview

The threshold number of USSD dialog IDs is controlled through


variable control. 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 USSD
in 2G

The USSD dialog ID restriction level is divided into level 1, 2, and


3, with level 3 as the default value.
Where,

Definition of USSD
in 3G

1: USSD restriction level 1, 1500 dialogs.

2: USSD restriction level 2, 800 dialogs.

3: USSD restriction level 3, 300 dialogs.

The maximum number of dialogs in 3G is 7500, which is used by


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.
The flow of USSD service load control initiated by the HLR is shown
in Figure 201.

Confidential and Proprietary Information of ZTE CORPORATION

291

ZXWN MSCS Technical Description

FIGURE 201 FLOW OF USSD SERVICE LOAD CONTROL INITIATED BY THE


HLR

The flow of USSD service load control initiated by the local office
is shown in Figure 202.
FIGURE 202 FLOW OF USSD SERVICE LOAD CONTROL INITIATED BY THE
LOCAL OFFICE

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.

292

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Iu_CS over IPV6 Function


In R4, the bearer mode of the interface (Iu interface) between
the CN and the RNC is ATM. In 3GPP R5 or later reversions, it is
specified that the bearer mode of the Iu interface can be ATM or
IP. With the popularity of the IP network, IP bearer will play more
and more important roles. The future UMTS network will be an
all-IP network. From the aspect of operators, using IP bearer can
save costs, compared with using ATM bearer. ZXWN can support
IP bearer mode (including IPV4 and IPV6) of Iu, Mc, Nc, and Nb
interfaces. The MSCS can be connected with NEs of different IP
versions. If some of MGWs carried by the local MSCS support IPV6,
the MSCS can only select IPV4 to be connected with other offices
because it cannot be confirmed which MGW the RTP bearer selects.
If it is configured that IPV6 is supported in the adjacent office node
configuration of the MSCS, the MSCS considers that the peer-end
office supports IPV6, and it is connected with the peer-end office
over IPV6.

NITZ Function
Description

The NITZ function is initiated by the VLR to notify subscribers of


the following information:

Network identity

Summer time

Time and timezone

The NITZ function sends the network identity, time/timezone and


other information to the UE through the Iu/A/Gs interface, facilitating roaming of subscribers. The involved NEs include VLR, MSC,
SGSN, BSC, and RNC.
Principle
Description

In the system, the VLR is the core of judging whether to sending


the NITZ information. It is required to perform analysis according
to the configuration and subscriber access condition. If it is required to send the NITZ information, the VLR still needs to decide
whether to send it through the Gs interface or Iu/A interface.
In the following five cases, it is required to send the NITZ information:

The UE logs in the network for the first time.

The UE moves to another timezone.

The network timezone changes.

The network identity changes.

The UE initiates an access procedure.

When the VLR makes judgement, it should be noted that the above
five cases of sending the NITZ information are not mutually exclusive. In fact, they usually overlap or even contain each other. For
example, between "The UE logs in the network for the first time"
and "The network changes its identity", if the operator configures
the condition to "The network changes its identity", all UEs will re-

Confidential and Proprietary Information of ZTE CORPORATION

293

ZXWN MSCS Technical Description

ceive a MM INFORMATION message after logging in the network


for the first time. After the network identity changes, if the operator configures the condition to "The UE logs in the network for the
first time", the UE will receive a MM INFORMATION message after
logging in the network for the first time even if the condition "The
UE logs in the network for the first time" is not configured.

Link Breaking Function of Iu


Interface
Description

When one RNC accesses the CN through two or more MGWs, and
when the Iu-interface bearer of one MGW is interrupted or the
ALCAP signaling point is inaccessible, the MGW sends a notification
to the MSCS, and the services from the RNC access the CN through
other MGWs. Thus the reliability of the network is improved.

Implementation
Principle

1. The ATM address of the RNC is configured on the MSC Server.


When the MGW is registered, H248S of the MSC Sever automatically deliveries the ATM address of the RNC through the
Modify message to the MGW.
2. The MGW monitors the Iu interface of this RNC. When the ATM
address of the RNC changes or the topology relationship between the RNC and the MGW changes, the MSC Server deliveries the final ATM address to the MGW. At this time, the MGW
reports the related information of the RNC whose ATM address
is matched to the MSC Server through the Notify message.
3. When the MGW detects the status change at the Iu interface,
it reports the condition to the MSC Server, and the MSC Server
writes the reported data to the database for the basis of selecting MGWs during calls.

SCUDIF Call Function


SCUDIF calls provide a function related to UDI and RDI multi-media. When a subscriber makes a UDI/RDI multi-media call, and
when the signal attribute or multi-media service cannot be provided, a general call can still be set up instead of call failure.
This function also allows the subscriber to roll back to a general
voice service as required, and vice versa, implementing service
change between multi-media services and voice services. This
type of change can be initiated by a subscriber, because the original service is not supported for network problems or the service
the subscriber expects most is not supported during signaling interaction of the network. This type of change may happen when
the call is set up or the call enter the reliable status.
This function supports following service changes and rollback:

294

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Rolling back to voice service during call setup: Allowing a subscriber to attempt to set up a multi-media call. When the
multi-media call fails to be set up, set up a voice call.

Rolling back to a lower-priority service (voice or multi-media


service) during call setup: Allowing special settings at the mobile terminated side, receiving or refusing a multi-media call
without affecting the setup of the voice call.

Rolling back to a higher-priority service (voice or multi-media


service) during call setup: Allowing a single type of service call
when the middle network does not support SCUDIF.

Call terminals performing BC negotiation: Allowing special settings at the mobile terminated side, and allowing one voice
call to change to a multi-media call, or one multi-media call to
change to a voice call.

Service change: Call modifying procedure after entering the


reliable status, changing the voice call to a multi-media call,
and then roll it back to the voice call.

In the voice mode, allowing any subscriber to refuse the multimedia call modification request originated by another party.

Service change initiated by the network: When a multi-media


call cannot continue, the network can initiate a service modification procedure, changing the multi-media call to a voice call.
When the multi-media call is supported again in the later period, the network can initiate a service modification procedure,
changing the voice call to a multi-media call.

VMGW Function
Feature
Description

One physical MGW can be divided into several different virtual


MGWs (VMGW) from the logical aspect. Each VMGW is identified by the VMGW ID, which is managed by different MSCSs. The
bearer resource of the MGW equipment can be allocated to different VMGWs in the manner of resource monopolization or resource
sharing, and thus the flexibility of the equipment is improved. The
VMGW function can reduce the network construction cost of operators, and also can enable the running of virtual operators.
In the default case, all MGWs are embodied by VMGW. For a single
MGW, the system consider it as a special instance of VMGW, and
the VMGW ID needs to be configured.
One physical MGW can be divided into several VMGWs, but the system supports at most 16 VMGWs. Each VMGW can share the resource of the physical MGW. From the aspect of MGC, each VMGW
is an independent and complete MG, so it has its own signaling
point, physical terminal group, and logical terminal group. However, other resources are shared instead of being statically allocated. If one MGW is not divided into multiple VMGWs, it is one
VMGW, which is a special instance of VMGW.

Confidential and Proprietary Information of ZTE CORPORATION

295

ZXWN MSCS Technical Description

Caution:
The terminal resources at the physical gateway can be divided into
physical terminal and temporary terminal. Only temporary terminals can be shared, while physical terminals cannot.
Typical
Networking
Diagram

Figure 203 shows the typical networking diagram of implementing


the VMGW function.
FIGURE 203 TYPICAL NETWORKING OF VMGW

The configuration for implementing the VMGW function contains


two aspects: configuration on the MSCS and configuration on the
MGW.
Where, the VMGW configuration on the MGW mainly contains the
following two items:

Basic information of the MGW: Defining the ID and other information of the VMGW to make it be identified.

Basic information of the MGC: Defining the corresponding relationship between each VMGW and the MSCS where it is registered.

As shown in Figure 203, one physical MGW is divided into VMGW1


and VMGW2. Where, VMGW1 is registered in MSC Server1, while
VMGW2 is registered in MSC Server2.

Multi-IP-domain Function
Description

The IP network is generally considered to be plat, and all equipment is connected to one IP network. However, in fact, the IP
network are not always flat.
At present, there is one Internet and multiple Intranets. The Internet is really one network, boasting worldwide interoperability,

296

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

while there are thousands of Intranets. If it is required to implement interoperability between Intranets, special interoperability
equipment is required to perform NAT conversion, such as BG.
Usually, the bearer netowrk of softswitch is one Intranet, which is
plat. In this case, it is not necessary to consider the problem of
connecting multiple Intranets. However, for the softswich equipment serving as a gateway, there may be multiple Intranets, so
the concept of multi-IP-domain is introduced. In this case, one
MGW can access one or more IP domains.
Figure 204 shows the case of the softswich equipment accessing
multiple IP domains.
FIGURE 204 MULTI-IP-DOMAIN NETWORKING OF SOFTSWITCH EQUIPMENT

The MSCS needs to has the following capabilities:


IP routes can distinguish multiple IP networks to guarantee
that IP packets can be correctly forwarded. Since the control
plane may be conencted to multiple IP domains, it is not necessary to consider the multi-IP-domain problem when routes are
forwarded, because the static SCTP association is configured.
Confiugre the corresponding relationship between the office
and the IP domain. In addition, it is required to specify the
IP public-domain information between MGWs in the special
networking mode, to facilitate bearer establishment between
MGWs.

The MGW needs to has the following capabilities:


Supports multi-IP-domain configuration, establishes terminals
of different IP domains according to the IPDC carried in the
H.248 message of the MSCS, and applies for the RTP resource
of the corresponding IP domain.

Function
Implementation

Control plane over mult-IP-domain


The MSCS/MGW finds the corresponding association of the adjacent office, finds the corresponding SIPI according to the virtual address of the association and the next-hop configuration,
and sends the message to the correct VPN.

User plane over mult-IP-domain

Confidential and Proprietary Information of ZTE CORPORATION

297

ZXWN MSCS Technical Description

The MSCS distinguishes multiple domains by taking the office


as the minimum granularity. All the IP resources of the MGW
should divide into multiple resource pools according to the configuration, and each resource pool corresponds to one IP domain. In this way, when the MSCS gets the domain information according to the office information, it notifies the MGW to
allocate resources in the corresponding resource pool of this
domain. The user-plane data packets can be correctly transferred in the IP domain.

Enhanced IMEI Check


Function
Description

The Enhanced IMEI Check function can be implemented in the


Check IMEI procedure of the original MSC/VLR MAP. When the MSC
sends a MAP Check_IMEI Req message to the EIR, the message
carries the IMSI of the subscriber for check by the EIR, and parameter "ReqEquipInfo" (requested equipment information).
This function is only supported when the dialog between the MSC
and the EIR is established based on AC version 3 of the MAP, and
the MAP revision is R4. In the case of version negotiation (the
dialog version is less than 2 after negotiation), the Enhanced IMEI
Check function is not supported.

Function
Implementation

To implement this function, it is required to expend the


MAP_CHECK_IMEI message based on the existing protocol, to
make its request message carrying the IMSI of the subscriber.
1. The MSCS upgrades the version for the CheckIMEI procedure.
The highest version supporting the CheckIMEI procedure is
version 2, which needs to be upgraded to version 3.
2. When the MSCS needs to perform the CheckIMEI procedure
according to the system configuration requirement, read the
EIR configuration. If the EIR is configured to support the Enhanced IMEI Check function, the MSCS initiates a dialog with
version 3, and sends the IMEI and IMSI of the subscriber to
the EIR. The MSCS decides whether to allow the services of
the subscriber to continue according to the response from the
EIR and the system configuration.
If the EIR is configured to not support the Enhanced IMEI Check
function, and the dialog is initiated less than version 3, it is
processed according to the standard protocol.

298

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Rf Offline Billing Function


Overview
Description

The 3GPP 32.240/32.260 protocol requires that the MGCF should


have Rf offline charging function. That is, the MGCF should be
able to send charging messages to the CCF (CDF) through the Rf
interface based on the Diameter protocol bearer.

Related Concepts

The specification for the equipment of CM-IMS integrated information network clearly specifies that the MGCF should have Rf offline
charging function. It also specifies the contents of the Rf interface
message. The protocol is shown in Figure 205.
FIGURE 205 INTERFACE PROTOCOL

The function of each logical entity in Figure 205 is described as


follows:
CTF (Charging Trigger Function): This is the processing points existing in each service. It is responsible for collecting offline charging information generated by the processing points of each service,
and sending the charging information through the standard Rf interface.
CDF (Charging Data Function): It collects the charging information
from CTF through the Rf interface and forms CDRs. It performs the
first collection of the charging information. This function should be
implemented by the charging server.
CGF (Charging Gateway Function): This is an interface between
the charging system and the charging center. It receives CDRs
from CDF through the Ga interface, forms CDR files, and completes
the second collection of the charging information. It also sends
the charging information to the charging center through the Bi
interface. This function should be implemented by the charging
server.

Confidential and Proprietary Information of ZTE CORPORATION

299

ZXWN MSCS Technical Description

In order to realize the CTF, the MGCF needs to realize the Rf offline
charging function first, as shown in Figure 205. Both the CDF and
the CGF should be realized by the charging server.
Based on the description of the above protocol, the MGCF adds the
Rf charging information triggering function on the service modules
of all SIPs (SIPCC). When the Rf charging triggering condition is
met, the SIP service module sends the triggering charging information to the agent process (BILLOCG) of the off-line charging
through the internal interface and the charging transfer (illTrans)
process.
The charging agent process sends the charging information to the
charging server (CCF/CDF) by invoking the diameter protocol stack
according to the normal charging message (ACR) generated by the
internal message, and then waits for the response message (ACA)
from the charging server. The charging server collects the charging messages related to the one-time sip session, generates the
charging CDR, and then transfers the CDR to the charging domain.
Protocol Standard
Followed

CM-IMS core network equipment criterion V1.0.0

rfc3588 (Diameter Protocol)

3GPP 32.240

3GPP 32.260

3GPP 24.229

Function Implementation
Description

In this function, the CTF is composed of two parts. One part collects and generates the internal charging information according to
the triggering points configured in each flow of SIP call signaling,
and then sends the charging information to the charging agent
process. The other part, the charging agent process, transfers the
received internal charging information to a charging format that
meets the 3GPP definition, and then sends it to the CDF through
the Diameter protocol. Thus the offline charging function is completed.
Because it is required to interconnect with the CDF (that is the
charging server) through the Diameter protocol, the function of
the Diameter protocol stack is added in ZXWN-CS. In addition, the
process related to charging is added. On one hand, the process
receives internal charging information sent by the SIPCC service
process. On the other hand, it invokes the interface provided by
the Diameter protocol stack to send the processed charging information to the CDF.

300

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

Charging Software
Architecture

The architecture of the charging software is shown in Figure 206.


FIGURE 206 CHARGING SOFTWARE ARCHITECTURE

As shown in Figure 206, a new module attribute OCG used for the
Rf offline function is added. And the new processes are added in
the original SIP module and the normal SMP module.
As shown in Figure 206, the processes in the red part belong to
the Diameter protocol stack, and the processes in the navy blue
party belong to the chargingrelated process. The MP board with
OCG attribute needs the hard disk to save the accumulated CDRs.
Principle
of Function
Implementation

When originating a session, the SIPCC module will check whether


the SIP adjacent office needs to generate Rfinterface CDRs. If
it is not required, the charging process will be terminated. If it
is required, obtain the entrance policy configuration according to
the peer-end IP address configured in the adjacent office. After
that, obtain the service group index from the entrance policy, and
then obtain the charging policy index from the configuration of
the related service group in order to obtain the triggering point
configuration of the subscriber (refer to the charging triggering
point in the charging policy configuration). If the subscriber is
configured with one trigger point, and it is the just triggering point
where the service occurs, the SIPCC module will originate the Rf
charging flow.
The SIPCC enters the charging information to the internal message, and then transfers this internal message to the OCG (ac-

Confidential and Proprietary Information of ZTE CORPORATION

301

ZXWN MSCS Technical Description

cording to the configured mapping relationship) module according


to charging transfer process of this module. The OCG module generates the charging message (ACR) according to the internal message, invokes the diameter link, transfers the charging message
to the CCF (if the link is unavailable, the charging message will be
sent to the backup server; if the backup link is also unavailable,
the charging message will be saved in the memory or the hard
disk of the OCG module. After the link is available, the OCG reads
the charging message from the memory or the hard disk, and then
transfers the charging message to the CCF), and waits for the ACA
message from the CCF.
The triggering point is categorized into two types according to
the triggering condition configured by the user: session type and
event type.
The session type includes SIP session answering, SIP session release, the SIP session duration exceeding that of the middle charging timer, and the media resource originated by the SIP service
changing.
The event type includes event charging in case of each kind of
failure in SIP sessions.

EPLMN Expansion Function


Overview
The MSCS implements EPLMN expansion function. According to
the 24.008 protocol in the new version of the R6 phase, the MSCS
expands the PLMN List in the location update request from the
network side to the mobile phone side from 5 groups to 15 groups.
At the same time, the PLMN List sent from the network to the
mobile phone can be configured according to the IMSI prefix and
the location area.

Function Implementation

302

When the network sends a location update message mcL3LUAcceptEvent to the mobile phone, the plmnList in the message
mcL3LUAcceptEvent can be obtained according to the IMSI
prefix and the location area. If the PLMN List group can not
be obtained according to the IMSI prefix and the location area
(in case that the data are not configured), set the PLMN of the
binding carrier under the local MSC mobile configuration path
as a standard. If the above two paths are not configured, the
EPLNM function will not be implemented.

The PLMN List in the location update message from the network
side to the mobile phone side can be expanded from 5 groups to
15 groups. The PLMN List is controlled by the variable control
mosCsNECfg_t.bLongEPLMNListSupported. If this variable is

Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6 Special Functions

0, 5 groups are supported. If this variable is 1, 15 groups are


supported.

If the version of the terminal is R98Phase2 or below, the EPLMN


function is not supported. Therefore, only when the message
mcL3LUAcceptEvent does not carry the plmnList. and the version of the terminal is R99 or above, the EPLMN function is
supported.

Confidential and Proprietary Information of ZTE CORPORATION

303

ZXWN MSCS Technical Description

This page is intentionally blank.

304

Confidential and Proprietary Information of ZTE CORPORATION

Figure

Figure 1 Network Structure of UMTS R99 ............................... 3


Figure 2 Network Structure of UMTS R4................................. 4
Figure 3 Network Structure of UMTS R5................................. 5
Figure 4 Network Structure of UMTS R6................................. 7
Figure 5 Interfaces in UMTS R4 CN ....................................... 9
Figure 6 Interfaces in R5 IMS-domain Network ......................11
Figure 7 Main Interfaces of the ZXWN MSCS System ..............14
Figure 8 PROTOCOL STACK OF THE IU-CS INTERFACE
CONTROL PLANE ..............................................16
Figure 9 Protocol Stack of the A Interface Control Plane .........17
Figure 10 MC INTERFACE PROTOCOL STACK..........................17
Figure 11 PROTOCOL STACK OF THE NC INTERFACE ..............18
Figure 12 PROTOCOL STACK OF THE MN INTERFACE .............19
Figure 13 PROTOCOL STACK OF THE MAP INTERFACE .............19
Figure 14 PROTOCOL STACK OF THE CAP INTERFACE .............20
Figure 15 PROTOCOL STACK OF THE GS INTERFACE ..............21
Figure 16 PROTOCOL STACK OF THE MJ/MG INTERFACE .........21
Figure 17 Billing Interface...................................................22
Figure 18 O&M Interface Protocol Architecture.......................22
Figure 19 Position of the CORBA Interface in the Network
Management Network ........................................23
Figure 20 Position of the SNMP Interface ..............................24
Figure 21 Structure of the Interception Interface ...................27
Figure 22 Narrowband NO.7 Signaling Protocol Stack ............32
Figure 23 MSU of Narrowband No.7 Signaling ........................33
Figure 24 LSSU of Narrowband No.7 Signaling .......................33
Figure 25 FISU of Narrowband No.7 Signaling .......................33
Figure 26 Format of Sf .......................................................34
Figure 27 MTP3 Architecture ...............................................36
Figure 28 Structure of the SCCP Protocol ..............................38
Figure 29 Layered Structure of the TCAP...............................42
Figure 30 Protocol Stack of the Broadband Signaling System ...45
Figure 31 SAAL Structure ...................................................46
Figure 32 Functional Structure of SSCOP Entities ...................46

Confidential and Proprietary Information of ZTE CORPORATION

305

ZXWN MSCS Technical Description

Figure 33 SIGTRAN Protocol Stack .......................................50


Figure 34 Structure of the SCTP ..........................................51
Figure 35 Functional Modules of SCTP ..................................53
Figure 36 Functional Structure of M3UA ................................56
Figure 37 Separated Gateway Model ....................................60
Figure 38 Application of the H.248 Protocol ...........................60
Figure 39 H.248/MEGACO Protocol Connection Model ............61
Figure 40 BICC Protocol Model ............................................68
Figure 41 Structure of the BICC Protocol Based on the IP
Transport Network .............................................73
Figure 42 Structure of the BICC Protocol Based on the ATM
Transport Network .............................................73
Figure 43 Structure of the BICC Protocol Based on the TDM
Transport Network .............................................73
Figure 44 GS Interface Protocol Stack ..................................75
Figure 45 Location Update of the Non-GPRS Service ...............75
Figure 46 Paging Procedure of the Non-GPRS Service .............76
Figure 47 Alert Procedure of the Non-GPRS Service ................76
Figure 48 Explicit IMSI Detach Procedure of the GPRS Service...77
Figure 49 Explicit IMSI Detach Procedure of the Non-GPRS
Service ............................................................77
Figure 50 Implicit IMSI Detach Procedure of the Non-GPRS
Service ............................................................78
Figure 51 VLR/SGSN Reset Procedure...................................78
Figure 52 MS Information Procedure ....................................79
Figure 53 Format of the SIP Request Message .......................83
Figure 54 Format of the SIP Response Message .....................84
Figure 55 CAP System........................................................98
Figure 56 Operation Description ..........................................99
Figure 57 Processing Flow Without Need of Location Update
to HLR ........................................................... 105
Figure 58 Processing Flow Needing Location Update Initiation
to HLR ........................................................... 106
Figure 59 GPRS Location Update Service Flow ..................... 108
Figure 60 Combined Location Update Service Flow ............... 109
Figure 61 UMTSUMTS Network Model Before Intra-Office
Relocation ...................................................... 111
Figure 62 UMTSUMTS Network Model During Intra-Office
Relocation ...................................................... 112

306

Confidential and Proprietary Information of ZTE CORPORATION

Figures

Figure 63 UMTSUMTS Network Model after the Intra-Office


Relocation ...................................................... 112
Figure 64 UMTSUMTS Intra-Office Intra-system Relocation
Flow .............................................................. 113
Figure 65 UMTSUMTS Intra-Office Intra-system Relocation
Flow (Continued) ............................................. 114
Figure 66 UMTSUMTS Network Model Before the
Inter-Office Intra-system Relocation................... 115
Figure 67 UMTSUMTS Network Model During the
Inter-Office Intra-system Relocation................... 116
Figure 68 UMTSUMTS Network Model After the Inter-Office
Intra-system Relocation.................................... 116
Figure 69 UMTSUMTS Inter-Office Intra-system Relocation
Flow .............................................................. 117
Figure 70 UMTSUMTS Inter-Office Intra-system Relocation
Flow (Continued) ............................................. 118
Figure 71 UMTSGSM Network Model Before Intra-office
Inter-system Handover..................................... 120
Figure 72 UMTSGSM Network Model During Intra-office
Inter-system Handover..................................... 120
Figure 73 UMTSGSM Network Model After Intra-office
Inter-system Handover..................................... 121
Figure 74 UMTSGSM Intra-office Inter-system Handover
Flow .............................................................. 121
Figure 75 UMTSGSM Intra-office Inter-system Handover
Flow (Continued) ............................................. 122
Figure 76 UMTSGSM Network Model Before Inter-office
Inter-system Handover..................................... 123
Figure 77 UMTSGSM Network Model During Inter-office
Inter-system Handover..................................... 124
Figure 78 UMTSGSM Network Model After Inter-office
Inter-system Handover..................................... 124
Figure 79 UMTSGSM Inter-office Inter-system Handover
Flow .............................................................. 125
Figure 80 UMTSGSM Inter-office Inter-system Handover
Flow (Continued) ............................................. 126
Figure 81 GSMUMTS Network Model Before the Intra-office
Inter-system Handover..................................... 128
Figure 82 GSMUMTS Network Model During the Intra-office
Inter-system Handover..................................... 128

Confidential and Proprietary Information of ZTE CORPORATION

307

ZXWN MSCS Technical Description

Figure 83 GSMUMTS Network Model After the Intra-office


Inter-system Handover..................................... 129
Figure 84 GSMUMTS Intra-office Inter-system Handover
Flow .............................................................. 130
Figure 85 GSMUMTS Network Model Before Inter-office
Inter-system Handover..................................... 132
Figure 86 GSMUMTS Network Model During Inter-office
Inter-system Handover..................................... 132
Figure 87 GSMUMTS Network Model After Inter-office
Inter-system Handover..................................... 132
Figure 88 GSMUMTS Inter-office Inter-system Handover
Flow .............................................................. 133
Figure 89 GSMUMTS Inter-office Inter-system Handover
Flow (Continued) ............................................. 134
Figure 90 GSMGSM Network Model Before Intra-office
Intra-system Handover..................................... 136
Figure 91 GSMGSM Network Model During Intra-office
Intra-system Handover..................................... 136
Figure 92 GSMGSM Network Model After Intra-office
Intra-system Handover..................................... 137
Figure 93 GSMGSM Intra-office Intra-system Handover
Flow .............................................................. 137
Figure 94 GSMINTRA-OFFICE SYSTEM HANDOVER FLOW
(CONTINUED) ................................................. 138
Figure 95 GSMGSM Network Model Before Inter-office
Intra-system Handover..................................... 139
Figure 96 GSMGSM Network Model During Inter-office
Intra-system Handover..................................... 139
Figure 97 GSMGSM Network Model After Inter-office
Intra-system Handover..................................... 140
Figure 98 GSMGSM Inter-office Intra-system Handover
Flow .............................................................. 140
Figure 99 GSMGSM Inter-office Intra-system Handover
Flow (Continued) ............................................. 141
Figure 100 Generation of Authentication Parameters in AUC .. 144
Figure 101 Generation of Authentication Parameters in
USIM ............................................................. 145
Figure 102 Normal Authentication Procedure ....................... 145
Figure 103 Generation of Authentication Resynchronization
Parameter AUTS in USIM .................................. 147

308

Confidential and Proprietary Information of ZTE CORPORATION

Figures

Figure 104 Generation Of Authentication Resynchronization


Parameter AUTS in AUC.................................... 147
Figure 105 Ciphering Process ............................................ 148
Figure 106 INTEGRITY PROTECTION PROCESS .................... 149
Figure 107 Flow of Inserting Subscriber Data ...................... 151
Figure 108 Service Flow of Deleting Subscriber Data ............ 152
Figure 109 VLR RESTART SERVICE FLOW ............................ 153
Figure 110 HLR RESTART FLOW ......................................... 154
Figure 111 Service Flow of Activating/Deactivating Subscriber
Tracing ........................................................... 155
Figure 112 IMSI-Sending Service Flow ............................... 156
Figure 113 Structure of the Mobile Call Service Processing
Module ........................................................... 158
Figure 114 NETWORK STRUCTURE OF THE UE ORIGINATED
CALL.............................................................. 159
Figure 115 SIGNALING FLOW OF THE UE ORIGINATED CALL .. 160
Figure 116 NETWORK STRUCTURE OF THE UE TERMINATED
CALL.............................................................. 162
Figure 117 SIGNALING FLOW OF THE UE TERMINATED CALL
WITH THE PAGING PROCEDURE ........................ 162
Figure 118 NETWORK MODEL OF ORIGINATED CALL ............ 164
Figure 119 ORIGINATED CALL SETUP TIME SEQUENCE IN
CASE OF FORWARD BEARER ESTABLISHMENT ..... 165
Figure 120 ORIGINATED CALL SETUP TIME SEQUENCE IN
CASE OF FORWARD BEARER ESTABLISHMENT
(CONTINUED) ................................................. 165
Figure 121 ORIGINATED CALL SETUP TIME SEQUENCE IN
CASE OF BACKWARD BEARER ESTABLISHMENT ... 167
Figure 122 ORIGINATED CALL SETUP TIME SEQUENCE IN
CASE OF BACKWARD BEARER ESTABLISHMENT
(CONTINUED) ................................................. 167
Figure 123 NETWORK MODEL OF TERMINATED CALL ........... 169
Figure 124 TERMINATED CALL SETUP TIME SEQUENCE IN
CASE OF FORWARD BEARER ESTABLISHMENT ..... 169
Figure 125 TERMINATED CALL SETUP TIME SEQUENCE IN
CASE OF FORWARD BEARER ESTABLISHMENT
(CONTINUED) ................................................. 170
Figure 126 TERMINATED CALL SETUP TIME SEQUENCE IN
CASE OF BACKWARD BEARER ESTABLISHMENT ... 173

Confidential and Proprietary Information of ZTE CORPORATION

309

ZXWN MSCS Technical Description

Figure 127 TERMINATED CALL SETUP TIME SEQUENCE IN


CASE OF BACKWARD BEARER ESTABLISHMENT
(CONTINUED) ................................................. 174
Figure 128 MS ON-HOOK FLOW ........................................ 177
Figure 129 NETWORK-SIDE ON-HOOK FLOW....................... 178
Figure 130 SM MO Processing Flow .................................... 182
Figure 131 SM MT Processing Flow..................................... 183
Figure 132 Alert Message Flow (1) ..................................... 184
Figure 133 Alert Message Flow (2) ..................................... 184
Figure 134 CLIR Flow ....................................................... 187
Figure 135 CFB Flow ........................................................ 189
Figure 136 CFNRY Flow .................................................... 190
Figure 137 Providing Forwarding Number............................ 191
Figure 138 Call Waiting Flow (1) ........................................ 192
Figure 139 Call Waiting Flow (2) ........................................ 192
Figure 140 Call Waiting Flow (3) ........................................ 193
Figure 141 Call Hold Flow ................................................. 194
Figure 142 MPTY Call Processing Flow................................. 196
Figure 143 BOC Service Flow ............................................ 198
Figure 144 BIC Service Flow ............................................. 199
Figure 145 ECT Processing ................................................ 200
Figure 146 CD Processing ................................................. 201
Figure 147 REGISTER OPERATION FLOW .......................... 203
Figure 148 ERASE OPERATION FLOW ............................... 203
Figure 149 ACTIVATION OPERATION FLOW ....................... 204
Figure 150 INTERROGATE OPERATION FLOW .................... 205
Figure 151 REGISTER PASSWORD FLOW .......................... 205
Figure 152 Application Fields of IN ..................................... 208
Figure 153 INCM Structure ............................................... 209
Figure 154 Block Diagram of CAMEL................................... 212
Figure 155 O-BCSM ......................................................... 216
Figure 156 T-BCSM .......................................................... 219
Figure 157 Originating BCSM of Mobile Subscriber................ 223
Figure 158 Terminating BCSM of Mobile Subscriber .............. 224
Figure 159 Terminating BCSM Call Forwarding of Mobile
Subscriber (1)................................................. 224
Figure 160 Terminating BCSM Call Forwarding of Mobile
Subscriber (2)................................................. 225
Figure 161 MO Processing Flow of the Basic Call in the UMTS .. 229

310

Confidential and Proprietary Information of ZTE CORPORATION

Figures

Figure 162 Route Processing Flow of the Basic Call in the


UMTS............................................................. 230
Figure 163 MT Processing Flow of Basic Calls in the UMTS ..... 232
Figure 164 MO Flow of MPPS ............................................. 234
Figure 165 Routing Flow of the MPPS ................................. 236
Figure 166 Called Service Flow of MPPS .............................. 238
Figure 167 Network Mode Adopting DT Link ........................ 241
Figure 168 Network Mode adopting SPB Link ....................... 242
Figure 169 Connection between LIC and network elements ... 243
Figure 170 Schematic Diagram of Lawful Interface ............... 244
Figure 171 Connection between LIC and NEs ....................... 245
Figure 172 Connection Schematic Diagram for ETSI
Interception Service......................................... 247
Figure 173 Russia Interception Service ............................... 248
Figure 174 MS-Terminated Location Request (MT-LR) ........... 250
Figure 175 MS-Originated Location Request (MO-LR)............ 253
Figure 176 Network-Initiated Location Request (NI-LR)......... 254
Figure 177 Deferred MS-Terminated Location Request
(DEFERED-MT-LR) ........................................... 256
Figure 178 Flow Chart of the Terminal Subscriber in the
IMS Domain Calling the Subscriber in the CS
Domain/PSTN ................................................. 260
Figure 179 Flow Chart of the Subscriber in the CS
Domain/PSTN Calling the Terminal Subscriber in
the IMS Domain .............................................. 262
Figure 180 Flowchart of Detecting Cheaters and Performing
Service Restriction ........................................... 264
Figure 181 Flowchart of Generating Call Attempt CDRs ......... 266
Figure 182 PROCESSING FLOWCHART ................................ 267
Figure 183 ARR Function .................................................. 270
Figure 184 Region-System Networking Mode ....................... 271
Figure 185 Networking Resource Partition of the Region
System .......................................................... 271
Figure 186 1+1 Active/standby-mode Networking ................ 273
Figure 187 1+1 Mutual-backup-mode Networking ................ 274
Figure 188 N+1 Active/standby-mode Networking................ 274
Figure 189 N+1 Mutual-backup-mode Networking................ 275
Figure 190 MSCS Load Control Mechanism .......................... 276
Figure 191 Networking Mode............................................. 278
Figure 192 Multi-EIR Networking Mode ............................... 281

Confidential and Proprietary Information of ZTE CORPORATION

311

ZXWN MSCS Technical Description

Figure 193 M2PA Networking Mode .................................... 282


Figure 194 Adaptation Model............................................. 282
Figure 195 Typical Networking Diagram of BFD .................... 284
Figure 196 Grading Access Based on Half Rate .................... 286
Figure 197 UE Authentication in International Roaming, and
National Inter-Network Roaming........................ 288
Figure 198 Judging the Type of An Incoming Call According
to the FOCIN Information in the ISUP/BICC
Signaling ........................................................ 289
Figure 199 PSTN Subscribers Accessing EGSM ..................... 290
Figure 200 FLOWCHART OF ADJUSTING SEPARATE IP
ADDRESSES.................................................... 291
Figure 201 Flow of USSD Service Load Control Initiated by
the HLR.......................................................... 292
Figure 202 Flow of USSD Service Load Control Initiated by
the Local Office ............................................... 292
Figure 203 Typical Networking of VMGW ............................. 296
Figure 204 Multi-IP-domain Networking of Softswitch
Equipment ...................................................... 297
Figure 205 Interface Protocol ............................................ 299
Figure 206 Charging Software Architecture ......................... 301

312

Confidential and Proprietary Information of ZTE CORPORATION

Table

Table 1 Interfaces in UMTS R4 CN ........................................10


Table 2 Functions of China 2G Interception Interfaces.............27
Table 3 Functions of ETSI Interception Interfaces ...................28
Table 4 Functions of Russia Interception Interfaces ................29
Table 5 Capabilities Supported by BICC for Basic Call..............69
Table 6 Generic Signaling Procedures, Services and Functions...71
Table 7 Category of Response Messages ...............................85
Table 8 List of Common 1xx Messages ..................................85
Table 9 List of Common 3xx Messages ..................................86
Table 10 List of Common 4xx Messages ................................87
Table 11 List of Common 5xx Messages ................................89
Table 12 List of Common 6xx Messages ................................90
Table 13 CAP Operations Associated with CS .........................99
Table 14 CAP Operations Associated with SMS ..................... 101
Table 15 UMTS Circuit Data Services .................................. 180
Table 16 UMTS Supplementary Services.............................. 185
Table 17 Architecture and Functions of IN ........................... 208
Table 18 Description of DPs in the O-BCSM ......................... 217
Table 19 Description of DPs (2) ......................................... 220
Table 20 DP Disarming Relations in the O-BCSM .................. 226
Table 21 DP Disarming Relations in the T-BCSM ................... 227
Table 22 Hardware required for Common Interception .......... 242
Table 23 Functions of China 3G Interception Interfaces ......... 245
Table 24 Hardware Required for Russia Interception Service .. 248

Confidential and Proprietary Information of ZTE CORPORATION

313

ZXWN MSCS Technical Description

This page is intentionally blank.

314

Confidential and Proprietary Information of ZTE CORPORATION

Index
3GPP ............................. 299

C
Congestion control........... 276
control plane................1417

M
M3UA............................... 16
MGCF............................. 299
MTP3 ............................... 17

N
networking mode ................1

S
SC..............................1314
Service control ................ 276

T
Traffic control.................. 275

Confidential and Proprietary Information of ZTE CORPORATION

315

ZXWN MSCS Technical Description

This page is intentionally blank.

316

Confidential and Proprietary Information of ZTE CORPORATION

Glossary
3GPP
- the 3rd Generation Partnership Project
AAA
- Authentication, Authorization and Accounting
AAL5
- ATM Adaptation Layer type 5
AMR
- Adaptive Multiple Rate
AS
- Application Server
ATM
- Asynchronous Transfer Mode
AUC
- Authentication Center
AoCC
- Advice of Charge Charging supplementary service
AoCI
- Advice of Charge Information supplementary service
bcp
- bulk copy program
BCSM
- Basic Call State Model
BFD
- Bidirectional Forwarding Detection
BGCF
- Breakout Gateway Control Function
BICC
- Bearer Independent Call Control protocol
BSC
- Base Station Controller
BSS
- Base Station System
BSSAP
- Base Station Subsystem Application Part
BSSAP
- Base Station System Application Part
CAP
- CAMEL ApplicationPart
CDR
- Call Detail Record
CG
- Charging Gateway

Confidential and Proprietary Information of ZTE CORPORATION

317

ZXWN MSCS Technical Description

CN
- Core Network
CORBA
- Common Object Request Broker Architecture
CPCS
- Common Part Convergence Sublayer
CS
- Circuit Switched
CUG
- Closed User Group
DTMF
- Dual-ToneMulti-Frequency
EIR
- Equipment Identification Register
ETSI
- European Telecommunication Standard Institute
FISU
- Fill-in Signaling Unit
GGSN
- Gateway GPRS Supporting Node
GTP
- GPRS Tunneling Protocol
HLR
- Home Location Register
HSS
- Home Subscriber Server
I-CSCF
- Interrogating-Call Session Control Function
IETF
- Internet Engineering Task Force
IM-MGW
- IP Multimedia-Media Gateway
IMS
- IP Multimedia Subsystem
IMSI
- International Mobile Subscriber Identity
IN
- Intelligent Network
INAP
- Intelligent Network Application Part
IP
- Internet Protocol
ISDN
- Integrated Services Digital Network

318

Confidential and Proprietary Information of ZTE CORPORATION

Glossary

ISUP
- ISDN User Part
IUA
- ISDN User Adaptation Layer
LCS
- LoCation Services
LSSU
- Link Status Signaling Unit
M2PA
- MTP2-User Peer-to-Peer Adaptation Layer Protocol
M2UA
- MTP2-User Adaptation Layer
M3UA
- MTP3-User Adaptation layer protocol
MAP
- Mobile Application Part
MEGACO
- Media Gateway Control
MGCF
- MediaGateway Control Function
MGCP
- Media Gateway Control Protocol
MGW
- Media GateWay
MPLS
- Multi Protocol Label Switching
MRFC
- Multimedia Resource Function Controller
MRFP
- Multimedia Resource Function Processor
MRFP
- Media Resource Function Processor
MSC
- Mobile Switching Center
MSCS
- Mobile Switching Center Server
MSISDN
- Mobile Station International Subscriber Directory Number
MSU
- Message Signal Unit
MTP1
- Message Transfer Part Level 1
MTP2
- Message Transfer Part layer 2
MTP3
- Message Transfer Part layer 3

Confidential and Proprietary Information of ZTE CORPORATION

319

ZXWN MSCS Technical Description

MTP3b
- B-ISDN Message Transfer Part level 3
NE
- Network Element
NITZ
- Network Identity and Timezone
P-CSCF
- Proxy-Call Session Control Function
PDG
- Packet Data Gateway
PDN
- Packet Data Network
PLMN
- Public Land Mobile Network
PS
- Packet Switched
PSPDN
- Packet Switched Public Data Network
PSTN
- Public Switched Telephone Network
PVC
- Permanent Virtual Circuit
RAN
- Radio Access Network
RANAP
- Radio Access Network Application Protocol
RNC
- Radio Network Controller
RNS
- Radio Network Subsystem
ROSE
- Remote Operation Service Element
RTP
- Real-time Transport Protocol
S-CSCF
- Serving-Call Session Control Function
SAAL
- Signaling ATM Adaptation Layer ATM
SAR
- Segmentation and Reassembly
SC
- Short Message Center
SCCP
- Signaling Connection Control Part
SCN
- Switched Circuit Network

320

Confidential and Proprietary Information of ZTE CORPORATION

Glossary

SCP
- Service Control Point
SCTP
- Stream Control Transmission Protocol
SG
- Signaling Gateway
SGSN
- Service GPRS Supporting Node
SIGTRAN
- Signalling Transport
SIP
- Session Initiation Protocol
SMC
- Short Message Center
SMP
- Signal Main Processor
SMS
- Short Message Service
SNMP
- Simple Network Management Protocol
SPC
- Signaling Point Code
SS7
- Signaling System No. 7
SSCF
- Service Specific Coordination Function
SSCOP
- Service Specific Connection Oriented Protocol
SSCS
- Service Specific Convergence Sublayer
SSN
- Sub-System Number
SSP
- Service Switching Point
SUA
- SCCP User Adaptation
TCAP
- Transaction Capability Application Part
TDM
- Time Division Multiplexing
TUP
- Telephone User part
UE
- User Equipment
UMTS
- Universal Mobile Telecommunication System

Confidential and Proprietary Information of ZTE CORPORATION

321

ZXWN MSCS Technical Description

VLR
- Visitor Location Register
VPN
- Virtual Private Network
WLAN
- Wireless Local Area Network

322

Confidential and Proprietary Information of ZTE CORPORATION