ZXUN USPP V4 (HLR) - BC-EN-Theoretical Basic-Interface Protocol-Interfaces and Services PDF

ZXUN USPP
Universal Subscriber Profile Platform

Training Manual
HLR Interfaces and Services
ZTE UNIVERSITY
ZTE University, Dameisha
YanTian District, Shenzhen,
P. R. China
518083
Tel: (86) 755 26778800
Fax: (86) 755 26778999
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 CORPO-
RATION 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 dis-
claimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose, title or non-in-
fringement. 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.
Publishing Date (MONTH/DATE/YEAR) : 08/09/2010

Contents
Interfaces and Services................................................ 1

1 Product Interfaces .................................................... 2
1.1 Interfaces with Other NEs ....................................................... 2
1.2 Service Provisioning Interfaces ................................................ 4
1.3 Operation and Maintenance Interfaces...................................... 5
2 Basic Services ........................................................... 7
2.1 Call Services ......................................................................... 7
2.1.1 Call Routing.................................................................. 7
2.1.2 Support of Optimal Routing ............................................ 8
2.2 Supplementary Services ........................................................10
2.2.1 Subscription of Supplementary Services ..........................10
2.2.2 Registering Supplementary Services ...............................10
2.2.3 Deleting Supplementary Services ...................................11
2.2.4 Activating Supplementary Services .................................12
2.2.5 Deactivating Supplementary Services..............................13
2.2.6 Interrogating Supplementary Services.............................14
2.2.7 Password Processing in Supplementary Services ...............15
2.2.8 MS Initiated USSD Operations ........................................17
2.2.9 NE Initiated USSD Operation and Handling ......................18
2.3 Short Message Services.........................................................19
2.3.1 Short Message Service Introduction ................................19
2.3.2 Short Message Routing .................................................20
2.3.3 Short Message Report ...................................................21
2.3.4 Short Message Notification Service .................................21
2.4 GPRS Services .....................................................................22
2.4.1 GPRS Routing Service ...................................................22
2.4.2 GPRS Failure Report......................................................22
2.4.3 GPRS Subscriber Reachable Notification Service ...............23
2.5 CAMEL Services....................................................................24
2.5.1 CAMEL Service Introduction ...........................................24
2.5.2 Interrogation Flow of Anytime Subscriber's Subscription
Information ....................................................................................27
2.5.3 Modifying Subscriber Subscription Information at Any
Time..............................................................................................28
2.5.4 Notification Service for Subscriber Data Modification .........29
2.5.5 Interrogating Subscriber Information at Any Time.............30
2.5.6 Second Routing Request for CAMEL.................................30
2.6 LCS Service .........................................................................31
2.7 EIR Services ........................................................................32
2.7.1 IMEI Check by MSCS ....................................................32
2.7.2 IMEI Check by SGSN ....................................................33
3 Special Services ...................................................... 35
3.1 Customized Supplementary Service ........................................35
3.2 SMS Alert Service .................................................................35
3.3 VPLMN Insert Control ............................................................35
3.4 Qos Profile...........................................................................36
3.5 Multi SIM Function ................................................................36
3.6 Termination of Service (TOS) .................................................37
3.7 ALS Function........................................................................37
4 Basic Functions ....................................................... 39
4.1 Mobility Management ............................................................39
4.1.1 Mobility Management Introduction ..................................39
4.1.2 Location Update ...........................................................40
4.1.3 Security Authentication Management ..............................46
4.1.4 Subscriber Data Management ........................................48
4.1.5 Error Recovery Processing .............................................49
4.2 Operation and Maintenance Functions .....................................51
4.3 Administration Domain Function .............................................52
Glossary ..................................................................... 55
USPP(HLR)_BT002_E1_0
Interfaces and
Services
After you have completed this course, you
will be able to:

>> Master ZXUN USPP (HLR) Product In-
terfaces
>> Master ZXUN USPP (HLR) Services
Flow
Confidential and Proprietary Information of ZTE CORPORATION 1

ZXUN USPP Training Manual
Chapter 1 Product Interfaces

After you have completed this chapter, you will know:
>> Interfaces with Other NEs
>> Service Provisioning Interfaces
>> Operation and Maintenance Interfaces
1.1 Interfaces with Other NEs

Figure 1 shows major interfaces of ZXUN USPP HLR in the mobile
communication network.
FIGURE 1 HLR LOCATION IN UMTS R4 NETWORK
Related NEs In UMTS R4, the following NEs are directly/indirectly connected to
the HLR:
Visitor Location Register (VLR)
The VLR stores information of all subscribers in its controlled
area (such as subscriber number and location ID), and creates
conditions for establishing call connections for the registered
mobile subscribers. When a subscriber gets out of the cover-
age of the VLR, the subscriber information will be registered in
another VLR. The original VLR will remove the temporary in-
formation of this subscriber.
Equipment Identity Register (EIR)
The EIR stores the IMEI of UEs so that operators can take
timely precautions to ensure the uniqueness and security of
UEs within their networks.
Authentication Center (AUC)
It is connected to the HLR to prevent illegal subscribers from
accessing the UMTS system.
Mobile Switch Center Server (MSC Server)
In the UMTS R4 network, the MSC Server processes all switch
traffic and signals in the local area, such as call establishment
(including authentication), call control and charging. It also
stores and updates the data of MSs that have roamed to the
area covered by the VLR.
Gateway MSC Server (GMSC Server)
2 Confidential and Proprietary Information of ZTE CORPORATION

In the UMTS R4 network, the GMSC server is responsible for

the call traffic control in the PLMN, PSTN and ISDN networks.
SMS-IW/GMSC
The SMS-IW/GMSC consists of SMS-GMSC and SMS-IWMSC
that are normally integrated into one physical entity. The SMS-
GMSC serves as the interface on the SC, allowing transmission
of short messages from the SC to the MS; SMS-IWMSC works
as the interface on the PLMN, allowing transmission of short
messages from the MS to the SC.
Serving GPRS Support Node (SGSN)
The SGSN is responsible for GPRS mobility management, sub-
scriber and equipment authentication, session management,
subscriber data management, packet data routing and trans-
mission, encoding, charging and network management.
Gateway GPRS Serving/Support Node (GSSN)
The GGSN provides interfaces to connect to the external
Packet-Switched Public Data Network (PSPDN).
Gateway MS Location Center (GMLC)
The GMLC allows external service applications to access PLMN
gateways for registration verification and routing information
acquisition from ZXUN USPP.
Interface In the UMTS R4 network, the HLR has the following interfaces:
Description
H interface between the HLR and the AUC
It is an internal interface, through which the HLR obtains sub-
scriber authentication related data from the AUC.
D interface between the HLR and MSC Server/VLR
It is an interface in the R4 UMTS network. It is an MAP inter-
face with the following functions: location update, subscriber
data insertion, Supplementary Service processing and MT call
routing.
C interface between the HLR and the GMSC Server and be-
tween the HLR and the SMS-IW/GMSC Server
It is an interface in the R4 UMTS network. It is an MAP inter-
face with the following functions: location update, subscriber
data insertion, Supplementary Service processing and MT call
routing.
Gr interface between the HLR and SGSN
It is responsible for GPRS location update and subscriber data
insertion.
Gc interface between the HLR and GGSN
It allows GGSN to acquire subscriber location information and
supported service information.
Lh interface between the HLR and GMLC
It allows the GMLC to acquire subscriber information.
F interface between the EIR and MSC Server
It is an interface in the R4 UMTS network, which allows the EIR
to check the IMEI of connected devices.

Gf interface between EIR and SGSN

It allows EIR to check the IMEI of connected devices.
1.2 Service Provisioning Interfaces

The Interface Message Processor (IMP) of the HLR provides open
interfaces for the BOSS, so that the BOSS can access the HLR
system to register, modify and query subscriber services. Figure
2 shows the networking method of the HLR system and the BOSS.
FIGURE 2 NETWORKING METHOD OF HLR SYSTEM AND BOSS
The protocol stack of Interface HB between the HLR IMP and the
BOSS IMP is divided into three layers, as shown in Figure 3.
FIGURE 3 INTERFACE STACK OF HB INTERFACE
According to the format prescribed in HB protocol stack, the BOSS

IMP sends MML commands in the form of message packets to the
HLR IMP, and decodes received messages from the HLR IMP.

1.3 Operation and Maintenance

Interfaces
Figure 4 and Figure 5 describe the operation and maintenance
(O&M) interfaces.
FIGURE 4 OPERATION AND MAINTENANCE INTERFACES (DUAL-LEVEL

NETWORK)
FIGURE 5 OPERATION AND MAINTENANCE INTERFACES (SINGLE-LEVEL

NETWORK)
N (Northbound) interface with the NMS center

With the N Interface, the OMM can connect with the NMS center
through CORBA/CNMP/CMIP protocols.
F interface with the OMM client
The F interface is the interface between the OMM client and the
OMM server. It describes commands and command responses
between the client and the server in text. In the OMM system,
the F interface is realized in XML text format.
EMB communications interface between the EMS subsystem
and the OMM subsystem.
Interface between OMM subsystem and other subsystems
Internal message interfaces or SNMP interfaces are adopted
between the OMM subsystem and FE, Provision and UDS sub-
systems.

This page is intentionally blank.

Chapter 2 Basic Services
>> Call Services
>> Supplementary Services
>> Short Message Services
>> GPRS Services
>> CAMEL Services
>> LCS Service
>> EIR Services
2.1 Call Services

2.1.1 Call Routing
Service If the called party is an MS, the MSCS of the calling party first
Description asks the HLR of the called party to provide routing information of
the called MS. This HLR then requests MSRN from the VLR, which
assigns the MSRN to the called MS and then to the MSCS of the
calling party. The MSCS then establishes a link according to the
MSRN.
Service Flow Figure 6 shows the call routing flow.
FIGURE 6 ROUTE CALLING FLOW
The flow is described as follows:

1. The MSC where the calling subscriber is located requests the
HLR for the routing information of the called mobile subscriber.
2. The HLR requests the VLR where the called MS is currently
located for the called subscriber roaming number MSRN.
3. The VLR responds to the HLRs request and provides the roam-
ing number of the called MS.

4. The HLR provides the requested routing information of the

called MS to the MSCS that originates the call.
In addition, in this service, the HLR should also determine and
process the call forwarding and incoming call restriction of the
called subscriber.
When the HLR sends a message to VLR to request the roaming
number, if the VLR has no information of this subscriber, the VLR
will send a RESTORE message to request HLR for the subscriber in-
formation.
2.1.2 Support of Optimal Routing
Service The HLR provides the Support of Optimal Routing (SOR) feature,
Description which is usually applied to inter-PLMN CS calls and forwarding ser-
vices. To reduce call costs, direct routing is adopted to avoid un-
necessary CS connections between PLMNs.SOR provides the fol-
lowing functions:
Optimal basic routing query: The calling subscriber is directly
routed to the called party in the same country ( or in the coun-
try of the called party). Even if the called party roams out of its
home UMTS, the home UMTS is still bypassed in this process.
Optical routing forwarding query: When the called party is
busy, unreachable or not responsive while roaming outside its
home country, the call is forwarded to the forwarded-to num-
ber in the home UMTS country of the called party or the visiting
UMTS country, without going through the visiting UMTS of the
called party.
Service Flow Figure 7 illustrates the basic routing principle of SOR.
FIGURE 7 ROUTING OPTIMIZATION FOR BASIC CALLS

1. VMSCS A sends an IAM message to route an outgoing call to

GMSCS A in the VPLMN of the calling subscriber.
2. GMSCS A checks if the call meets the conditions of routing
optimization. If yes, it requests routing information from HLR
B in the home network of the called party.
3. HLR B obtains the roaming number from VLR B and then re-
turns the routing information to GMSCS A.
4. GMSCS A routes the call to VMSCS B according to the VMSCS B
address it receives (sending to VMSCS B IAM message formed
from the called party MSRN as obtained from HLRB). Basic call
routing optimization is complete.
Figure 8 illustrates the routing forwarding principle of SOR.
FIGURE 8 OPTIMAL ROUTING PRINCIPLE FOR CONDITIONAL FORWARDING
1. After call signals reach VMSCS B from the GMSCS, if the VM-
SCS/VLR determines to forward the call, it then send Resume
Call Handling to the GMSCS.
2. The GMSCS uses forwarding information received from Resume

Call Handling or queries call forwarding information from the
HLR, as directed by the HLR; If the GMSCS determines that the
call can be directly directed to the destination, it then clears
the connection to the VUMTSB and sends ISUP IAM to the for-
warded-to destination.

2.2 Supplementary Services

2.2.1 Subscription of Supplementary
Services
The subscription status of the supplementary services can only

be modified by the network carrier on the OMM of the HLR. The
MS is not allowed to make such modifications. After any modi-
fication, the HLR originates a request for inserting (subscription
status changed to subscribed) or deleting (subscription status
changed to not subscribed) subscriber data to synchronize the
corresponding data in the VLR.
2.2.2 Registering Supplementary

Services
Service The registration operation applies to the call forwarding services

Description and call barring services.
Call forwarding registration service
CFU: The registration request covers the supplementary
service code (indicating the CFU) and the forwarding num-
ber.
The registration of CFB and CFNRc is the same as CFU, only
that the SS Codes are different: CFB and CFNRc.
Call forwarding on no reply (CFNRy): The registration re-
quest carries the no reply timer time in addition to the sup-
plementary service code and the forwarding number.
Call barring registration service
The operations for call barring registration service are different
from those for call forwarding registration service. The process
of the former requires a login password to guarantee that only
the authorized user can use this service.
Service Flow The registration flow of supplementary services is as shown in
Figure 9.

FIGURE 9 SUPPLEMENTARY SERVICE REGISTRATION FLOW

1. The MS initiates the registration of supplementary services to
the MSCS/VLR, which then sends the MAP_REGISTER_SS_Req mes-
sage to the HLR.
2. The MAP_REGISTER_SS_REQ message carries the SS type. For call
restriction service, the HLR sends MAP_GET_PASSWORD_Req to obtain
subscriber password.
3. After obtaining the subscriber password, the MSC/VLR will re-
turn the password to the HLR in the corresponding acknowl-
edgement message in response to the getting password re-
quest message.
4. The HLR verifies whether the received password is correct. If
the password is correct, the HLR registers the supplementary
service and returns response MAP_REGISRER_SS_Ack to the VLR; if
the password is incorrect, the HLR re-initiates the password re-
quest process, and terminates the registration after the pass-
word is incorrectly input for 3 times.
5. If the HLR needs to update the subscriber data in the VLR, it
will send a subscriber data insertion request to the VLR.
6. After the VLR inserts the data successfully, it will return an
acknowledgement to the HLR.
2.2.3 Deleting Supplementary Services
Service The deletion operation applies to the call forwarding services and
Description call barring services.
Service Flow Figure 10 shows the supplementary service deletion flow.

FIGURE 10 SUPPLEMENTARY SERVICE DELETION FLOW

1. The subscriber sends an supplementary service deletion re-
quest to the MSCS/VLR, which then sends a deletion request
message to the HLR.
2. After deleting the request SS, the HLR returns an acknowledge-
ment.
3. The HLR sends a subscriber data insertion request to the VLR
to update subscriber data in the VLR.
2.2.4 Activating Supplementary

Services
Service The activation operation is applicable to the call forwarding, call

Description waiting and call barring services. When activating the call barring
service, the subscriber should provide a password. As for call for-
warding and call waiting, no password is required.
Service Flow Figure 11 shows the SS activation flow.

FIGURE 11 SUPPLEMENTARY SERVICE ACTIVATION FLOW

1. The subscriber sends an activation request to the MSCS/VLR,
which then sends the MAP_ACTIVATE_SS_Req message to the HLR.
2. When activating the call barring supplementary service, the
HLR sends a request to the VLR to obtain the subscribers pass-
word.
quest message.
the password is correct, the HLR activates the supplementary
service and returns response MAP_ACTIVATE_SS_Ack to the VLR; if
the password is incorrect, the HLR re-initiates the password
request process, and terminates the activation after the pass-
word is incorrectly input for 3 times.
5. The HLR sends subscriber data insertion request to the VLR to
update subscriber data.
2.2.5 Deactivating Supplementary

Services
Service The deactivation of supplementary service is applicable to call for-

Description warding, call waiting and call barring services. When deactivating
the call barring service, the subscriber needs to provide a pass-
word. As for call forwarding and call waiting, no password is re-
quired.
Service Flow Figure 12 shows the SS deactivation flow.

FIGURE 12 SUPPLEMENTARY SERVICE DEACTIVATION FLOW

1. The subscriber sends a deactivation request to the MSCS/VLR,
which then sends MAP_DEACTIVATE_SS_Req message to the HLR.
2. When deactivating the call barring supplementary service, the
HLR sends a request to the VLR/MSC to obtain the subscribers
password.
quest message.
the password is correct, the HLR deactivates the supplemen-
tary service and returns response MAP_DEACTIVATE_SS_Ack to the
VLR; if the password is incorrect, the HLR re-initiates the pass-
word request process, and terminates the deactivation after
the password is incorrectly input for 3 times.
5. The HLR sends subscriber data insertion request to the VLR to
update subscriber data.
6. After successful data insertion, the VLR will return an acknowl-
edgement message to the HLR.
2.2.6 Interrogating Supplementary

Services
Service SS interrogation means interrogating the data related to supple-

Description mentary services. The HLR can handle the interrogation of call
forwarding unconditional service and incoming call barring supple-
mentary service. Other supplementary services are interrogated
in the VLR.
Service Flow Figure 13 shows the supplementary service interrogation flow.

FIGURE 13 SUPPLEMENTARY SERVICE INTERROGATION FLOW

1. The subscriber sends an interrogation request to the
MSCS/VLR, which then sends the MAP_INTERROGATE_SS message
to the HLR.
2. The HLR returns an acknowledgement message that contains
the supplementary service status of the subscriber to the VLR.
The MSCS/VLR then returns the supplementary service state
to the subscriber.
2.2.7 Password Processing in

Supplementary Services
Service Password registration involves only call barring supplementary ser-

Description vices. With this function, a mobile subscriber can register or mod-
ify the password for the call barring supplementary services to
ensure that only authorized subscribers can use such services.
Service Flow Figure 14 shows the password processing flow in supplementary
services.

FIGURE 14 SUPPLEMENTARY SERVICE PIN REGISTRATION FLOW

1. The subscriber sends a password registration/modification re-
quest to the MSCS/VLR, which then sends the MAP_REGISTER_PASS
WORD_Req message to the HLR to request password registration.
2. The HLR sends a request to the VLR to obtain the subscribers

password (a registered number), and the VLR obtains (from
the MS) the original password of the MS.
3. After receiving the password of the MS, the VLR will return
the password to the HLR in the acknowledgement message in
response to the password acquiring request message.
4. The HLR checks the old password of the subscriber. If the pass-
word is correct, the HLR will once again send a request to the
VLR to obtain the subscribers password (the new subscriber
of the password).
5. The VLR obtains the new password from the MS and returns
the password to the HLR in the acknowledgement message in
response to the password acquiring request message.
6. The HLR checks whether the format of the new password is
valid (the password can only be a number consisting of four
digits ranging from 0 to 9). If the format of the new password
is valid, the HLR will once again send a request to the VLR to
obtain the new password.
7. The VLR obtains the new password from the subscriber once
again and returns the password to the HLR in the acknowledge-
ment message in response to the password acquiring request
message.
8. The HLR modifies the supplementary service operation code of
the subscriber saved in the HLR. After successful modification,
the HLR will return an acknowledgement message MAP_REGISTER
_PASSWORD_Ack.

2.2.8 MS Initiated USSD Operations
Service The USSD provides a universal mechanism that is irrelevant to spe-

Description cific services and that supports the random expansion of supple-
mentary services. To be specific, USSD is a mechanism to transmit
information (such as character strings) between the MS and appli-
cation entities (MSCS, VLR, HLR, gsmSCF, etc.) in the mobile net-
work. This information transmission mechanism is not concerned
with information content. The sender determines the content of
transmitted information, which is then interpreted and processed
by the receiver. USSD supports bidirectional and interactive mes-
sage transmission: in one session, data packets are transmitted
intermittently from the MS to GSM network entities and vice versa.
A USSD session may be initiated by the MS or GSM network en-
tities. The MS initiated USSD service can be processed in any
module, such as MSCMAP, VLRMAP, HLRMAP or gsmSCF, according
to the service code carried in USSD String.
Service Flow Figure 15 shows the USSD application message flow from the MS
to the gsmSCF module.
FIGURE 15 MS INITIATED USSD OPERATION FLOW

1. The MS initiates a USSD operation request. The VLR deter-
mines whether it can be supported by the local VLR; if not, the
VLR sends MAP_ProcUSSReq_Req to ZXUN USPP.
2. After the HLR receives the request, it determines whether
the USSD operation can be locally supported according to the
string in the request message; if not, the HLR checks whether
the subscriber is a CAMEL subscriber and whether subscribed
U-CSI or configured UG-CSI CAMEL data is available. If such
data is available, the HLR then finds the gsmSCF address that
corresponds to the service code in the USSD string according

to such data, and sends MAP_ProcUSSReq_Req message to the

gsmSCF module.
3. If the gsmSCF needs to obtain some information from the sub-
scriber before proceeding to other operations, it sends MAP_USS-
Req_Req to the HLR; if the gsmSCF is to notify the subscriber
on some information before proceeding to other operations, it
sends MAP_USSNotify_Req to the HLR and waits for response from
the HLR.
4. The HLR transparently sends MAP_USSReq_Rsp or MAP_USSNotify_Rsp
to the gsmSCF.
5. The VLR returns MAP_USSReq_Rsp or MAP_USSNotify_Rsp to the HLR,
which forwards this message to the gsmSCF.
2.2.9 NE Initiated USSD Operation and

Handling
Service Network Entity (NE) initiated USSD service may be initiated by

Description USSD applications in MSCMAP, VLRMAP, HLRMAP and gsmSCF
modules, or by the USSD center through these modules.
Service Flow Figure 16 shows the service flow initiated by gsmSCF.
FIGURE 16 NE INITIATED USSD OPERATION FLOW

1. The gsmSCF initiates USSD. It first establishes a session with
the HLR of the subscriber and sends MAP_USSReq_Req or MAP_USSNo
tify_Req message, and then waits for the HLR to respond.
2. The HLR establishes a session with the subscriber registered

VLR according to subscriber location information, and then
sends MAP_USSReq_Req or MAP_USSNotify_Req transparently to the
gsmSCF.

3. The VLR returns MAP_USSReq_Rsp or MAP_USSNotify_Rsp to the HLR,

which forwards this message to the gsmSCF.
4. The HLR transparently sends MAP_USSReq_Rsp or MAP_USSNotify_Rsp
to the gsmSCF.
5. After the gsmSCF processes all messages, it shuts down the
session with the HLR, which, after receiving the session shut-
down message, releases all resources to end the processing in
different NEs.
2.3 Short Message Services

2.3.1 Short Message Service
Introduction
The Short Message Service (SMS) is divided into point-to-point

short message service and the broadcast short message service.
The SMS involved in the mobile switching system is only the point-
to-point SMS.
The point-to-point SMS transfers length-limited messages be-
tween PLMN mobile stations and Short Message Entities(SMEs)
and between MSs through the short message center (SC). The SC
can store and forward messages, constituting a short message
processing entity that integrates the storing, interacting and trunk
functions. However, the function of the PLMN is to support short
message transfer between the SC and MSs.
The point-to-point SMS defines two types of services: Short Mes-
sage Mobile Originated (SM_MO) and Short Message Mobile Ter-
minated (SM_MT).
The SM_MO refers to the short messages originated by the
MS to the SC. These messages can be sent to other MSs or
SMEs, or can be sent to fixed subscribers that support the SMS
function.
SM_MT are messages sent to the MS by the SC. These mes-
sages may come from MSs(SM MO) or SMEs.
The HLR supports SMS. The SMS function is realized by the SM
Routing Unit, SM Report Unit and SM Notification unit in HLR/AUC.
Different tasks are completed by invoking different units, as shown
in the figure below.

FIGURE 17 SMS UNITS
2.3.2 Short Message Routing
Service When the SC sends short messages to the MS, it needs to know
Description the location of the MS, namely the MSCS/VLR/SGSN. Short mes-
sage routing information request enables IW/GMSCS to request
the MSCS/VLR/SGSN number of the MS from the HLR. It provides
routing information for IW/GMSCS.
Service Flow Figure 18 shows the flow of the short message routing.
FIGURE 18 SHORT MESSAGE ROUTING INFORMATION REQUEST FLOW

1. The IW/GMSCS sends MAP_SEND_ROUTING_INFO_FOR_SM_Req to the
HLR to request short message routing information, namely
MSCS/VLR/SGSN number.
2. The HLR responds with a message that contains routing infor-
mation.

2.3.3 Short Message Report
Service Short message sending failure or success may be reported to the

Description HLR, and the HLR changes the flag bit for short message sending
saved in the HLR.
Service Flow Figure 19 shows the flow of the short message report service.
FIGURE 19 SHORT MESSAGE SENDING REPORT SERVICE FLOW

1. The IW/GMSC reports short message sending success or failure
to the HLR.
2. The HLR changes the short message sending flag bit and re-
turns an acknowledgement message.
2.3.4 Short Message Notification

Service
Service When an MS is unreachable or its memory is full, short messages

Description cannot be sent to this MS. In this case, the flag bit is set in the HLR.
When the MS is available or has memory available again, the IGW
will notify the HLR; the HLR then sends an notification message to
the IW/GMSCS so that the SC resends the short message to the
MS.
Service Flow Figure 20 shows the flow of the short message notification service.
FIGURE 20 SHORT MESSAGE NOTIFICATION FLOW

1. The VLR sends MAP_READY_FOR_SM_Req message to the HLR when

the MS is reachable or has available memory.
2. The HLR sends notification message MAP_ALERT_SERVICE_CEN-
TRE_Req to all SCs that failed to send short messages to the MS.
3. The IW/GMSCS responds to the HLR with message

to indicate that the notification
MAP_ALERT_SERVICE_CENTRE_Ack
message has been successfully processed.
4. The HLR responds message MAP_READY_FOR_SM_Ack to MSC/VLR to
indicate the service is successfully handled.
2.4 GPRS Services

2.4.1 GPRS Routing Service
Service When the GGSN receives a PDP PDU and needs to originate the
Description PDP Context activation process needed by the network, the GGSN
sends a routing request to the HLR to obtain the number of the
SGSN where the subscriber is currently located.
Service Flow Figure 21 shows the GPRS routing flow.
FIGURE 21 GPRS ROUTING SERVICE FLOW

1. The GGSN initiates a routing request to the HLR, asking for the
GPRS routing information of the subscriber.
2. The HLR returns the number of the SGSN where the subscriber
is currently located in the GPRS routing acknowledgement
message.
2.4.2 GPRS Failure Report
Service This service is used by the GGSN to notify the HLR of the failure of
Description the PDP context activation needed by the network. After the HLR
receives failure reports from the GGSN, it sets the MNRG flag in the
database and then saves the GGSN number and GGSN address(if
any) in the failure report to the database.
Service Flow Figure 22 shows the GPRS failure report flow.

FIGURE 22 GPRS FAILURE REPORT FLOW

1. The GGSN sends a failure report request to the HLR. The re-
quest contains the GGSN number and GGSN address or only
contains the GGSN number.
2. The HLR sets the MNRG flag for the subscriber and returns a
response.
2.4.3 GPRS Subscriber Reachable

Notification Service
Service After the HLR receives the Ready_for_SM message or a Mobile Sta-
Description tion with the MNRG flag initiates location update, the HLR sends a
message to notify the GGSN that the MS is reachable.
Service Flow Figure 23 shows the flow of MS reachable for GPRS notification.
FIGURE 23 MS REACHABLE FOR GPRS NOTIFICATION FLOW

1. The HLR sends a GPRS subscriber reachable notification to the
GGSN.
2. The GGSN returns an acknowledgement message, indicating
that the service processing is completed.

2.5 CAMEL Services

2.5.1 CAMEL Service Introduction
Network Structure The HLR supports CAMEL phase 3 and is compatible with CAMEL
phase 1 and 2. The Mobile Intelligent Network (MIN) consists of
the HLR, gsmSCF, GMSCS (with gsmSSF functions), MSCS/VLR
(with gsmSSF functions), SGSN (with gprsSSF functions) and
gsmSRF (independent Intelligent Peripheral or integrated with
MSC/VLR). The figure below shows the basic structure of the MIN.

FIGURE 24 MIN STRUCTURE
The SCP is the control center of the entire IN service, and the
SMP is the management center. The network is divided into three
layers:
Service bearing layer: including the RAN, MSCS, Intelligent
Peripheral (IP), SGSN and GGSN.
Service control layer: including the SCP/SDP, HLR and VC.
Service management layer: including the SMP, SMAP and
SCEP.

Network Element Functions of the Network Elements are as follows:

Functions
VMSCS/VLR/SSP functions:
Traffic control of basic MO/MT calls.
Attachment/detachment, location update and security
management for mobile subscribers.
Authentication for the call originating MS.
Traffic control for MO_SMS and MT_SMS.
Triggering and execution for MO, VT and MF intelligent calls,
i.e. call control and service switch.
Triggering and execution of MO_SMS events, namely SMS
call control and SMS service switch.
Load control for intelligent call services: call gapping.
Supplementary Service invocation notification.
MS location change notification.
Inband interaction with mobile subscribers: Playing an-
nouncement tones, playing tones and receiving numbers,
namely, the Specialized Resource Function (SRF).
GMSCS/SSP functions:
Control of traffic between the local network and other net-
works (including MO and MT traffic).
Triggering and execution of MT and MF intelligent calls,
namely CCF and SSF.
Load control for intelligent call services: call gapping.
Inband interaction with calling subscribers: Playing an-
nouncement tones, playing tones and receiving numbers,
that is, the Specialized Resource Function (SRF).
Intelligent Peripheral functions:
Responsible for inband interaction with calling subscribers:
Playing announcement tones, playing tones and receiving
numbers, and tone identification.
SGSN/gprsSSP functions:
GMM context management for MS.
PDP context activation and reverse activation for MS.
Responsible for triggering and execution of IN transactions.
HLR functions:
MS subscription data management, including CAMEL sub-
scription data.
Routing and authentication of MT MS.
Routing for MT_SMS events.
Dynamic configuration of TDP.
Notification of subscription data change.
Supporting query and modification at any time.
SCP functions:

Execution of IN service logic.

Query and modification of MS subscription data.
Saving and real-time update of MS IN service data.
Automatic detection and control of SCP load.
Interaction with other SCPs/SDPs.
SMP functions:
Configuration management, performance management,
fault management and supervision management of IN
services.
Security management.
Accounting management of IN services.
SCEP functions
IN service creation.
IN service testing.
IN service maintenance.
VC functions:
Voucher card management.
SMAP functions:
Service management operation interfacing.
Security management.
Service management operations.
In Figure 24, the HLR stores MS-related CAMEL subscription data
such as OCSI, TCSI, TIFCSI, UCSI and SSCSI; it also stores UGCSI
that applies to all subscribers.
In which:
O-CSI, SS-CSI, VTCSI, MCSI, DCSI and SMS CSI are transmit-
ted to the VLR during MS location update or data variation.
OCSI, TCSI and DCSI are transmitted to GMSCS in router re-
sponse messages.
TIFCSI, UCSI and UGCSI are stored in the HLR only, and the
HLR provides the gsmSCF interface for anytime query and
modification of such subscription information.
2.5.2 Interrogation Flow of Anytime

Subscriber's Subscription Information
Service If the gsmSCF needs to know the subscription information of a

Description subscriber, it will start the service of interrogating subscriber sub-
scription information at any time to ask the HLR for the basic sub-
scription data of the subscriber. The HLR can be configured to
allow/disallow gsmSCF to interrogate subscription data. The gsm-
SCF can only interrogate the subscriber data such as CAMEL phase
supported by CF, CB, ODB, CAMEL, VLR and SGSN.

Service Flow Figure 25 shows the service flow.
FIGURE 25 QUERY FLOW OF ANYTIME SUBSCRIBER'S SUBSCRIPTION

INFORMATION

1. The gsmSCF sends a request on interrogating subscriber sub-
scription information at any time to the HLR to query the sub-
scription information of the subscriber.
2. The HLR returns an acknowledgement message to the gsm-
SCF; the message contains the subscriber subscription infor-
mation to be interrogated.
2.5.3 Modifying Subscriber

Subscription Information at Any
Time
Service If the gsmSCF needs to modify the subscription information of a

Description subscriber, it will start the service of modifying subscriber subscrip-
tion information to ask the HLR to modify the subscription data of
the subscriber. According to the protocol, the gsmSCF can mod-
ify only one item among CSI, CF and CB during each modification
process. The HLR can be configured to allow/disallow gsmSCF to
modify subscription data.
FIGURE 26 MODIFICATION FLOW OF ANYTIME SUBSCRIBER'S SUBSCRIPTION

INFORMATION


1. The gsmSCF sends a subscriber subscription information mod-
ification request to the HLR, and the message indicates the
subscriber data to be modified.
2. The HLR determines whether such data can be modified, such
as whether modification is allowed and whether the subscriber
has registered such data. If the subscriber data can be modi-
fied, the HLR will modify the data and return the modified data
to the gsmSCF in the acknowledgement message.
3. After the HLR modifies subscriber data, it inserts changed data
into MSCS/VLR.
4. The MSCS/VLR returns a subscriber data insertion acknowl-
edgement message. Service processing is complete.
2.5.4 Notification Service for

Subscriber Data Modification
Service If the subscriber signs up for CAMEL service that requires gsmSCF
Description be notified upon subscriber data change, the notification flow is
triggered in the following cases:
The subscriber's CAMEL, ODB, CB and CF registration data is
changed through the HLR agent.
The subscriber modifies registered CB and CF data through the
registration and deletion of call-unrelated supplementary ser-
vices.
With Anytime Modification service, gsmSCF modifies the sub-
scriber's CAMEL, ODB, CB and CF data.
Service Flow Figure 27 shows the notification flow for subscriber data modifica-
tion.
FIGURE 27 NOTIFICATION FLOW FOR SUBSCRIBER DATA MODIFICATION
The service flow is described as follows:

1. After the subscriber's CAMEL, ODB, CB and CF data is modi-
fied, the HLR notifies the gsmSCF with a message that contains
modified data.
2. After receiving the notification message, the gsmSCF will re-
turn an acknowledgement message, and the service process-
ing ends.

2.5.5 Interrogating Subscriber

Information at Any Time
Service The gsmSCF starts the service of interrogating subscriber infor-

Description mation at any time, asking the HLR to provide the location and
status information of the subscriber. Whether the interrogation at
any time is supported is configured on the OMM client of the HLR.
FIGURE 28 ATI SERVICE FLOW

1. The gsmSCF sends a request to query subscriber location/sta-
tus.
2. The HLR determines whether to accept ATI according to back-
ground configuration. If not, the HLR sends ATI failure re-
sponse to the gsmSCF; otherwise the HLR sends a request to
the VLR asking for subscriber information.
3. After obtaining the subscriber information, the VLR sends the
subscriber information to the HLR in the subscriber information
acknowledgement message.
4. After receiving the subscriber information from the VLR, the
HLR sends the subscriber information to the gsmSCF in the
acknowledgement message in response to the request of in-
terrogating at any time.
2.5.6 Second Routing Request for

CAMEL
Service When a CAMEL subscriber is called, the T_CSI parameter in the

Description first routing request sent by GMSCS is not set, so the HLR returns
O/T_CSI data to the GMSCS; The second routing request inhibits
T_CSI parameter setting and the HLR returns routing information.
Service Flow Figure 29 shows the routing flow.

FIGURE 29 SECOND ROUTING SERVICE FLOW
2.6 LCS Service

Service The HLR supports LCS service and the registration of related data.
Description It also synchronizes LCS data in VLR/SGSN and provides location
router information when LCS related data changes.
When the LCS client is to obtain the geological location of the sub-
scriber, it sends a location request to the server.
The first NE connected to the server is the Gateway Mobile Loca-
tion Center (GMLC). The GMLC first queries the current MSCS/VLR
or SGSN of the subscriber from the HLR, namely LCS router in-
formation; it then obtains the geological location information from
the current MSCS/VLR of the subscriber.
The OMM of the HLR is configured to allow the access of specified
GMLCs. If the GMLC is not configured, it is then considered ille-
gal and denied access, i.e. LCS router request from the GMLC is
denied.
Service Flow Figure 30 shows the service flow of the LCS router.
FIGURE 30 LCS ROUTER SERVICE FLOW

1. After the HLR receives the LCS router request from GMLC, it
examines whether the GMLC is legal, whether the subscriber is
knowable, whether the subscriber has registered LCS service
and whether the subscriber is available. If all examinations are
successful, the HLR returns LCS router response to the GMLC.
2. The LCS router response contains LCS router information, i.e.
MSCS/VLR number or SGSN number or a combination of both
MSCS/VLR number and SGSN number.
According to subscriber access method and LCS capability set
information, the system determines the method to return LCS
router information in the response message.
If the subscriber accesses the system through only the
CS field or the PS field, namely the HLR contains only
MSCS/VLR number or SGSN number, then the response
message shall contain only the MSCS/VLR number or the
SGSN number;
If the subscriber accesses the network from both the CS
field and the PS field, then the HLR contains both the
MSCS/VLR number and the SGSN number. In this case,
the response message contains the number that has a
higher LCS capability set (if both numbers have equal
capability sets, then both numbers shall be contained in
the response message). The LCS capability set of the
VLR/SGSN refers to the LCS version information supported
by VLR/SGSN, such as R99 and R4.
2.7 EIR Services

2.7.1 IMEI Check by MSCS
Service For the purpose of MS management, the MSCS connects to EIR to

Description check IMEI status through the F interface.
Service Flow Figure 31 shows the IMEI check flow.
FIGURE 31 IMEI CHECK FLOW

1. The MSCS initiates an IMEI check request to the EIR.
2. Upon receiving the request, the EIR checks the IMEI and re-
turns the result to the MSCS.

2.7.2 IMEI Check by SGSN
Service For the purpose of MS management, SGSN connects to EIR to

Description check IMEI status through the Gf interface.
Service Flow Figure 32 shows the IMEI check flow.
FIGURE 32 FLOW OF IMEI CHECK BY SGSN

1. The SGSN initiates an IMEI check request to the EIR.
2. Upon receiving the request, the EIR checks the IMEI and re-
turns the result to the SGSN.


Chapter 3 Special Services
>> Customized Supplementary Service
>> SMS Alert Service
>> VPLMN Insert Control
>> Qos Profile
>> Multi SIM Function
>> Termination of Service (TOS)
>> ALS Function
3.1 Customized Supplementary

Service
ZXUN USPP provides a platform for the operator to provide cus-
tomized services according to actual needs. Operator determined
supplementary services can be realized through proper configura-
tions in ZXUN USPP.
3.2 SMS Alert Service

When one mobile subscriber calls another, if the called party is
power off, then call fails; when the called party is powered on, the
system sends a short message to the calling party that the called
party is powered on and can be reached. This enables the calling
party to reach the called party in time and improve QoS.
3.3 VPLMN Insert Control

Function When the subscriber roams to the VPLMN, many problems may
occur, such as unsupported device version, unable to trigger ser-
vices and charging problems. It is therefore necessary to control
VPLMN services such as service insertion, insertion transforma-
tion, and called-side service triggering when a subscriber in ZXUN
USPP roams to the VPLMN. Subscribers of different types can se-
lect service insertion control methods for specific networks so that
each subscriber can register one service insertion control plan. For
each service insertion control plan, the service to be controlled and
the insertion/called-side control range of such service can be cus-
tomized.

Application Libyan carrier Libyana started international roaming services.

Scenario Due to its current charging system, prepaid subscribers cannot be
charged in real time during international roaming. Therefore, it is
necessary to insert different services when the subscriber roams
to different countries in order to restrict service usage and avoid
unnecessary costs.
3.4 Qos Profile

ZXUN USPP provides two methods to subscribe/modify QoS data:
QoS parameter configuration and QoS Profile ID settings. When
QoS Profile ID and QoS parameters are provided at the same time,
QoS Profile ID has a higher priority.
ZXUN USPP supports QoS Profile. One APN corresponds to one QoS
Profile. The same APN for different subscriber settings may cor-
respond to different QoS Profiles. To modify the QoS subscription
attribute of the subscriber, you only need to modify the subscribed
QoS Profile ID.
3.5 Multi SIM Function

ZXUN USPP supports the multi-SIM function, including voice and
short message forwarding. The details are as follows:
Each Multi-SIM group contains 1 to 5 SIMs, with the MSISDN
of one SIM as the primary number.
The primary number is the common MSISDN of other SIMs,
while other SIMs have their own MSISDNs.
Each SIM in the Multi-SIM group can register its own subscriber
information.
Any SIM in the Multi-SIM group can set itself as "on-duty",
after which the voice calls and short messages of the primary
number shall be forwarded unconditionally to the MSISDN of
the on-duty SIM.
In the home network, when any SIM in the Multi-SIM group
inserts COMMON MSISDN and OWN MSISDN to the VLR, the
MO number displayed is the common MSISDN while both the
common MSISDN and the own MSISDN can be the MT number
for voice calls and short messages.
After the Multi-SIM MS roams out of the home network, only
the OWN MSISDN of each SIM is inserted into the VLR.
Multi-SIM subscribers do not restrict subscriber registration of
CFU through MS.
This service is controlled by the license.

Chapter 3 Special Services
3.6 Termination of Service (TOS)

ZXUN USPP supports the Termination of Service (TOS) function.
The data for each subscriber contains a flag that is normally
marked as "ACTIVE" and marked as "deactive" when the sub-
scriber has reported loss. When the flag is "deactive", subscriber
location update fails and a special announcement tone is played
when the subscriber is called.
3.7 ALS Function

ZXUN USPP supports the Alternative Line Service (ALS), which pro-
vides two different lines for public calls and private calls. One SIM
card corresponds to two MSISDNs that are charged separately.


Chapter 4 Basic Functions
>> Mobility Management
>> Operation and Maintenance Functions
>> Administration Domain Function
4.1 Mobility Management

4.1.1 Mobility Management
Introduction
In the HLR system, the mobility management service consists of

the location update module, security management module, MS
data management module and error recovery module, as shown
in Figure 33.
FIGURE 33 MOBILITY MANAGEMENT SERVICE

4.1.2 Location Update
4.1.2.1 Location Update Description
Due to the mobility of mobile subscribers, the locations of mobile

subscribers are constantly changing. To obtain the location infor-
mation of mobile subscribers during the processing of call service,
SMS, supplementary service and location service and meanwhile
to improve valid utilization of the radio resources, the mobile sub-
scribers must register their locations and report their active status
on the network, namely, the subscribers must originate the loca-
tion update service.
Location update is classified into three types: general location up-
date, periodic location update and IMSI(GPRS)attach/detach.
General location update is further divided into VLR location update,
GPRS location update and joint location update.
4.1.2.2 VLR Location Update
Service When the location area of the subscriber changes during roaming,
Description the MS initiates the location update operation.
If the Previous Location Area (PLA) and the new LA belong to
the same MSC/VLR, then location information is modified in
this VLR.
If the PLA and the new LA do not belong to the same MSC/VLR,
then the new MSC/VLR requests permission from the HLR to
obtain MS data.
The HLR will notify the original MSC/VLR to delete the loca-
tion, register the MS in the new MSC/VLR and register the
MSC number/VLR number of the MS in the HLR at the same
time when the HLR sends out the information necessary for
the new MSC/VLR.
When the MS requests location update to the new MSC/VLR
using TMSI and PLAI, if PLAI is not in the new MSC/VLR, the
new MSC/VLR calculates PVLR (Previous VLR) address accord-
ing to TMSI and PLAI and then sends a request authentication
message to obtain MS IMSI and unused authentication param-
eters from PVLR.
Service Flow Figure 34 shows the flow of location update initiated by the VHLR
to the HLR.

FIGURE 34 FLOW OF VLR REQUESTING LOCATION UPDATE TO HLR

1. The VLR where MS is currently located originates a location
update request to the HLR. The HLR determines whether to
allow this subscriber to roam. If yes, it will proceed with the
next step.
2. After receiving the location update request from the new VLR
where the MS is located, the HLR originates the location can-
celing operation to the VLR (PVLR) where the MS is originally
located, to request the PVLR to delete the data of this sub-
scriber.
3. PVLR deletes MS data and sends a response message to the
HLR. After the HLR sends the location deletion request mes-
sage, if the PVLR returns a failure message, the HLR will re-
transmit a request message according to the retransmission
mechanism. The message retransmission times and retrans-
mission interval depends upon the configuration.
4. The HLR originates a request to the VLR where the MS is cur-
rently located to insert subscriber data (according to the quan-
tity of subscriber data, they can be inserted in one or more
packets).
5. The VLR where the subscriber is currently located responds and
acknowledges the subscriber data insertion with the HLR.
6. If the subscribers supplementary service data are ever mod-
ified, the HLR will send the supplementary service check re-
quest to the VLR where the subscriber is currently located.
7. The HLR confirms the location update request of the VLR.
4.1.2.3 GPRS Location Update
Service SGSN initiated location update to the HLR procedure is similar to

Description VLR location update. When the SGSN address received by the HLR

is inconsistent with the original SGSN address, the HLR will send
the location cancellation service to the original SGSN,
Service Flow Figure 35 shows the GPRS location update flow.
FIGURE 35 GPRS LOCATION UPDATE FLOW

1. The SGSN where the MS is currently located originates a loca-
tion update request to the HLR. The HLR determines whether
to allow this subscriber to roam. If yes, it will proceed with the
next step.
2. After the HLR receives the location update request from the
new SGSN where the MS is located, if the HLR has already
recorded the SGSN where the MS is located originally, the HLR
will initiate the location deleting operation to this SGSN (PS-
GSN), to request PSGSN to delete the data of this subscriber.
3. After deleting the subscriber data, the PSGSN sends an ac-
knowledgement message to the HLR.
4. The HLR originates a request to the SGSN where the MS is cur-
rently located to insert subscriber data (according to quantity
of subscriber data, they can be inserted in one or more pack-
ets).
5. The SGSN where the MS is currently located responds and ac-
knowledges with the HLR for subscriber data insertion.
6. The HLR acknowledges the location update request of the
SGSN.
4.1.2.4 Joint Location Update
Service If SGSN and MSC Server/VLR are connected through the Gs port,
Description the SGSN will notify the VLR to start location update after GPRS
location update. This process is called joint location update.
Service Flow Figure 36 shows the joint location update flow.

FIGURE 36 JOINT LOCATION UPDATE FLOW
After receiving the location update acknowledgement message of

the HLR, the SGSN sends a location update request expressed with
BSSAP + primitive to the VLR through the Gs interface. After re-
ceiving the message, the VLR updates the location. After location
update, the VLR returns location update acknowledgement mes-
sage (also expressed in BSSAP + primitive) to the SGSN to end
the joint location update process.
4.1.2.5 Periodical Location Update
Service When the MS is powered off, the UMTS/GSM network may fail to
Description obtain MS status change due to poor network conditions or other
reasons and still deems the MS as attached; the same case may
happen when the MS is powered on but roams out of the covered
area of the network. In both cases, if the subscriber is called,
the system will keep sending paging messages, wasting radio re-
sources.
To solve the above-mentioned problems, the measures of forced
registration are taken in the GSM system: The MS must make
registration at a regular interval. This is called periodical location
update.
However, if a subscriber is inoperative for a long time (determined
by system administrator, usually 24 hours), the VLR(SGSN) will
delete its subscriber data and notify.
The periodic location update flow is the same as that of the general
location update.

Service Flow Figure 37 shows the data deletion service flow requested by the
VLR/SGSN.
FIGURE 37 VLR/SGSN REQUESTED DATA DELETION FLOW
The service flow is described as follows:

1. The VLR (SGSN) requests MS data deletion.
2. The HLR resets with the Purge or SGSN Purge flag of this sub-
scriber and sends an answer message to the VLR (SGSN).
4.1.2.6 IMSI (GPRS) Attach/Detach
When an MS is powered off (or the SIM card is removed), this

MS cannot set up any connection. If the MSC (SGSN) still sends
normal paging to the MS, system resources will be wasted. Thus,
the IMSI (GPRS) attach/detach procedure is introduced to avoid
unnecessary waste of system resources.
During the MS power-on process
When the MS is powered on, the location update operation is
initiated. The location area of the MS is then registered in the
current MSCS/VLR (SGSN).
If the current MSCS/VLR (SGSN) has no record of the MS, then
it requests information of the MS to the HLR according to the
MSIMSI. The HLR then records the current location of the sub-
scriber (current MSCS/VLR(SGSN) number) and transmits sub-
scriber data to the MSCS/VLR(SGSN). The MSC/VLR will set the
subscriber status to attach.
If the MSC/VLR (SGSN) has the subscriber data, it need not ask
the HLR for the data. The MSC/VLR (SGSN) simply originates
location update and then sets the subscriber status to attach.
During the MS power-off process
When the MS is powered off, it will send a message to MSC/VLR
(SGSN). When the network receives this message, it regards
the MS as being powered off and sets the subscriber status as
detach.
The IMSI attach flow is the same as the general location update
flow.

4.1.2.7 Super-Charger Service
Service Super-Charger provides a mechanism to reduce mobility related

Description signal traffic when the MS performs location update between VLRs
or SGSNs.
In a network that supports Super-Charger, when the MS roams
from one NE to another, the original NE retains its subscription
data. The NEs here refer to MSCS/VLR and SGSN.
Service Flow Figure 38 shows the flow of location update initiated by the
VLR/SGN to the HLR in a network that supports Super-Charger.
FIGURE 38 LOCATION UPDATE FLOW IN A NETWORK THAT SUPPORTS

SUPER-CHARGER

1. The VLR where MS is currently located originates a location
update request to the HLR. The HLR determines whether to
allow this subscriber to roam. If yes, it will proceed with the
next step.
2. The HLR receives the location update request and determines
whether the PVLR supports Super-Charger. If not, the HLR
sends a location deletion request to the VLR/SGSN(PVLR/PS-
GSN) of the MS to delete MS data.
3. After the PVLR/PSGSN that does not support Super-Charger
deletes MS data, it sends a response message to the HLR. Af-
ter the HLR sends the location deletion request message, if the
PVLR/PSGSN returns a failure message, the HLR will retrans-
mit a request message according to the retransmission mech-
anism. The message retransmission times and retransmission
interval depends upon the configuration.
4. If the current VLR/SGSN of the MS retains subscription data,
such data comes from the last visit of the MS. The HLR deter-
mines whether the retained data is consistent with that stored
in the HLR according to time stamp check. The HLR sends MAP-
INSERT-SUBSCRIBER-DATA Request to the VLR/SGSN to insert sub-
scriber data only when the retained data is inconsistent with

data stored in the HLR. Data may be inserted in multiple pack-

ets.
5. The VLR/SGSN where the MS is currently located responds and
acknowledges with the HLR for subscriber data insertion.
6. The HLR confirms the location update request from the
VLR/SGSN.
4.1.3 Security Authentication

Management
Service UMTS authentication is implemented by means of Authentication

Description and Key agreement (AKA). In the AKA process, bi-directional au-
thentication is used: The network can authenticate subscribers;
on the other hand, the subscribers also can authentication the
network. In this way, unauthorized illegal subscribers cannot
access the network, and unauthorized illegal networks cannot
provide subscribers with services. Compared with GSM authenti-
cation, UMTS authentication has the following additional features:
Bi-directional authentication: network authentication initiated
by the subscribers is added.
The introduction and use of Sequence Number (SQN).
Use of authentication management or domain parameter AMF.
Authentication vector cannot be reused.
With these features, the security of the UMTS is improved.
Subscriber authentication needs the authentication quintuplet pro-
vided by the system. The quintuplet is generated in the AUC.
During registration, each subscriber is allocated an International
Mobile Subscriber Identity (IMSI). The IMSI is written into a USIM
card using a USIM card writer, and meanwhile a unique subscriber
key Ki corresponding to this IMSI is generated in the card writer
and stored in the USIM card and the AUC independently.
Parameters stored in the USIM and the AUC also include authen-
tication algorithms: f1, f2, f3, f4, f5, f1*, and f5*. The sequence
numbers SQNms and SQNhe are stored in the USIM and AUC in-
dividually. These sequence numbers change continuously during
the authentication. The AUC also has a pseudo random code gen-
erator, used to generate an unpredictable pseudo-random code
(RAND) for the subscriber. In addition, the AUC also stores pa-
rameter Authentication Management Field (AMF).
The figure below illustrates how the authentication quintuplet is
generated.

FIGURE 39 GENERATION OF AUTHENTICATION QUINTUPLET
RAND, Ki, AMF and SQNhe generate the authentication code

MAC-A by using the f1 algorithm of the AUC.
RAND and Ki generate the response number XRES by using the
f2 algorithm of the AUC.
RAND and Ki generate the Ciphering Key (CK) by using the f3
algorithm of the AUC.
RAND and Ki generate the Integrity Key (IK) by using the f4
algorithm of the AUC.
RAND and Ki generate the Anonymous Key (AK) by using the
f5 algorithm of the AUC.
If it is necessary to protect the SQN, use the AK to cipher the
SQN (exclusive or), and combine SQN, AMF and MAC-A into an
authentication token AUTN. Thus, RAND, XRES, CK, IK and AUTN
form a quintuplet.
Service Flow The figure below shows the normal UMTS authentication proce-
dure.
FIGURE 40 NORMAL UMTS AUTHENTICATION FLOW


1. According to the IMSI of a subscriber, the AUC finds such pa-
rameters as Ki, SQN and AMF of the subscriber in the data-
base, and meanwhile generates certain groups of pseudo-ran-
dom codes (RAND) and calculates the XRES, CK, IK and AUTN.
2. The HLR invokes the AUC interface function to obtain the au-
thentication parameter group. The UMTS subscribers apply
for the quintuplet, while the GSM subscribers apply for the
triplet. The maximum requested number of parameter groups
is five. After obtaining the authentication parameters success-
fully from the AUC, the HLR will check if the UMTS subscriber
accesses the network from the VLR/SGSN of R99 version and
below. If yes, the HLR needs to convert the quintuplet into
the triplet and also send the authentication parameter groups
to the VLR/SGSN; otherwise, the HLR does not make any con-
version and sends the authentication parameter group to the
VLR/SGSN directly.
3. The VLR/SGSN originates the authentication operation and
sends an RAND and an AUTN to the MS.
4. The MS obtains the authentication code XMAC-A by using the
same f1 algorithm according to Ki, RAND and AUTN. Then, the
MS will verify whether XMAC-A is equal to MAC-A. If not, it in-
dicates that the network is an illegal network, that is, the MS
fails in network authentication; otherwise, the MS will verify
whether the SQN is in a correct range. If the SQN is not in a
correct range, a resynchronization process will be generated;
otherwise it can be inferred the network is an authorized net-
work, that is, the MS has successfully authenticated the net-
work.
5. Based on Ki and RAND, the MS obtains RES by using the same
f2 algorithm, obtains CK by using the same f3 algorithm and
obtains IK by using the same f4 algorithm. Then, the MS sends
the calculated RES to the VLR/SGSN.
6. The VLR or SGSN compares the RES calculated by the MS with
the RES calculated by the AUC. If they are the same, it indicates
that the subscriber is a legal subscriber, and the network has
successfully authenticated the subscriber.
4.1.4 Subscriber Data Management
Service If the subscriber subscription information changes in the HLR,

Description the HLR will take the initiative in originating a synchronization
message to synchronize the subscriber data in the VLR/SGSN to
those in the HLR. There are two synchronization modes: Inserting
subscriber data and deleting subscriber data (these two message
types have the resending mechanism).
Inserting The subscriber data insertion flow to add or modify subscriber reg-
Subscriber Data istration information is shown in Figure 41.

FIGURE 41 FLOW OF INSERTING SUBSCRIBER DATA

1. The HLR originates a subscriber data insertion request to the
VLR or SGSN (in one or multiple packets, according to the
quantity of subscriber data).
2. After the VLR or SGSN successfully inserts the subscriber data,
it will return an acknowledgement.
Due to restrictions of the SS7 link TCAP layer, a message packet
cannot exceed 150 bytes. Therefore, if the subscriber data to be
inserted is oversized, the HLR must send the subscriber data in-
sertion message for several times.
Deleting To delete subscriber registration information, the HLR deletes sub-
Subscriber Data scriber data in the flow as shown in Figure 42.
FIGURE 42 FLOW OF DELETING SUBSCRIBER DATA

1. The HLR originates a request for deleting the subscriber data
to the VLR or SGSN.
2. After the VLR or SGSN successfully deletes the corresponding
subscriber subscription information, it will return an acknowl-
edgement.
4.1.5 Error Recovery Processing
Service Error recovery includes data recovery after restarting the VLR and
Description data recovery after restarting the HLR.
VLR Restart The VLR system might stop working due to faults or sudden power
failure. After VLR resetting, the data in the VLR must be recovered.
Two recovery methods are available:

If the VLR recovery operation is triggered during operations

such as making calls and sending short messages, the HLR will
send the data of this subscriber to the VLR. Figure 43 shows
the processing flow.
FIGURE 43 VLR RESTARTING SERVICE FLOW

i. The VLR sends a data recovery request to the HLR during
operations such as making calls and sending short mes-
sages.
ii. The HLR originates a subscriber data insertion request to
the VLR (in one or more packets, according to quantity of
subscriber data).
iii. The VLR where the subscriber is currently located responds
and acknowledges the subscriber data insertion with the
HLR.
iv. The HLR acknowledges the data recovery request of the
VLR.
The data recovery process incurred by location update is the
same as "IMSI-attach". See 4.1.2.6 for details.
HLR Restart After the HLR is restarted, it will send a RESET message to all the
VLRs and SGSNs that have been registered by subscribers in the
HLR before the restart. After the VLRs/SGSNs receive this mes-
sage, they will add the uncertain flag to the data of the sub-
scribers in this HLR. The VLRs/SGSNs perform location update in
the following MS wireless connection establishment to re-obtain
the subscriber data. Figure 44 shows the processing flow.
FIGURE 44 HLR RESTARTING SERVICE FLOW

MAP_RESET_Req does not need acknowledgement.
4.2 Operation and Maintenance

Functions
The following table introduces the operation and maintenance
(O&M) functions of the OMM system.
TABLE 1 OMM FUNCTIONS LIST
Function Description
MML Terminal The MML terminal management system is a data-

base management system with complete functions.
Its major purpose is to manage various system re-
sources. It provides the configuration data neces-
sary for the normal functioning of the system. Data
configuration fundamentally determines the opera-
tion mode and status of the switch. It is the core
of the entire system, and the most frequently used
part during background maintenance.
Fault Manage- The fault management system performs integrated

ment monitoring of the running of the entire system and
collects abnormal data of boards, links, databases
and servers. When faults occur or an index exceeds
the threshold, the alarm management system gener-
ates alarms, which help the maintenance personnel
to locate and troubleshoot the problems and guar-
antee stable system operation.
Performance The performance management system creates per-

Management formance data collection jobs, collects performance
data, queries performance data, and provides net-
work running status report and performance alarm
alert for users.
Version Manage- It provides the version information of all boards.

ment
Failure Observa- Failure observation is a tool for system debugging,

tion maintenance and observation. It provides accurate
and reliable maintenance measures for the operator.
It is easy to operate and provides accurate, rich and
reliable information. Through the failure observation
system, the operator can observe in real time con-
tents of failure data in the foreground process data
zone of the observation exchange system on the MML
interface of the maintenance agent.
Signaling Trac- The signaling tracing system provides a dynamic de-

ing bugging and observation tool for system. It enables
the operator to observe the signal coordination be-
tween the local office and the remote office and be-
tween independent entities in the local office during
system debugging.

Function Description
File Manage- The file management system is an important part

ment of the signaling gateway. It manages and main-
tains files and folders in the system. Major functions
are: folder and file management, including inquiry of
foreground devices, addition, deletion, name change
and inquiry of foreground and background folders
and files.
Dynamic Data The dynamic data management module provides

MML interface for system operators and mainte-
nance staff to observe and trace dynamic data
resources and perform other actions. It enables sys-
tem operators and maintenance staff to control and
observe the realization process of various functions
of the system, thus providing necessary technical
measures for system debugging and management.
It is a very important system maintenance tool and
observation tool.
Log Manage- The log management system allows the maintenance

ment staff to view the operation logs, security logs and
system logs in the database. In addition, the main-
tenance personnel can filter logs and assort them
according to their entry/exit sequences in order to
obtain useful information.
Security Man- The security management system defines security

agement management policies such as "role", "role set" and
"user". Through setting passwords and access rights
for the user account, it prevents unauthorized users
from accessing the system, ensures the legal use of
network resources, security and integrity of mainte-
nance operations, and satisfies confidentiality needs.
Topology Man- The topology management module collects topology

agement information from the source, and displays the topo-
logical relationships between NEs and their running
statuses through topology tree or topology map on
the user interface. The maintenance personnel can
operate on the topology map and navigate to differ-
ent application interfaces.
System Man- The system management system provides a unified

agement platform to maintain and manage the network
management system, through which users can
monitor and maintain the application server and
the database server.
Objects of system management include the
application server and the database server.
4.3 Administration Domain

Function
The Administration Domain Function (AMF) is introduced to the
USPP so that the USPP is divided into multiple administration do-
mains (VHLRs) according to administrative regions or other prin-
ciples (such as service functions). The service functions, service

provisioning, and operation and maintenance of each VHLR is in-

dependent, without any correlation with any other VHLR.
Figure 45 shows the VHLR division of HLR applications.
FIGURE 45 DIVISION OF INTERNAL VHLRS IN HLR
The AMF is a functional service entity, not a physical entity. It is

separated from the device, and its functions realized on physical
entities through OMM configuration. It provides the natural disas-
ter tolerance and near access function.


Glossary
AKA
Authentication and Key Agreement
AUC
Authentication Center
CAMEL
Customised Applications for Mobile Network Enhanced Logic
CB
Call Barring
CCF
Conditional Call Forwarding
CF
all Call Forwarding services
CMIP
Common Management Information Protocol
CORBA
Common Object Request Broker Architecture
CSI
CAMEL Subscriber Information
DCSI
Dialed Service CAMEL Subscription Information
GGSN
Gateway GPRS Supporting Node
GMLC
Gateway for Mobile Location Center
GMM
GPRS Mobile Management
GPRS
General Packet Radio Service
IMEI
International Mobile Equipment Identity
IN
Intelligent Network
ISDN
Integrated Services Digital Network
MAP
Mobile Application Part
MCSI
Mobility Management CAMEL Subscription Information
MF
Mediation Function
MO
Mobile Originated

MO_SMS
Mobile Originating Short Message Service
MSC
Mobile Switching Center
MSISDN
Mobile Station International Subscriber Directory Number
MT
Mobile Terminated
MT_SMS
Mobile Terminating Short Message Service
OCSI
Originating CAMEL Subscription Information
ODB
Operator Determined Barring
PDP
Packet Data Protocol
PSPDN
Packet Switched Public Data Network
PSTN
Public Switched Telephone Network
QoS
Quality of Service
RAN
Radio Access Network
SC
Short Message Center
SCEP
Service Creation Environment Point
SCP
Service Control Point
SDP
Service Data Point
SGSN
Service GPRS Supporting Node
SIM
Subscriber Identity Module
SMAP
Service Management Access Point
SMP
Service Management Point
SMS
Short Message Service
SNMP
Simple Network Management Protocol
SRF
Specialized Resource Function
SSCSI

Glossary
Supplementary Service CAMEL Subscription Information

SSF
Session Service Function
SSP
Service Switching Point
TCSI
Terminating CAMEL Subscriber Information
TDP
Trigger Detection Point
TIFCSI
Translation Information Flag CAMEL Subscription Information
UCSI
USSD CAMEL Subscription Information
UGCSI
USSD General CAMEL Subscription Information
UMTS
Universal Mobile Telecommunication System
USSD
Unstructured Supplementary Service Data
VC
Voucher Center
VLR
Visitor Location Register
VT
Video Telephone
VTCSI
VMSC Terminating CAMEL Subscription Information
XML
eXtensible Markup Language

ZXUN USPP V4 (HLR) - BC-EN-Theoretical Basic-Interface Protocol-Interfaces and Services PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ZXUN USPP V4 (HLR) - BC-EN-Theoretical Basic-Interface Protocol-Interfaces and Services PDF

Hochgeladen von

Copyright:

Verfügbare Formate

ZXUN USPP

Universal Subscriber Profile Platform

HLR Interfaces and Services

Copyright 2010 ZTE CORPORATION.

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

Publishing Date (MONTH/DATE/YEAR) : 08/09/2010

Interfaces and Services................................................ 1

will be able to:

Confidential and Proprietary Information of ZTE CORPORATION 1

Chapter 1 Product Interfaces

1.1 Interfaces with Other NEs

FIGURE 1 HLR LOCATION IN UMTS R4 NETWORK

2 Confidential and Proprietary Information of ZTE CORPORATION

In the UMTS R4 network, the GMSC server is responsible for

Confidential and Proprietary Information of ZTE CORPORATION 3

Gf interface between EIR and SGSN

1.2 Service Provisioning Interfaces

FIGURE 2 NETWORKING METHOD OF HLR SYSTEM AND BOSS

FIGURE 3 INTERFACE STACK OF HB INTERFACE

According to the format prescribed in HB protocol stack, the BOSS

4 Confidential and Proprietary Information of ZTE CORPORATION

1.3 Operation and Maintenance

FIGURE 4 OPERATION AND MAINTENANCE INTERFACES (DUAL-LEVEL

FIGURE 5 OPERATION AND MAINTENANCE INTERFACES (SINGLE-LEVEL

N (Northbound) interface with the NMS center

Confidential and Proprietary Information of ZTE CORPORATION 5

This page is intentionally blank.

6 Confidential and Proprietary Information of ZTE CORPORATION

2.1 Call Services

FIGURE 6 ROUTE CALLING FLOW

The flow is described as follows:

Confidential and Proprietary Information of ZTE CORPORATION 7

4. The HLR provides the requested routing information of the

2.1.2 Support of Optimal Routing

FIGURE 7 ROUTING OPTIMIZATION FOR BASIC CALLS

8 Confidential and Proprietary Information of ZTE CORPORATION

1. VMSCS A sends an IAM message to route an outgoing call to

FIGURE 8 OPTIMAL ROUTING PRINCIPLE FOR CONDITIONAL FORWARDING

2. The GMSCS uses forwarding information received from Resume

Confidential and Proprietary Information of ZTE CORPORATION 9

2.2 Supplementary Services

The subscription status of the supplementary services can only

2.2.2 Registering Supplementary

Service The registration operation applies to the call forwarding services

10 Confidential and Proprietary Information of ZTE CORPORATION

FIGURE 9 SUPPLEMENTARY SERVICE REGISTRATION FLOW

The flow is described as follows:

2.2.3 Deleting Supplementary Services

Confidential and Proprietary Information of ZTE CORPORATION 11

FIGURE 10 SUPPLEMENTARY SERVICE DELETION FLOW

The flow is described as follows:

2.2.4 Activating Supplementary

Service The activation operation is applicable to the call forwarding, call

12 Confidential and Proprietary Information of ZTE CORPORATION

FIGURE 11 SUPPLEMENTARY SERVICE ACTIVATION FLOW

The flow is described as follows:

2.2.5 Deactivating Supplementary

Service The deactivation of supplementary service is applicable to call for-

Confidential and Proprietary Information of ZTE CORPORATION 13

FIGURE 12 SUPPLEMENTARY SERVICE DEACTIVATION FLOW

The flow is described as follows:

2.2.6 Interrogating Supplementary

Service SS interrogation means interrogating the data related to supple-