Anda di halaman 1dari 36

Mobile Product Support Center

Content
MSC POOL
s
CS Dual-home Disaster Recovery
Seamless Upgrade
Unified NM Platform
SIP
Networking Technologies in IP-lization
SBCS Server
USPP

Disaster-tolerant HLR
AAA

MSC POOL (Part I)


MSC POOL is a new function introduced in 3GPP R5. It helps to realize disaster
recovery and load-sharing at MSC level.
In traditional network mode, one BSC/RNC can belong to only one MSC and
different MSCs manage different BSC/RNC and they are independent from each
other. If one MSC gets overloaded or out of order, we have no choice but to cut the
BSC/RNC it manages to other MSC, which is inconvenient and risky.
After the introducing of MSC POOL, MSCs can form a POOL and BSC/RNC they
manage can also form a POOL. MSC and BSC/RNC are no longer one-to-one
related. One BSC/RNC can be controlled by any MSC in the POOL meanwhile any
MSC in the POOL can serve all BSC/RNC.
In MSC POOL, one RNC/BSC is connected to all MSCs in the POOL therefore we
need to pick a MSC for service originated by subscriber in the RNC/BSC. The
function of choosing service MSC for subscribers is called NNSF (NAS Node
Selection Function) and the choice is made according to NRI (Network Resource
Identifier) in subscribers TMSI, which means TMSI must be used in POOL. NRI
corresponds to one and only one MSC in POOL but one MSC can have more than
one NRI. If subscribers TMSI is not allocated by any MSC in POOL or the service
is originated with IMSI, NNSF chooses one MSC in the POOL as the service MSC
according to the load-sharing algorithm and the MSC allocates TMSI that contains
NRI to the subscriber.

MSC POOL (Part II)


After that, NNSF can route service originated by the subscriber to MSC that
NRI corresponds to so all services originated by subscribers in the POOL can
be routed to the MSC where the subscriber is registered and service MSC does
not need to be changed when subscriber is roaming inside the POOL.
Therefore, there is no handover and re-selecting among MSCs in one POOL so
there are less signaling messages at Interface C/D as compared to traditional
network. When a subscriber switches into POOL, MSC outside the POOL
configures any MSC in the POOL as the target MSC. When a subscriber moves
out of POOL, all MSCs in the POOL need to configure the adjacent MSC as the
target MSC of HO because any MSC in POOL can be the source MSC.
When a MSC Server in MSC POOL is out of order, NNSF can detect it through
SP state check. Once subscribers whose NRIs correspond to the out-of-order
MSC originate service, NNSF allocated the services to other MSCs in the POOL
according to algorithm so that services will not be affected. When subscribers
in the out-of-order MSC originate LU or calls, MSC ID held in HLR will be
updated so that this part of subscribers can be called normally. However, some
of such subscribers may be called before they perform LU or originate calls. To
address this issue, we need to configure a standby MSC for every MSC in the
POOL and active MSC synchronizes subscriber information to standby MSC.
Once active MSC is out of order, HLR will send PRN message to standby MSC
who will carry on the MT process of the subscribers.

MSC POOL (Part III)


When one MSC Server in MSC POOL gets overloaded, we can execute
NM command to move subscribers among MSCs in the POOL without
affecting their services.
At NNSF, set MSC whose subscribers need to be moved out as offload;
When subscribers in the off-load MSC originate services, the MSC
allocates TMSI with Null NRI to the subscribers meanwhile indicates
that current LAI of the subscribers is Non-broadcast LAI so that the
subscribers can start location update immediately;
After NNSF receives LU messages that contain Null NRI from
subscribers, it picks an effective MSC according to capacities of all
effective MSCs in the POOL (off-load MSC excluded) and routes the
service to the picked MSC. We can move part of or all subscribers
out of a MSC or relocate relevant BSC/RNC, subscribers with specific
LAI or subscribers with specific MSISDN/IMSI.
NNSF can be realized by BSC/RNC. However, as a lot of BSCs need to
be upgraded to achieve NNSF in commercial network, which will be very
challenging, we can implement it in MGW.

CS Dual-home Disaster Recovery (Part I)


Definition
Dual-home mode is one type of disaster recovery mechanism of
MSCS, in which standby MSCS is configured for active MSCS. Once
active MSCS is out of order, standby MSCS will take over its functions
and carry on service. Standby MSCS should have
Signaling point same as active MSCS to external network
Same services as active MSCS
Fault-detecting method for active MSCS
Manual take-over of services

Dual-home system changeover


Automatic
Manual

Automatic changeover happens when the standby node


detects heartbeat is down and registrations in MGW exceed
halt of the configured number.

CS Dual-home Disaster Recovery (Part


II)
ZXWN CS supports two modes of signaling backup
Link sharing
Rout PRI
Link sharing is link-level backup. Adjacent offices take active and standby
nodes as one signaling point and allocate a certain number of SLC/STCP to
active and standby nodes. Active MSCs SLC/STCP to adjacent offices are
open so active MSC can communicate with adjacent office. Standby MSCs
SLC/STCP to adjacent offices are blocked and it does not take part in
signaling and service processing.
Link sharing mode is easier for configuration and we only need to
configure half of SLC/STCP from STP to active and standby nodes
respectively.
Disadvantages:
Half of links are always in idle state, a waste.
Blocked links generate alarm.

CS Dual-home Disaster Recovery (Part III)


Route PRI is route level signaling backup. Configure active
signaling route for active node and configured standby signaling
route for standby node at adjacent offices. When everything is OK,
the active node works and adjacent offices communicate with it
through active route. When active node is out of order, adjacent
office switches to standby node through standby route.
The advantage is that less links are needed in 1+1 mutual
backup and N+1 active-standby modes. Compared to link
sharing, half of links can be saved for 1+1 mutual backup mode
and N-1/N of links can be saved for N+1 active-standby mode.
The shortcoming is that configuration will be more
complicated and not so reliable as link-sharing mode.
ZXWN CS V3.07.40 does not support route PRI mode of IP link
backup at this moment.

CS Dual-home Disaster Recovery (Part IV)


Dual-home static data synchronization
Static data synchronization has two types by how it is triggered.
Manual sync: Click sync to synchronize data to standby node after
configurations at active node are done.
Timed sync: Active node synchronizes data to standby node periodically.
Different data at standby node will be overwritten.
Static data sync can be categorized into another two types by sync
principle.
Forced sync: synchronize data and resource tree at same time and
overwrite resource tree at the standby node.
Unforced sync: Synchronize data to standby node but do not
synchronize resource tree. Data not in resource tree of the standby node
will be discarded.
It is suggested that timed sync should be disabled during configuration
and maintenance at active node because there will be frequent data change
during that period.

CS Dual-home Disaster Recovery (Part V)


Dual-home dynamic data synchronization
Dual-home system dynamic data synchronization can synchronize
subscription and authentication data of subscribers to standby node
so as to reduce volume shock from standby node to HLR upon
changeover. Dynamic sync also has two types.
Instant sync: Active node synchronizes changed data to
standby node instantly after subscription or authentication data
are changed.
Periodic sync: Active node synchronizes local data to standby
node every 6 hours. The two types of sync work together to best
avoid data difference between active and standby nodes.

Seamless Upgrade (Part I)


Upgrade foreground versions and synchronize
background configurations to OMP during foreground
upgrade. Boards need to be restarted for one or more
times and services will be interrupted completely during
the restart. Such approach of upgrade will cause at least
10 minutes of service interruption even with the best
design of procedure. Moreover, boards need to be
restarted again during version rollback if upgrade fails,
making service interruption even longer.
The solution sums up relevant operations involved in NE
upgrade and provides quick upgrade in Version
Management. It has the following advantages.
Reduce time of service interruption during upgrade.
Interruption time is shorter than 5-minute if there are
standby boards;
Easy automatic operations during upgrade;
Support remote operation for rollback.

Seamless Upgrade (Part II)

Version functions can take effect only after boards are restarted and
during the restart, board functions are definitely interrupted.
To avoid service interruption, we need to load new versions to standby
boards, switch the original standby boards to active and then load new
versions to the original active boards to complete loading of new
versions.

Seamless Upgrade (Part II)

Version functions can take effect only after boards are restarted and
during the restart, board functions are definitely interrupted.
To avoid service interruption, we need to load new versions to standby
boards, switch the original standby boards to active and then load new
versions to the original active boards to complete loading of new
versions.

Seamless Upgrade (Part III)


Major version upgrade
There is no specific requirement for change of interface before and after
upgrade. Usually Z1 in version ID will change, for example from ZXWN
CSV3.07.10 to ZXWN CSV3.07.20. Apart from normal startup of work
mode, start and suspend mode will be added, in which boards load
version files from FLASH after power-on and basic processes will be
suspended after power-on is finished and logic address is got and service
processes will not be powered on.
Standby boards are set to Start and suspend mode when loading new
versions. Then halt running of active boards and standby boards take over
the active role and continue power-on process and enter work mode. By
such means, services will be interrupted only during power-on of service
processes, which is estimated to be shorter than 5 minutes.

Seamless Upgrade (Part IV)


Minor version upgrade
Interface change shall be limited inside the application layer
before and after upgrade and only affects service protection
between active and standby boards, which means changes only
happen in data areas of the application layer while other
interfaces do not change. (Other interfaces herein refer to data
synchronization between active and standby nodes and all
interfaces between boards and interfaces between network
elements and OMM system.) In such upgrade, usually Z2 in
version ID will change, for example from ZXWN CSV3.07.21 to
ZXWN CS V3.07.22.
Active-standby sync should be disabled before upgrade. Then
upgrade standby boards to new version and make active-standby
changeover and continue.
This method of upgrade will release all stable and unstable
services but new services can be accessed immediately and the
upgrade appears to be interruption-free to outsiders.
Estimated time of service interruption is below 1 minute.

Seamless Upgrade (Part V)


Patch upgrade
External interfaces of boards shall remain unchanged or totally
compatible after upgrade (Interfaces herein refer to interfaces
between active and standby nodes, interfaces between boards
and interfaces between network elements and OMM system.)
Usually P,B(I,T) in version ID will change, for example from
CS3.07.20 to CS3.07.20.P1 and from ZXWN CS V3.07.20.P1 to
ZXWN CS V3.07.20.P2.
In this kind of upgrade, boards configured in active-standby
mode can be upgraded through changeover. As for load-sharing
boards, we need to unload services from them group by group
and upgrade them also group by group.
Such means of upgrade will interrupt services in load-sharing
boards but services in active-standby boards will not be
interrupted and new services can be accessed instantly.

Seamless Upgrade (Part VI)


Hot patch upgrade
Board change shall be limited at function level after
upgrade and external interfaces shall not be
changed at all. Usually the patch ID in version ID will
change (patch ID is an optional lowercase English
letter, a-o ), for example from ZXWN
CSV3.07.20.P1.B1 to ZXWN CSV3.07.20.P1.B1a or
from ZXWN CSV3.07.20.P1.B1a to ZXWN
CSV3.07.20.P1.B1b.
This type of upgrade adopts hot patch method and
boards do not need to be restarted and services will
not be interrupted.

Unified NM Platform EMS 4X Functions


Support multi-process deployment
Support distributed deployment
Small in size
Unified northbound interface and EMS can be configured as northbound interface processor
Able to integrate with other nets to form unified NM system
Support all-net rack diagram monitor, able to monitor board state and alarms, support alarm
confirmation and cleaning.
Support multi-dimension stat. monitor of alarms
Performance stat. support creating of cross-NE all-NE and all-object jobs
Performance stat. support gathering by all-NE, NE and object
Performance stat. support filter and sequencing by indicator, for example, TOP10 of a timer
Support right and domain division
Support MSC POOL management
Support powerful CTS, support tracking on entire call flow from RNC/BSC to MSCS/GGSN
EMS supports maintainable and measurable framework to improve efficiency of troubleshooting

Unified NM Platform EMS Functions


Centralized topology management
Centralized alarm management (including rack alarm display)
Centralized performance statistics
Centralized command terminal (configuration management)
Security management
Log management
Job management
Backup restoration
Configuration view
VLR subscriber data management
Northbound UniEMI alarm interface, middle-DB interface
System installation
UEP4X is a big step-forward as compared to 3X. (Main interface provides unified gateway;
Performance sub-system style change, two operation perspectives of resource and counter to
achieve better availability)

SIP (Part I)
SIP is an application control (signaling) protocol put forward by IETF. It is used
to originate dialog. It can be used to create, change or terminate multimedia
session attended by a number of parties. Participants of the session can
communicate with one another through multicast, unicast or mix of the two.
SIP has client and server. Client is the application for sending requests to server
and establishing connection with it. User Agent and Proxy have client. Server is
the application for providing service on clients request and returning reply.
There are four types of basic servers.
User agent server: It contacts user and responds on behalf of user when it
receives SIP request.
Proxy server: It sends request on behalf of other servers. It plays the role of
server and media program of clients. Before transferring a request, it can
change the original request.
Re-directing server: It receives SIP request and maps the original address in the
request into zero or a number of new addresses and return to the client.
Registration server: It receives registration request from clients and completes
registration of user address. Users terminal programs usually need to include
User Agent client and User Agent server. Proxy server, re-directing server and
registration server can be seen as public network servers. Another concept,
positioning server, is often mentioned in SIP. However, positioning server is not
a kind of SIP services.

SIP (Part II)


SIP gives full amount of consideration to
extension to other protocols. It supports a
rich variety of address description and
addressing methods, including
username@host address, called
number@PSTN gateway address and Tel:01062281234. So calling party can find position of
called party in traditional telephone network
according to its address and originates and
set up call through a gateway connected to
the telephone network. The most useful
function of SIP is user positioning. SIP itself
has the function of registering to registration
server or strengthening its positioning
function by other positioning services
provided by other DNS and LDAP.

SIP supports three approaches of


call:
direct call from user agent client
(UAC) to user agent server (USA)
re-directing call by UCA with the
help of re-directing server
agent server originating call to
called party on behalf of UAC

Networking Technologies in IP-lization(I)


In traditional network, end office of soft-switch system is built in the
architecture as described below.
Establish direct links between MSCS and local HLR and LSTP;
Establish direct voice channels and links between MSCS and local
GMSC. ISUP links are transferred by MGW M2UA and LSTP serves as
the primary alternate signaling route;
Establish direct voice channels and links between MSCS and local
MSC. ISUP links are transferred by MGW M2UA and LSTP serves as
the primary alternate signaling route;
Establish direct voice channels between MSCS and Office A, SSA and
B. ISUP signaling messages are transferred by LSTP.

Networking Technologies in IP-lization(II)


After IP-lization, end office of soft-switch system will be like
Establish direct links between MSCS and local HLR and LSTP;
If GMSC has not been IP-lized yet, direct voice channels need to be
established between MSCS and local GMSC and ISUP signaling
messages are transferred by built-in SG of MGW through M3UA. If
GMSC has been IP-lized, direct BICC links shall be established
between MSCS and GMSC and traffic between MGW and GMGW is
borne by IP;
Direct BICC links shall be established between MSCS and local
MSCS and traffic between MGW and local MGW is borne by IP;
Direct voice channels shall be established between MSCS and local
MSC and ISUP messages shall be transferred by built-in SG of MGW
through M3UA;
Direct voice channels shall be established between MSCS and
office A and B and ISUP messages shall be transferred by LSTP;
Direct BICC links shall be established between MSCS and SSA and
traffic between MGW and TMG is borne by IP.

SBCS Server
SBCS (Single Board Computer Sossaman) can be seen as a small server
platform that appears as a board physically. It can be plugged in ATCA shelf and
ATCA provides power, monitor and interfaces to it. SBCS has front and rear cards
and both support hot-swap and hot redundancy backup. After operation system,
drivers and service applications are installed, it can be used as an independent
service-processing unit to store data and process services.
Windows, KLinux and SUSE can run in SBCS. It offers two SATA hard disks
(5400 rmp, 160GB) through LSISAS1064E, two fiber interfaces through QLOGIC
EP2432, four 10/100/1000M adaptive Ethernet ports through INTEL 82571 and two
10/100M adaptive Ethernet ports through INTEL 82551. The system and chips
require support of BIOS and FW when working.
There are three types of front SBCS for ATCA, SBCS, SBCO and SBCW, and two
types of rear board, RSBC and RSGC.
RSBC is the earliest rear board of SBCS and it can only be used on SBCS. It
provides a few debugging interfaces. Its software does not support RSBC
hardware management. RSGC is the new and can be used on
SBCS/SBCO/SBCW. Besides debugging interfaces, it also has giga-byte ports,
FC optical ports and SCSI interfaces. Its software supports RSGC hardware
management.

USPP (Part I)

USPP is the Universal Subscriber Profile Platform in communication network. It


provides functions of network elements based on subscriber profile
management, such as PSTN HLR, PCS HLR, SS HLR, WCDMA HLR/HSS and
CDMA HLR. It provides services like subscriber authentication, data
management and routing.

USPP (Part II)


From an overall view, USPP consists of FE subsystem, UDS
subsystem, PROVISION subsystem and NM subsystem and they
are responsible for signaling and service processing, data
management, service provisioning and network management
respectively.
FE Front end includes signaling and service processing
modules for various applications.
BE Back end includes PROVISION and UDS subsystems.
PROVISION Responsible for registration and de-registration
of subscribers and subscription and de-subscription of
services in USPP. It consists of service provisioning client
(agent and interface server), server (DBIO) and comprehensive
maintenance tool.
UDS Universal Directory Server is the DB sub-system of
USPP. Subscriber data are held in memory DB of UDS. There
are two types of data permanence, commercial DB and file
storage.

USPP (Part III)


Management domain is the smallest unit of subscriber
group for services in USPP and it is the fundamental unit
that constitutes USPP applications. Management domain
does not include any equipment. Services, data
management and operation & maintenance of
subscribers in each management domain are
independent from that of another domain.
Compared to V3 equipment, USPP features larger DB
capacity, general DB, integrated network elements,
distributed and richer variety of disaster recovery. It is an
indispensable substitution of V3 equipment.

Disaster-tolerant HLR (I)


Disaster-tolerant HLR is usually deployed away from active HLR.
When active HLR goes out of order and cannot be restored within
short period of time, the disaster-tolerant HLR will take over all
services from the active HLR.
ZTE disaster-tolerant HLR has the following modes of working.
1+1Consist of two sets of ZTE HLR, one active and one
standby;
N+1 by one vendorN sets of ZTE HLR as active and one set of
ZTE HLR as standby;
N+1 by different vendorsN sets of HLR of other vendor as active
and one set of ZTE HLR as standby.
The following two issues are essential for disaster-tolerant HLR.
SynchronizationStandby HLR shall stay consistent with active
HLR;
ChangeoverStandby HLR shall take over services when active
HLR is out of order.

Disaster-tolerant HLR (II)


ZTE disaster-tolerant HLR synchronizes data in two parts, static and dynamic.
Subscriber data changed at background DBIO are categorized as static data,
including subscriber data modified by agent or BOSS.
Subscriber data changed by HLR on MAP notice are categorized as dynamic
data, such as location information change in VLR and SS registration.
Dynamic data synchronization is realized by ZTE private MAP. Direct links are
established between active and standby HLRs so active HLR sends dynamic sync
message to the other side through private MAP when it detects dynamic data
change. (Dynamic data sync is not supported if other vendors are involved
because of incompatible protocol. So HLRRESET needs to be sent before
changeover can take place.)
Management domain is the smallest unit of subscriber group for services in USPP
and it is the fundamental unit that constitutes USPP applications. Management
domain does not include any equipment. Services, data management and operation
& maintenance of subscribers in each management domain are independent from
that of another domain.
Compared to V3 equipment, USPP features larger DB capacity, general DB,
integrated network elements, distributed and richer variety of disaster recovery. It
is an indispensable substitution of V3 equipment.

Disaster-tolerant HLR (III)


The basic principle of changeover is that all outgoing links of
active HLR are blocked and MSC/VLR/SGSN/LSTP finds that
signaling office direction of active HLR is unreachable or SSN
subsystem is unusable so they send messages to the standby
HLR.
Disaster-tolerance changeover has two modes, SSN backup
subsystem and signaling point interception.
Backup SSN subsystem mode: For every SSN subsystem of the
active HLR, configure backup SSN subsystem to standby HLR
at MSC/VLR/SGSN/LSTP.
Signaling interception mode: Configure standby route to the
standby HLR for the active HLR at MSC/VLR/SGSN/LSTP and
configure at standby ZTE HLR so that messages with
destination SPC being the active HLR will be intercepted and
processed as its own service and standby HLR returns
response to the source side.

AAA Concept
AAA Authentication Authorization Accounting
Authentication
Authentication method: SimpleIP, MobileIP, Mobile Proxy Agent
Authentication method: PAP, CHAP, MD5-Challenge, EAP-TTLS, EAPTLS, EAP-AKA

Authorization
User Profile authorization
APN authorization

Accounting
Get billing info from PDSN/GGSN/AGW/AC Postpaid, prepaid, hot
billing
Billing mode: subscriber-based billing (or IP session-based billing)
and packet data flow-based billing
Billing mode: duration-based, volume-based and tariff switch

Radius Proxy Functions


Proxy transfers authentication, authorization and accounting
messages.
Realm-based route, IMSI-based route, MSISDN-based route, default
route and route with designated IP

AAA Network Architecture


PPS/SCP server/service-control node interface 1: used as
3GPP2 packet PPS interface and SCP PPS interface of China
Unicom;
Packet data service node interface 2 of PDSN CDMA
network: interface to PDSN, used for authentication,
authorization and billing, based on RADIUS
Home proxy interface 3 of HACDMA or WiMAX network:
HA-to-AAA authentication and billing interface in mobile IP
services, based on RADIUS
Access network equipment interface 4 of ANCDMA DO
network: authentication interface for DO subscribers access
to network, based on RADIUS
HLRCDMA home location register interface 5: Cave needs
to get authentication information from HLR in DO network of
China Unicom, based on SS7
ASN-GW interface 6 in AGWWiMax network:
Authentication, authorization and billing interface for WiMAX
network access, based on RADIUS

AAA Network Architecture


GPRS NM service node interface 7 of GGSN3GPP network:
Authentication, authorization and billing interface for GPRS
network access, based on RADIUS
BRAS broadband, DSL access server interface 8:
Authentication, authorization and billing interface for
broadband access, based on RADIUS
WapGateWAP gateway interface 9: WAP network
management, AAA transfers RADIUS billing messages
Other AA remote AAA, as middle AAA or home AAA,
interface 10: proxy transfers RADIUS
BOSS billing and accounting system, provide subscriber
provisioning functions, interface 11: Provide MML interface
for subscriber data maintenance and FTP provides CDR
output interface. The interfaces are not discussed in this
document.
Home subscription server interface 12 of HSS3GPP
network: Support early IMS services and undertake direct
interface change between GGSN and HSS.

AAA System Architecture


AAA server AAA server consists
of dual-server system and disk array. It
runs such AAA processes as RADIUS
and billing. Disk array holds subscriber
information, billing information and
billing CDRs.
Provisioning Client local AAA
provisioning client, which undertakes
local service provisioning
OMM Server Provide OMM
functions
OMM Client Undertake local OMM
client functions
AAA DBIO Provide connection
between AAA and BOSS system to
realize BOSS provisioning and client
provisioning.
Alarm box sound and flash alarm
box

AAA Network Functions


Transfer
Radius_Accounting _Requst
Allow active and standby
WAPGWs to have different IP
addresses
Support simultaneous
transferring of several Radius
servers
Proxy repeat 3 times
Consecutive failure
counter
Give out alarm when
failure counter reaches
threshold