Mobile Product Support CenterMobile Product Support Center

ContentsContents

MSC POOL

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 subscriber’s 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 subscriber’s 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 affe

cting their services. At NNSF, set MSC whose subscribers need to be moved out as off-l

oad; 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 MSC’s SLC/STCP to adjacent offices are open so active MSC can communicate with adjacent office. Standby MSC’s 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 configur

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

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

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 principl

e. Forced sync: synchronize data and resource tree at same time and over

write resource tree at the standby node. Unforced sync: Synchronize data to standby node but do not synchroniz

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

uring that period.

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.

CS Dual-home Disaster Recovery (Part V)

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.

Before

Right

Left

Old version New version

Standby board upgrade

Right

Left

Old version New version

Upgrade standby board and changeover

Original active board upgrade

Right

Left

New version New version

Upgrade original standby board

Active

StandbyBoard state

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.

Minor version upgradeInterface 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 IV)

Seamless Upgrade (Part V)

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

Hot patch upgradeBoard 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.

Seamless Upgrade (Part VI)

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 client’s 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:010-62281234. 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.

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.

Networking Technologies in IP-lization(II)

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

FE PROVISION

UDS subsystem

FE PROVISION FE PROVISI

ON

OMC

Others like STP BOSS SystemOther

applications

OMC interface

LDAP interface MML interface

Signaling interface

Signaling transfer interface

NMS

Northbound interface

Subscriber notice change interface

UMT

Maintenance tool interface

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.

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.

USPP (Part III)

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+1—Consist of two sets of ZTE HLR, one active and one standby; N+1 by one vendor—N sets of ZTE HLR as active and one set of ZTE HLR as standby; N+1 by different vendors—N 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. Synchronization—Standby HLR shall stay consistent with active HLR; Changeover—Standby 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, EA

P-TLS, 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) a

nd packet data flow-based billing Billing mode: duration-based, volume-based and tariff switch

Radius Proxy Functions Proxy transfers authentication, authorization and accounting messa

ges. Realm-based route, IMSI-based route, MSISDN-based route, default r

oute 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 subscriber’s 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 counte

r

Give out alarm when failure counter reaches threshold