MSC Pool VMS6 Presentation

GU CS MSC Pool Network Design Training Material
CN Professional Service Team
www.huawei.com
HUAWEI TECHNOLOGIES CO., LTD.
All rights reserved
(Optional) Principle of the MSC Pool
All rights reserved
Page 2
Contents
Principles and Functions of the MSC Pool
Huawei MSC Pool Solution
All rights reserved
Page 3
Networking Topology of the MSC Pool

Traditional networking MSC Pool networking
BSS
BSS
The most typical difference between the MSC Pool network and the traditional network is that the topology between core network nodes and wireless network nodes changes from one-to-multiple tree topology in the traditional network to multiple-to-multiple mesh topology in the MSC Pool network. With the absence of the virtual MGW technology, all A interfaces and all Iu interfaces must interwork. Viewed from the access network side, the MSC Pool acts as an MSC server with an extra-large capacity.
All rights reserved
Page 4
Softswitch Networking Topology of the MSC Pool MSC servers are

MSC Server
distributed for service processing. MGWs act as interface boards.
IP Backbone
Virtual MGWs are used.
MGW
BSS
The virtual MGW technology can be used to avoid the interworking of all A interfaces.-just for manage A interface
All rights reserved Page 5
Technical Principles of the MSC Pool

MSC Server 1 MSC Server2 MSC Server3
The NRI allocated for the user is carried in the TMSI.
NNSF component
2. Positive location update response
NNSF: NAS node selection function
1. Location update request
The NNSF detects a new location update request destined for the MSC Pool and routes the request to an MSC server in the MSC Pool according to a sharing algorithm.(focus that it is location update) The MSC server allocates an NRI for the user. Then, all in-pool service requests of the user are routed by the NNSF to the MSC server that possesses the NRI. The NNSF function can be provided by the BSC/RNC. In the softswitch networking of the separated architecture, the NNSF function can be provided by the MGW with the A/Iu interface unchanged.
HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 6
Principle of NNSF Implementation on the BSC/RNC

The NRI allocated for the user is carried in the TMSI.
MSS1 MSS2 MSS3MSS4
When the RNC detects a new location update request destined for the MSC Pool, the RNC routes the request to an MSS in the pool according to a sharing algorithm. The MSS allocates an NRI carried in the TMSI for the user. Then, all in-pool service requests of the user are routed by the RNC to the MSS that possesses the NRI.
MGW-A Ma1 Ma2 Ma3 Ma4
Mb1 Mb2 Mb3 Mb4MGW-B
1. New location update request 2. Positive location update response
RNC
All rights reserved
Page 7
Principle of NNSF Implementation on the MGW

The NRI allocated for the user is carried in the TMSI. When the MGW detects a new location update request destined for the MSC Pool, the MGW routes the request to an MSS in the pool according to a sharing algorithm. The MSS allocates an NRI for the user. Then, all in-pool service requests of the user are routed by the MGW to the MSS that possesses the NRI. The RNC chooses an MGW based on the link balancing principle.
MSS1 MSS2 MSS3MSS4
MGW-A
Ma1 Ma2 Ma3 Ma4
Mb1 Mb2 Mb3 Mb4MGW-B
RNC
1. New location update request 2. Positive location update response
All rights reserved
Page 8
Relationship Between TMSIs and NRIs

TMSI structure: 31 30 29
VLR-restart
28~24
User ID range
23-14
use NRI range
13~0
User ID range
CS/PS
Bit 31 and bit 32 indicate whether a TMSI is used by the CS domain or PS domain, that is, whether it is a TMSI or P-TMSI. Bit 29, namely, VLR-restart, is a counter used to ensure that different TMSIs are allocated by the MSC server or VLR on the mobile network for a user before and after the MSC server restarts. Bits 14 to 23 indicate the range of NRIs that can be used by the MSC Pool. One or multiple bits of these 10 bits can implement this function. At present, the 10 bits are temporarily used to indicate user IDs on the GSM network to enlarge the number of users that can be managed by the MSC server. The remaining bits, that is, bits 0 to 13 and bits 14 to 28, indicate the range of user IDs that are allocated for users by the MSC server or VLR.
All rights reserved
Page 9
Resource Sharing and Load Sharing in the MSC Pool

MSC
Users are evenly distributed to the MSC servers in the pool.

. RNC RNC RNC
All rights reserved
Page 10
Home MSC Server Remaining Unchanged in the Case of Roaming Within the MSC Pool
STP
HLR/SCP/SMSC
MSC
This function reduces the traffic on the C/D interface, enhances the MSC capacity gain, and decreases inter-office handovers.
. RNC RNC RNC
All rights reserved
Page 11
Saving the Total Capacity and Investments

MSC
The traffic peaks in different areas and different periods are balanced without considering the maximum traff load in each area, thus saving the total capacity.
. RNC RNC
Residential area
RNC
RNC
Business area
RNC
All rights reserved
Page 12
Implementing Network Disaster Recovery

MSC
If an MSC server in the MSC pool is faulty, another MSC server in the pool takes over the users of the faulty MSC server.
. RNC RNC RNC
If the user is the caller, the service recovers immediately; if the user is the callee, the service recovers after a location update.
If the user is the caller, the service recovers immediately. If the user is the callee, the service recovers after a periodical location update.
Contents
Principles and Functions of the MSC Pool
All rights reserved
Page 14

Solution Where BSC Upgrade Is Not Required Solution of Sharing TDM Circuits of the A Interfaces
Optimized Solution for the Called Service

Load-balancing Solution Simplified OM Solution
MGW Implementing the A-Flex Function

MSS
MSS
MSS
All MSC servers use the same signaling point for interworking with the BSC; thus, the BSC senses only one MSC server.
User distribution
User distribution
User distribution
A-Flex function
BSC1 BSC2 BSC3
The MGW implements the AFlex/Iu-Flex function, and the A/Iu interface is not changed. When the MGW is used in the 2G network, the number of BSCs that need to be upgrade is less. This makes the solution easy to implement. When the MGW is used in the 2G network, if the RNC supports the Iu-Flex function, you can disable the Flex proxy function of the MGW through software so that multiple networking modes can be supported.
All rights reserved
Page 16

Solution Where BSC Upgrade Is Not Required Solution of Sharing TDM Circuits of the A Interfaces Optimized Solution for the Called Service Load-balancing Solution
Simplified OM Solution
Difficulties in A Interface Management in the MSC Pool

Current situation
Traditionally, A interface circuits are managed by MSC servers. Lower efficiency in using A interface circuits More complicated planning and adjusting of A interface circuits Every time an MSC server is added to the MSC Pool, the TDM circuits of the A interfaces of all MSC servers in the pool must be re-planned and adjusted. More complicated routine OM of the A interface circuits To maintain a circuit, for example, to block a circuit, you must locate the MSC server that manages the circuit and then block the circuit on the MSC server; if the circuits to be blocked are managed by different MSC servers, you must block the circuits on their respective MSC servers. If an MSC server breaks down, the A interface circuits managed by the MSC server become unavailable.
Difficulties after the MSC Pool is adopted
All rights reserved
Page 18
Lower Efficiency in Using A Interface Circuits

MSC Server MSC Server
Mc
Mc
MGW
MGW
BSC
BSC
The efficiency of using A interfaces decreases. For example: A company has 100 employees and 10 vehicles. The 10 vehicles are just enough for the company. If the company is divided into 10 branches, each of which has 10 employees and one vehicle, maybe some branches need more vehicles while the vehicles of others are idle.
More Complicated Adjustment and OM of the A Interface Circuits

MSC Server 1 MSC Server 2 MSC Server 3 MSC Server 4
When the MSC Pool is expanded, the following problem arises:
Every time an MSC server is added to the MSC Pool, the TDM circuits of the A interfaces of all MSC servers in the pool must be re-planned and adjusted.
MGW
Routine OM of the A interface circuits becomes more complicated after the MSC Pool is adopted.
BSC
To maintain a circuit, for example, to block a circuit, you must locate the MSC server that manages the circuit and then block the circuit on the MSC server; if the circuits to be blocked are managed by different MSC servers, you must block the circuits on their respective MSC servers.
Page 20
All rights reserved
A Interface Circuits Unable to Be Shared

MSC Server 1 MSC Server 2 MSC Server 3 MSC Server 4
MGW
Circuits are managed by MSC servers, causing the following problem:

If an MSC server is faulty, the circuit management function of the MSC server is unavailable. As a result, the A interface circuits managed by the MSC server cannot be used although the circuits are normal. This is a waste of resources.
BLOCK
BSC
All rights reserved
Page 21
Solution to Sharing A Interface Circuits

Details
The MGW configures and manages A interface circuits in place of the MSC server. To set up a call, the MSC server asks the MGW for A interface circuits. The MGW is responsible for allocating and managing A interface circuits. The commands for routine OM of the circuits are delivered by
the OM center to the MGW, and the MGW implements routine

maintenance and management of the A interface circuits. Using the MGW to manage A interface circuits can share the A interface circuits among all MSC servers in the MSC Pool.
All rights reserved
Page 22
Solution to Sharing A Interface Circuits

MSC Server 1 MSC Server 2 MSC Server 3
Benefits for operation
Management of A interface circuits
TDM circuits are shared among multiple virtual MGWs to prevent resource waste in the case of MSC server failures and to increase the efficiency of using the A interface circuits. The OM is simple when A interface circuits are managed by the MGW. Adjustment of A interface circuits is not required even if MSC servers are added to the MSC Pool.
A interface circuits are shared.
BSC1
BSC2
BSC3
All rights reserved
Page 23

Solution Where BSC Upgrade Is Not Required
Solution of Sharing TDM Circuits of the A Interfaces Optimized Solution for the Called Service Load-balancing Solution
Reason Why the Called Service Cannot Be Recovered Immediately

STP The HLR fails to about user The information obtain HLR updates the the server 1 is server MSC roaming number 2, location to MSCstored HLR/SCP/SMSC from MSC HLR. can on the server and follow-up calls 1. be connected successfully.
MSC1
MSC2
GMSC-Server
The MS is called.
. RNC RNC RNC
If the user is the caller, the service recovers immediately; if the user is the callee, the service recovers after a location update.
MS
Solution to the Called Service in At the STP, specify the active route A-B to the MSC Pool MSC server 1 as a direct route.
At the STP, configure the route A-E-B to MSC server 1 with a low priority. HLR OPC:1A When MSC server 1 functions properly, the direct route, that is, the route with a high STP1 priority, is used for the signaling interworking between node A and node B. Standby route If MSC server 1 is faulty, the direct route fails. MAP/CAP signaling Active route Then, PRN messages are sent to node E along the low-priority route, and node E enables the multiple signaling point technology so that the signaling of the callee is terminated at node E. MSC-Server1 MSC-Server2 MSC-Server3 MSC-Server4 After receiving the PRN messages, MSC server 4 obtains the location information from Node B Node C Node D Node E the VLR and delivers paging based on the IMSI. After receiving the paging response, the MGW/BSC routes the paging response to an MSC server in the pool based on the loadMGW/BSC balancing algorithm. Then, the MSC server enables MSC virtual location update to The VLR on MSC server 4 backs up the basic update the MSC/VLR data on the HLR. VLR user data on all MSC servers in the pool. The first called service fails, and follow-up The functions of MSC server 4 can be provided by called services can be connected other MSC servers in the pool. successful.
Node A HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 26

Load Balancing Through User Re-distribution Adaptive Load Balancing
Application Scenario
The user re-distribution solution is generally used in the following scenarios for user migration:
Routine maintenance, for example, important upgrade operations Fault clearance Pool adjustment, for example, adding or removing MSC servers
The user re-distribution solution is applicable to significant manual adjustment. The principle is as follows:
The OM center delivers the load re-distribution command to the MSC
server and specifies target MSC servers so that idle users can migrate to
the target MSC servers. Users migrate to target MSC servers through load sharing, thus completing the load adjustment among MSC servers.
User Re-distribution
Migration of all users
MSC Server1 MSC Server2 Upgrade Rollback
MSC Server3 O&M
IP bearer
Before upgrading one or multiple MSC servers in the pool, you must ensure that all users of the MSC server(s) migrate to other MSC servers in the pool. This prevents the upgrade from interrupting user services.
Migration of some users

To which MSC server the user belongs After the upgrade is complete, some users of other MSC servers need to migrate to the upgraded MSC server(s). Through the OM configuration, specify the number of users or percentage of current registered users that migrate from the MSC server. When the specified value is reached, the migration operation automatically stops.
User Re-distribution in the NMS
User re-distribution on the NMS is applicable to the following scenarios: 1. All the users of an MSC server migrate to other MSC servers in the MSC Pool. 2. A certain percentage of the users of an MSC server migrate to other MSC servers in the MSC Pool. 3. A certain number of the users of an MSC server migrate to other MSC servers in the MSC Pool.
4. The users from the specific BSC/RNC to an MSC server migrate to other MSC servers in the MSC Pool.
5. The users in specific areas of an MSC server migrate to other MSC servers in the MSC Pool. 6. The specified users (specified by the MSISDNs obtained through the IMSIs) of an MSC server migrate to other MSC servers in the MSC Pool.
Non-MS Manual Uninstallation in the MSC Pool

HLR 1. A user initiates the location update service or another calling service. 2. MSC server 1 determines that the user requires uninstallation, specifies MSC server 2 as the uninstallation office, starts the inter-office uninstallation process, and then sends an interoffice location update message to MSC server 2. 3. After receiving the inter-office location update message, MSC server 2 attempts to process it according to the normal location update process but does not detect any user data, and then MSC server 2 initiates the independent location update process to the HLR. 4. The HLR returns a positive location update response. Then, MSC server 2 returns the positive location update response to MSC server 1. In addition, MSC server 2 uninstalls the allocated TMSI and sends the TMSI to MSC server 1. 5. After receiving the positive location update response, MSC server 1 sends the TMSI allocated by MSC server 2 to the MS to complete the TMSI re-allocation process. 6. For the uninstallation triggered by a location update, the uninstallation is completed successfully after the TMSI carried in the positive location update response is returned. For the uninstallation triggered by a call, the TMSI of the MS is updated in the TMSI re-allocation process initialed after the call is complete. Page 31
3 5
MSC-Server1 Node A
2 6
MSC-Server2 Node B
MGW/BSC
The key for MS uninstallation is that the NRI in the TMSI is refreshed to the NRI of the target MSC server. The MSC server number in the HLR is refreshed to the target MSC server number.
HUAWEI TECHNOLOGIES CO., LTD. All rights reserved

Load Balancing Through User Re-distribution Adaptive Load Balancing
Application Mode and Scenario

Adaptive load balancing is generally applied in the following scenarios: When the link between an MSC server and the BSC fails for a short time or encounters other abnormalities, the users of the MSC server migrate to other MSC servers. After the link recovers, these users cannot migrate back to the original MSC server automatically. Thus, after a long period, the load of the MSC servers in the pool may be slightly inconsistent with the preset load percentage. Frequent manual intervention may complicate the OM process. Users always roam to or out of MSC servers. If the number of users roaming to or out of the pool varies with MSC servers, unbalanced load occurs. Adaptive load balancing is suitable for slight automatic adjustment. The principles are as follows: The MSC servers can broadcast the current load to its connected MGW so that the MGW can dynamically adjust the load of MSC servers based on the available capacity of each MSC server. Whether to enable broadcast, the start time of broadcast, and the broadcast period can be set. The MGW distributes new users who access the MSC Pool based on the available capacities broadcasted by the MSC servers. The key is the automatic adjustment and distribution algorithm.
All rights reserved
Page 33
Adaptive Load Balancing Through Active Load Notification

Assumption MSC Server 1 1:1 MSC Server 2
IP bearer
BSC
BSC
Benefits for operation The load notification mechanism between MSC servers and MGWs does not involve wireless NEs. Load notification is implemented within the CN, and close coupling of CN nodes and RAN nodes is not required. In the previous, the BSC cannot adjust load distribution without manual intervention because the A interface between the MSC server and the BSC does not support load notification. This mechanism solves this problem.
All rights reserved
Page 34

Solution Where BSC Upgrade Is Not Required
Solution of Sharing TDM Circuits of the A Interfaces Optimized Solution for the Called Service Load-balancing Solution
Changes in OM Brought by the MSC Pool

After the MSC Pool is introduced, the OM changes in the following aspects:
Heavier OM workload: The data configuration workload is doubled. More complicated OM: The service-related data consistency must be ensured. Changes to the performance measurement mode: The location-related
measurement entities are distributed on multiple MSSs.
All rights reserved
Page 36
Centralized MSC Pool Management Implemented by the MSC Pool Management Module of the M2000
Unified maintenance of MSC Pool parameters
MSC Pool parameters must be maintained in a unified manner over the entire network. Thus, the MSC Pool service model is established on the M2000 on the basis of thorough analysis on the service parameters. Then, maintenance of the MSC Pool parameters can be synchronized among all NEs in the pool.
Synchronous data configuration of multiple NEs

Synchronous data configuration of multiple NEs can be implemented.
All rights reserved
Page 37
MSC Pool Network Design Training
All rights reserved
Page 38
Audience, Purpose, Scope
Audience
GU CS MSC Pool network design delivery engineer and
service marketing engineer
Purpose

Familiarize with the MSC Pool source design principle Familiarize with the MSC Pool common structure of traffic network, signaling network and access network Learn MSC Pool billing principle Learn MSC Pool common migration principle
Scope
GU CS MSC Pool feature network design
All rights reserved
Page 39
Reference

GU CS MSC Pool HLD Reference Guide
GU CS HLD Template
MSOFTX3000 MSC Pool User Manual MSC Pool Network Planning Guide MSC Pool White Paper.doc
All rights reserved
Page 40
Contents
Pool Area planning and Pubilc Attribute planning
Signalling Network Design

MT Recovery Solution Traffic Network Design Access Network Design Billing Solution Design
All rights reserved
Page 41
Contents

Key design principles of MSC Pool common attribute is as follows:
MSC Pool area planning

NRI planning Default MSC planning
Non-broadcast LAI planning

Handover to target MSC Server in MSC Pool planning
All rights reserved
Page 42
Glossary
A-Flex/ Iu-Flex: A key technology used for implementing MSC Pool networking. As stipulated in 3GPP 23.236, A-Flex/ Iu-Flex enables one BSC or RNC to connect to multiple MSC servers. MSC Pool: A pool constituted by a group of MSC servers that serve multiple BSCs or RNCs. Pool Area: An area in the MSC Pool in which an MS can roam without changing the serving CN node. NRI: The Network Resource Identifier that uniquely identifies a CN node in a Pool Area. The NRI, consisting of 0 to 10 digits, is carried in the TMSI (in the CS domain) or the P-TMSI (in the PS domain). NNSF: An NAS Node Selection Function node used to choose CN nodes in an MSC Pool. Default MSC: The default MSC server used to transfer messages for obtaining subscriber information between MSC servers in the MSC Pool and MSC servers outside the MSC Pool. Virtual MGW: A technology that enables a physical MGW to connect to multiple MSC servers.
All rights reserved
Page 43
MSC Pool Area Planning Principle

One MSC Pool area could consists of high traffic area and low traffic area One MSC Pool area could be the area which the population migrate frequently. For example, the city center and suburbia can be planned as an MSC Pool area. This planning can reduce the location update times between CN nodes.
The RAN of an MSC Pool should be a whole areaLAI coverage in an MSC Pool is continuous ). This planning can reduce handover times between MSC Servers and make the traffic balanced in an MSC Pool.
The subscriber capacity and service which can be provided should be the same for all the CN nodes in an MSC Pool.
Nnormally, CN nodes in an MSC Pool do not provide service for the BSC/RNC outside the MSC Pool.
All rights reserved
Page 44
NRI Planning
POOL1 POOL2 POOL3 POOL4
Plan principles 1One NRI belongs to only one MSC Server in MSC Pool but one MSC server in MSC Pool could be configured more than one NRI.; 2The NRI value of each area in one MSC POOL should try to be unique but the length should be the same 3The length of NRI depends on the quantity of planning subscribers; 4The Null-NRI and the NRI should be planned on a uniform basis. The maximum or minimum value of the NRI in an NRI set within an MSC Pool can be selected as the Null-NRI. It is proposed that the NRI should be planned by Four-Color-Method in the whole network.
For exampleThe length of NRI is 6 bitsthe value could be 0~63NRI group 10~15 NRI group 216~31 NRI group 332~47 NRI group 448~63.
All rights reserved
Page 45
Default MSC Planning

Once one subscriber is roaming out from MSC Pool area. This subscriber will take the LAI which is the old LAI in MSC Pool. When this subscriber registers to a non-pool MSC, the non-pool MSC can find the MSC in pool area according to the old LAI. The MSC which is found by the non-pool MSC is the default MSC. The default MSC can confirm the pre-MSC address according to the NRI which is in the TMSI. If only one MSC is configured as default MSC, the signaling flows is very huge in this MSC. The huge signaling flows may disturb the default MSC.
Planning Principle:
MSC5 MSC6
In order to keep the signaling is balanced in MSC Pool, the MSC out of MSC Pool should connect to different default MSC
MSC2
MSC3
in MSC Pool.
Pool area
MSC1
In order to increase the resource usage, the MSC out of MSC Pool should connect to the location nearest MSC in
MSC4
MSC Pool while the traffic is TMD based.

Handover Target MSC Planning

There will have a handover when a subscriber out of MSC Pool is roaming to the MSC Pool area. To keep the traffic balanced and the handover successful rate normal, following factors should be considered:
In an MSC Pool the proximate MSC Server to handover origination MSC is

the handover target MSC. Consider the signaling balance in MSC Pool.
In project, the handover target MSC is normally the default MSC in MSC Pool.
All rights reserved
Page 47
Non-broadcast LAI Planning
The Non-broadcast LAI is a special LAIthe function of Non-broadcast LAI refers to MSC Pool White Paper. The Non-broadcast LAI is encoded together with ordinary NRI on a uniform basis, but it cannot be the same as any LAI already configured in the MSC Pool.
You can configure the Non-broadcast LAI according to the descending order or
ascending order based on actual configuration of the LAI.
Each MSC in an MSC Pool should be configured with a Non-broadcast LAI of the local office and an MSC maps a unique Non-broadcast LAI.
Each MSC in an MSC Pool should be configured with the Non-broadcast LAI of
all other offices in the same MSC Pool. Non-broadcast LAI is not configured in BSC or RNC.
All rights reserved
Page 48
What is the planning principles of MSC Pool area? What is the NRI planning principles in a MSC Pool? Is the planning result of Default MSC and Handover Target different?
Why the Non-broadcast LAI of other MSC should be configured in

every MSC of a MSC Pool?
All rights reserved
Page 49
Contents

All rights reserved
Page 50
Contents

Key design principles of this section are as follows:
Signaling network design principles

Common signaling network structure and analysis
All rights reserved
Page 51
Signaling Network Design Principle
The capacity of the nodes in the MSC Pool should be balanced. The nodes serve as the VMSC (not recommended to concurrently serve as the GMSC and TMSC). In addition, the nodes should provide the same services. The MSC Pool networking requires the IP-based Mc, Nc, and Nb interfaces. The MSC Server and MGW in the MSC Pool are connected in full mesh mode. It is recommended that the signaling connection between the MSS and the pure signaling NEs such as the SMC, SCP, and HLR in the MSC Pool is transferred through the STP, and the STP is directly connected to the MSS. Generally, the BICC signaling adopts the direct connection mode. It is recommended that the trunk signaling between the MSS in the MSC Pool and the TDM office outside the MSC Pool should be transferred through the independent TDM/IP interworking office. When an independent TDM/IP interworking office is unavailable, the signaling should be transferred through one pair of MSS in the MSC Pool. The trunk signaling to the PLMN/PSTN is transferred through the GMSC. It is recommended that the signaling of service NEs such as VMS, IVR, and CRBT with traffic is transferred through the GMSC or TMSC. There is signaling connection between BSC/RNC and all MSC Servers in the MSC Pool. The M3UA transfer mode is recommended for the BSSAP and RANAP. The centralized backup mode is recommended for VLR subscriber data backup.
All rights reserved
Page 52
Common Signaling Structure First Sample
All rights reserved
Page 53
Common Signaling Structure Second Sample
All rights reserved
Page 54
Sample Analysis
The networking is applicable to scenario where the IP-based reconstruction is implemented in the GMSC, with the following advantages: The maintenance and management are convenient. The capacity of each node in the MSC Pool must be the same. In this way, the load of each node in the MSC Pool is balanced. All signaling to external TDM offices is transferred through the independent IP-based GMSC. Each node in the MSC Pool features the unique function, consistent signaling route configuration, and clear signaling network architecture. These features facilitate the data planning and daily maintenance management. VLR subscriber data is in the centralized backup mode. The data configuration, operation, and maintenance are simplifie The network can be expanded and developed conveniently. The signaling to the HLR/SMSC/SCP is transferred through the STP. When a node is added to the MSC Pool, only the signaling link between the STP and the new node should be established. This decreases the complexity of the expansion project. The trunk signaling to external TDM office directions is transferred through the GMSC. When a node is added to the MSC Pool, only the IP signaling link between the GMSC and the new node should be established. This decreases the complexity of the engineering implementation. VLR subscriber data is in the centralized backup mode. When a node in the MSC Pool is added, the backup relation between nodes in the MSC Pool needs not to be redesigned. This simplifies the expansion workload.
The second solution can reduce MGW number while the traffic is very few between MSC Pool and other MSC.
One Pair IP/TDM Interworking Office Solution-I
All rights reserved
Page 56
Sample Analysis
In the scenario where the GMSC exists in the target network and the independent IP/TDM interworking office is not planned in the target network, it is recommended that one pair of MSS in the MSC Pool should be selected to concurrently function as the TDM/IP interworking office. The advantages are as follows:
The trunk signaling to external TDM office directions is transferred through the GMSC, without establishing the signaling link between the nodes in the MSC Pool and office directions outside the MSC Pool. This simplifies the data configuration and reduces the engineering implementation workload. The signaling from nodes in the MSC Pool to the GMSC is transferred through two MSC Servers, without establishing the signaling link between each node in the MSC Pool and the GMSC. This simplifies the data configuration and reduces the engineering implementation workload. When a node in the MSC Pool is added, a signaling link should not be established for office directions outside the MSC Pool.
With the increase of the MSC Pool capacity, the MSC Server concurrently functioning as the interworking office gradually becomes an independent IP/TDM interworking office. In the networking, the physical connections or data configurations of each NE are not changed greatly during the evolution. This eases the smooth network evolution.
All rights reserved
Page 57
One Pair IP/TDM Interworking Office Solution-II
All rights reserved
Page 58
Sample Analysis
In this scenario where the independent GMSC is unavailable in the target network, it is recommended that one pair of MSS in the MSC Pool concurrently functions as the GMSC/TMSC, to transfer the trunk signaling between other nodes in the MSC Pool, PSTN/PLMN, and external TDM office directions. Benefits:
Only two MSC servers in the MSC Pool are used to concurrently function as the GMSC, without exposing the networking architecture in the MSC Pool. The utilization ratio of the link to the PSTN/PLMN increases. When the number of nodes in the MSC Pool is expanded, the modification of the data configuration in the PSTN/PLMN is not required. Only two MSC Servers in the MSC Pool concurrently function as the TMSC to transfer the trunk signaling from the local network to other office directions. The data configurations are simplified and the engineering implementation load decreases. In the case of the expansion of the MSC Pool, the modification of data configurations in other office directions outside the MSC Pool is simplified. The functions of the nodes in the MSC Pool feature are relatively single, which facilitates the network evolution. Note:
The MSC Pool is not recommended in this scenario, because the data configuration and maintenance management are
more complicated, and the load of NEs in the MSC Pool is unbalanced. In addition, this networking is not according with the trend of the network evolution.
All rights reserved
Page 59
Question
Please describe the signaling solution of MSC Pool.
All rights reserved
Page 60
Contents

All rights reserved
Page 61
Contents

Introduction of MT recovery solution MT recovery solution (The data configuration principle and application scenarios of Route Priority mode and SCCP Load-sharing mode)
All rights reserved
Page 62
MT Recovery Solution
In MSC Pool network, the MT recovery solution is not mandatory. Huawei provides two MT recovery solution for customer. The First MT recovery solution and the second MT recovery solution.
The first MT recovery solution and the second recovery solution are configured by software parameter in HUAWEI device. The different of network structure: The signaling link is not necessary between VLR and NNSF Node (MGW/BSC) while using the central backup in the first MT recovery solution.
The restriction of the first MT recovery solution: a. In 2G network, the NNSF node (BSC or MGW) can realize the first MT recovery solution. b. In 3G network, if MGW acts as the NNSF node can realize the first MT recovery solution.
c. In 3G network, if RNC acts as the NNSF node can realize the first MT recovery solution.
This is only available for HUAWEI R11 RNC.
All rights reserved
Page 63
User Data Backup Solution

To provide MT Recovery Solution, the backup MSC server must back up subscriber data on the active MSC servers.
Central backup solution There is independent MSC Server in the central backup solution. This MSC Server backups all the MSC Servers user data information. Central backup MSC Server only processes the MT recovery service.
Chain backup solution There is no independent MSC Server in the chain backup solution. Every MSC Server in MSC Pool processes the self-service and the same time acts as the backup MSC Server of other MSC Server in the MSC Pool.
All rights reserved
Page 64
Signaling Route Design

In MSC Pool MT recovery solution, while the primary MSC Server is down, the backup MSC Server only process the PRN message which should be sent to primary MSC Server. The MT recovery solution signaling route design requirement:
The PRN message which should be sent to primary MSC Server must be sent to backup MSC Server. The ISUP message which should be sent to primary MSC Server
must not be sent to backup MSC Server.
All rights reserved
Page 65
Signaling Route Design- SCCP Load Share

As figure show, MSC Server 2 is backup MSC/VLR of MSC Server 1. SCP AA1 is configured in MSC Server 1, SCP AA2 is configured in MSC Server 2. The GT to MSC Server 1 is configured as AA1+SSN in STP and AA2 is configured as the loading-sharing SCP of AA1. The priority of AA2 is lower than AA1. The translation mode of from HLR to MSC Pool is GT.
For centralized backup mode, only one SPC need to be configured in active MSC Server. Also only one SPC need to be configured in backup MSC Server. The SPC of backup MSC Server is the assistant SPC and the priority is lower than the SPC of active MSC Server.
Signaling Route Design- Route Priority First

Trunk Signaling not through STP MSC Server2 is the backup MSC/VLR of MSC Server 1, the trunk signaling is not through
STP. Only one SCP AA1 will be configured in

MSC Server 1. It is used to process self-service. There are two SCP need to be configured in MSC Server 2. One is the SCP AA2 and another is AA1 the same as MSC
Server1. (CAP service is not configured in

AA1, only VLR sub-system need to be configured for MAP service and AA2 is the backup SPC of AA1 )
For centralized backup mode, the configuration of active MSC Server is the same as above. For backup MSC Server, one SPC of MAP service need to be configured. The SPC of active MSC Server also need to be configured in backup MSC Server but only for VLR sub-system. The relationship of these two SPC need to be configured too.
ThinkingWhat problem will come out if the trunk signaling is through STP in this solution?
Trunk Signaling Resend Problem
When active MSC Server is down, only paging message and PRN message will be processed in backup MSC Server. If other messages (M3UA/MAP/CAP) are sent to backup while active MSC Server was down, the resource boards of backup MSC Server will become heavy.
Signaling Route Design- Route Priority First

Trunk Signaling through STP Each MSS is allocated with two signaling points: one is for processing trunk signaling, and the other is for processing the MAP/CAP. At this time, two routes must be configured on the STP: The direct route from the STP to the BB1 of the MSS1 is set to the route with the higher priority. The alternative route from the STP to BB1 with passing BB2 of the MSC2 is set to the route with the lower priority. The MSC addressing mode in the STP and MSC server in the MSC Pool should be set to the DPC addressing. In MSC2, the BB2 should be set to the assistance signaling point of the BB1, without configuring the assistance signaling point of AA1.
Trunk Signaling through STP

The data configuration of Route
priority mode is so complex
So, SCCP Loadsharing mode is adopted. It is much more easier.
1SCCP Load-Sharing mode is recommend when STP supports SCCP Load-Sharing mode. 2Route Priority mode is recommended when STP does not support SCCP Load-sharing mode.
All rights reserved
Page 70
Question
What is the difference between the first MT recovery solution and the second MT recovery solution? What is the reason of trunk signaling resend problem?
Please describe the signaling route design solution (SCCP Load Share and
Rout Priority Fist).
All rights reserved
Page 71
Contents

Traffic Network Design Access Network Design Billing Solution Design Network Migration Design
All rights reserved
Page 72
Contents

Key design principles of this section is as follows:
Traffic network design principle

Common traffic network structure and analysis
All rights reserved
Page 73
Traffic Network Design Principle
MGWs in the MSC Pool must be connected over IP in the full mesh. It is recommended that the traffic from a node in the MSC Pool to a service NE (for example, VMS, IVR, and CRBT) should be transferred through the interworking office. It is recommended that the traffic from a node in the MSC Pool to a traditional MSC outside the MSC Pool should be transferred through the interworking office. It is recommended that the traffic from a node in the MSC Pool to the PSTN/PLMN should be transferred through the GMSC. For the traffic interconnection between a node in the MSC Pool and the TDM office direction outside the MSC Pool, the TDM circuit directly led out from the MGW inside the MSC Pool is not recommended, because the TDM resources between virtual MGWs cannot be shared. It is recommended that the traffic between the MGW in the MSC Pool and the TDM office direction outside the MSC Pool should be transferred through the independent IP/TDM interworking office. If the IP/TDM interworking office is not planned in the target network, it is recommended that only one pair of MGW in the MSC Pool should be used to establish the circuit with the TDM office direction outside the MSC Pool. The traffic between a node in the MSC Pool and the TDM office direction outside the MSC Pool should be transferred through one pair of MGWs.
All rights reserved
Page 74
Common Traffic Network Structure First Sample
Pool MSC The traffic route form Pool to outside Internal call in MSC Pool; The call between MSS MS in same MSC Server; The call of MS in MSS different MSC Servers
All rights reserved
Page 75
Analysis
The MSC Pool traffic networking is recommended, the benefits are as follows:
The MGW function in the MSC Pool is unique, which facilitates the planning of the MGW capacity and the load balance between MGWs. The TDM circuit needs not to be led out from the MGW in the MSC Pool. This reduces the complexity of the engineering implementation and daily maintenance management. The networking architecture is clear, which facilitates the network evolution and expansion.
All rights reserved
Page 76
Common Traffic Network Structure Second Sample

MSS2/MSS3 are the IPTDM interworking MSC Servers
MGW3/MGW4 are the IPTDM interworking MGW
Non-IP GMSC
All rights reserved
Page 77

Configure one interworking circuit direction in every IP-TM interworking office
All rights reserved
Page 78

Configure interworking circuit in all IP-TM interworking offices
All rights reserved
Page 79
Analysis
For the solution of all interworking office circuits configured in each interworking MGW, the traffic of Nb interface decreases. The redundancy protection capability is available in the interworking MGW. The limitations of this solution include the decrease of the trunk circuit utilization, and the complexity of the engineering implementation and management maintenance.
In the scenario where the node in the MSC Pool concurrently functions as the interworking office, the solution of one interworking office direction circuit configured in each interworking MGW is recommended.
All rights reserved
Page 80
GMSC/TMSC Interworking (Multi-area)

In Multi-area network, the virtual MGW in MSC Pool will connect to all the local GMSC/TMSC to
insure the route reliability. Normally, the virtual MGW will not connect to the GMSC/TMSC in other area.
Local Area 1 MSS1 MSS2 Local Area 2
MGW1 V1 V2 V3 V4
MGW3
BSC1
GMSC1
GMSC2
BSC3
All rights reserved
Page 81
Question

What is the trunk CIC resource management in MSC Pool network? What is the advantage and disadvantage when the MGW trunk CIC resource is arranged to only one MSC Server?
All rights reserved
Page 82
Contents

All rights reserved
Page 83
Contents

Key design principles of this section is as follows:
Common access network structure and analysis

M3UA agent mode and M3UA forwarding mode
All rights reserved
Page 84
Access Network Structure

There are two interconnection solution between MGW and BSC/RNC when the A/Iu interface is not IP based. If there is no redundancy requirement, the first solution is recommended.
The first solution One BSC connects to one MGW

The second solution: One BSC connects to more MGW

M3UA Forwarding Mode

The MSC Server in MSC Pool commutates with BSC use different SPC BB and CC. MGW communicates with MSC Server use different SPC DD and EE. MGW communicates with BSC use the same SPC AA. BSC communicates with MSC Server using the same DPC AA. This is the M3UA forwarding mode.
For exampleThe signaling
route between MSC Server

and BSC is
MGW will change the SPC into AA in down-link and will change the DPC into BB in up-link.
All rights reserved
Page 86
M3UA Agent Mode

The MSC Server in MSC Pool communicates with BSC using the same SCP AA but communicates with other CN element using different SPC XX and YY.
MGW communicates with MSC Server using the same SPC AA.
BSC communicates with MSC Server using the DPC AA. All above is the M3UA agent mode.
All rights reserved
Page 87
2G/3G Signaling Access Solution

MSC Server1 BB MSC Server2 CC
The M3UA forward mode is adopted when the RNC is IP based. This solution is adopted when the RNC is ATM based. The RNC should be configured more than two DPC when the RNC is ATM based as most RNC can support one DPC
MGW1 DD
EE AA
MGW2 NN
AA
MM
mapping multi-ATM address.

XX YY
BSC1
BSC2
BSC3
RNC1
Pool Area
All rights reserved
Page 88
Question
Please describe the influence what the M3UA forward mode to uplink message and downlink message. What is the design solution when the RNC is ATM based?
All rights reserved
Page 89
Contents

All rights reserved
Page 90
Contents

Common billing network structure

Virtual MSC ID billing and LAI billing
All rights reserved
Page 91
Billing Principle
Billing system can not recognize the location of subscriber according to origination MSC ID, so the charge can not be confirmed. This is because of every MSC Server can server all LAI in MSC Pool.
What can we do?
There are two solutions, one is virtual MSC ID billing and another is LAI
billing.
All rights reserved
Page 92
Virtual MSC ID Billing

MSC Pool Physical MSC Server1 Virtual MSCB Virtual MSCA 8613900753 8613900752 Physical MSC Server2 Virtual MSCA' Virtual MSCB ' 8613900754 8613900755
MGW
A
MGW
A
MGW
A
MGW
A
BSC
BSC
BSC
BSC
Local Area A
Local Area B
One physical MSC is divided into multi-virtual MSC, every virtual MSC is arranged one independent MSC ID. One virtual MSC ID belongs to one local area.
All rights reserved
Page 93
LAI Billing
The system specifies the LAI in caller and callee CDRs outgoing from the local office. The local office allocates roaming numbers according to the LAI. The GMSC can map the location of the callee
according to the called roaming number to charge the subscriber. To implement the charging of the
Free Roaming to Same City for IN subscribers, the SCP uses the ATI procedure to obtain the location information of the caller and callee in the calling and called processes to implement the precision charging.

Requirements of peripheral NEs in the LAI charging are as follows: The BOSS should support the LAI-based charging. The SCP should support the ATI process of obtaining the location information. The HLR should support the PSI process of obtaining the location information from the MSC.
All rights reserved
Page 94
Analysis
Charging Mode
Virtual MSC ID charging
Benefits
1.It does not have special requirements on peripheral NEs. 2. Mature applications are available in the existing networks.
Limitations
1. Many MSC IDs are required. 2. Data configurations are complicated. 3. The number of inter-office location updates or interoffice handovers increases in the case of roaming between different MSC servers in the MSC Pool. The traffic of C interface or D interface may increase.
LAI Charging
1. It reflects location information. The data configuration is simplified. 2. The benefits of the MSC Pool networking are not affected.
1. The current BOSS system should be reconstructed. 2. The SCP in the current network should support the ATI process. 3. The HLR in the current network should support the PSI process. 4. The MSC in the current network should support the ZC function. The ZC information should be added for the subscriber in the HLR.
All rights reserved
Page 95
Question
What is the advantage and disadvantage of virtual MSC ID billing solution and LAI billing solution?
All rights reserved
Page 96
Practices
HLR SCP SMSC Service Platform IVR VMS CRBT
The MSC pool refers to the topology. Two MSS and two MGW.
STP
Legacy VMSC
For this network, what is the key point of network design? What other solution could be considered?
MSS1
MSC POOL
MSS2
IP Bearer
TMSC
MGW1
MGW2
IP Signaling TDM Signaling IP Traffic TDM Traffic
BSC1 HUAWEI TECHNOLOGIES CO., LTD.
RNC1
RNC2
BSC2 Page 97
All rights reserved
ATCA MSC Pool Network Design

The different of network design compared with CPCI platform:

EMS Interconnection Design
Billing Interconnection Design

Timestamp Synchronization Interconnection Design Lawful Interception Interconnection Design
Compared with ATCA and CPCI platform, the MSC Pool network design is only a little different. The difference of above network design is the topology and hardware board. The detailed information refers to network design reference guide and template.
All rights reserved
Page 98
FAQ
1The bandwidth resource requirement is not enough after the office is cutover. Analysis The traffic model is incorrect. The traffic model from sale engineer is incorrect. The traffic model is not converted into MSC Pool traffic model. The bandwidth result is incorrect The analysis of signaling route and traffic route is not correct, and the bandwidth combiner and bandwidth split are wrong. The traffic planning is not rational, there are many devious traffic between different MGW. The trunk data configuration is incorrect. The BICCTG data configuration is missing in VMSC and this occur large traffic between different MGW. There are more cases in following link: http://support.huawei.com/support/pages/kbcenter/view/product.do?actionFlag=detailProdu ctSimple&web_doc_id=SC0000523532&doc_type=123-2
All rights reserved
Page 99
MSC Pool Network Global MAP

Russian VIP Canada OT Shan Dong Lin YI Egypt ET Iran MTN India BSNL Chong Qing Jiang Shu Nan Jin Guang Dong Yemen MTN Bengal TMIB Malaysia MAXIS Indonesia XL
Uganda WARID
Latin American MILLICOM
Cote D'Ivoire MTN Nigeria MTN
Kenya Safaricom
Beta Commerce Project Implementation
All rights reserved
Page 100
Thank you
www.huawei.com

MSC Pool VMS6 Presentation

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MSC Pool VMS6 Presentation

Uploaded by

Copyright:

Available Formats

GU CS MSC Pool Network Design Training Material

CN Professional Service Team

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

(Optional) Principle of the MSC Pool

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Huawei MSC Pool Solution

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Networking Topology of the MSC Pool

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Softswitch Networking Topology of the MSC Pool MSC servers are

distributed for service processing. MGWs act as interface boards.

Virtual MGWs are used.

HUAWEI TECHNOLOGIES CO., LTD.

Technical Principles of the MSC Pool

The NRI allocated for the user is carried in the TMSI.

NNSF: NAS node selection function

1. Location update request

Principle of NNSF Implementation on the BSC/RNC

MGW-A Ma1 Ma2 Ma3 Ma4

Mb1 Mb2 Mb3 Mb4MGW-B

1. New location update request 2. Positive location update response

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Principle of NNSF Implementation on the MGW

Ma1 Ma2 Ma3 Ma4

Mb1 Mb2 Mb3 Mb4MGW-B

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Relationship Between TMSIs and NRIs

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Resource Sharing and Load Sharing in the MSC Pool

Users are evenly distributed to the MSC servers in the pool.

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Saving the Total Capacity and Investments

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Implementing Network Disaster Recovery

Huawei MSC Pool Solution

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Huawei MSC Pool Solution

Optimized Solution for the Called Service

MGW Implementing the A-Flex Function

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Huawei MSC Pool Solution

Difficulties in A Interface Management in the MSC Pool

Difficulties after the MSC Pool is adopted

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

Lower Efficiency in Using A Interface Circuits

More Complicated Adjustment and OM of the A Interface Circuits

When the MSC Pool is expanded, the following problem arises:

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved