mss pooling

8/16/2019 MSS Pooling

http://slidepdf.com/reader/full/mss-pooling 1/196DRAFT_3rd October 2013

MSS Pooling and Multipoint Guidelinesfor MSS System

DN70304728

Issue 9-0 draft

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects ofits products and services. We would like to encourage you as our customers and users to joinus in working towards a cleaner, safer environment. Please recycle product packaging andfollow the recommendations for power use and proper disposal of our products and their compo-nents.

If you should have questions regarding our Environmental Policy or any of the environmentalservices we offer, please contact us at Nokia Siemens Networks for any additional information.


http://slidepdf.com/reader/full/mss-pooling 2/196

DRAFT_3rd October 2013

DRAFT_3rd October 20132 DN70304728

Issue 9-0

MSS Pooling and Multipoint Guidelines for MSS Sys-tem

Id:0900d805809d6e02

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for the

use of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmittedin any form or means without the prior written permission of Nokia Siemens Networks. Thedocumentation has been prepared to be used by professional and properly trained personnel,and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomescustomer comments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity,or performance of the mentioned hardware or software products are given "as is" and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However ,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which

may not be covered by the document.Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NOEVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITEDTO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITYOR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATIONIN IT.

This documentation and the product it describes are considered protected by copyrights andother intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademarkof Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respectiveowners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2013/10/3. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sourcesof danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handlethis product and only after having carefully read the safety information applicable to thisproduct.

The safety information is provided in the Safety Information section in the “Legal, Safety

and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur ProduktsicherheitVon diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oderandere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durchgeschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-satzes.




DN70304728Issue 9-0 draft

3


Id:0900d805809d6e02

Table of ContentsThis document has 196 pages.

1 Changes in MSS Pooling and Multipoint Guidelines for MSS System. . . 9

2 MSS System Pooling and Multipoint overview. . . . . . . . . . . . . . . . . . . . 102.1 Multipoint key concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Pooling and Multipoint features and concepts . . . . . . . . . . . . . . . . . . . . 223.1 Pool area concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Network Resource Identifier (NRI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 TMSI/NRI allocation process by the core network. . . . . . . . . . . . . . . . . 233.4 Radio network configuration for pooling and multipoint features in

MSC/MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5 Default MSC/MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.6 Mobility in the MSC/MSS pool concept . . . . . . . . . . . . . . . . . . . . . . . . . 263.6.1 Roaming and the MSC/MSS pool concept . . . . . . . . . . . . . . . . . . . . . . 263.6.2 Handover and the MSC/MSS pool concept . . . . . . . . . . . . . . . . . . . . . . 293.6.3 Gs interface: inter-working with MSS Pooling . . . . . . . . . . . . . . . . . . . . 313.7 Subscriber distribution between MSCs/MSSs . . . . . . . . . . . . . . . . . . . . 363.8 Multipoint interworking with other features. . . . . . . . . . . . . . . . . . . . . . . 433.9 Multipoint Iu and Flexi Direct (former Internet High Speed Packet Access

(I-HSPA)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.10 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.11 Statistics and performance monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . 453.12 NetAct support for Multipoint features . . . . . . . . . . . . . . . . . . . . . . . . . . 473.12.1 OSS support for Multipoint and MSS pooling . . . . . . . . . . . . . . . . . . . . 473.12.1.1 Nokia Siemens Networks Multipoint Configuration Assistant . . . . . . . . 473.12.1.2 MSC Server Pool Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.12.1.3 Core Network Productivity Suite (CNPS). . . . . . . . . . . . . . . . . . . . . . . . 493.12.2 NetAct Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.13 Forced test subscriber location update to a specific MSS inside the MSS

pool area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4 Pooling and Multipoint architecture guidelines. . . . . . . . . . . . . . . . . . . . 614.1 Network architecture overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2 MSC/MSS pool planning aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3 NRI planning and management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5 Pooling and Multipoint configuration and connectivity guidelines . . . . . 845.1 Multipoint A/Iu in MSS System architecture. . . . . . . . . . . . . . . . . . . . . . 845.2 Multipoint A in MSC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.3 RAN Independent Multipoint A/Iu support in MGW . . . . . . . . . . . . . . . 1115.4 TDM A interface control in MGW for MSS pool . . . . . . . . . . . . . . . . . . 1255.5 LTE interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.5.1 CSFB interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.5.1.1 CSFB architecture scenarios with MSS Pooling . . . . . . . . . . . . . . . . . 1285.5.1.2 SGs interface interworking with MSS Pooling . . . . . . . . . . . . . . . . . . . 130

5.5.1.3 Interworking of LTE overlay solution and MSS pooling . . . . . . . . . . . . 1345.5.2 SRVCC interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136





Issue 9-0 draft


Id:0900d805809d6e02

5.5.2.1 Single radio voice call continuity (SRVCC). . . . . . . . . . . . . . . . . . . . . . 1365.5.2.2 Sv interface and MSS Pool overview . . . . . . . . . . . . . . . . . . . . . . . . . . 1365.5.2.3 MSS Pool and Sv interface interworking. . . . . . . . . . . . . . . . . . . . . . . . 140

6 Pooling and Multipoint configuration and management . . . . . . . . . . . . 1426.1 Configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.2 Preparatory steps for multipoint configuration . . . . . . . . . . . . . . . . . . . 1466.3 Pooling and Multipoint configuration management use cases . . . . . . . 1556.3.1 Adding an MSC/MSS with its whole radio network to the MSC/MSS pool .

1556.3.2 Adding an MSC/MSS with part of its radio network to the MSC/MSS pool.

1566.3.3 Adding a new MSC/MSS to the MSC/MSS pool. . . . . . . . . . . . . . . . . . 1586.3.4 Adding an LA, BSC, RNC, BTS or SA to the MSC/MSS pool. . . . . . . . 1596.3.5 Removing an LA, BSC, RNC, BTS or SA from the MSC/MSS pool . . . 1616.3.6 Moving an LA from the MSC/MSS pool into the MSC’s/MSS’s own radio

network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636.3.7 Moving a BSC/RNC from the MSC/MSS pool to another MSC/MSS pool .

1646.3.8 Managing neighbor MSC/MSS pool areas for pool MSCs/MSSs . . . . . 1646.3.9 Multipoint feature deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656.4 Pool operability use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656.4.1 Off-loading an MSC/MSS in a pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656.4.2 On-loading an MSC/MSS in a pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

7 Pooling and Multipoint capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

8 Pooling and Multipoint System limitations. . . . . . . . . . . . . . . . . . . . . . . 182

9 Summary of Pooling and Multipoint parameters . . . . . . . . . . . . . . . . . . 183

10 Pooling and Multipoint import/export procedure . . . . . . . . . . . . . . . . . . 185

11 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19011.1 Subscriber distribution in the pool area in Nokia Siemens Networks’ RNC,

BSC, SGSN and Flexi Direct BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19011.1.1 WCDMA Radio Network Controller (RNC) . . . . . . . . . . . . . . . . . . . . . . 19011.1.2 Base Station Controller (BSS releases) . . . . . . . . . . . . . . . . . . . . . . . . 19011.1.3 Base Station Controller (BR releases) . . . . . . . . . . . . . . . . . . . . . . . . . 193

11.1.4 SGSN (SG releases). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19411.1.5 Flexi Direct BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19511.1.6 MME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19511.2 Related documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195





Issue 9-0 draft


Id:0900d805809d6e02

90Figure 41 Resource division in the A interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Figure 42 Resource division in Ater interface in the transcoder . . . . . . . . . . . . . . . 91

Figure 43 Resource division in the Ater interface in the MGW . . . . . . . . . . . . . . . . 92Figure 44 Virtual MGW and multipoint feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Figure 45 Virtual MGW–MSS connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Figure 46 Intra-virtual MGW connection limitation . . . . . . . . . . . . . . . . . . . . . . . . . 96Figure 47 Multipoint topology without MGW disaster resilience . . . . . . . . . . . . . . . 98Figure 48 Multipoint topology with MGW disaster resilience. . . . . . . . . . . . . . . . . . 99Figure 49 Multipoint topology with MGW disaster resiliency, 2nd option . . . . . . . 101Figure 50 Multipoint Iu with meshed Iu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Figure 51 Multipoint Iu call case with non-meshed Iu . . . . . . . . . . . . . . . . . . . . . . 103Figure 52 Example of pool area network topology . . . . . . . . . . . . . . . . . . . . . . . . 105Figure 53 MSS1-MSS2 and MGW1 connections . . . . . . . . . . . . . . . . . . . . . . . . . 106

Figure 54 Impact of POI in network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Figure 55 Digit analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Figure 56 Multipoint Ater connectivity in MSC architecture. . . . . . . . . . . . . . . . . . 110Figure 57 Increase in inter-MSC traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Figure 58 Multipoint A/Iu support in MGW with the NAS node selection function

(NNSF) in the MGW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Figure 59 RAN node configuration alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . 114Figure 60 Addressing principle in MGW and MSS for RAN Independent Multipoint

A/Iu support in MGW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Figure 61 Addressing example for RAN Independent Multipoint A/Iu support in MGW

116

Figure 62 MGW resiliency solution in RAN Independent Multipoint A/Iu support inMGW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Figure 63 Signaling link set configured with RAN independent multipoint for a BSC .120

Figure 64 Overlapping MGW clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Figure 65 CGR configuration in RAN Independent Multipoint A/lu support in MGW .

122Figure 66 Example of CGRs with RAN Independent Multipoint A/Iu support in MGW

123Figure 67 A/Ater-interface CGRs with the RAN Independent Multipoint A feature -

simplified CGR management in BSCs . . . . . . . . . . . . . . . . . . . . . . . . . 124

Figure 68 Current pool network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Figure 69 Network topology with TDM A interface control in the MGW . . . . . . . . 126Figure 70 CSFB architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Figure 71 CSFB overlay MSS inside the pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Figure 72 CSFB overlay MSS outside the pool - no A/Iu interface . . . . . . . . . . . . 129Figure 73 CSFB in every MSS of the pool - IMSI hash selection in MME . . . . . . 130Figure 74 SGs interface interworking with MSS pooling . . . . . . . . . . . . . . . . . . . . 131Figure 75 MSC/MSS selection during Combined RA/LA Update procedure when SGs

interface is used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Figure 76 Overlay CSFB architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Figure 77 SRVCC and MSS pooling architecture – MSSs in pool, one SRVCC MSS

in pool; MME/SGSN not in pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Figure 78 SRVCC and MSS pooling architecture – MSSs in pool, all MSS are SRVCC





7


Id:0900d805809d6e02

capable; MME/SGSN not in pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Figure 79 SRVCC and MSS pooling architecture – MSSs in pool, all MSS are SRVCC

capable; MME/SGSN also in pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Figure 80 SRVCC and MSS pooling architecture – MSSs in pool, one SRVCC MSS

in pool; MME/SGSN also in pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Figure 81 Example of a network without pool areas (non-pooled network) . . . . . 143Figure 82 Example of pool areas in the network . . . . . . . . . . . . . . . . . . . . . . . . . 143Figure 83 Creating a pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Figure 84 Preparing the primary MSC/MSS radio network . . . . . . . . . . . . . . . . . 149Figure 85 Creating a pool when RAN Independent Multipoint A/Iu support in MGW is

used–primary MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Figure 86 Adding secondary MSSs into the configuration when RAN Independent

Multipoint A/Iu support in MGW is used. . . . . . . . . . . . . . . . . . . . . . . . 153Figure 87 Adding BSC or RNC into the configuration when RAN Independent Multi -

point A/Iu support in MGW is used . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Figure 88 Adding an MSC/MSS with its whole radio network to the MSC/MSS pool

155Figure 89 Adding an MSC/MSS with part of its radio network to the MSC/MSS pool.

157Figure 90 Adding a new MSC/MSS to the MSC/MSS pool.. . . . . . . . . . . . . . . . . 158Figure 91 Adding LA, BSC, RNC, BTS or SA to the MSC/MSS pool. . . . . . . . . . 160Figure 92 Removing a BSC, RNC, BTS or SA to the MSC/MSS pool. . . . . . . . . 162Figure 93 Moving an LA from the MSC/MSS pool into the MSC/MSS own radio net -

work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Figure 94 MSC/MSS off-loading in a pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Figure 95 MSC/MSS off-loading in a pool with MSC/MSS controlled load redistribu -

tion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Figure 96 MSS off-loading with MGW off-loading mode . . . . . . . . . . . . . . . . . . . 170Figure 97 MSS off-loading with SGs interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Figure 98 MSC/MSS on-loading with Multipoint A . . . . . . . . . . . . . . . . . . . . . . . . 173Figure 99 MSC/MSS controlled on-loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Figure 100 MSS on-loading with MGW on-loading mode. . . . . . . . . . . . . . . . . . . . 176Figure 101 Making the pool area-related configurations.. . . . . . . . . . . . . . . . . . . . 185Figure 102 Exporting RN data from the primary and the secondary MSSs . . . . . . 186Figure 103 Importing data to the primary MSS from each MSS, one at a time . . . 186Figure 104 Activating the configuration in the primary MSS . . . . . . . . . . . . . . . . . 187Figure 105 Making configurations (for instance, UP and unlock). . . . . . . . . . . . . . 187Figure 106 Exporting RN data from the primary MSS . . . . . . . . . . . . . . . . . . . . . . 188Figure 107 Importing data to the secondary MSSs . . . . . . . . . . . . . . . . . . . . . . . . 188Figure 108 Activating the configuration in the secondary MSSs . . . . . . . . . . . . . . 189Figure 109 Making configurations (for instance UP and unlock) . . . . . . . . . . . . . . 189





Issue 9-0 draft


Id:0900d805809d6e02

List of TablesTable 1 Changes in MSS Pooling and Multipoint Guidelines for MSS System be -

tween MSS SR 4.2, V1 and MSS SR 5.0, V1. . . . . . . . . . . . . . . . . . . . . . 9Table 2 Example of traffic distribution in the MGW with weighted round robin

method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Table 3 Required NRI length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Table 4 NRI length versus available TMSI space in MSC/MSS . . . . . . . . . . . . . 76Table 5 CGR to tree number mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Table 6 CGR to tree number mapping in MSS1 . . . . . . . . . . . . . . . . . . . . . . . . 108Table 7 Pool area configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Table 8 Example of traffic distribution with weighted round robin method . . . . 191Table 9 Values for the load balancing value parameter. . . . . . . . . . . . . . . . . . . 192





9


Changes in MSS Pooling and Multipoint Guidelines for MSS System

Id:0900d805809d6ec8

1 Changes in MSS Pooling and MultipointGuidelines for MSS SystemThe following changes have been made since the last documentation release betweenMSS SR 4.2, V1 and MSS SR 5.0, V1. The changes are detailed in the table below.

Change See

Table 1 Changes in MSS Pooling and Multipoint Guidelines for MSS System between MSS SR 4.2, V1 andMSS SR 5.0, V1.





Issue 9-0 draft


Id:0900d805809d6eca

MSS System Pooling and Multipoint overview

2 MSS System Pooling and Multipoint overviewMSS System Pooling and Multipoint Guidelines introduce theNokia Siemens NetworksMultipoint features, Multipoint A Interface and Multipoint Iu Interface, in the DX 200 MSCand the Classic and Open MSS. The guidelines give guidance on pooling and multipointnetwork configuration, planning and management at system level. These guidelines usethe term multipoint , but the features may also be referred to as A Flex and Iu Flex , orMSS Pooling in other documentation.

Feature 1564: Multipoint A Interface and Feature 1449: Multipoint Iu in MSS Concept ,introduce a routing mechanism and other related functions which enable the BSCs,RNCs and SGSNs/MMEs to route information to different MSCs/MSC Servers (MSS).The features remove the strict hierarchy that restricts RAN node (BSC/RNC) connectionto only one MSC/MSS.

The features introduce the concept of pool areas, enabled by the routing mechanism in

the RAN nodes, or optionally in the MGW. A pool area is comparable to an MSC/MSSservice area as a collection of one or more RAN node service areas. The differencebetween a pool area and an MSC/MSS service area, is that a pool area is served bymultiple MSC/MSSs in parallel, sharing traffic between them.

Multipoint features provide many benefits for the operator:

• Enables signaling savings in the core network. There are fewer location updates,fewer inter-MSC/MSS handovers/relocations, and reduced HLR update signaling;

• Multipoint in MSC Server architecture, when compared to MSC architecture,provides optimal use of A and Iu transmission resources. There is no need toconnect user plane trunks from each BSC to each MGW;

• Overlapping pool areas support MS moving patterns and achieve improved utiliza-tion of core network resources during traffic profile variations;

• Allows for easier capacity upgrades in the network and planning of network levelcapacity;

• Provides for greater core network (CN) element resiliency, for example, in naturaldisasters;

• Provides for more flexible software upgrades to, and maintenance of, a pool areaMSC/MSS;

• Reduces the number of RAN node re-homings due to a larger, pool area wide,service area;

• Enables simpler CN controlled load balancing between MSCs/MSSs in the poolarea;

• Provides higher resiliency and signaling savings at the radio interface throughenhancements in core network signaling;

• Enables the optimal use of VLR resources in the pool area when VLR capacity orlicense is limiting the subscribers inclusion in a certain VLR.

These benefits are explained in more detail below.

Signaling savings in the core network are enabled by an enlarged, pool area-wideservice area, compared to the service area of one MSC/MSS. There are fewer inter-MSC/MSS location updates and handovers/relocations and less HLR update traffic.Because inter-MSC location updates and handovers are reduced to a minimum, signif-icant SS7 network savings and HLR load reduction can be achieved.

The Multipoint A and Multipoint Iu features are both supported in the MSC Server archi-tecture, as illustrated in the figure Multipoint interfaces between RAN nodes and MSS





11



Id:0900d805809d6eca

System , for RAN node based multipoint solutions. In addition, the optional RAN Inde-pendent Multipoint A/lu solution is supported as described later in this section. The samebenefits as are provided by Multipoint A/lu are also available using the alternative solu-tion, where the subscriber distribution is located in the MGW instead of the RAN node.

Figure 1 Multipoint interfaces between RAN nodes and MSS System

g The RAN areas can be either BSC areas or RNC areas.

g Flexi Direct BTS (previously called I-BTS) are treated in this document as being similarto RANs as regards multipoint functionality and subscriber distribution logic. For further

information about Flexi Direct (previously known as I-HSPA) and pooling and multipointconfiguration, see the Section Multipoint Iu and Flexi Direct (former Internet High SpeedPacket Access (I-HSPA)) .

The Multipoint A feature is also supported in the traditional MSC architecture as illus-trated in the figure Multipoint A interfaces between BSCs and MSCs .

Figure 2 Multipoint A interfaces between BSCs and MSCs

g This document describes the reference architecture with the Nokia Siemens NetworksBSS release BSC. For more information on the flexible A feature in the BR release BSC,

see Flexible A-interface\FD10556 in Nokia Siemens Networks Base Station Subsystem(BR releases) Operating Documentation.





Issue 9-0 draft


Id:0900d805809d6eca


The Multipoint A feature in MSC Server architecture provides significant benefits for theoperator compared to the Multipoint A feature in MSC architecture. An architecturecomposed of separate MSC Servers and MGWs with the virtual MGW (vMGW) conceptallows the utilization of Multipoint A without the need to connect user plane trunks fromeach BSC to each MGW. Similarly, for signaling connections, it is sufficient to have fullmesh only at the Mc interface, provided that a signaling connection from each BSS toeach MSS is available.

For both Multipoint A and Multipoint Iu features, MSC Server architecture also enablesoptimal usage of the A and Iu interface transmission resources by supporting localswitching.

When the Multipoint A interface is used, resource allocation is not as flexible in a TDM-based interface as it is in ATM and IP-based interfaces. In the Multipoint A interfacefeature, therefore, when TDM is used for A interface transport, an additional functionalityhas been added to perform an inter-MSC/MSS handover in congestion situations result-

ing from a lack of Pulse Code Modulated (PCM) TDM resources. When Multipoint A isused with the IP based A interface, such PCM resource congestion is avoided.In addition, NetAct Core Network Productivity Suite (CNPS) implements TDM A Inter-face Load Balancer for MSS pooling to dynamically re-allocate A/Ater circuits betweenMSSs based on circuit load. This is beneficial because the utilization of configured ded-icated TDM resources may become unbalanced over time. This is further described laterin this document, in Section Dynamic TDM A interface Circuit Balancer for MSS Pooling .

Overlapping pool areas can be implemented in both the MSC Server and the MSC archi-tecture. The service area is further enlarged because in the overlapping pool areas, oneRAN node can be connected to more than one MSC/MSS pool. This is illustrated in thefigure Overlapping pool areas .

Figure 3 Overlapping pool areas

The configuration of overlapping pool areas allows the separation of the total trafficvolume into different MS moving patterns. An example could be pool areas which eachcover a separate residential area and overlap to cover the same city center, or majortraffic route, providing enhanced capacity for suburban subscribers who drive daily tothe city and back in the evening as shown in the simplified figure Overlapping pool areaswith an example of an MS moving pattern .





13



Id:0900d805809d6eca

Figure 4 Overlapping pool areas with an example of an MS moving pattern

Once a subscriber has been allocated to a pool area, the subscriber is served by the

same pool area while commuting between the city center and the residential area. Withoverlapping pool areas it is thus possible to reduce core network signaling load evenfurther, because the service area is expanded to cover the overlapping pool areas.

Traffic profiles vary daily, weekly and monthly. Variations are due to, for example, com-muting traffic, special local traffic profiles on weekends, and special local conditionsduring holiday months. Pooling enables the operator to use core network resourcesmore efficiently because less inventory needs to be maintained to avoid congestionresulting from exceptional traffic conditions.

Easier capacity upgrades, such as the addition of more MSCs/MSS to the pool area, arealso enabled by multipoint features. Capacity planning becomes simpler because it ispool wide rather than regional.

Multipoint features improve core network element resilience. Core network elements arehigh capacity elements and so operators require network level resilience, for example,to protect from natural disasters. When using the Multipoint A and Iu solutions, thefailure of one MSC/MSS does not require transmission reconfiguration, and coveragecan be provided without disruption. Similarly, software upgrading and maintenance ismore flexible. When one MSC/MSS is under maintenance, the service is maintained byother pool area MSC/MSSs.

Fewer RAN node re-homings and similar tasks are needed because the MSC/MSSareas are larger due to pooling. This results in operational savings. In non-pooled net-works, for example, the commissioning of one large capacity RAN node typicallyrequires re-homing of other RAN nodes to enable the core network to support the





Issue 9-0 draft


Id:0900d805809d6eca


increasing traffic. With pooling, only the total pool capacity is relevant. Providing the poolhas the capacity for the increase in traffic, no re-homings are required.

Load balancing enhancements

There are several optional enhancements for multipoint load balancing to facilitate sub-scriber management in the pool area:

• To reduce Operation and Maintenance (O&M) work to control load balancingbetween pool MSCs/MSSs, CN controlled load balancing between MSCs/MSSs isallowed, both in normal operation and when, for example, an MSC/MSS is set to offloading mode. The operator can assign the subscribers from the off-loadedMSC/MSS directly to a pre-defined pool MSCs/MSSs, without having to modify sub-scriber distribution definitions in the RAN nodes or in the MGW.

• An automatic threshold limit on off-loading and load redistribution can be set, acti-vated when a predefined Visitor Location Register (VLR) utilization rate has beenreached. This is very useful in situations when the load from one MSC/MSS must bereduced to a pre-defined threshold level.

• More optimal use of VLR resources is enabled within the pool area when the VLRcapacity, or capacity license is limiting subscribers’ inclusion to a certain VLR. Insuch situations, the incoming subscribers can be directed to other pool areaMSCs/MSSs. With NetAct CNPS VLR load balancing for MSS pooling, the VLR uti-lization can even be automatically balanced, as described later in this document inSection VLR load balancing for MSSPooling .

• In addition to the redistribution of idle state subscribers functionality, redistribution ofactive state subscribers has also been included according to Intra-domain connec-tion of Radio Access Network (RAN) nodes to multiple Core Network (CN) node .

After redistribution of the idle state subscribers, the operator can also redistribute theactive mode subscribers as soon as their connection management transaction ends.

• In networks where the MSCs/MSSs serve both 2G and 3G subscribers, but poolingis used only in the 2G, or the 3G area, it is possible, after a change between 2G and3G access, to direct the subscriber to the same MSS. This avoids inter-MSC/MSSlocation updates. Alternatively, the subscriber can be directed for subscriber distri-bution in the RAN node/MGW to achieve the optimal MSC/MSS selection within thepool area. The optimal method depends on network planning considerations.

• When a subscriber roams into a pool area from outside of the pool, it is possible thatthe subscriber evades subscriber distribution because of a coincidental NetworkResource Identifier (NRI) value in the Temporary Mobile Subscriber Identity (TMSI),allocated previously outside the pool area. This can be detected by the MSC/MSS

and the subscriber is directed for RAN node/MGW subscriber distribution. • Area-specific off loading can be configured in the MSS to enable off-loading of sub-

scribers on the basis of location areas. A similar functionality can also be realized with NetAct CNPS Location Area Code(LAC) based subscriber balancer, which is described in detail in this document inSection Location Area Code (LAC) based Subscriber Balancing .

The enhancements and potential interactions with other functionalities described above,are described in more detail later in the document.

For further information about configuring multipoint, see Feature 1564: Multipoint AInterface, Feature Activation Manual and Feature 1449: Multipoint Iu in MSS Concept,Feature Activation Manual in M-release feature documentation.





15



Id:0900d805809d6eca

Core network signaling enhancements

The core network signaling enhancements related to the multipoint feature include aresiliency solution for target MSC/MSS selection during location update and handover.

Functions to enable signaling savings at the radio interface are also introduced: • Higher network resiliency in handovers between pooled areas is achieved by

enabling another MSC/MSS to be selected if the first choice is not available. Thismay occur if there is a failure in the target MSC/MSS, or, if it is in off loading mode.It is possible to configure in the non-pooled MSC/MSS all the pooled MSC/MSSs,instead of using a single default pool MSC/MSS. These enhancements are includedin the basic multipoint functionality.

• Signaling over the radio interface is reduced by an optional functionality. The newMSS is able to find the old MSS/VLR directly instead of requesting the subscriberinformation from the User Equipment (UE). When an MSC/MSS is set to off-loadingmode and subscribers are moved to another MSCs/MSSs, the new MSC/MSS can

obtain the information from the old MSC/MSS without signaling over the radio inter-face.

Feature 1564: Multipoint A Interface and Feature 1449: Multipoint Iu in MSS Concept are implemented according to 3GPP TS 23.236 Intra-domain Connection of Radio

Access Network (RAN) Nodes to Multiple Core Network (CN) Nodes .

Multipoint A interface in MSC/MSS

The Multipoint A interface feature can be used in the MSC and MSC Server architecture.

g This document describes the reference architecture with the Nokia Siemens NetworksBSS release BSC. The pool area planning and configuration principles described in thisdocument are however generic for both BSS and BR release BSC from the perspectiveof the MSS System.

For more information on the flexible A feature In the BR release BSC, see Flexible A-interface/FD 10556 in Nokia Siemens Networks Base Station Subsystem (BR releases)Operating Documentation.

The following network elements are involved in the Multipoint A interface feature (in RANbased multipoint configuration):

• Nokia Siemens Networks Open Mobile Softswitch (MSS) • Classic MSS (Integrated or Standalone) • MSC and Compact DX MSC •

The SGSN if the Gs interface is implemented in the network • The BSC must also support this functionality

The Multipoint A interface feature has traditionally been used primarily as a resiliencysolution by operators because of Time-Division Multiplexing (TDM) transport. If one corenetwork element (MSC/MSS, transcoder, or Multimedia Gateway) fails, the whole BSSis not out of service. A disadvantage is that the number of E1s at the TDM-based A-inter-face required may increase, depending on the exact configuration.

In the traditional MSC architecture, Multipoint A requires full mesh connectivity betweenthe BSCs and MSCs of one pool, because TDM based A interface includes both controland user plane. This may result in high A interface transmission costs.

An architecture composed of a separate MSC Server and MGW with the virtual MGWconcept allows the utilization of Multipoint A without requiring full mesh connectivity in





Issue 9-0 draft


Id:0900d805809d6eca


the A interface. In the MSS System, Multipoint A needs full mesh connectivity for the Mcinterface only (control plane). The user plane is terminated to one, or two physicalMGWs for resilience.

In MSC Server System architecture, the user plane TDM trunks are terminated in theMGW and the linking to the MSC Server is only logical. The signaling links are termi-nated in the MSS. Because multiple MSSs can control the same physical MGW, thereis no significant impact on transmission level from the operability or topology perspec-tives. The only disadvantage is that the trunk groups are smaller because they are splitbetween pool MSSs. Maintaining the service level requires additional trunks. If,however, the BSC service area is also large, this should not have a significant impact.

When Multipoint A is used with A interface over IP (AoIP), the TDM related transportrestrictions described above are removed. Compared to TDM, AoIP also enables moreflexible pool area configuration and simplifies pool area management.

The MSC Server pool enables an optimal use of transmission resources between

MGWs by supporting local switching. When, for example, a subscriber is registered inMSS1 and another subscriber is registered in MSS2 and they are both within the sameBSC service area, the calls between them can use the same local MGW. If the BSC isconnected to two MGWs, optimal routing based on MGW-ID should be used in the MSSto select the same MGW.

For further information about the benefits of local switching, see MSC Server ProductDescription and the Open Mobile Softswitch Product Description in M-release ProductDocumentation.

Multipoint A interface can be used independently of the Multipoint Gb interface.

Multipoint A interface feature related configuration and connectivity aspects aredescribed in Multipoint configuration and connectivity guidelines . For Multipoint A inter-face, see the Feature Description Feature 1564: Multipoint A Interface, in M-releaseFeature Documentation.

Multipoint Iu interface in MSS

The Multipoint Iu in MSC Server concept feature can be used in the MSS architecture.

The following network elements are involved (in RAN based multipoint configuration):

• Open Mobile Softswitch (MSS); • Classic MSS (Integrated and Standalone); • The SGSN if the Gs interface is implemented in the network • The RNC (which must also support this functionality).

Although an MGW is introduced in to the network architecture, this feature does notrequire any special functionality from the MGW.

Multipoint Iu-CS can be used independently of Multipoint Iu-PS.

Multipoint Iu interface related configuration and connectivity aspects are described inMultipoint configuration and connectivity guidelines . For the Multipoint Iu interface, seethe Feature Description Feature 1449: Multipoint Iu in MSS Concept , available in M-release Feature Documentation.

RAN Independent Multipoint A/Iu support in MGW

Feature 1778: RAN Independent Multipoint A/Iu Support in MGW builds on Feature1449: Multipoint Iu in MSS concept and Feature 1564: Multipoint A Interface. Asdescribed earlier in this document, multipoint features remove the strict hierarchy





17



Id:0900d805809d6eca

restricting RAN node connection to just one MSS and allows traffic sharing among theMSSs in the pool area. For RAN Independent Multipoint A/lu Support in MGW, Multipoint

A or Multipoint lu interface support in the MSS is required but multipoint support in theRAN nodes is not required.

RAN Independent Multipoint A/Iu Support in MGW feature implements, in the MGW, thesame non-access stratum (NAS) node selection function (NNSF) and subscriber distri-bution that would be required in the RAN nodes (RNCs and BSCs) in the 3GPP standardbased multipoint functionality. This feature allows core network node selection to takeplace in the MGW instead of the RAN node and enables MSS pooling without multipointfunctionality support in the radio network.

RAN independent multipoint A/Iu support in MGW solution is illustrated in the figure RANIndependent Multipoint A/Iu support in MGW solution .

Figure 5 RAN Independent Multipoint A/Iu support in MGW solution

In this solution, the interface towards the RAN nodes is a standard point-to-point inter-face and multipoint connectivity is achieved between the MGWs and MSSs. In order toavoid a single point of failure, more than one MGW in an MGW cluster provides connec-tivity between the RAN nodes and the MSSs.

In general, multipoint solutions provide improved MSS resiliency and disaster recoverybecause the RNC/BSC can be connected to several MSSs. The reduced signaling load(due to less inter-MSS handovers and location updates) results in significant SS7network savings and decreased HLR load. The MGW-based multipoint solution is ableto provide pool area capacity usage benefits amongst the MSSs and has load sharingand resiliency capabilities comparable to the RAN node-based multipoint solution.

The RAN Independent Multipoint A/Iu Support in MGW reduces network complexitywhen compared to the RAN node-based multipoint solution, because multipoint featuresupport and configuration in the RNC/BSC is not necessary. In addition, subscriber dis-

tribution management is easier and the operational effort minimized. Subscriber distri-bution is controlled in the core network instead of in each RNC/BSC elements





Issue 9-0 draft


Id:0900d805809d6eca


separately. RAN Independent Multipoint A/Iu Support in MGW also offers better interop-erability in multivendor networks because not all vendors RNCs/BSCs support 3GPPstandards-based multipoint solutions.

Feature 1778: RAN Independent Multipoint A/Iu Support in MGW supports the followinginterfaces:

• A interface (over TDM and IP); • Ater interface (over TDM); • Iu-CS interface (over ATM and IP).

The MGW-based multipoint solution is able to provide pool area capacity usage benefitsamongst the MSSs and has load sharing and resiliency capabilities comparable to theRNC/BSC-based multipoint solution.

RAN Independent Multipoint A/Iu Support in MGW feature related configuration andconnectivity aspects are described in Pooling and Multipoint configuration and connec -tivity guidelines . For the RAN Independent Multipoint A/Iu Support in MGW feature, alsosee Feature 1778: RAN Independent Multipoint A/Iu Support in MGW in M-releaseFeature Documentation, and the document RAN Independent A/Iu Multipoint support inMGW , available in the U- and Ui-release documentation libraries.

In most network planning and configuration aspects, the RAN Independent Multipoint A/Iu Support in MGW feature follows the same principles as the standard Multipoint A/Iusolution, where the core network selection is done in the RAN nodes. Throughout thisdocument, differences between the solutions are specifically highlighted.

2.1 Multipoint key concepts

A interface The interface between a base station controller (BSC) and anexchange (MSC/MSS) through which all the services and otherfacilities are offered to a GSM PLMN user in order to enable theuse of the system.

AoIP A interface over IP. AoIP is a standardized interface accordingto 3GPP specifications.

Ater interface Interface between the BSC and the remote transcoder.

Default MSC/MSS MSCs/MSSs that do not support multipoint feature, or are notconfigured with detailed information about the NRIs, do not havethe information about multiple MSCs/MSSs serving a Location

Area (LA) within the pool area. They can derive only oneMSC/MSS from the Location Area Identifier (LAI). These nodescan therefore contact only one MSC/MSS per LA, for example,for fetching the subscriber information from the old VLR, orwhen a handover to a pool area is made. For this reason, adefault MSC/MSS is needed within the pool area to resolve thecorrect pool area MSC/MSS Default MSC/MSS use is describedin Default MSC/MSS and Mobility in MSC/MSS pool concept.





19



Id:0900d805809d6eca

Iu interface The interface between a radio network controller (RNC) and anexchange (MSC/MSS) through which all the services and otherfacilities are offered to a UMTS PLMN user in order to enable

the use of the system. The Iu interface can be either ATM or IP-based.

MGW cluster To achieve core network resiliency, it’s possible to route the sig-naling from one RAN node via a redundant MGW in the RANIndependent Multipoint A/Iu Support in MGW feature. Theredundant MGWs together form an MGW cluster, which hidesthe MGWs own Signaling Point Code (SPC) from RAN nodesand instead the RAN nodes see only the MGW clusterscommon SPC. The MGWs in the MGW cluster act in loadsharing mode.

MSC/MSS service

area

An MSC/MSS service area is a geographical area that is

covered by the radio network of one MSC/MSS.

MSC Server

architecture

CS core network architecture with separated control and userplane handling.

Multipoint A, AFlex, MultipointIu, IuFlex, MSSpooling

The RAN nodes (BSCs or RNCs) are able to route informationto more than one MSC/MSS in a pool configuration.

Non-accessstratum (NAS)

Protocols between the UE and the core network that are not ter-minated in the UTRAN (reference: 3GPP TS 21.905, Vocabu-lary for 3GPP Specifications).

NAS Node In the context of multipoint features, NAS Node is an MSC/MSS(or an SGSN/MME) serving the pool area.

NAS Node Selec-tion function,(NNSF)

The function used to assign specific network resources, that is,an MSC/MSS to serve an MS and route the traffic to theassigned network resource.

Network Mode ofOperation 1(NMO1)

The Gs interface between the MSC and SGSN is used forpaging coordination. CS paging is sent on the same channel asused by packet-switched services to guarantee CS pagingreception in the mobiles. The mobile thus needs to monitor onlyone paging channel.

Network Mode ofOperation 2(NMO2)

Paging coordination is done by the BSS/RNC. In 2G, a Class Bmobile in a packet data transfer is not required to decode the CSpaging channel.

Non-BroadcastLAI

Each MSC/MSS in a pool is assigned with one unique non-broadcast LAI. The non-broadcast LAI is used for off loadingtraffic from the MSC/MSS node.





Issue 9-0 draft


Id:0900d805809d6eca


Null-NRI In addition to the NRI, and as part of 3GPP 23.236 release 6specifications, a Null-NRI is introduced. The Null-NRI is used inthe MSC/MSS, together with a non-broadcast LAI, to re-distrib-

ute subscribers from the MSC/MSS, which initiated the Null-NRI(set by an MML command), to other available pool MSCs/MSSs.

A Null-NRI is used, for example, to perform load redistributionbetween MSC/MSS elements in a pool, or to off load traffic fromthe MSC/MSS due to scheduled maintenance. According to the3GPP 23.236 specification a Null-NRI is PLMN specific. A Null-NRI can be the same within the pool area MSCs/MSSs, but itcan also be configured in Nokia Siemens Networks MSC/MSSas MSC/MSS-specific within a pool area.

Off-Loading mode In the RAN Independent Multipoint A/Iu Support in MGWfeature, the operator can put a pool MSS into maintenance.

When the “off-load” mode is activated, all initiating transactions(except paging responses) are routed to other pool MSSs.

On-loading mode In the RAN Independent Multipoint A/Iu Support in MGWfeature, if the “on-load” mode is activated, all initiating transac-tions (except paging responses) are routed to a chosen MSSregardless of the NRI value allocated in the subscribers TMSI.

Overlapping poolarea

A RAN node coverage area, which belongs to more than onepool area, is considered to be an overlapping pool area. In thePool area configuration example figure, BSC area 2 and BSCarea 6 are overlapping pool areas, both belonging to CS poolarea 1 and to CS pool area 2.

ParallelMSCs/MSSs

MSCs/MSSs which belong to the same pool area are parallel.

Pool area A pool area is an area within which an MS may roam withoutneeding to change the serving MSC/MSS. A pool area is servedby one or more MSC/MSS in parallel. All the cells controlled bya RAN node belong to the same one (or more) pool area(s).

PrimaryMSC/MSS

An MSC/MSS is defined as primary when it is used as thesource of the radio network configuration and data later will beexported to all the other MSCs/MSSs in the same pool area.Only one MSC/MSS within each pool area is defined as primary.

RAN node servicearea

RAN node service area is a geographical area that one RANnode (BSC or RNC) serves.

SecondaryMSC/MSS

The radio configuration done for the BTS, RNC/BSC, LAC, Net-LAC in the primary MSC/MSS is available to be exported on allthe other MSC/MSSs. The MSC/MSSs that import this configu-ration are called secondary MSC/MSS.

SGs interface SGs interface is the reference point between the MME and theMSS/VLR. The SGs interface is used for the mobility manage-ment and paging procedures between the EPS and the CSdomain, and is based on the Gs interface procedures.The SGsreference point is also used for the delivery of both mobile orig-inating and mobile terminating SMS.





21



Id:0900d805809d6eca

vMGW A Set of statically partitioned physical terminations, or sets ofephemeral terminations that are implemented by partitioning aphysical media gateway. Each physical MGW can be divided in

to a number of virtual MGWs.





Issue 9-0 draft


Id:0900d805809d6ecc

Pooling and Multipoint features and concepts

3 Pooling and Multipoint features andconcepts

3.1 Pool area concept A pool area is an area within which a Mobile Station (MS) may roam without having tochange the serving MSC/MSS. An example of a pool area is illustrated in the figure Poolarea configuration example .

The pool area is served by one, or more, MSC/MSS at the same time. The whole servicearea of a RAN node (BSC/RNC) may belong to one, or more pool areas. A pool area iscomposed of many RAN node service areas. All the Location Areas (LAs) of a RANnode must belong to one or more pool areas. It is not possible for some RAN node cellsor LAs to belong to different pool areas, or for a RAN node to belong only partially to a

pool area concept. A subscriber is served by one dedicated MSC/MSS, and registered in one VLR, as longas they stay within the radio coverage of the pool area.

Figure 6 Pool area configuration example

The same concept applies to both the Multipoint A and Multipoint Iu feature, as well asto RAN Independent Multipoint A/Iu Support in MGW feature. It is also possible that inthe same network there are MSC/MSSs that do not belong to any pool area, forexample, MSC/MSS 7 as illustrated in the figure Pool area configuration example.

3.2 Network Resource Identifier (NRI)The Network Resource Identifier (NRI) is a unique identifier for individual MSC/MSS andis distinct from all the other MSC/MSSs within the same pool area and overlapping poolareas.

The operator can configure one, or several, specific NRIs for each MSC/MSS. The NRIis part of the Temporary Mobile Subscriber Identity (TMSI), generated by the MSC/MSS.

A TMSI is assigned to every mobile subscriber. The NRI is used by the RAN node (oroptionally the MGW when RAN Independent Multipoint A/Iu Support in MGW feature isin use) to distribute the subscribers’ originating transactions to the correct MSC/MSS.

TMSI/NRI structure is illustrated in the figure NRI and TMSI .





23



Id:0900d805809d6ecc

Figure 7 NRI and TMSI

An NRI has a flexible length of between 10 and 0 bits, where 0 bits means that thefeature is not activated and the NRI is not used. The NRI values are defined by the oper-ator. Within the pool area all NRIs must be of the same length. It is recommended thatthe value is also unique within neighboring pool areas.

In the CS domain, the NRI is part of the TMSI. The TMSI consists of 4 octets (32 bits),represented as an eight-digit hexadecimal number, and it is unique in one MSC/MSS

VLR area. The bits are numbered from b0 to b31, b0 being the least significant. The NRIbits are b14 through b23 of the TMSI, where bit b14 is the least significant. An NRIshorter than 10 bits will be encoded with the most significant bit of the NRI field startingfrom bit 23.

NRI planning and management is described in more detail in Section NRI planning andmanagement .

3.3 TMSI/NRI allocation process by the core networkEach MSC/MSS is configured with one (or more) specific NRI. One of these specificNRIs is part of every temporary identity (TMSI) which the MSC/MSS assigns to an MS.

The TMSI allocation mechanism in the MSC/MSS generates TMSIs which contain oneof the specific NRIs in the relevant bit positions. If there is more than one NRI value con-figured for an MSC/MSS, NRI allocation in to the TMSI is done by round robin selection.

The NAS Node Selection Function (NNSF) in the RAN node (or optionally in MGW whenRAN Independent Multipoint A/Iu Support in MGW feature is in use) directs the MS tothe MSC/MSS where it is registered based on the NRI information. If an NRI is not avail-able for MSC/MSS selection, then the NNSF uses its own subscriber balancing functionto direct the MS to a pool MSC/MSS.

The NNSF subscriber balancing function is also used when the selected MSC/MSS isnot available and the NNSF has to select an alternative. In such instances, the chosenMSC/MSS allocates its own NRI during TMSI re-allocation. This NRI is later used by the

NNSF in the RAN node (or optionally in an MGW when RAN Independent Multipoint A/IuSupport in MGW feature is in use) for routing the traffic to the correct MSC/MSS.





Issue 9-0 draft


Id:0900d805809d6ecc


The TMSI/NRI allocation process and the NNSF in case of a BSC is illustrated in thefigure TMSI/NRI allocation process.

Figure 8 TMSI/NRI allocation process

In forthcoming transactions, the BSC derives the NRI from the TMSI.

The NRI allocation process is similar for the RNC. The difference is that the NNSF in theRNC derives the NRI from the Intra Domain NAS Node Selector (IDNNS) parameterreceived from the MS. The IDNNS contains a routing parameter with a fixed length of 10bits. This routing parameter contains the NRI value.

In a similar way to the BSC NNSF, the RNC then forwards the initial signaling messagesto the correct MSC/MSS according to the derived NRI.

NRI allocation is similar when RAN Independent Multipoint A/Iu Support in MGW featureis in use, as illustrated in the figure TMSI/NRI allocation process in RAN IndependentMultipoint A/Iu Support in MGW .

Figure 9 TMSI/NRI allocation process in RAN Independent Multipoint A/Iu Supportin MGW

Similarly to the RAN nodes, the MGW in the forthcoming transaction, selects the MSSbased on the NRI received in the TMSI.

Location Update (LUP) behavior when subscriber changes from one VLR toanother at MSS pool borders

When multipoint configuration is used, and a subscribed switches from one VLR toanother at a border of MSS pool areas, the VLR address is not updated in the HLR inthe following special situation:





25



Id:0900d805809d6ecc

• either the Cancel Location message is lost, or the VLR has not processed themessage at all, therefore, the subscriber os registered into two different VLRs

• the subscriber initiated a mobile-originated (MO) transaction without performing any

location update (LU) (it is possible with multipoint configuration)In this case, the VLR address of the subscriber stored in the HLR is incorrect, as a resultof which the mobile-terminated (MT) transactions fail.

This functionality, however, offers a solution to the problem by initiating an implicit LUfrom the VLR, even if the subscriber data already exists in the VLR database, in the caseof every MO transaction where the Network Resource Identifier (NRI) in the TMSI is dif-ferent from the MSS’s own NRI.

Therefore, it is ensured that the HLR stores the correct VLR address, and the successrate of the MT transactions increase.

There is no activation needed for this functionality.

For detailed instructions on how to test the LUP behavior when subscriber changes fromone VLR to another at MSS pool borders functionality, see the Feature ActivationManual Feature 1449: Multipoint Iu in MSS Concept , available in the M-release FeatureDocumentation library.

3.4 Radio network configuration for pooling and multipointfeatures in MSC/MSSWhen the pool area concept is in use and the MSCs/MSSs share the total traffic of thepool area, the radio network of an MSC/MSS covers a larger geographical area thanwithout this concept. The radio network configuration of the pool area must be the same

in every pool area MSC/MSS. One, or several MSSs (a maximum of 10), can serve aCS pool area.

The whole service area of a RAN node belongs to one pool area. The RAN nodecoverage area may also belong to multiple pool areas. This is the case when multipleoverlapping pool areas include this RAN node coverage area. The whole Location Area(LA) must belong to one pool area and in overlapping pool areas the LA must belong toeach of the overlapping pool areas.

The overlapping pool areas are illustrated in the figure Pool area configuration example ,where RAN area 2 and RAN area 6 belong to overlapping pool areas.

Overlapping pool areas can also be implemented when RAN Independent Multipoint A/Iu Support in MGW feature is in use. Since the RAN nodes have point-to-point con-nectivity to MGWs, overlapping pool areas are achieved by configuring the MGWs tomore than one MSS pool area. An example of overlapping pool areas in this configura-tion is illustrated in the figure Overlapping pool areas with RAN Independent Multipoint

A/lu support in MGW .

For further information, see also Section Overlapping MGW clusters .





Issue 9-0 draft


Id:0900d805809d6ecc


Figure 10 Overlapping pool areas with RAN Independent Multipoint A/Iu Support inMGW

Overlapping pool areas is discussed in Section MSC/MSS pool planning aspects .

3.5 Default MSC/MSS A default MSC/MSS, one of the parallel MSC/MSSs in a pool, is used by an MSC/MSSwhich does not support the multipoint feature, to resolve the ambiguity of the multipleMSCs/MSSs for a LA, by deriving the NRI from the TMSI. The default node relays thesignaling between the new MSC/MSS and the old MSC/MSS which does not supportthe multipoint feature. The default node is configured for each LA in the MSCs/MSSsthat do not support the multipoint feature. The MSCs/MSSs that do not support the mul-tipoint feature handle the default node as a normal neighboring MSC/MSS.

Different MSCs/MSSs in a network may have been configured with different defaultnodes for a LA in a pool area. With this approach, more than one of the poolMSCs/MSSs is used as the default node, so that load concentration on one node in apool area and so creating a single point of failure is avoided.

Default MSC/MSS functionality is described in Section Mobility in MSC/MSSpoolconcept .

3.6 Mobility in the MSC/MSS pool conceptThe mobility procedures in the following sections apply both for the 3GPP standard RANbased multipoint solution as well as for RAN Independent Multipoint A/Iu Support inMGW where the NNSF is located in the MGW, unless specifically indicated.

3.6.1 Roaming and the MSC/MSS pool concept

Roaming within MSC/MSS pool area

When an MS moves from an old LA to a new LA, and both LAs are within the same poolarea, the RAN node that receives the request checks the NRI in the Location Updating

CS pool 1 CS pool 2

MSS 3

MGW MGW MGW MGW MGWNNSF NNSF NNSF NNSF NNSF

RAN 8RAN 7RAN 6RAN 5RAN 4RAN 3RAN 2RAN 1

MSC/MSS1 MSC/MSS2 MSC/MSSnMSS 3

MSS4 MSS5 MSS6MSS1 MSS2 MSS3MSS pool area 1 MSS pool area 2





27



Id:0900d805809d6ecc

Request message. The NRI value sent by the MS, is used by the RAN node (or option-ally by MGW when RAN Independent Multipoint A/Iu Support in MGW feature is in use)to address the request to the same VLR under which the subscriber is already regis-tered.

Figure 11 Roaming within an MSC/MSS pool areaWithin the pool area the subscriber does not need to change between VLRs. Comparedto the traditional architecture, this reduces signaling messages between the VLR andthe HLR because there are fewer inter-VLR location update requests.

Roaming between MSC/MSS pool areas within network

When an MS moves from one LA to a new LA which does not belong to the same poolarea, an inter-MSC/MSS location update is required. During this procedure, the newMSC/MSS contacts the old MSC/MSS to retrieve the subscriber-related information.The new MSC/MSS uses the old LA together with the NRI to derive the signalingaddress of the old MSC/MSS from its configuration data.





Issue 9-0 draft


Id:0900d805809d6ecc


Figure 12 Inter pool area location update

At the end of the LU procedure, the MS is assigned a new TMSI and a new NRI valuethat belong to the newly selected MSC/MSS.

The procedure is similar when the old LA is outside the pool area concept, except thatthe old MSC/MSS is derived from the old LA information only.

Roaming from MSC/MSS pool area to a non-pooled area

When an MS performs a location update in an area controlled by an MSC/MSS that doesnot belong to the pool area concept, the new MSC/MSS uses the old Location AreaIdentification (LAI) received in the Location Updating Request message to derive thesignaling address of the default MSC/MSS.

The default MSC/MSS, which receives the subscriber information request messagefrom the new MSC/MSS, may not be the one which served the MS in the pool area, andtherefore it needs to resolve the correct MSC/MSS address. The default MSC/MSSderives the NRI from the TMSI, and forwards the request to the correct MSC/MSS. Thecorrect MSC/MSS responds by sending the subscriber information directly to the newMSC/MSS. It is possible to use more than one pool MSC/MSS as a default node todecrease the load on a single node and avoid creating a single point of failure.





29



Id:0900d805809d6ecc

Figure 13 LA under MSC/MSS not belonging to the pool area concept

In this scenario, if the new MSC/MSS supports multipoint features but does not belongto any pool, it can either use the default MSC/MSS as described above for finding theold MSC/MSS or, it can be configured with the NRIs of all of the pool MSCs/MSSs. Inthe latter case, the new MSC/MSS can find the old MSC/MSS directly without contactingthe default MSC/MSS.

With such a configuration, network resiliency is enhanced when moving from a pooledto a non-pooled area during a location update. It is possible to configure all the poolMSCs/MSSs NRIs in the MSC/MSS that is located outside of the pool area. Having asingle default MSC/MSS is then not required. If there is only one default pool MSC/MSSdefined in the MSC/MSS outside of the pool area, the default pool MSC/MSS maybecome unavailable because of maintenance or failure. With this enhancement suchlimitations do not exist. The MSC/MSS outside of the pool area can identify, based onthe NRI and the old LA information, which pool MSC/MSS had earlier been serving thesubscriber.

g The MSC/MSS outside of the pool area must also have the multipoint feature activatedfor this enhancement to function.

Roaming from a non-pooled area to an MSC/MSS pool area

When an MS performs a location update, having been in an area controlled by anMSC/MSS that does not belong to the pool area concept, to a pool MSC/MSS, the newpool MSC/MSS is able to derive the signaling address of the old MSC/MSS. The newpooled MSC/MSS uses the old Location Area Identification (LAI) received in theLocation Updating Request message to derive the signaling address of the oldMSC/MSS, as in a normal inter-VLR Location Update.

3.6.2 Handover and the MSC/MSS pool concept

Handover within a pool area

Using multiple MSCs/MSSs in a pool concept enlarges the served area compared to theservice area of one MSC/MSS, and the need for inter-MSC/MSS handovers is corre-





Issue 9-0 draft


Id:0900d805809d6ecc


spondingly reduced. As long as an MS remains within the pool area, it will only makeintra-MSC/MSS handovers.

Resource division between many MSCs/MSSs may, however, increase the probability

of congestion when A interface over TDM is used. This can be prevented with additional A-/Ater-interface resources.

There is also an additional Nokia Siemens Networks functionality in the MSC/MSS toprevent the clearing of an ongoing call during an intra-MSC/MSS handover in theassignment phase inside the pool area due to a lack of PCM resources in Multipoint A.

An inter-MSC/MSS handover inside the pool area is performed if an intra-MSC/MSShandover fails. In this situation, an intra-MSC/MSS handover is attempted once toanother MSC/MSS in the pool area as illustrated in the figure Intra pool area handoverenhancement.

Figure 14 Intra-pool area handover enhancement

In the above example, the intra-MSC/MSS1 handover fails due to congestion atMSC/MSS1–BSC2 A-interface, however, an inter-MSC handover from MSC/MSS1 toMSC/MSS2 is successful because free A-interface resources between BSC2 andMSC/MSS2 are available.

Handover between pool areas

When the MS moves in active mode from one pool area to a neighboring pool area, aninter-MSC/MSS handover is initiated. In inter-MSC/MSS handovers, the sourceMSC/MSS selects the target MSC/MSS by load balancing between all targetMSCs/MSSs serving the neighboring pool area. The source MSC/MSS uses round-robin selection for the MSC/MSSs of the neighbor pool area. If there are targetMSC/MSS 1, MSC/MSS 2 and MSC/MSS 3, the first handover from this pool area ismade to MSC/MSS 1 of the neighboring pool area. If a second subscriber moves fromthe same pool area into the same neighboring pool area, it is directed to MSC/MSS 2,the third to MSC/MSS 3, a fourth to MSC/MSS 1, and so on.

In a subsequent handover, where the first handover is from the pool area but targetedoutside the pool, and the second one is back into the same pool area, the servingMSC/MSS is always the same one: the anchor MSC/MSS in the original pool area.

Handover into a pool area

If a handover into a pool area from a non-pooled network occurs, an inter-MSC/MSShandover is required. An MSC/MSS serving the MS in the non-pooled network has foreach target LA a certain MSC/MSS configured as the target MSC/MSS located in the





31



Id:0900d805809d6ecc

pool area. In such cases, load balancing between all target pool MSCs/MSSs can beachieved using a fixed configuration (certain LAs for an MSC/MSS).

If the enhanced handover functionality is activated for handovers between pooled areas,

it is possible to select, during a inter-MSC/MSS handover, another MSC/MSS from thetarget pool area if the first choice is not accessible because of, for example, a failure inthe target MSC/MSS. This is achieved by enabling the configuration of more than onetarget pool MSC/MSS towards the neighboring pool area. The same enhancement canalso be utilized when the source MSC/MSS is located outside of the pool area. This,however, requires that the multipoint feature is activated in the source MSC/MSS whichis located outside of the pool area, in order to create the required configuration in thesource MSC/MSS for multiple target MSCs/MSSs.

If congestion is experienced in the A-interface during a handover, as described earlierin this section in the case of Multipoint A, with this enhancement it is possible to detectsuch situations and attempt to perform the handover using another pool area MSC/MSS

to increase the handover success rate. When the ongoing call ends and the MSbecomes idle, it detects that the location area has changed and performs a LocationUpdate procedure, the NRI will be allocated as described in Section TMSI/NRI allocation

process by the core network .

Handover from a pooled area to a non-pooled area

When a handover from a pool area into a non-pooled network occurs, an inter-MSC/MSS handover is performed normally.

3.6.3 Gs interface: inter-working with MSS PoolingIn NMO1 (Network Mode of Operation 1), the Gs interface between the Serving GPRS

Support Node (SGSN) and the MSC/VLR is used for co-ordinating an MS that is bothGPRS-attached and IMSI-attached. The Gs interface functionalities include 2G/GSMpaging coordination and combined mobility procedures for radio resource saving.Paging co-ordination is required because some 2G MSs do not otherwise respond topaging while having a Packet Data Protocol (PDP) context active in the packet core.Such paging coordination is not required in 3G/UMTS radio access since this can bemanaged by the RNC, however, the combined mobility management procedures for sig-naling saving can be used. For combined mobility management, an SGSN-VLR associ-ation is created by the SGSN on the Gs interface toward the VLR/MSS when a mobilemakes a combined mode GPRS/IMSI attach, or a combined RA/LA update, through theSGSN.

CS and PS pool areas in an operators network are handled independently, however, theGs interface creates some dependency between the planning and operation of the CSand the PS pool areas. When PS pool areas are introduced in to the network, the appro-priate SGSN is first selected by the NAS node selection function (NNSF) in the RANnode, based either on:

• The SGSN NRI value in the P-TMSI (independent of the MSC/MSS NRI valuerange), or

• Upon the RAN node subscriber distribution function.

Each SGSN is configured with one or more SGSN-specific NRIs. One of these SGSN-specific NRIs is part of every packet temporary mobile subscriber identity (P-TMSI)assigned to the UE by the SGSN.





Issue 9-0 draft


Id:0900d805809d6ecc


When MSCs/MSSs are in pool configuration and there is more than one MSC/MSSserving the relevant LAI, the SGSN has to select an MSC/MSS from the MSC/MSS poolto serve the subscriber during the combined mobility procedure. Typically, this is donewith the so called IMSI hash algorithm defined in 3GPP TS 23.236 (Intra-domain con-nection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes).With the IMSI hash algorithm [(IMSI div 10) modulo 1000], the SGSN derives a value (V)ranged between 0 and 999. Each value (V) corresponds to a specific MSC/MSS in theMSC/MSS pool area. Usually, a range of values (V) are allocated to each MSC/MSS inthe MSC/MSS pool area.

The MSC/MSS selection process during the Combined RA/LA update procedure whenGs interface is used is illustrated in the figure MSC/MSS selection during CombinedRA/LA Update procedure when Gs interface is used.

Figure 15 MSC/MSS selection during Combined RA/LA Update procedure when Gsinterface is used

In NMO1, the Combined LA/RA Update procedure is used, as defined in 3GPP TS

23.060 General Packet Radio Service (GPRS); Service description. A combined RA/LAupdate takes place in NMO1 when, for example, the MS enters a new Routing Area(RA). The MS sends a Routing Area Update Request indicating that an LA update mayneed to be performed. This concerns only MSs in idle mode, because combined RA/LAupdates are not performed during a CS connection.

When the MS initiates a Combined LA/RA Update procedure towards the network, theRAN node selects the SGSN according to the RAN node subscriber distribution func-tionality. The RAN node forwards the Combined LA/RA Update to the selected SGSN.

When an SGSN supports pooling, the SGSN makes the MSC/MSS selection accordingto the SGSN subscriber distribution functionality (for instance, with IMSI hash) and initi-ates the establishment of the Gs association towards the selected MSC/MSS bysending the Location Update Request to that MSC/MSS.





33



Id:0900d805809d6ecc

The selected MSC/MSS includes a new TMSI with its NRI value in the Location Update Accept message and sends it to the SGSN over the Gs interface. The SGSN completesthe Routing Area procedure and responds to the MS with an RA Update Acceptmessage containing both the new P-TMSI and the TMSI. The respective SGSN andMSC/MSS NRI values are available in the TMSI/P-TMSI for later transactions to makethe corresponding CN node selection for the subscriber. The subscriber distributionfunctionality may either be located in the RAN node, or in the MGW when the RAN Inde-pendent Multipoint solution is used.

Nokia Siemens Networks MSC/MSS selection functionality in multipoint configuration isdescribed in Subscriber distribution in the pool area in Nokia Siemens Networks' RNC,BSCs, SGSN and Flexi Direct BTS .

Gs interface resiliency requirement when MSC/MSS pooling is used

When multiple MSCs/MSSs are configured in the SGSN for an LAI and the MSCs/MSSsare in a pool configuration, it must be possible for the SGSN to distribute the subscribersbetween the pooled MSCs/MSSs when creating the Gs association. Subscriber distri-bution by the SGSN can be achieved, for example, using the IMSI hash algorithm. TheSGSNs selection mechanism must also prevent unnecessary MSC/MSS changes forsubscribers.

The SGSN must provide sufficient resiliency when one or more of the pool areaMSCs/MSSs are unavailable for subscriber distribution to guarantee service availabilityfor the combined subscribers during MSS failure situations. The MSC/MSS selectionalgorithm in SGSN must be modified accordingly in order to select a different pooledMSC/MSS to that which is unavailable.

g The Gs interface resiliency solution in MSC/MSS failure situations may be SGSN vendor

specific.

If SGSN implementation does not provide support for MSS pooling with Gs resiliency aswell as for MSS off-loading, it is recommended not to use Gs interface in the network.Instead, RAN provided features (when available) should be considered for paging coor-dination.In NSN BSC, paging coordination is introduced by Feature BSS20738: Paging coordi-nation in BSC.

If the SGSN does not support multipoint functionality and the related MSC/MSS selec-tion function, only one default MSC/MSS from the pooled MSC/MSSs serving therelated LA can be used for combined mobility procedures. MSC/MSS resiliency is notachieved if the SGSN does not support multipoint. Similarly, Gs association load sharingis not possible either.

The Gs association has to be updated when an MS changes VLR or when an MSchanges SGSN. In optimal pool area planning, unnecessary MSC/MSS changes areavoided. Although the PS and CS pool areas can be defined independently, from theperspective of network planning and signaling saving, it is beneficial if the SGSN doesnot need to unnecessarily change the Gs association towards a new MSC/MSS withinthe same CS pool area when the UE remains in the same MSC/MSS service area.

Effective radio network planning reduces the number of unnecessary MSC/MSSchanges by, for example, restricting the SGSN area to that of the CS pool area.

The LU mode always changes if the mobile changes radio network attachment between

2G and 3G. Similarly, the Gs association breaks if the mobile makes a CS LU directly tothe VLR.





Issue 9-0 draft


Id:0900d805809d6ecc


For the reasons mentioned above, the Gs interface can be used together with the Mul-tipoint A and Iu features only if the SGSN also supports the multipoint functionality andthe related subscriber distribution to the pool MSCs/MSSs. If the Gs interface is used ina network where the Multipoint A or Iu feature is planned to be implemented, it is nec-essary to have multipoint-related subscriber distribution and Gs interface resiliencysolution support for MSC/MSS failure and subscriber off-loading situations in the SGSNas well.

Gs interface and MSS off-loading

When the Gs interface is implemented in the network and the operator uses the loadredistribution functionality to off-load one or more MSCs/MSSs in the pool area in NMO1the MSC/MSS allocates a Null-NRI and non-broadcast LAI during the Combined LA/RAUpdate procedure. In the same way as with NMO2 without Gs interface, this triggers theMS to initiate a new Combined LA/RA Update procedure.

For proper network functionality it must be ensured that the SGSNs` MSC/MSS selec-tion mechanism does not re-select the MSC/MSS that is being off-loaded. According to3GPP TS 23.236 (Intra-domain connection of Radio Access Network nodes to multipleCore Network nodes), this can be achieved by using O&M commands to exclude theaddress of the MSC/MSS being off-loaded from the SGSNs` MSC/MSS selection func-tion.

Additionally, the SGSN is required to modify its IMSI hash table to reflect the change. IfSGSNs are also configured in a pool, this change must be repeated in every SGSNsconnected to the off-loaded MSC/MSS. From the SGSNs perspective, MSC/MSS off-loading is done in two phases according to 3GPP TS 23.236.

1. In the first phase, MSs that are performing Combined RA/LA Update are moved toa new MSC/MSS in the MSC/MSS pool area according to the SGSNs modified IMSIhash table.

2. In the second phase, the SGSN scans its Gs associations to identify which MSsmust be moved. To force the MSs to move, the SGSN first sends a Detach Requestto the MSs, which triggers the MSs to re-attach to non-GPRS service and to sendCombined RA/LA Updating with IMSI Attach. When the Combined RA/LA updatingwith IMSI Attach is received in SGSN and the MS is identified as one that must bemoved, the SGSN makes the MSC/MSS selection according to the modified IMSIhash table.

Therefore, for MSC/MSS off-loading with Gs interface, SGSN support is required. IfSGSN support does not exist (for example, for IMSI hash table reconfiguration), the off-loaded subscriber may be directed back to the same MSC/MSS that is being off-loaded.This would generate an undesirable increase in signaling in the network. In the worstcase, the subscriber may not be able to access non-GPRS services at all if theMSC/MSS which is off-loaded is excluded from the SGSN subscriber distribution butthere is no Gs resiliency support in the SGSN to enable another pooled MSC/MSS to bechosen.

For the reason outlined above, without SGSN redistribution support at the Gs interface,MSC/MSS off-loading, both MSS controlled off-loading and Null-NRI based off-loading,may not result in the desired subscriber distribution in the MSC/MSS pool area. Thus,MSC/MSS off-loading scenarios must be carefully considered during the networkplanning phase, taking into account, in particular, the availability of SGSN support foroff-loading.





35



Id:0900d805809d6ecc

Gs interface and the RAN Independent Multipoint solution

The principles described above for Gs association establishment and NRI allocationapply also when Gs interface with optional RAN Independent Multipoint A/Iu Support in

MGW feature is used.In addition, RAN Independent Multipoint A/Iu Support in MGW feature ensures that thePaging Response is delivered to the MSS that initiated the Paging (with TMSI or IMSI)over the Gs interface.

Paging over Gs and paging coordination in MGW is illustrated in the figure CS Pagingcoordination in the MGW.

Figure 16 CS Paging coordination in the MGW

Incorrect TMSI allocation during MTC call when MSS is in maintenance mode

When Feature 1449: Multipoint Iu in MSS Concept and/or Feature 1564: Multipoint A

interface are active and the MSS is in maintenance mode, the load redistribution of thesubscribers is done by allocating Temporary Mobile Subscriber Identities (TMSIs) withnull-NRI or parallel MSS NRI values to the subscribers. That forces the network to directthe subscribers to a parallel MSS. The SGSN uses MSS selection method based onIMSI, and because of this, the subscribers are always directed to the same MSS. Theenhancement makes it possible to skip the redirection of the subscribers who registeredfrom the SGSN side to the VLR, and paging failures of combined subscribers are alsoprevented. This can be done by allocating TMSIs with their own NRI values, that is, thevalues of the current serving MSS, for those subscribers and it means that they are notredirected to another MSS. So SGSN attached subscribers can be handled differentlyby MSS in case of load redistribution.

Feature 1449: Multipoint Iu in MSS Concept and Feature 1564: Multipoint A interfacecan be activated with new PRFILEs.





Issue 9-0 draft


Id:0900d805809d6ecc


For more information on the activation on these functionalities, see the documentsFeature 1449: Multipoint Iu in MSS, Feature Activation Manual and Feature 1564: Mul-tipoint A interface, Feature Activation Manual , available in the M-release documentationlibrary.

3.7 Subscriber distribution between MSCs/MSSsThe NAS node selection function (NNSF) in the RAN node and in the SGSN, or option-ally in the MGW when RAN Independent Multipoint A/Iu Support in MGW feature is inuse, distributes the subscribers between the available MSCs/MSSs. This is achieved byselecting an appropriate MSC/MSS for an MS.

For subscriber distribution in the pool area, the NNSF functionality is specified in 3GPPTS 23.236 . The NNSF is responsible for directing the MS with a valid NRI value to therespective MSC/MSS element. For incoming subscribers that do not have a valid poolNRI and are not yet allocated to an MSC/MSS, the NNSF also distributes the subscrib-ers between the pool MSCs/MSSs during Location Update and IMSI Attach procedures.

According to 3GPP TS 23.236 , subscriber distribution between the pool MSCs/MSSswhen the NRI value is not yet available, is an implementation-specific functionality.

Subscriber distribution also includes the load redistribution functionality as specified in3GPP TS 23.236 . The load redistribution functionality is used for off-loading subscribersfrom an MSC/MSS in an orderly manner.

Subscriber distribution between the network elements in the pool area is described inSubscriber distribution in the Nokia Siemens Networks RNC, BSCs, SGSN and FlexiDirect BTS .

gSubscriber distribution between the MSCs/MSSs is made only for the subscribersentering the pool area. Any adjustments made to subscriber distribution in the BSC,RNC or SGSN/MME (or in MGW when MGW-based multipoint solution is in use) onlyslowly affect the overall subscriber distribution in the MSCs/MSSs. This is valid in acountry wide pool area, for example, unless other on-loading methods for faster sub-scriber distribution are available in the related NNSFs, or unless CN controlled load bal-ancing functionality is used.

Subscriber distribution in an MGW when optional RAN Independent MultipointA/Iu Support in MGW feature is in use

When the optional RAN Independent Multipoint A/Iu Support in MGW feature is used,the subscriber distribution functionality is located in the MGW. The MGW provides sub-

scriber distribution and load balancing for new incoming subscribers to the pool area thatare not yet assigned to an MSS. If the MSS address is not configured for the NRI or ifan NRI cannot be derived from the TMSI, the MGW subscriber distribution selects a poolarea MSS.

Subscriber distribution amongst pool MSSs is achieved using a weighted round robinmethod with configurable weight factors (0 to 100) for each pool MSS.

This method is used independently in each MGW ISU unit. Within the MGW, SCCPmessage distribution is used to balance traffic between ISU units and thus on an MGWlevel subscriber distribution is statistically related to the weight factors.

The table, Example of traffic distribution in MGW with weighted round robin method,provides an example of subscriber distribution in the MGW. With the example weight





37



Id:0900d805809d6ecc

factors, the respective subscriber load of each MSS in normal operation when all poolMSSs are in use is shown, as well as subscriber load when one MSS is out of use.

On-load and off-load modes in MGW

It is also possible to configure in the MGW each MSS either to on-load mode or to off-load mode.

In the on-load mode, all initiating transactions (except paging responses and IMSIdetaches) are routed to the indicated MSS regardless of the NRI value. Pagingresponses and IMSI detaches are still routed based on the included NRI value to theMSS which has been serving the subscriber. "On-load" mode is timer controlled. Afterthe timer expires, normal subscriber distribution in the MGW is restored. On-load modecan be utilized when more rapid subscriber distribution to a certain MSS is needed, forexample, after taking the MSS back into use.

In off-load mode, all initiating transactions (except paging responses) are routed to otherpool MSSs. With this mode the operator can prepare for MSS maintenance by movingthe subscribers from an MSS that is to be taken out of use. Paging responses are stillrouted to the original MSS which has been serving the subscriber within the pool area,in order to provide MT service availability. When the next MO transaction (for example,location update or MO call) takes place, the MGW subscriber distribution off-loads thesubscriber to a new MSS within the pool area.

These are alternate methods for CN initiated subscriber re-distribution, which are alsoapplicable when feature RAN Independent Multipoint A/lu support in MGW is in use.

Load redistribution using a Null-NRI

There are situations where a network operator wants to reduce load from an MSC/MSSin an orderly manner (for example, to perform scheduled maintenance or for load redis-tribution to avoid overload) with minimal impact on end users and/or additional load onother network elements.

3GPP defines the load redistribution functionality in Rel-6 3GPP TS 23.236, Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network(CN) nodes . Each pool MSC/MSS has to be assigned one unique non-broadcast LAIand a Null-NRI value that will be used if the operator wants to off-load the MSC/MSS.The load redistribution procedure is illustrated in the figure Load redistribution proce-dure.

MSS WeightFactor Load Load with one MSS out of use

1 100 100(100+70+50+30)=40%

0%, out of use

2 70 70(100+70+50+30)=2

8%

70(70+50+30)=47%

3 50 50(100+70+50+30)=20%

50(70+50+30)=33%

4 30 30(100+70+50+30)=12%

30(70+50+30)=20%

Table 2 Example of traffic distribution in the MGW with weighted round robinmethod





Issue 9-0 draft


Id:0900d805809d6ecc


Figure 17 Load redistribution procedure

The load redistribution procedure is used when an MSC/MSS has been set into off-loading mode, for example, to off-load it for maintenance or to reduce the subscriberload. When the MSC/MSS receives the Location Update or Attach request from the MS,it returns a new TMSI including a Null-NRI and a non-broadcast LAI in the LocationUpdating Accept message.

On receiving the Location Updating Accept message, the non-broadcast LAI causes theMS to immediately send a new location update request. The non-broadcast LAI is notone of the LAIs broadcast by the RAN node and so the MS interprets this as being in anew LA. When a new location update request is initiated by the MS, the RAN node (oroptionally the MGW when RAN Independent Multipoint A/Iu Support in MGW feature isin use) routes it to a new MSC/MSS according to its subscriber distribution functionality.The Null-NRI and O&M indication in the RAN node/MGW prevents the RAN node/MGWfrom selecting the MSC/MSS that is being off-loaded. When an MSC/MSS is off-loaded,a Null-NRI is returned in response to all Location Update or Attach requests regardlessof VLR parameters.

The 3GPP standards-based load redistribution procedure, described above, requiresthat O&M commands preclude the selection of the MSC/MSS that is set to off-loadingmode. This procedure is described in the Section MSC/MSS off-loading in a pool withNull-NRI . The subscriber distribution function may be located in the RAN nodes, in theMGW when RAN Independent Multipoint A/Iu Support in MGW feature is in use, or inthe SGSN (or MME) if the Gs (or SGs) interface is used.

In the CS domain, the load redistribution process is performed in two phases asdescribed in 3GPP TS 23.236 .

1. In the first phase, often referred to as Idle mode off-loading, (lasting perhaps twoperiodic LU periods) the VLR to be off-loaded, in response to an O&M command,allocates TMSIs with a Null-NRI and a non-broadcast LAI when a Location Update,or Attach request, is received from an idle mode MSS. This causes the MS to makea new location update.When the RAN node (or optionally the MGW when RAN Independent Multipoint A/IuSupport in MGW feature is in use) receives a message with a Null-NRI, it uses theNAS Node Selection Function to select an MSC/MSS to forward the message to.

After phase one, the majority of subscribers have been redistributed to other poolarea MSCs/MSSs.

2. According to 3GPP TS 23.236 , the second phase, often referred to as active modeoff-loading, re-distributes active mode MSs. It involves scanning through the remain-





39



Id:0900d805809d6ecc

ing MSs and initiating a move to another MSCs/MSSs. A new TMSI is allocated tothose UEs using the TMSI re-allocation procedure (with a Null-NRI and a non-broad-cast LAI). When the ongoing connection management (CM) transaction ends, aLocation Update is triggered. The UEs are moved to a new MSC/MSS according tothe RAN node/MGW subscriber distribution functionality.

The start of load distribution can be defined in the MSC/MSS using O&M commands.This is done by setting the MSC/MSS into off-loading mode. It is also possible to definethe time period after which the active mode subscribers will also be included in Null-NRIallocation. The recommended time period corresponds to a couple of periodic locationupdate periods to allow for redistribution of idle mode subscribers in the first phase. Ifthe time period is shorter, the redistribution of subscribers is faster, but may cause ahigher inter-VLR location update load because more subscribers are redistributed at thesame time. As a minimum, set the active mode off-loading starting time period to onehour. If the time period is not set, the Null-NRI allocation for active mode subscribers isnot used.

Even though some calls would be lost when an MSC/MSS is taken out of service beforeall subscribers have been distributed to another MSC/MSS, new call attempts succeedthrough another pool area MSC/MSS.

MSs being moved from one MSC/MSS are prevented from registering to the sameMSC/MSS by an O&M command in the pool RAN nodes/MGW. MSs moving into a poolarea may also be prevented from registering to an MSC/MSS being off-loaded in thesame way.

When the RAN Independent Multipoint A/Iu Support in MGW feature is in use, the MGWcan detect the MSS which is being off-loaded based on Null-NRI included in subscriberTMSI. This functionality reduces the required O&M effort, because it is not necessary to

specifically indicate in the MGW which MSS is being off-loaded. The pre-requirement forthis is that MSS-specific Null-NRI values are defined for the pool MSSs. This optionalfeature also significantly hastens the off-loading of subscribers from the MSS.

Effective pool area planning ensures that the redistribution of MSC/MSS traffic does notcause an overload in the other pool MSC/MSSs. The BSCs/RNCs/MGWs must havesufficient capacity to manage situations where one, or more, MSC/MSSs are off-loaded.

Pool area MSCs/MSSs may also manage a radio network that is not included in the poolarea. Load redistribution does not affect MSs that are in non-pooled areas, because thenon-broadcast LAI is not sent to non-pool area LAs and, thus, MSs do not initiate a newlocation update (LU).

For load redistribution and Gs interface interworking, see Section Gs interface: inter-working with MSS Pooling and for load redistribution and SGs interface interworking,see Section SGs interface interworking with MSS Pooling .

CN controlled load balancing between MSCs/MSSs using parallel MSC/MSS NRIallocation

As an enhancement to the 3GPP standards-based basic multipoint functionality, themultipoint feature provides for CN controlled load balancing between MSCs/MSSs. Thisenables faster load balancing between pool area MSCs/MSSs and reduces the O&Meffort necessary to modify the subscriber distribution in the RAN nodes (or optionally inMGW when RAN Independent Multipoint A/Iu Support in MGW feature is in use).

The operator can assign the subscribers from the MSC/MSS that is being off-loaded

directly to a predefined pool area MSCs/MSSs. This is done by allocating the NRI value





Issue 9-0 draft


Id:0900d805809d6ecc


of another pool area MSC/MSS instead of using a Null-NRI during off-loading. The sub-scribers from the MSC/MSS that is off-loaded can be distributed to multiple pool areaMSC/MSS by configuring the target MSCs/MSSs NRIs. Subscribers are allocated to theMSC/MSSs by weighted round robin selection set using O&M commands in theMSC/MSS.

The non-broadcast LAI is allocated to the subscriber during the location updating orTMSI reallocation procedures. This triggers the MS to initiate a new location update pro-cedure, which is automatically directed to the desired MSC/MSS by RAN node/MGWload balancing, based on the target MSC/MSSs‘ predefined NRI value.

It is necessary to configure the non-broadcast LAIs of the parallel MSCs/MSSs into eachpool MSC/MSS to avoid subscribers bouncing between MSCs/MSSs if, for example,redistribution of subscribers coming from non-pooled areas is used simultaneously.When it is identified in the new MSC/MSS that the subscriber has previously been redis-tributed, it is not redistributed back to the old MSC/MSS. The old MSC/MSS is identified

by its non-broadcast LAI.The MSC/MSS can still be set as unavailable for subscriber distribution in the RANelements using O&M commands, in order to exclude the MSC/MSS that is being off-loaded from RAN node subscriber distribution for new incoming subscribers. The RANis prevented from allocating subscribers coming into the pool area without a valid NRIto the MSC/MSS being off-loaded. Signaling for the incoming subscribers during CNcontrolled load balancing is reduced.

If the MSC/MSS is not set as unavailable in the RAN elements, subscribers that areunnecessarily distributed to the MSC/MSS which is being off-loaded, are re-directed toother pool area MSCs/MSSs by the CN controlled load balancing functionality. Theoperator can thus avoid additional RAN node O&M effort.

If the SGSN makes MSC/MSS selection based on, for example, IMSI hash algorithm,which does not take into account the desired subscriber distribution defined in theMSC/MSS for CN controlled off-loading, the SGSN may re-select the same MSC/MSSfor the subscriber.

Automatic stopping of load redistribution at a predefined VLR threshold

A predefined VLR utilization rate can be defined in MSC/MSS which stops further loadre-distribution. This is useful in situations when the load from one MSC/MSS needs tobe reduced to a certain threshold level. This enhancement means that monitoring theVLR filling rate in the MSC/MSS being off-loaded is not necessary, nor is it necessaryto manually de-activate the off-loading mode in MSC/MSS when the targeted filling rate

is reached.Location area based subscriber off-loading

Instead of off-loading all subscribers of an MSS, subscribers at certain location areascan be off-loaded from the MSS. The LA based off-loading can be initiated by the useof the MSS off-loading commands by indicating an LA list (1 - 10 LAs) when activatingthe MSS off-loading.

Location area based subscriber off-loading is beneficial in cases when it is necessary tooff-load subscribers at certain location areas from one pool MSS to MSS(s) in the poolarea, for example, during pool configuration migration or when subscribers need to bemoved back to a certain MSS after its recovery and if this is necessary for certain LAsubscribers only. In addition, when TDM circuits are used at A-interface and due tosome reason congestion towards certain BSC is experienced, it is possible to off-load





41



Id:0900d805809d6ecc

subscribers from the BSC (=concerned LA) to other MSSs in the pool area and, this way,relieve the circuit congestion situation. This enhancement is applicable for both RANindependent and RAN based multipoint solutions.

Subscriber redistribution in case of load restriction in VLRIncoming subscribers can also be directed to other pool MSCs/MSSs for more optimaluse of VLR resources when either the VLR capacity, or VLR capacity license, is limitinga subscribers inclusion in a certain VLR. This is done by allocating the NRI value ofanother pool MSC/MSS and activating load redistribution. A pre-configured NRI list ofparallel pool MSCs/MSSs NRI values and their relative weight factors is used for select-ing the MSC/MSS in the pool area where the subscriber will be directed. The parallelNRI list for redistribution is always used when this functionality is activated. The Null-NRIvalue is not used.

Redistribution because of load restriction in a VLR is activated by MML command in theMSC/MSS. When the off-loading mode is active, the VLR checks, during the locationupdate/attach procedure, the VLR`s capacity limit and decides if redistribution of sub-scribers to another MSC/MSS is required. If redistribution is required, the NRI of aparallel MSC/MSS is added to the new TMSIs. A non-broadcast LAI is added to thelocation updating accept message to initiate the new location updating procedure by theMS. The new location updating procedure moves the subscriber to the parallelMSC/MSS indicated by the NRI value.

Radio interface signaling optimization during load redistribution

Signaling over the radio interface can be reduced when the off-loading mode is activatedin an MSC/MSS and subscribers are moved to other MSCs/MSSs. The new MSC/MSSis capable of finding the old MSC/MSS and obtaining the subscriber information directly,

instead of requesting the subscriber information from the mobile.The old MSC/MSS is identified by the new MSC/MSS from the MSC/MSS specific non-broadcast LAI value. Based on the MSC/MSS address configuration of the parallel poolMSCs/MSSs, the new MSC/MSS can contact the old MSC/MSS for the subscriber datainstead of requesting it from the MS and HLR.

Service restoration when the multipoint feature is active

A pool area MSC/MSS may go out of service because of a failure, or be temporarilyunavailable due to software upgrade or configuration maintenance.

If one, or more, pool MSC/MSSs goes out of service, all the MSC/MSS-related ongoingcalls are lost, as would be the case in a non-pooled architecture. At the same time,

because the VLR address contained in the HLR refers to an MSC/MSS that is tempo-rarily out of service, all the subscribers registered under the VLR are unreachable forMobile Terminated (MT) transactions. The mobile cannot detect that the MSC/MSS isout of service.

Based on these considerations, the service can be restored in the multipoint configura-tion in the following ways:

• The mobile performs a Periodic Location Update request when the periodic LU timerelapses.

• The subscriber makes an originating call, or SMS, or any other mobile-originatingtransaction.

These actions imply a new registration request to a new MSC/MSS. To reduce the timeduring which MT services are unavailable, it is possible to set a shorter interval for the





Issue 9-0 draft


Id:0900d805809d6ecc


periodical LU timer value in the RAN. The optimal periodical timer value in the networkmust be selected taking into account the increased signaling caused at the radio inter-face caused by more frequent periodic updates.

After VLR recovery, mobile terminating transaction (for example, an MT call) also initiateservice restoration. Service restoration after a VLR restart is described in more detail inService restoration after VLR restart .

When the RAN nodes (or optionally MGW when RAN Independent Multipoint A/IuSupport in MGW feature is in use) detect that one, or more, MSCs/MSSs are unavail-able, they stop forwarding the subscriber's originating transactions to that MSC/MSS.The transactions are instead diverted to other MSC/MSSs to ensure that the subscribersservices remain available. The first subscriber transaction will be rejected since the sub-scriber is not yet registered in the new MSC/MSS. The MS will then perform a LocationUpdate procedure. The new MSC/MSS will allocate a new TMSI and a new NRI.

With the optional VLR Backup feature it is possible to maintain full MT service availability

in the pool area configuration if the MSC/MSS which is serving the subscriber becomesunavailable.

VLR backup solution: interworking with multipoint features

VLR backup solution facilitates the immediate restoration of terminating services afteran MSS fails. With the VLR Backup feature, the most critical operational VLR informa-tion is backed up to an external database facilitated by the VLR Backup Server.

When the HLR is unable to contact the failed MSS to establish a mobile terminatingtransaction, the signaling request is automatically or manually rerouted to an alternatepool MSS. This MSS/VLR fetches the key subscriber data from the VLR Backup Server(BS) and continues the transaction as normal.

If the HLR or STP supports re-routing of the PRN (pre-paging) to the replacementMSS/VLR the first mobile terminating transaction (without a preceding originating trans-action) will succeed. If re-routing of the PRN is not supported, then in certain instancesthe first terminating transaction fails, and only the second one succeeds.

The VLR BS solution prevents network overload because of excess signaling due tolocation updating if a VLR/MSS fails. In multipoint configurations, because of MSS poolwide radio network, the consequences of a VLR failure are more severe, and the VLRBS solution is a valuable enhancement improving network stability.

For VLR BS solution to work together with MSS Pooling, GT routing is required for situ-ations when an MSS in an MSS pool area fails. In such a scenario, there are multipleMSS/VLRs replacing the failed MSS/VLR in load sharing mode, so, as a result, all theremaining MSS/VLRs in the MSS Pool handle the failed MSS subscribers. Therefore, abasic requirement for MSS pool and VLR BU interworking is that all routing betweenMSS/VLRs and HLRs is based on GT addresses in HLRs (or in STPs) and inMSS/VLRs. Additionally, GT re-routing in HLR is required to have multiple destinationMSS/VLRs in load sharing mode.

For further information about VLR Backup feature, see the Feature Description Feature1881: VLR Backup Server in M-release Feature Documentation.

For further information about the VLR Backup solution in the MSS System, see SectionVLR Backup Solution in the document MSS SystemNetwork Resilience .





43



Id:0900d805809d6ecc

MSC/MSS overload

If a pool MSC/MSS becomes overloaded, the MSC/MSS sends an Overload messageto the two most burdensome RAN nodes indicating that it is overloaded. The MSC/MSS

can send multiple Overload messages to reduce traffic further, or to maintain a trafficlevel. Overload messages received from one, or more, pool MSCs/MSSs cause theRAN node to use load balancing to reduce the load on the MSC/MSS.

The overload procedures for the A and Iu interfaces are specified by 3GPP TS 48.008 for BSSAP (Base Station system (MSC-BSS) interface; Layer 3 specification) and 3GPPTS 25.413 for RANAP signaling (UTRAN Iu interface Radio Access Network ApplicationPart (RANAP) signaling).

The same solution for MSS overload handling is also used when the RAN IndependentMultipoint A/Iu Support in MGW feature is in use. The MGW transfers the MSS origi-nated Overload messages to the two most burdensome RAN nodes and the RAN nodesact to reduce the load on the MSC/MSS.

3.8 Multipoint interworking with other features

Features requiring cell/location area based routing

If routing-based features are in use in a pool area MSC/MSS, careful planning isrequired because the radio network configuration in each pool area MSCs/MSSs mustbe identical.

Routing features include Mobile Station Roaming Number (MSRN) allocation enhance-ment, cell independent routing categories, or other routing-based set-ups related to celldata, for example, the use of Original Dialling Class (ODC) together with Location AreaCode (LAC), or Cell ID (CI) in the extended pre-analysis.

Emergency call

All pool area MSCs/MSSs must be able to correctly handle emergency call routing. Inthe multipoint configuration, the routing data varies in the MSCs/MSSs since only oneMSC/MSS owns the ISUP connection and other MSCs/MSSs use the BICC, or SIPinter-connection to reach the final destination's point-of-interconnect (POI). The ISUPconnection cannot be shared because the ISUP routes in the network would be split intosmall routes. This would make configuration handling complicated.

The configuration for emergency call routing must be properly designed in each poolarea MSC/MSS. Cell level configuration must be identical in all pool area MSCs/MSSs,including the emergency call routing information.

Multi-Operator Core Network (MOCN)

The network sharing architecture allows different core network operators to connect toa shared 3G or 2G radio access network. The operators do not only share the radionetwork elements, but may also share the radio resources themselves. In addition to thisshared radio access network, the operators may have additional dedicated radio accessnetworks, for example, 2G radio access networks.

It is possible for one, or more, operators in a shared network to use the Multipoint Iu orMultipoint A feature with the Multi-Operator Core Network (MOCN), as defined in the3GPP TS 23.251: Network Sharing; Architecture and functional description . One ormore of the operators in the shared network may deploy the Multipoint Iu or Multipoint

A feature between the shared radio access network and their core networks. Addition-





Issue 9-0 draft


Id:0900d805809d6ecc


ally, operators may deploy the Multipoint Iu or Multipoint A feature within their own corenetworks.

If the MOCN feature is used without MSS pooling in the operator's network, multipoint

features are not required to be activated in the MSC Server System.When MOCN and multipoint features (Multipoint Iu or Multipoint A) are used in parallelin the network, NRI coordination is also required between the shared network and thesharing partners dedicated networks:

• To guarantee that a non-supporting MS in the visited PLMN remains registered inthe same operator's network when the MS moves from a dedicated network to ashared network;

• To avoid redirection when the non-supporting MS in the home PLMN performs anLA/RA update from the dedicated network to a shared network.

Each operator sharing the 3G access may also have their own pool areas, for example,for 2G access (or vice versa). In such cases, attention must be paid to interworkingbetween the operator-specific pool areas and the shared radio network area whenplanning the operator-specific pool areas. The NRI range, NRI value planning, radionetwork configuration and connectivity aspects are important considerations.

MOCN interworking is also provided with the optional load balancing enhancements andcore network signaling enhancements described earlier in this document.

RNCs/BSCs that support MOCN typically also support the Multipoint Iu or Multipoint Afeature with NNSF in the RAN nodes. Thus, such RAN nodes can perform subscriberdistribution in a configuration where the MGW is a signaling transfer point (STP). It is,however, possible to use the RAN Independent Multipoint A/Iu Support in MGW featuretogether with MOCN, for example, in a situation where network sharing operators imple-

ment multipoint configurations in their own networks, but the RNC/BSC elements areshared between operators. In such case, the shared RNC/BSC first makes the operatorselection and within the chosen operator network, multipoint connectivity may be real-ized, for example, with the RAN independent multipoint solution.

w When RAN Independent Multipoint A/Iu Support in MGW feature together with MOCNis used, the Global CN-ID in all the MSSs of the pool area must be configured to be thesame.

For further information about MOCN, see the Feature Description Feature 1847: Multi-operator Core Network support in MSC Server System in M-release feature ocumenta-tion.

g MOCN has been standardized for 2G in 3GPP Rel-10. This is not currently supportedby MSC Server System. However, 2G radio network may also be shared by utilizing, forexample, NSN BSC MOBSS solution. Furthermore, 3G radio network may also beshared by utilizing, for example, NSN RAN MORAN solution. MOBSS and MORAN aretotally transparent from CN viewpoint and do not require multipoint features to be acti-vated in the MSS.

3.9 Multipoint Iu and Flexi Direct (former Internet High SpeedPacket Access (I-HSPA))In Flexi Direct architecture, the Flexi Direct BTSs (former I-BTS) can be connected tothe CS core through the 3GPP standards-based Iu-CS interface. The CS core can then





45



Id:0900d805809d6ecc

be used for voice calls using Flexi Direct radio access. Flexi Direct introduces a flatnetwork architecture without separate RNC elements because RNC functions havebeen moved to Flexi Direct BTSs.

g Flexi Direct BTSs are treated in this document as being similar to RANs as regards mul-tipoint functionality and subscriber distribution logic.

Figure 18 Flexi Direct with Multipoint

Nokia Siemens Networks Flexi Direct solution provides support for Multipoint Iu func-tionality. However, MSS capacity (for example, radio network configuration limitationsand Flexi Direct BTS connectivity limitations) must be carefully considered before a mul-tipoint solution is implemented. For further information about capacity, see SectionPooling and Multipoint capacity .

It is, however, possible to have non-pooled Flexi Direct access even though 2G/3Gaccess is pooled.

Due to significantly higher signaling and connectivity capacity requirements in FlexiDirect, using the RAN Independent Multipoint A/Iu Support in MGW feature is not rec-ommended.

For further information about Flexi Direct support in the MSC Server System, see

Feature 1952: I-HSPA Support in MSC Server in M-release Feature Documentation.For more information about Flexi Direct, see the WCDMA RAN, Operating Documenta-tion .

3.10 ChargingMultipoint features have no effect on charging. CDRs for local calls can be generated byany pool MSC/MSS utilizing existing charging functionalities.

3.11 Statistics and performance monitoring

The operator can monitor the multipoint feature functionality in the Nokia SiemensNetworks MSS using NetAct. A number of parameters can be considered:





47



Id:0900d805809d6ecc

MGW statistics in RAN Independent Multipoint A/Iu Support in MGW feature

Feature 1778: RAN Independent Multipoint A/Iu Support in MGW introduces the follow-ing measurements in the MGW:

• SCCP Connection Establishment measurement, MID = 774 (306H). Measurementcontains counters.

• M774C0 ASSIGNMENT_CONN_ATT The number of all signaling connectionattempts received via SCCP interface for assignment.

• M774C1 ASSIGNMENT_CONN_ATT_FAIL The number of all unsuccessful signal-ing connection attempts received via SCCP interface for assignment.

• M774C2 HANDOVER_CONN_ATT The number of all signaling connectionattempts received via SCCP interface for handover.

• M774C3 HANDOVER_CONN_ATT_FAIL The number of all unsuccessful signalingconnection attempts received via SCCP interface for handover.

• NRI Routing measurement, MID = 773 (305H). Measurement contains counters. • M773C0 ALL_NNSF_ROUTINGS The number of all NAS Node Selection Function

(NNSF) routing events.• M773C1 NNSF_WITHOUT_NRI The number of NNSF routing events when the

NRI/TMSI can not be used for routing.

A maximum of 10 RAN nodes (BSC or RNC), can be included in one measurement bya user using MML commands. All RAN nodes, BSC or RNC, defined in one measure-ment by a user using MML commands with value “ALL”.

3.12 NetAct support for Multipoint features

3.12.1 OSS support for Multipoint and MSS poolingOSS enhances support for MSS pooling and resilience by introducing a comprehensiveoffering that significantly improves network operations efficiency. It includes the follow-ing functionalities:

• Multipoint Configuration Assistant • MSC Server Pool monitor • Core Network Productivity Suite (CNPS) applications

– VLR Load Balancer – Dynamic TDM Circuit Balancer (CNPS) – LAC-based Subscriber Balancing – E1 Line Mass Transfer (EMT)

The following sections give detailed information about these functionalities.

3.12.1.1 Nokia Siemens Networks Multipoint Configuration AssistantCreating and maintaining multipoint configurations in a network poses significant oper-ational and planning challenges due to the large volume of data and the large numberof data items that must be correlated. Building and managing a configuration is particu-larly challenging when a full pool area radio network must be configured to all the pooledMSSs. Modifying a configuration by, for example, adding an MSS to a pool, is a compli-cated configuration task often compromised by human error.





Issue 9-0 draft


Id:0900d805809d6ecc


Figure 19 Multipoint Configuration Assistant

Multipoint Configuration Assistant supports Multipoint configuration at network/pool(rather than on Network Element) level with a “wizard-like” functionality enabling a sim-plified, increasingly automated and user-friendly interface to facilitate configuration.Pool-related data is displayed in a concise form providing an overview of the configura-tion of the available pools. The new application will be available through the tools menuin CM. A number of use cases will be supported in phase 1, with enhanced functional-ities offered in later phases:

• Adding a pool. • Adding an MSS to a pool. • Adding radio area to a pool. • Deleting an MSS from a pool. • Deleting a radio area from a pool. • Activating off-loading mode for a single MSS.

The solution facilitates the consistent configuration of a pool and enables pool data andpool-related parameters to be modified in a user-friendly, efficient and consistent way.Benefits for the operator are evident:

• Improved operational efficiency when handling Multipoint Configuration tasks. • Reduced incidence of human errors by automating configuration tasks. • Improved operational performance of Multipoint configurations because pool-related

data inconsistencies are more easily identifiable and resolvable.

For further information see NetAct Configurator Functionality Description in OSS-release NetAct product documentation.





49



Id:0900d805809d6ecc

3.12.1.2 MSC Server Pool Monitor This functionality enables monitoring of VLR utilization within MSS pools. It is capableof providing visibility on:

• MSS level, • pool level, and • neighboring MSS level

It illustrates deviation from average load in a pool by the means of a graphic interface,and it is also possible to set MSS pool alarms based on threshold levels.

The use of this functionality improves network operations efficiency as it provides bettervisibility to MSS pool utilization and helps to dimension the pool load distribution.

3.12.1.3 Core Network Productivity Suite (CNPS)

Core network Productivity Suite enhances MSS pooling by implementing self-optimiza-tion functionalities to balance load between MSSs in the pool and reacting quickly tochanges in the resource utilization in A and Ater interface.

CNPS assists RAN independent MSS pooling with the following functionalities:

• VLR load balancing for MSSPooling • Dynamic TDM A interface Circuit Balancer • Location Area Code (LAC) based Subscriber Balancing • E1 Line Mass Transfer (EMT)

These functionalities are described in detail in the below sections.For more information, see Core Network Productivity Suite Product Description in OSS-release product documentation.

VLR load balancing for MSS Pooling

The RAN Independent Multipoint lu/A features, enable subscriber and traffic load to bedistributed between a number of pool MSSs. However, over-time, or because ofabnormal occurrences, for example the failure of a pool MSS, load may become unbal-anced. Building and maintaining load balancing between pooled MSSs requires signifi-cant planning, implementation, monitoring and prompt configuration changes to achieveoptimal load balancing.

Visitor Location Register (VLR) load balancing for MSS pooling can automaticallyensure that subscriber load is evenly distributed across the pooled MSSs. The Operatorbenefits are evident:

• Reduced OPEX because Operation and Maintenance (O&M) is simplified • Reduced risk of unintentional pool MSS overload • Ensures balanced load for MSSs handling both pooled and non-pooled BSCs/RNCs • It is simple to return to the situation before Load Balancing was necessitated, for

example because of the failure of a pool MSS.





Issue 9-0 draft


Id:0900d805809d6ecc


Figure 20 CNPS and VLR load balancing for MSS pooling

The Core Networks Productivity Suite (CNPS) implements automatic VLR Load Balanc-ing. The fill level of each pooled MSSs` VLR are interrogated and monitored at configu-

rable intervals. The MGW is responsible for determining to which VLR (MSS) theLocation Updating Request is forwarded to using a weighted round robin method. CNPSgenerates load factors for subscriber distribution to the MSSs by the MGWs. The gen-eration and implementation of the load factors can be entirely automated, or, imple-mented only after the operators approval following an acceptance procedure. The Non

Access Stratum (NAS) Node Selection Function (NNSF) in the MGW takes in to accountVLR utilization once the changed load factors have been implemented. The changedload factors do not affect on-going calls. CNPS verifies that the changes made were suc-cessful and maintains a log of changes. Additionally, CNPS also provides reports detail-ing the VLR load and the MGW load factors to facilitate network monitoring.

For further information see Core Networks Productivity Suite Product Description inOSS-release product documentation.

Dynamic TDM A interface Circuit Balancer for MSS Pooling

Each BSC has a separate TDM Circuit Group (CGR) controlled by each pooled MSS.The CGRs are connected to the same physical MGW, but different virtual MGWs(vMGW) that are controlled by the corresponding pool MSS. Utilization of the configureddedicated resources can become uneven overtime. Some CGRs are overloaded, whileothers have spare capacity. Inefficient resource allocation and the resulting congestionare particularly severe if a pooled MSS becomes unavailable. NetAct CNPS can dynam-ically re-allocate A or Ater interface circuit resources between MSSs based up on circuitload. Circuit load may differ simply because of distortions in subscriber allocation fromBSCs to MSSs that occur over time, or because a particular pooled MSS becomes

unavailable. Reallocation can either be automatic, or subject to the operators approval.





51



Id:0900d805809d6ecc

Figure 21 CNAP and TDM A interface load balancer for MSS pooling

The figure illustrates a situation, where, over time, the distribution of subscribers from aBSC to the pooled MSSs becomes uneven. However, the mechanism employed byCNPS is the same if a pooled MSS become unavailable. CNPS is able to reallocate the

A interface resources reserved for the unavailable MSS to the other pool MSSs.

1. Utilization of VLR capacity is balanced. However, the allocation of subscribers fromBSC4 (RAN Area 4) to the MSSs is uneven.

2. Consequently, the A interface resources reserved for MSS1 are under-utilized(there is spare capacity; illustrated in the figure by a solid orange line) while, con-versely, the A interface resources reserved for MSS2 are over-burdened, resultingin congestion (illustrated in the figure by a dotted red line).

3. CNPS reallocates A interface circuits reserved for MSS1 to MSS2. MSS2 now hasmore dedicated A interface circuits (more capacity) and so traffic is not congested.

The benefits of the CNPS solution for the operator are evident:

• Provides a combination of end-to-end resiliency with efficient use of TDM resources.

Less redundant TDM A and Ater interface capacity is required to deliver a higherlevel of resiliency.

MSS Pool

MGW

MSS Pool Area

RAN Area1

RAN Area2

RAN Area3

RAN Area4

NNSF NNSF

60%

60%60%

60%

60%

60%

60% 60%60%60%

20%MSS 1

MSS 3

MSS 2

60%60%60%

MSS 1 MSS 3MSS 2

Over-loaded andcongested circuitsUnder-utilized circuitswith free capacity

100%





Issue 9-0 draft


Id:0900d805809d6ecc


• Operators can offer subscribers an improved user experience. • Offers the opportunity to dynamically re-employ TDM A and Ater interface capacity

that is reserved for the use of a pooled MSS that is unavailable.

For further information see Core Networks Productivity Suite Product Description inOSS-release product documentation.

Location Area Code based Subscriber Balancing (LAC SB)

Location Area Code based Subscriber Balancing (LAC SB) off-loads subscribers of aselected LACs from an MSS to other MSSs within the same pool. This way, subscriberdistribution between MSSs in a pool can be actively balanced in order to achieve aneven load from LACs (RANs). Traffic load on the A/Ater interface circuit groups becomesbalanced, and network resources are used efficiently.LAC SB also balances VLR utilization.

Figure 22 Location Area Code based Subscriber Balancing

The functionality also makes it possible to automatize the necessary processes, whichis a substantial benefit due to the high number of (sub-)tasks involved in case of largeMSS pools. Manually, off-loading is heavily time-consuming or can even be impossible.However, LAC SB makes it convenient to continuously balance subscribers in an MSSpool.

This functionality is feasible for both RAN dependent and RAN independent multipointMSS pools.

The following figure illustrates an example of subscriber balancing in a LAC with 6 MSSs

involved.





53



Id:0900d805809d6ecc

Figure 23 Example of LAC SB

E1 Line Mass Transfer (EMT)

MSS pools share TDM resources, that is, E1 lines at A/Ater interface. E1 lines are ded-icated to MSS Circuit Groups (CGRs) and configured also in MGW CGRs. There can bethousands of E1 lines dedicated to each MSS in the pool. One of the reasons why MSSpooling was introduced is improved resilience. If one MSS is not available, the otherMSSs in the pool can still serve subscribers in pool area. Unavailability can be caused,for example by natural disasters (like flood or earthquake), which may lead to a longbreak until the MSS can be put back in service. While the MSS is not available, its A/AterTDM resources are still configured to it and they are not available for other MSSs in thepool. This situation will most likely lead to overload at A/Ater interface, and may result in

revenue loss and lower CS voice service.In the worst case scenario, trafficincrease/overload in the other MSS may lead to the crash of another MSS or otherMSSs, and even more severe problems in the CS core service.

E1 Line Mass Transfer (EMT) application provides a solution to transfer E1 lines con-trolled by a lost MSS to remaining MSS in the pool in controlled and automated way. Theapplication consists of two major functionalities:

• user initiated E1 Line Mass Transfer to other MSSs in the pool• user initiated recover procedure to transfer E1 lines back to original MSS

The E1 Line Mass Transfer application has several benefits:

• It ensures that no voice traffic is directed to the lost MSS during the abnormal situa-

tion.





Issue 9-0 draft


Id:0900d805809d6ecc


• It allows fast move of E1 line resources of a lost MSS to retain adequate voiceresources in the MSS pool.

• It helps to save a lot of manual work and allows operator to work in other crucial

areas during an abnormal situation. Manual effort to move potentially thousands ofE1 lines would take very long time and lead shortage of voice resources and causelost revenue and lower service quality.

• It is also possible to use E1 Line Mass Transfer application in MSS maintenanceoperations and it helps to move the maintenance break to day time and so to saveOPEX. After emptying (offloading) subscribers from a MSS, E1 Line Mass Transferapplication can be used for moving E1 line resources to other MSSs. By doing thisit allows more flexible scheduling of SW/HW maintenance, because it is not neces-sary to be scheduled to night time when the traffic load is much lower.

The overall process how the EMT application works is shown in figure Overall processof E1 Line Mass Transfer application .

Figure 24 Overall process of E1 Line Mass Transfer application

3.12.2 NetAct Configurator NetAct Configurator is a component in the scalable NetAct framework for operatingmobile networks. NetAct Configurator gives access to real-time network configurationdata and provides tools to manage network configuration.

The major benefits of the NetAct Configurator are:

1. Centralized management of both the BSS/RAN and NSS radio network configura-tion.

2. Minimizes the manual data input involved in large-scale network operations.3. Provides an interface for external tools to transfer actual and plan data.4. Ensures consistency and synchronization of pool configurations across managed

elements.

The following figure illustrates NetAct Configurator role in network development andoptimization.





55



Id:0900d805809d6ecc

Figure 25 NetAct Configurator

The basic concepts of NetAct Configurator are:

• Network resources are represented as managed objects. NetAct Configuratorsupports managed object classes in LTE, WCDMA, Flexi Direct, GSM and the corenetwork.

• Changes to the actual configuration are implemented using plans. A plan containsa configuration change that will be performed or has been performed in the network.

• The consistency of network parameters is vital for the optimal functioning of the

network. NetAct Configurator provides rules and tools to check the consistency ofthe actual configuration or a single plan.

NetAct Configurator is a fully integrated solution which provides common configurationmanagement functionality for multi-radio and core networks. Single data storage,common applications and processes enable efficient and reliable management ofcomplex networks comprising of different technologies. Efficiency is gained by usingmass operations in all network development, expansion and optimization phases.

1. CM Editor is used for displaying configuration data and for comfortable editing ofdata when creating a network plan. The tool supports: • All the radio network parameters and objects in LTE, WCDMA, Flexi Direct and

GSM.

• All the AXC/SC/FTM objects and parameters. • MSS System core objects and parameters which are relevant for typical daily

operational use cases (for example, the configuration of routing, signaling anddigital analysis).

2. CM Analyzer runs use-case-specific consistency checks. CM Analyzer the consis-tency of the different configurations handled by the system to be checked. CM

Analyzer provides consistency/audit reports on the Actual Configuration, the Refer-ence Configuration and any Planned Configuration.CM Analyzer generates reports for the objects and parameters that violate the rules.

A correction plan can be generated automatically to address the inconsistencies.





Issue 9-0 draft


Id:0900d805809d6ecc


3. CM Operations Manager is used for uploading network element data and provision-ing network plans. It can also be used for importing externally created network plansinto NetAct Configurator for further processing.CM Operations Manager is the application that provides the means to start andschedule all the different operations supported by the system (for instance, export,import, upload, download), to provide real time feedback on the progress of theoperations and to provide a history of executed operations.

Figure 26 NetAct controlling network operations

Once a new configuration has been defined, NetAct Configurator provides all necessarychanges in the relevant network-element-specific data formats. The automation of alldownload tasks ensures network consistency and minimizes operational efforts. Theresult is complete transparency of all planning, without delay, and with minimized marginfor error. All provisioning steps are controlled by the CM Operations Manager.

Nokia Siemens Networks NetAct Configurator provides supporting tools to manageradio network configuration and gives access to real-time radio network configurationdata, for example:

• Radio network plan management including plan modification, consistency checking,storing the radio network plans, viewing and comparing radio network parameters,and provisioning/activating them into the network;

• Integrating sites, extending the network, and modifying the network configuration; • Setting, modifying, viewing, and comparing radio network parameters.

The MSC/MSS radio network object model in the NetAct Configurator is illustrated in thefigure MSC/MSS radio network object model in the NetAct Configurator.





57



Id:0900d805809d6ecc

Figure 27 MSC/MSS radio network object model in the NetAct Configurator.

NetAct Configurator use cases include:

• BTS Auto Configuration and Site integration. • Adding/removing adjacency relations, modify HO margins.

• Modifying LACs, RACs and SACs. • Optimizing radio parameter settings and troubleshooting. • Rehosting of sites under new target BSC/RNC. • Increasing the capacity of the transport network. • Configuring IP addresses and routes. • Creating signaling configurations, including point codes and user plane destinations. • Configuring QoS parameters. • Configuring load balancing parameters. • Running consistency checks.

For multipoint features, in addition to the general use cases, the NetAct Configuratorsupports MSC/MSS pool area configuration handling for the pool area and neighboringpool areas.

PLMN

BSCM

MSC

RN W

ALA

LA

BTSM

MGWM

MS A

AS A

NWLA

RNCM

AR NC

BSSAP

IBTSM

LMMEM

SGSM

SVSMM

LMMEP

PGIBTSPGRP

SVSMP

LTEM





Issue 9-0 draft


Id:0900d805809d6ecc


g Nokia Siemens Networks Multipoint Configuration Assistant is a dedicated feature whichprovides enhanced support for pooling and multipoint.

For further information see the Section Nokia Siemens Networks Multipoint Configura -

tion Assistant .

Pooling and multipoint-specific operations include:

• Uploading the supported managed objects and parameters to the NetAct database.Multipoint A and Iu related configuration parameters include, for example: • Pool Area List, Pool Name, NRI length, NRI values; • Neighbor Pool Area List, Neighbor Pool Name, Neighbor NRI Length; • MSS Configuration (primary/secondary), MSS Global Title address, MSS Name,

MSS Signaling Point Code, Base Station System Application Part (BSSAP)service profile (versions), MSS Network Indicator;

• VLR Network Indicator, VLR Signaling Point Code, VLR Global Title address.

• Downloading (provisioning) object creations and object modifications to theMSC/MSS. The NetAct Configurator-supported objects are BSC in MSC/MSS(BSCM), BTS in MSC/MSS (BTSM), Location Area (LA), SGSN in MSC/MSS(SGSNM), and MSS/MSC Service Area (MSA).

• 3GPP Northbound Interface (N-if) support for the supported MSC/MSS managedobjects including Bulk CM & Basic CM. The Nokia Siemens Networks vendorspecific parameters related to multipoint are handled using N-if.

• Consistency checking of the Nokia Siemens Networks MSC/MSS configuration datastored in the NetAct Configurator.The pre-defined consistency checks related to Multipoint A are:1. BscmInPoolArea: This rule reports:

• If the pool MSCs/MSSs that do not have the same BSCMs with the sameparameters as the BSCM in the pool area's primary MSC/MSS;

• If the BSCMs have incorrect parameters; • If there is more than one primary MSC in a pool area.

2. BtsmInPoolArea: This rule reports BTSMs that have inconsistencies with otherpool BTSMs. If the pool BTSMs point to an LA that is included in pool, the otherpool MSCs should have the same BTSMs and the same parameters.

3. LaInPoolArea: This rule reports the LAs with inconsistencies compared to theLAs that are included in the pool area or missing LAs.

4. NwlaInPoolArea: This rule reports the NWLAs with inconsistencies compared tothe NWLAs that are included in the pool area or missing NWLAs.

For Multipoint Iu the LaInPoolArea and NwlaInPoolArea are supported. • Open XML, CSV interface can be used for import/exporting the above mentioned

multipoint-related configuration data (for Planning tools, Reporting, and so on). • Basic functionality and tools are provided by the CM Editor and CM Analyzer to view,

modify, search, mass modify and analyze the above mentioned multipoint-relatedconfiguration data.

It is also possible to monitor the relevant measurements and alarms using NetAct. Forinformation on measurements and alarms, see Statistics and performance monitoring .

More detailed information on the Configurator, and multipoint parameters and consis-tency checks, is available in NetAct Configurator Functionality Description, NetAct product documentation (OSS release).





59



Id:0900d805809d6ecc

3.13 Forced test subscriber location update to a specific MSSinside the MSS pool areaThis enhancement eases the operator’s testing a new functionality installed on onespecific MSS within the MSS pool area. With this enhancement operators can ensurethat the test mobile station (MS) performs a location update to the selected MSS thathas the functionality to be tested installed.

This functionality can be activated with a new ON/OFF license.

The Forced test subscriber location update to specific MSS inside MSS pool funcionalitycan be used in the following way:

Select one of the test MSS’s (TEST_MSS’s) NRIs to be the test NRI (NRI-T), andconfigure it to all the other MSSs of the pool area which do not have installed thefunctionality that needs to be tested.

2 Set a flag for the PLMN created for storing the test subscribers’ settings to indicatethat this IMSI range contains the test subscribers.

3 Perform a location update (LU) with the test mobile station (TEST_MS).

If the LU goes to the TEST_MSS, it accepts it and handles the situation as needed.No further steps are to be taken in this case.

However, if the LU goes to another MSS, the following procedure starts, as alsoshown in figure Forced test subscriber location update to a specific MSS inside theMSS pool area :

The LU goes to an MSS that checks whether the subscriber is a test subscriber.

2 For test subscribers, the MSS allocates a new TMSI with NRI-T, and returns the

LU acknowledgement with the new TMSI (containing NRI-T) and the NonBroad-cast-Location-AreaIdentifier (NB-LAI).

3 TEST_MS will initiate a new LU with the TMSI containing NRI-T.

4 The LU is directed to TEST_MSS that accepts and handles the situation asneeded.





Issue 9-0 draft


Id:0900d805809d6ecc


Figure 28 Forced test subscriber location update to a specific MSS inside theMSS pool area

For detailed instructions on how to test the Forced test subscriber location update to aspecific MSS inside the MSS pool area enhancement, see the Feature ActivationManual Feature 1449: Multipoint Iu in MSS Concept , available in the M-release FeatureDocumentation library.

MSS pool area

MSS2

MSS1

MSS3

MSS6

MSS4

MSS7

MSS8

TEST_MSSMSS5

TEST_MS

NRI-T

NRI-TNRI-T

NRI-TNRI-T

NRI-TNRI-T

NRI-T

2. LU ack (NRI-T)

1. LU

3. LU (NRI-T)

4. LU ack





61


Pooling and Multipoint architecture guidelines

Id:0900d805809d6ece

4 Pooling and Multipoint architecture guide-linesThe main examples of the alternative architectures that can be built in multipointnetworks are described below. Guidelines for selecting an appropriate architecture, aswell as for successful pool planning, are also included.

4.1 Network architecture overviewThere are several high level architecture options for implementing pool areas withinoperators networks. The most suitable architecture for a specific operators networkdepends upon the operators requirements. Different requirements, for example, a desireto improve network redundancy, or network optimization through the organization ofmobile movement patterns, can best be achieved with different architectures.

The main alternatives and their respective advantages and disadvantages are detailedhere to provide some guidance for the selection of an appropriate architecture.

Operators must also decide whether to increase network resilience during a corenetwork element outage. The operator has a number of options:

• Offering the service with lower capacity during a fault (congestion may be experi-enced);

• Investing in additional network resources to guarantee the service with the samequality as in normal working conditions;

• Multipoint Iu and Multipoint A both provide signaling savings. The operator mustensure that the savings are not wasted in increased transmission cost. In the Multi-

point A in MSC architecture with full resiliency, for example, each BSC in a pool mustbe connected to each pool MSC. The operator can easily lose the calculated savingsfrom adopting multipoint in increased signaling costs. In the Multipoint A in MSCServer architecture, however, it is sufficient to connect a BSC to one, or two MGWsto provide improved resiliency.

Careful network planning by the operator is required so that the pool areas are definedto maximize their benefit in terms of the grade of service at the minimum cost to the oper-ator.

The following pool area high level configuration considerations are applicable in generalfor both RAN node based multipoint solutions as well as for the RAN Independent Mul-tipoint A/Iu Support in MGW feature.

One large pool covering full country/network

In this alternative, a full country/network is covered by one pool area, as illustrated in thefigure One pool covering a whole country/network .





Issue 9-0 draft


Id:0900d805809d6ece


Figure 29 One pool covering a whole country/network

In this pool area architecture alternative, the radio network pool area configurations arethe same in all the pool area MSCs/MSSs. Radio network planning and actual configu-

ration tasks are, thus, much easier.In such a network, there can also be CN nodes and RAN that do not belong to the poolarea, but must be considered in the management of the radio network configuration. Forexample, one MSC/MSS in the pool area may also have its own radio network, whichdoes not belong to the pool area.

In a country/network wide pool area, a relatively small amount of extra capacity isneeded at the core network to cover the unavailability of a pool MSCs/MSSs due tomaintenance or failure. Load calculation and dimensioning within the pool area are alsosimplified because it is not, for example, necessary to consider traffic between poolareas within the network/country.

The routing configuration definitions in this alternative can be identical for all the alter-native routes. However, the number of routes required increases with the number of poolMSCs/MSSs, as well as the number of PCMs in the Multipoint A interface configurationwhen TDM is used over the A interface. In a configuration that covers a geographicallylarge network this may create network planning challenges.

Load distribution between the different routes must also be carefully planned. In a mul-tipoint configuration, a number of smaller user plane links may need to be createdbetween the RAN nodes and the MSCs/MSSs instead of single large link traditional in anon-pooled network. In Multipoint A, it is not possible to split E1 links to a number ofMGWs, and thus the utilization rate of the link may be sub-optimal when TDM is used atthe A interface.

Local routing and numbering plan changes must be visible to all pool MSCs/MSSs. EachMSC/MSS acts as a local point-of-interconnect (POI) to the local networks. Each localPOI is seen in all MSCs/MSSs, but the configuration may differ in each of theMSC/MSSs. This requires local network planning and increases pool area planningcomplexity to prevent unnecessary inter-MSC/MSS calls.

The routing configuration is described in more detail in Section Multipoint configurationand connectivity guidelines . Section Connectivity example in Multipoint configuration provides an example of POI and analysis tree configuration.

In large networks with multipoint interfaces, the A or Iu interfaces may be implementedwith satellite links. A satellite link is used as a transmission method at the A or Iu inter-face. A detailed description of transmission methods is not, however, in the scope ofMSS Pooling and Multipoint documentation.





63



Id:0900d805809d6ece

Several pools covering full country/network

In networks covering large countries, it may be beneficial to have several pool areas, forexample, covering different geographical areas. This alternative is illustrated in the

figure Several pools covering a whole country or network .

Figure 30 Several pools covering a whole country or network

Capacity and routing in a network with more than one pool area requires more planningbecause of the interactions between pool areas, but the route utilization rate is betterand the configurations within each MSC/MSS are simplified than if the whole countrywas covered with one pool area. The number of routes and PCMs required is also likelyto be less.

If the MSCs/MSSs in the network are geographically distant from each other, the trans-mission costs incurred in a single big pool may become high. In such cases it is prefer-able to implement 'local' pool areas instead of one big pool. There may also be othergeographical considerations such as local connectivity for calls between one or morepools in the multipoint configuration.

Overlapping pool areas

To gain the maximum advantages from multipoint features, the operator may aggregateareas through which subscribers regularly move. This can also be achieved in the otheralternative architectures presented, but overlapping pool areas offer the greatest bene-fits.

Overlapping pool areas can be areas that:

• Cover large cities. •

Follow major transport routes. • Lead to the city center.

Many suburban subscribers drive daily to the city and back home in the evening, theconfiguration of overlapping pool areas allows the separation of the traffic into differentmobile moving patterns. Each pool covers a separate residential area and all the poolstogether cover the city center. Handovers and location update signaling can be reduced.

An overlapping pool areas architecture option is illustrated in the figure Overlapping poolareas for city/residential traffic optimization .





Issue 9-0 draft


Id:0900d805809d6ece


Figure 31 Overlapping pool areas for city/residential traffic optimization

The aggregation of areas covering major urban commuter traffic routes into over-lappingpool produces significant advantages for both the operator in terms of resiliency andload balancing while providing an improved grade of service for subscribers.

An example of an MS moving pattern within overlapping pool areas is illustrated in thefigure Example of a moving pattern between city and suburban areas .

Figure 32 Example of a moving pattern between city and suburban areas

Suburban residential areas can be covered with individual pools, while the urban area

is covered by overlapping all three pool areas.





65



Id:0900d805809d6ece

The advantage of overlapping pool areas is increased capacity where pool areasoverlap without extra investment in core network capacity.

The MSCs/MSSs controlling the RANs providing coverage at overlapping pool areas are

required to manage the radio network configuration of the entire overlapping pool areainstead of a single pool area. This configuration is more complex compared to the con-figuration of a single pool area. Radio network planning must consider relevant restric-tions on radio network configuration. Radio network configuration is discussed further inthe Section Pooling and Multipoint capacity .

As described in the Section Radio network configuration for pooling and multipointfeatures in MSC/MSS , overlapping pool areas can also be implemented with the RANIndependent Multipoint A/Iu Support in MGW feature.

4.2 MSC/MSS pool planning aspects

When planning the MSC/MSS pool area, there are several factors that must be consid-ered in addition to pool architecture and the presence of the Gs interface as discussedin Section Gs interface: inter-working with MSS Pooling and the SGs interface as dis-cussed in Section SGs interface: inter-working with MSS Pooling . Relevant factors aredetailed in the sections below.

The same factors apply also for RAN Independent Multipoint A/lu support in MGW,unless explicitly stated.

Number of parallel MSCs/MSSs within a pool

There is a theoretical maximum of 10 MSCs/MSSs in one pool area, but the actualnumber of MSCs/MSSs in one pool depends on many factors: VLR capacities, callhandling capacities, radio network configuration limitations, suitable NRI length, and soon. Local routing needs and geographical characteristics also have an effect upon thedecision of how many MSCs/MSSs are included in a pool. In practice, therefore, thenumber of MSCs/MSS in a pool area is typically less than the theoretical maximum.

If a pool MSC/MSS fails, or an MSC/MSS is taken out of service for maintenance, itssubscribers are directed to other pool MSCs/MSSs. Reserving extra VLR capacity withinthe pool for handling the subscribers of a failed MSC/MSS is recommended. Thereshould be enough VLR capacity to tolerate the failure of at least one pool MSC/MSS.

As an example:

• One pool area is covered by 3 MSCs/MSSs.• Each node can support 1M subscribers.

• The pool area serves 2M subscribers. In practice, 66.7% of each VLR's capacity isused in normal conditions.

• The operator allows VLR utilization of up to 90%.

If one MSC/MSS fails, the remaining two fully support the pool area if extra transmissionand signaling capacity are also reserved. This, however, means 100% VLR utilization inthe remaining nodes. In such a situation, it may be beneficial to add another MSC/MSS(totaling 4 nodes) with similar coverage capacity. In normal operation there would be50% VLR utilization and during an MSC/MSS failure, 66.7% VLR utilization.

Call handling capacity must be considered independently of VLR capacity. The operatormay provide spare call handling capacity to avoid congestion at peak demand or during

an core network element failure.





Issue 9-0 draft


Id:0900d805809d6ece


With the pool area concept, the complexity of radio network configuration in a singleMSC/MSS increases. The radio network configuration capacity in the MSC/MSS is suf-ficient for large pool areas. The restrictions on radio network configuration are detailedin Section MSC/MSS capacity .

The effects of NRI length are explained in Section NRI planning and management .

Dual GSM/UMTS access

In the Multipoint Iu/A concept, a key issue is whether the system includes dualGSM/UMTS access. Even though a location area can include both GSM cells andUMTS service areas, it is recommended that location areas be defined and used sepa-rately for UMTS and GSM radio access. Thus, a single LA would either consist of UMTSservice areas, or GSM cells. Distinct LAs for GSM and UMTS enable, for example, 2Gand 3G roaming subscribers to be controlled differently and avoiding unnecessary2G/3G paging load because paging is based on the LA (and implicitly the type of radioaccess).

It is possible that only Multipoint A or Multipoint Iu is deployed in the network. In suchcases there must be different LAs for GSM and UMTS.

In the figure Example of LAs for dual GSM/UMTS access with Multipoint Iu , the config-uration before the Multipoint Iu feature is introduced is illustrated. The original configu-ration contains LAC1 for BSC1 and RNC1, and LAC2 for BSC2 and RNC2. WhenMultipoint Iu (but not Multipoint A) is introduced into the network, it is recommended thatdedicated LAs be added for the RNCs as illustrated. If this is not done and only the Mul-tipoint Iu interface is used in the network, LAC1 and LAC2 would, from the perspectiveof Multipoint lu, be seen as separate location areas under MSS1 and MSS2. However,for the A interface/GSM the LAC2 should be defined as a neighboring LA in MSS1,which creates a contradiction because one LA can only be either the MSCs/MSSs ownLA, or a neighboring LA, and in this example LAC2 must be MSS1’s own LA due to Mul-tipoint Iu.





67



Id:0900d805809d6ece

Figure 33 Example of LAs for dual GSM/UMTS access with Multipoint Iu

Example of roaming between GSM and UMTS accesses, when pooling for only UMTSaccess is implemented in the network

In a network where, for example, pooling for Iu only is used and when the Multipoint Iufeature is activated in the dual access MSS, the MSS will allocate the TMSI with an NRIto all the subscribers regardless of the LAC (or access type) from where the locationupdate request was received. A valid NRI is included with the TMSI when the usermakes a location update request to the MSS through GSM access. When the subscribermoves to a UMTS access area within the area covered by the pool, the RNC will select,based on the allocated NRI, the same MSS which served the subscriber during GSMaccess.

g A similar principle applies in reverse when only Multipoint A is used.

In networks where pooling is used in either GSM or UMTS areas only, the operator canselect how the subscriber is handled after a change of access between GSM and UMTS:

• The subscriber is directed to the same MSC/MSS that was used earlier.The same MSC/MSS is automatically selected by the RAN node subscriber distribu-tion functionality, based on the existing NRI value within the TMSI. In this alternative,inter-MSC/MSS location update is avoided.

• The subscriber is passed back to the RAN node/MGW for subscriber distribution.To achieve optimal MSC/MSS selection for load balancing within the pool area, theMSC/MSS, when receiving a Location Update Request, checks the LA configurationto see if the previous LA belongs to the pool area. If not, the MSC/MSS returns aTMSI with a Null-NRI and a non-broadcast LAI in the Location Updating Acceptmessage to the MS/UE. The non-broadcast LAI causes the MS to immediately send





Issue 9-0 draft


Id:0900d805809d6ece


a new Location Update. Based on the Null-NRI included, the RAN node distributesthe subscribers as if they were a new subscriber entering the pool area.

The optimal implementation depends on network planning priorities.

For further information about Null-NRIs and subscriber re-distribution, see Section Loadre-distributiong using a Null-NRI .

If the Gs interface is used with this optional functionality, the MSC/MSS selectionmethod in the SGSN should enable MSS off-loading and perform the desired load bal-ancing between the pool MSCs/MSSs. The MSC/MSS selection functionality in theSGSN is SGSN vendor dependent and therefore the actual capabilities of a particularSGSN must be taken into account during network planning.

Location areas not belonging to the pool area within an MSC/MSS

The configuration of pool areas may be combined with MSC/MSS service areas that donot belong to pool areas. There may also be cases where one, or more, MSC/MSS

nodes within a pool serve LAs outside the pool area. This can be because of intentionalconfiguration or, happen as part of a migration process as location areas are progres-sively included into the pool area. As a result, the radio network configuration differsbetween the MSCs/MSSs pooled and non-pooled areas.

The additional RAN nodes and LAs, compared to the other pool area MSCs/MSSs, arepart of the internal radio network configuration of the MSC/MSS. From the perspectiveof the other pool MSCs/MSS, they are considered as neighboring location areas. Inter-MSC/MSS handovers will be performed between the LAs belonging to the pool area andthe LAs of the additional RAN nodes which are not in the pool configuration. Load redis-tribution processes, or changes in the pool area configuration, do not affect subscribersin non-pooled location areas even though they maybe served by an MSC/MSS that is

part of the pool area configuration.RAN transmission

With the pool concept, RAN interface transmission is split between a number ofMSCs/MSSs.

In Multipoint A with MSC architecture, for example, the BSC must be connected to all ofthe pool MSCs for signaling and user plane connectivity. In contrast, in the MSC Serverarchitecture, the transmission must be split between a number of virtual MGWs (at leastone vMGW for each MSS, but preferably two vMGWs for resilience).

In MSC/MSS architecture, before multipoint is configured, for user plane connectivity theBSCs are connected to only one MSC/MSS with a large single CGR when TDM-based

A interface is used. After the pool area concept is configured, there will be a number ofsmaller CGRs, divided between the pool MSSs. This increases the complexity of CGRconfiguration and may increase the probability of congestion between the BSC and theMSC/MSS, when TDM is used at the A interface, if total transmission capacity is notincreased.

When determining capacity for a failure situation, a decision must be made about thetolerated service grade degradation. The amount of service grade degradation tolerateddetermines the required transmission capacity between the RAN nodes and the MGWs(in MSC Server architecture) and between the BSCs and the MSCs (in MSC architec-ture). The actual transmission capacity will be that required for normal operations pluscapacity needed to maintain service grade in failure situations.





69



Id:0900d805809d6ece

It is possible to increase the capacity between the BSC and the MSC/MSS one E1 linkat a time, or multiple E1 links at a time when TDM is used at the A interface. Thisdepends on the operators preference. The operator, for example, may want to share theload from one BSC to vMGWs unequally, or use the same number of E1s for each BSCto vMGW connection. Both alternatives are illustrated in the figure A-interface transmis -sion dimensioning .

Figure 34 A-interface transmission dimensioning

The issues are covered in more detail in Pooling and Multipoint configuration and con -nectivity guidelines .

When Iu-CS or A interface over IP is used, RAN transmission can be managed moreflexibly.

Re-use of RAN user plane transmission links

In a network where a RAN node is connected to one MSC/MGW and the pool conceptis introduced, the RAN node is then also connected to every MSCs/MGWs in the pool.Each new additional transmission interface (A or Iu) link will carry only a portion of thetotal traffic originally carried by the single RAN node-MSC/MGW link. The dimensioningof the additional links depends on the number of pool MSCs/MSSs and redundancyrequirements. When the subscribers are distributed among the parallel MSCs/MGWs,some of the capacity of the original link becomes available for reuse.

It is recommended that during the introduction of the RAN node into the pool, the originallink is unchanged, and only after the subscribers are distributed successfully is any ofthe now spare capacity of the original link re-used. Although this does not efficiently usetransmission resources, it helps guarantee a smooth implementation and offers asecure fallback. Similar caution is recommended when introducing a new MSC/MSS tothe pool.

In a simplified example, prior to multipoint configuration, a BSC is connected to an MSCwith a single transmission link carrying all the traffic. After multipoint configuration with5 pool MSCs, assuming that the traffic is shared equally, there are for 5 smaller linkscarrying 20% of the total traffic. After the feature is successful implemented and the sub-scribers have been redistributed, the original link is carrying only 20% of the total traffic.The extra capacity in the original link is now unnecessary and can safely be reused.





Issue 9-0 draft


Id:0900d805809d6ece


Optimization of MSS and MGW selection for A-interface transmission savings

When designing a Multipoint A configuration, the operator may consider options for opti-mizing the MSS and pMGW selection to save A-interface transmission costs within the

pool area when TDM is used at the A interface. These options are alternative ways ofbuilding the multipoint configuration compared to the more typical situation where MSSand MGW resources are evenly configured within the pool area.

The existing transmission network capacity can be incorporated. There may already bemore A-interface circuits configured towards the local pMGWs than to the pMGWs thatare geographically distant in the network, for instance, because of local PSTN connec-tivity.

If the smaller PSTN interfaces have not been designed for redundancy, and this is notrequired in the multipoint configuration either, the operator can prefer the local pMGWto the distant MGWs in circuit hunting and benefit from transmission cost savings.

One option is to direct subscribers in a certain geographical area to a preferred poolMSS. This can be achieved by configuring the BSC's subscriber distribution function tofavor a specific MSS/VLR when allocating subscribers from that geographical area.

At the pool area level, this means that different BSCs distribute the traffic in different pro-portions to different pool MSSs. However, the total capacity limits of the pool area mustbe complied with. For routing, it is possible in the MSS to select the local pMGW. Whenthe local MGW is used for most of the traffic in a certain area, A-interface transmissioncosts are lowered. MGW redundancy can still be achieved by connecting the BSC to anMGW located in another part of the network. However, during normal operations mosttraffic is directed by the MSS to the geographically local pMGW. Sufficient A-interfaceresources must be configured between the local pMGW and the BSC. Similarly, for eachpool MSS, there must be sufficient A-interface resources to meet the different trafficlevels distributed by the BSC.

Another option is to configure the routes and circuits at the A-interface so that there aremore circuits available through the local MGW than through the other MGW(s) which aremainly used for redundancy. When the amount of local circuit use increases, itdecreases the required transmission capacity that must be reserved for the longerdistance MGW connections. The number of BSC-MGW circuits must reflect the BSCsload balancing subscriber distribution amongst the pool MSSs.

From the BSCs perspective, when circuit load based subscriber distribution is in use,the BSC determines subscriber distribution based on free circuits for each MSS. Whenplanning the appropriate subscriber distribution for each BSC, in each MGW that theBSC is connected to, there must be sufficient circuits to handle the traffic the BSC dis-tributes. There must be more circuits allocated in the primary MGW and less in theMGW(s) used for redundancy.

When the local pMGW is preferred for routing, it may be necessary to allow some levelof congestion, for example, in situations when a pool area MSS fails or, is in mainte-nance. This is because the A-interface configuration is static and the traffic must behandled with the A-interface resources that have been configured for the use of theremaining MSSs.

NetAct Core Network Productivity Suite (CNPS) provides support for TDM A interfaceload balancing by making it possible to dynamically re-allocate A-interface resourcesbased on circuit load. TDM A interface Load Balancer for MSS Pooling is described inSection TDM A interface Load Balancer for MSS Pooling .





71



Id:0900d805809d6ece

With A-interface over IP (AoIP), the transmission planning becomes more simple simi-larly as in Multipoint Iu with ATM or IP transport.

Physical location of parallel MSCs and MGWs in multipoint configuration

Parallel MSCs (in MSC architecture) and MGWs (in MSC Server architecture) can beco-located at the same physical site together with RAN nodes (centralized), or in differ-ent sites (distributed). A centralized location can save operational costs but it increasesthe risks if there is a site failure caused by, for example, a natural disaster or a powerfailure. Distributed MSCs and MGWs are less vulnerable to a site failure, but operationalcosts may be higher.

The transmission costs of both centralized and distributed site locations in the multipointconfiguration need to be compared when planning the pool area concept. If, forexample, the multipoint configuration is planned to cover a wide geographical area, acentralized site may result in high network transmission costs.

PSTN/PLMN connectivityThe pool area concept has no significant impact on PSTN/PLMN connectivity. Typically,connections are made to more than one gateway to provide redundancy. This shouldoccur in the pool area concept as well. MSC/MSS pooling protects the radio interface,meaning that it is still possible to have service from RAN nodes if a pool MSC/MSS fails.MSC/MSS pooling does not, however, protect the connection to the Point of Intercon-nect (POI). If greater resilience is needed the PSTN/PLMN can be connected to moreMSCs/MSSs than previously.

With MSC/MSS pooling when subscribers A and B are located at the same area, theprobability that two MSCs/MSSs are involved in the call increases and local connectivitywithin the operator network can be partially lost. The same thing may happen when a

PSTN–MS call is made locally. This increases inter-MSC/MSS node calls.If there are many POIs, more CGRs, routes and routing trees may be needed. Onemethod of overcoming the user plane optimization limitation when several MGWs areinvolved in a call, is to define a dedicated MO tree to each pMGW.

See the Section Connectivity example in Multipoint configuration for an example of POIsin the MGW.

Traffic within VPNs and Corporate Networks

If there are large Virtual Private Networks (VPNs) and corporate networks in theMSC/MSS pool area, it is important to consider that VPN and corporate subscribers aredistributed randomly amongst all the pool MSC/MSS. Many internal calls within theVPNs and corporate networks are handled as inter-MSC/MSS pool member calls evenif the VPN or corporate (radio) is controlled by the same RAN node.

Consequently, inter-MSC/MSS resources must be dimensioned to handle the VPN andcorporate internal traffic (higher traffic intensity and longer hold-time). In a non-pooledMSC/MSS configuration a VPN or a corporate network is controlled by the same RANnode and MSC/MSS, and all the corporate internal traffic is handled as intra-MSC/MSStraffic.

MSS-MSS and MSS/VLR–HLR interfaces

During normal operation, there are no inter-MSC/MSS handovers within a pool area. Ifsubscribers move inside the MSC/MSS pool area, there are only intra-MSC/MSS han-

dovers. Consequently, within the pool area, use of the E-interface (MSC/MSS–MSC/MSS) between pool MSC/MSS is reduced.





Issue 9-0 draft


Id:0900d805809d6ece


The E-interface is still needed for the handover enhancement in Multipoint A asdescribed in the Section Handover within a pool . The E-interface is also needed whena radio network configuration not included in the pool concept exists within the network.Inter-MSC/MSS handovers are required between radio network areas outside the pooland those within the pool area.

In normal pool operation, signaling use in the D-interface (MSC/VLR-HLR) is decreasedbecause there are no location updating requests towards the HLR if the subscriberroams inside the MSC/MSS pool area. D-interface dimensioning must, however, take into consideration MSC/MSS failure. A large number of subscribers are moved from thefailed MSC/MSS to other parallel MSC/MSSs and a large number of transactions wouldbe directed to the HLR through the D-interface.

MGW–MGW interface

A MGW-MGW interface is required when RAN Independent Multipoint A/Iu Support inMGW feature is in use and MGW resiliency is built with two, or more, MGWs forming anMGW cluster. RAN nodes will only be configured with one destination SPC (DPC) forsignaling, and in this case the Destination Point Code (DPC) is the MGW cluster’s Sig-naling Point Code (SPC). Even though signaling links configured towards the redundantMGWs (using the MGW cluster SPC) are required, the RAN node is not required tomake link selection between the signaling links because from the RAN nodes perspec-tive they all terminate to the MGW clusters‘ SPC. Thus, signaling transfer betweenMGWs is utilized to coordinate the BSSAP/RANAP signaling connections betweenMSS–MGW and MGW–RAN interfaces, when the MSS–MGW signaling connection andMGW–RAN signaling connection are handled by different MGWs in the MGW cluster.

An example of the signaling configuration is given in Section MGW resiliency .

Message forwarding at Message Transfer Part (MTP) level, through the MGW-MGWinterface, is needed when the BSC/RNC is unable to prioritize MGW selection betweenthe redundant MGWs in the MGW cluster to be the same as that chosen by the MSS tohandle the BSSAP/RANAP application for the subscriber’s signaling connection.

The MGW-MGW interface also transfers BSSAP/RANAP signaling at MTP levelbetween the redundant MGWs in the MGW cluster. This enables ongoing transactions,like calls, to continue even if there is, for example, a signaling link failure change situa-tions between the BSC/RNC and the MGW that was initially selected for handling of theBSSAP/RANAP application for the subscriber’s signaling connection.

The MGW-MGW interface is also used to coordinate paging responses to the correctpool MSS when IMSI has been used in the Paging message as the subscriber identity.When the MGW receives a paging request with IMSI from an MSS, it temporarily storesthe IMSI–CN node ID relation. The IMSI-CN node ID relation is also forwarded to redun-dant MGWs within the MGW cluster. This ensures that the paging response (with IMSI)received from BSC/RNC can be sent to the correct MSS regardless of which MGW inthe cluster receives the paging response.

For more information about MGW resiliency with RAN Independent Multipoint A/IuSupport in MGW feature , see the Section MGW resiliency .

4.3 NRI planning and management As described in the Section Network Resource Identifier (NRI) , the NRI identifies an indi-vidual MSC/MSS from all the parallel pool MSC/MSSs and those that serve overlapping





73



Id:0900d805809d6ece

pool areas. The NRIs of the CS and the PS domain are different from each otherbecause the PS and the CS domain MSC/MSSs are addressed independently.

Each MSC/MSS in a pool area/overlapping pool areas must have at least one unique

NRI value, but it is recommended that an additional NRI (a Null-NRI ) is allocated for loadredistribution purposes.

More than one NRI can be assigned to a single MSC/MSS. This is useful, for example,in situations when more specific subscriber distribution is needed between pool areaMSCs/MSSs with different subscriber handling capacities, and particularly if the RANnodes do not support more flexible subscriber distribution methods like weighted roundrobin. If a lower capacity MSC/MSS1 is, for example, allocated with 1 NRI value and ahigher capacity MSC/MSS2 is allocated with 3 NRI values, the RAN node subscriber dis-tribution chooses MSC/MSS1 for 25% of subscribers incoming to the pool area andMSC/MSS2 for the remaining 75%.

The Nokia Siemens Networks' RAN subscriber distribution methods are outlined in Sub -

scriber distribution in the pool area in Nokia Siemens Networks RNC, BSCs, SGSN andFlexi Direct BTSs . More information about the subscriber distribution in network nodescan also be found in the respective product customer documentation libraries. WhenRAN Independent Multipoint A/Iu Support in MGW feature is in use, the MGW sub-scriber distribution functionality is described in the Section Subscriber distribution inMGW when the optional RAN Independent Multipoint A/Iu Support in MGW feature isused .

The optimal number of NRIs for each pool MSC/MSS also depends on the desired TMSIavailability space in the MSC/MSS. The possible NRI values can be from 0-1023. Theformula ((2^NRI length)-1) describes the relationship between the length of the NRI andthe number of NRIs available. The actual maximum NRI values depend on the NRI

length. For more information, see Planning NRI length .If there are several NRIs defined for the MSC/MSS, the MSC/MSS will select one ofthem during the TMSI allocation procedure based on a round-robin selection. If there areno more NRIs in the list, the first one is chosen again and other components of the TMSIare translated so that the TMSI value is different from the previous TMSI with the sameNRI.

The NRI value are set, both in the MSC/MSSs and in the RAN nodes (or in the MGWwhen the RAN Independent Multipoint Solution is used), using O&M commands.

Null-NRI

A Null-NRI needs to be reserved in each pool area MSC/MSS for subscriber redistribu-

tion purposes, to handle situations when one MSC/MSS is off-loaded due to scheduledmaintenance, or if traffic must be reduced. A Null-NRI is also utilized in certain loadredistribution enhancements. Each pool MSC/MSS has one Null-NRI defined usingO&M commands. According to 3GPP TS 23.236 Intra-domain Connection of Radio

Access Network (RAN) Nodes to Multiple Core Network (CN) Nodes , the Null-NRI mustbe unique in the PLMN.

The main purpose of the Null-NRI is to indicate to a RAN node (BSC/RNC/MGW) thatthe subscriber distribution function must be used for (re-)selecting a pool areaMSC/MSS. In addition to a Null-NRI, an O&M command in the BSC/RNC/MGW isrequired to prevent the selection of the MSC/MSS which is being off-loaded. More thanone MSC/MSS can be off-loaded at the same time.





Issue 9-0 draft


Id:0900d805809d6ece


In the Nokia Siemens Networks MSS, a Null-NRI can be defined as an MSS-specificvalue. This is advantageous when, for example, RAN Independent Multipoint A/lusupport in MGW solution is used. When MSS off-loading using a Null-NRI is initiated,the MGW‘s NNSF can identify which MSS is being off-loaded using the MSS-specificNull-NRI. If a pool MSS is being off-loaded, an MGW can select a different MSS withoutan O&M command in the MGW to set the off-loading MSS as being unavailable forselection.

Null-NRI can be defined to be generic for all MSSs in the pool, or each MSS in the poolcan have its own specific Null-NRI value.

It is possible to use the MSS-specific Null-NRI together with the RAN independent Mul-tipoint A/Iu support in MGW solution. When the MSS off-loading using the MSS-specificNull-NRI is initiated, the MGW’s NNSF can identify which MSS is off-loaded based onthe MSS-specific Null-NRI. Another MSS can be automatically selected without theneed for indicating which MSS is off-loaded through any O&M action in the MGW.

However, for example, during the migration to MSS pooling with the RAN independentMultipoint A/Iu support in MGW solution, there can be both pooled and non-pooled areasin the network. If uneven load distribution is experienced as a result of subscribers’moving between the pooled and non-pooled areas, it might be more beneficial to use ageneric Null-NRI value for all MSSs at this phase.

A Null-NRI can be reused in other pool areas.

NRI planning for networks requires careful management. The factors detailed in the fol-lowing sections must be considered.

Planning NRI length

The NRI bit string consists of a flexible length between 0 and 10 bits. A length of 0 bits

indicates that the NRI is not used and the feature is not active. The length of the NRImust be the same in each pool area/overlapping pool areas. The NRI length can be dif-ferent in neighboring pool areas, however, it is recommended that NRI lengths shouldbe the same in all pools in the network.

NRI length should be selected based on:

• The number of MSCs/MSSs in the pool (or in all pool areas in the network if the NRIvalue is not to be reused in neighboring pool areas);

• The number of NRIs allocated per MSC/MSS, including the Null-NRI for load redis-tribution, the minimum required number of NRIs for each MSC/MSS is 2;

• Future expansion needs.

The table Required NRI length illustrates the required NRI length when there is amaximum of 10 pool MSCs/MSSs and a maximum of 10 NRI values for each MSC/MSS(plus a Null-NRI equaling a total of 11 NRIs).

MSSs in pool

NRIsperMSS

2 3 4 5 6 7 8 9 10

2 3 3 4 4 4 4 5 5 5

3 3 4 4 4 5 5 5 5 5

Table 3 Required NRI length





75



Id:0900d805809d6ece

As can be seen from the table above, the longest NRI length required even for themaximum configuration is 7 within one pool area. If there is more than one pool areas inthe network, and NRI reuse in different pool areas is to be avoided, the total number ofNRIs required for all the pool areas needs to be taken into account when calculating therequired NRI length for the whole network.

The NRI is allocated as part of the TMSI, and so the selected NRI length and relatedNRI values should not use TMSI space unnecessarily. However, it is recommended thatwhen an NRI length is chosen, future expansion needs are considered. The additionalNRIs are allocated to the MSCs/MSSs. When evaluating future extension requirements,configuration effort for each RAN node/MGW must be carefully considered.

The longer the NRI is, the less likely it is that the RAN node/MGW NNSF will receive aTMSI value with a valid, but coincidental, NRI value when an MS moves from outsidethe pool area into the pool area. If a TMSI with a valid NRI is received coincidentally, itcauses the MS to be routed by the RAN node/MGW NNSF to the correspondingMSC/MSS, even though that MS should have been subject to RAN node load balancing.

For further information about subscriber redistribution because of an invalid NRI, see theSection NRI planning and management .

NRI value coincidences are estimated to be only a theoretical possibility if the describedprecautions are taken. However, by the use of an optional load balancing enhancement

a Null-NRI and non-broadcast LAI in the Location Updating Accept message sent by theMSC/MSS directs the subscriber correctly for RAN node/MGW subscriber distribution.

The table NRI length versus available TMSI space in MSC/MSS , details the effect of theNRI length selected and the number of NRIs allocated for each MSC/MSS on the avail-able TMSI range within one MSC/MSS.

g The table shows values for the case when LAI based TMSI allocation is not in use.

4 4 4 5 5 5 5 6 6 6

5 4 4 5 5 5 6 6 6 6

6 4 5 5 5 6 6 6 6 6

7 4 5 5 6 6 6 6 6 7

8 5 5 6 6 6 6 7 7 7

9 5 5 6 6 6 6 7 7 7

10 5 5 6 6 6 7 7 7 7

11 5 6 6 6 7 7 7 7 7

MSSs in pool

NRIsper

MSS

2 3 4 5 6 7 8 9 10

Table 3 Required NRI length (Cont.)





Issue 9-0 draft


Id:0900d805809d6ece


For reference, when multipoint features are not in use, the available TMSI space is 402653 184 for each MSC/MSS.

During a TMSI change, while the new TMSI is not acknowledged by the MS, both thenew and the old TMSIs are reserved for the same subscriber. This increases therequired number of available TMSIs, which shall be taken into account when determin-ing the NRI length and number of NRIs. Selecting an NRI length and number of NRIs for

each MSC/MSS so that at least twice the maximum VLR capacity is reserved for TMSIavailability, is recommended. For example, if the actual VLR static capacity is 3 000 000subscribers, then it is recommended to ensure at least 6 000 000 TMSIs. The effect ofthe selected NRI length and the number of NRIs for each MSC/MSS on the reservedTMSI range is shown in the table above. The NRI value is embedded into the TMSI andis effectively used as part of the TMSI. This means that in practice even though the NRIis longer, the number of available TMSIs remains at a workable level as illustrated.

When LAI based TMSI allocation is in use (can be turned ON by UTPFIL patch), thenthe number of available TMSIs are valid per location area, which in practice enlarges theTMSI space drastically. Please note that all VLRs in the PLMN must support LAI basedTMSI allocation, because the TMSI will not uniquely identify the subscriber in the inter-

communicating VLRs during an inter-VLR location update.In normal operation, the VLR does not reserve an already allocated TMSI to any otherIMSI, even after repeated restarts. A VLR restart does not have any effect on IMSI-TMSIhandling. VLR maintains a preallocation table with certain number of free TMSIs and thistable is continuously refilled after each TMSI allocation. This minimizes the probabilityof unsuccessful TMSI allocations. If free TMSI is still not found at the next reservationattempt, then the event will continue without the TMSI. Unsuccessful TMSI allocationsare indicated in CM/CMM computer error logs.

Once an NRI length is selected, changing it is not recommended because changing theNRI length also changes the NRI value. For successful operation, and because ofMSC/MSS capacity enhancements in future MSC/MSS releases, selecting an NRI

length greater than current requirements is recommended.

NRI length

# NRIsper

MSS

2 3 4 5 6 7 8 9 10

2 201326592 100663296 50331648 25165824 12582912 6291456 3145728 1572864 786432

3 301989888 150994944 75497472 37748736 18874368 9437184 4718592 2359296 1179648

4 NA 201326592 100663296 50331648 25165824 12582912 6291456 3145728 1572864

5 NA 251658240 125829120 62914560 31457280 15728640 7864320 3932160 1966080

6 NA 301989888 150994944 75497472 37748736 18874368 9437184 4718592 2359296

7 NA 352321536 176160768 88080384 44040192 22020096 11010048 5505024 2752512

8 NA NA 201326592 100663296 50331648 25165824 12582912 6291456 3145728

9 NA NA 226492416 113246208 56623104 28311552 14155776 7077888 3538944

10 NA NA 251658240 125829120 62914560 31457280 15728640 7864320 3932160

11 NA NA 276824064 138412032 69206016 34603008 17301504 8650752 4325376

Table 4 NRI length versus available TMSI space in MSC/MSS





77



Id:0900d805809d6ece

Changing NRI length

If the NRI length in the network must be changed, the change needs to be carefullymanaged. Without careful planning and simultaneous modifications in the MSC/MSS

and the RAN/MGW major traffic disturbances will result. A mobile-originating transactionmay be, for example, forwarded to an MSC/MSSs in which the mobile is not currentlyregistered, and as a result, a large number of unnecessary inter-VLR location updatesmay occur.

If the length of the NRI is changed, all NRIs in the pool area (in MSC/MSSs and RANnodes/MGWs) have to be changed to correspond with the new NRI length. This isbecause the added bit(s) will be present at the Least Significant Bits (LSB(s)) in theNRIs.

An example of a possible traffic disturbance scenario

For a 3-bit long NRI, bits 23-21 have been used. NRI value 5, for example, is coded‘101’. If the NRI length is changed to 4 bits, no subscribers in the VLR will have thecorrect NRI in their TMSI. For a 4-bit long NRI, the NRI is encoded using bits 23-20, sobefore a new TMSI re-allocation is made, routing based on the NRI length will not workas defined. For NRI value 5, instead of routing based on bits ‘101’, it will be based onbits ‘1010’ or ‘1011’ (bit 20 can be 0 or 1). Whether it is bit ‘0’ or ‘1’ depends on whichbit was assigned in the old TMSI. After a new TMSI is re-allocated, NRI value 5 with 4bits will be ‘0101’.

Changing NRI length may unbalance the pool. The capacity of each pool MSC/MSSmust be sufficient to support the sudden movement of subscribers, even though TMSIre-allocation occurs for the majority of subscribers only when the periodic locationupdate timer elapses. The periodic location update timer is an operator-specific param-eter.

If the allocation of the new NRI values is properly managed, NRI values with the old andnew NRI length will both point to the same MSC/MSS. The first mobile-originated trans-action is directed to the same MSC/MSS at which the subscriber is already registered.If the change is not properly managed, the transaction is routed to the wrong MSC/MSS.It does not have the subscriber information and the first transaction may be rejectedunless implicit location updating is in use. As a result, a large number of location updateswill occur.

Changing NRI during periods of low traffic (at night for example), and speeding up TMSIre-allocations is recommended. The change must be as quick as possible. It must bedone first in all the pool MSC/MSSs, one at a time, followed by each of the RAN

nodes/MGWs, one at a time.Reuse of NRI values

NRI values cannot be reused in MSC/MSSs in the same pool area nor in overlappingpool areas. However, NRI values can be reused in other pool areas within the network.For example, NRI values 1 and 11 are reused, as illustrated in the figure Reuse of NRIvalues .





Issue 9-0 draft


Id:0900d805809d6ece


Figure 35 Reuse of NRI values

Reusing NRI values in neighboring pool areas is not recommended. Neighboring poolareas have subscribers moving between them, reusing NRI values will affect the selec-tion of a pool MSC/MSS.

When a subscriber, for example, makes a location update request from a pool areawhich reuses NRI=1 to the area which is served by the four overlapping pool areas, thetarget MSC/MSS will not be selected by the NAS node subscriber distribution selectionfunction. The selected target MSC/MSS is the one that has the NRI=1 value assigned.

In a handover, the source MSC/MSS selects the target node using round-robin, but oncethe call is ended, the RAN node/MGW forwards the location update request based onthe NRI=1 value that the subscriber had previously. This means that the targetMSC/MSS which handled the handover might be changed to the MSC/MSS assignedwith NRI=1.

Having distinct NRI values helps to distribute traffic in a planned and efficient way.

Deleting an NRI

An NRI value can be deleted from an MSC/MSS which has more than one NRI. Deletingan NRI from the MSC/MSS causes the MSC/MSS to stop generating TMSIs with thatNRI. Subscribers who still have the deleted NRI as part of their TMSI will be handled bythat MSC/MSS until their TMSI is re-allocated. It is important to wait at least until theperiodic location update time has elapsed before deleting the NRI value from the RANnodes/MGW within the pool area/overlapping pools.

Deleting an NRI from an MSC/MSS does not affect traffic flow, unless the deleted NRIis the last NRI allocated for that MSC/MSS.

Adding an NRI

It may be necessary to add an NRI to a pool MSC/MSS, for example, after increasingcapacity in an MSC/MSS. An NRI can be added at any time as long as there are avail-

NRI:16, 17, 18, 19, 20

NRI:1, 2, 3, 4, 5

NRI:11, 12, 13, 14, 15

NRI:6, 7, 8, 9, 10

Reuse NRI: 11

Reuse NRI: 1





Issue 9-0 draft


Id:0900d805809d6ece


MS. No new subscriber data or location information is stored for an affected mobilestation until the VLR has received either a Provide Roaming Number (PRN) request oran Update Location Area request from that mobile station.

• If the restoration of subscriber data in the VLR is triggered by location updating orIMSI attach, the VLR retrieves the subscriber data from the HLR. The VLR sends anUpdate Location request, which triggers one, or more, Insert Subscriber Data oper-ations in the HLR.

• If the restoration of subscriber data in the VLR is triggered by a Provide RoamingNumber request, the VLR retrieves the subscriber data from the HLR. The VLRsends a Restore Data request, which triggers one or more Insert Subscriber Dataoperations in the HLR.

Mobile-originating call, mobile-originating short message, or call-independent supple-mentary service activity from the MS, cause the VLR to check its IMSI record for thatMS. Mobile-terminating transactions and mobile-terminating calls also trigger restora-

tion, but not, for example, an MT SMS. An MT SMS is delivered to the subscriber onlyafter the subscribers information has been restored in the VLR, but does not trigger res-toration.

The restore data operation (according to MAP phase 2) for Provide Roaming Number isillustrated in the figure VLR restoration in GSM phase 2 . The operation is very similar toa location update operation.





81



Id:0900d805809d6ece

Figure 36 VLR restoration in GSM phase 2

If the subscriber attempts to make a call (MO), or makes a supplementary servicecontrol request, the VLR performs an implicit location update providing this is config-ured. The VLR notifies the HLR and if the IMPLICIT_LOC_UP system configurationparameter is active downloads the subscriber's data. The original operation then contin-ues normally. If the implicit location update feature is not active, the VLR returns the'unidentified subscriber' error code. The MS then initiates the location registration

request. The HLR handles the 'send parameters' and the 'update location' requests nor-mally.

The network starts the restoration procedures automatically after the VLR is reset.

If the Gs/SGs interface is configured, Reset messages are sent on the Gs/SGs interfaceto the SGSNs/MMEs serving the location areas served by the VLR. SGSN/MME target-ing is based upon configuration data. The SGSNs/MMEs mark all Gs/SGs associationsas unreliable for all the MSs served by that VLR. The associations will be re-initiated,one by one, by the SGSN/MME at the next Routing Area update or combined RA/LA (orTA/LA) update request from each MS.

Parameters related to “Search”

If the subscriber information is not known in the VLR (for example, after MSC or VLRrestart and when no MS-originated transaction has been made yet), the IMSI paging by

1. Send_Routing_Information

2. Provide_Roaming_Number

3. Restore_Data

Subscriber Data Transfer

4. Restore_Data_Ack

5. Provide_Roaming_Number_Ack (MSRN)

6. Send_Routing_Info_Ack (MSRN)

7. IAM

8. Page MS

Normal Call Completion

GMSC VMSC HLR MS





Issue 9-0 draft


Id:0900d805809d6ece


the MSC/MSS is done as 'Search’. This means that the subscriber is paged with theIMSI in the whole MSC/MSS area. In the multipoint configuration this potentially affectsa wide geographical area and increases the paging load in the network. Adjusting therelated VLR search parameters to avoid overloading the network with simultaneoussearch procedures is therefore recommended.

In the VLR, the MX-VLR and PLMN Parameter Handling command group is used tohandle VLR-specific operations including search. The search related parameters arelisted below:

• SLIM IT = <limit for simultaneously started search procedures>This parameter defines the maximum number of search procedures started eachsecond. A search means that the subscriber is paged in all the location areas. Thishappens when the subscriber's LAC is unknown (VLR reset). The parameter valuerange is between 0 and 254.

• SCOUNT = <number of search repetitions>

This parameter defines how many times a single search is repeated. The parametervalue range is between 0 and 5.

• SINTER = <waiting interval of an answer of a search request>This parameter defines the time interval between the request being made and thetime the system waits for an answer. The parameter value range is between 50 and1000, that is, 500 ms to 10 s.

There are no additional parameters in the BSC, or RNC, that would affect the numberof pagings initiated towards the radio interface. If the paging channel capacity isexceeded, some of the paging messages are lost.

Parameters related to TMSI paging

It is also possible to control TMSI paging repetitions for the following cases with thesame MX commands in the VLR:

• RTPMTC = <use of TMSI page repetition in mobile-terminated calls>This parameter is used by the MSC/MSS to decide whether paging is repeated in anMT call where the first paging is done with the TMSI and the MS is not found. If thevalue is not found the paging is repeated using the IMSI. The recommended param-eter value is Y = Paging is repeated using the IMSI.

• RTPMTS = <use of TMSI page repetition in mobile-terminated short messages>The parameter is used by the MSC to decide whether paging is repeated in an MTshort message where the first paging is done with the TMSI and the MS is not found.If the value is not found the paging is repeated using the IMSI. The recommended

parameter value is Y = Paging is repeated using the IMSI. • RTPMTU = <use of TMSI page repetition in mobile-terminated USSDs>

The parameter is used by the MSC to decide whether paging is repeated in MTUnstructured Supplementary Services Data (USSD) where the first paging is donewith the TMSI and the MS is not found. If the value is not found the paging isrepeated using the IMSI. The recommended parameter value is Y = Paging isrepeated using the IMSI.

• RTPMTL = <use of TMSI page repetition in mobile-terminated LRs> <option>The parameter is used by the MSC to decide whether paging is repeated in an MTlocation request where the first paging is done with the TMSI and the MS is notfound. If the value is not found the paging is repeated using the IMSI. The recom-

mended parameter value is Y = Paging is repeated using the IMSI.





83



Id:0900d805809d6ece

Parameters related to MSRN

The VLR can allocate Mobile Station Roaming Numbers (MSRNs) to mobile-terminatingcalls either from a common number pool (simplest), or from different pools (roaming

number groups), based on the subscribers last known location area, or home network.In the latter case, the total number of MSRNs must be divided into separate MSRNgroups. The operator must plan enough spare numbers in all groups. The total numberof roaming numbers available is 7000 (Classic MSS) and 15000 (Open MSS).

With the MX command group, it is also possible to modify the PLMN parameters relatedto the MSRN in the VLR:

• MSRN = <MSRN life time>This parameter defines the life time of the Mobile Subscriber Roaming Number(MSRN). It is recommended that the parameter value is 2 seconds for home sub-scribers and 30 seconds for visiting subscribers.

• RNGP = <MSRN group>This parameter defines the roaming number group. The parameter value range isbetween 1 and 50. The default value is 0.

For further information about the MX Command Group, see MX Command Group-PLMN Parameter Handling in M-release documentation.





Issue 9-0 draft


Id:0900d805809d6ed0

Pooling and Multipoint configuration and connectivityguidelines

5 Pooling and Multipoint configuration andconnectivity guidelinesWhen considering the network configuration and connectivity options for the Multipoint

A and Iu interfaces, there are several configuration possibilities and different levels ofimplementation of multipoint connections between network elements.

Multipoint Iu and Multipoint A in MSC Server architecture and for Multipoint A in MSCarchitecture are considered in detail below. The optional feature RAN Independent Mul-tipoint A/Iu support in MGW is also considered in the Section RAN Independent Multi -

point A/lu support in MGW .

5.1 Multipoint A/Iu in MSS System architectureThe benefits of MSC Server architecture apply also when deploying the multipoint

feature. Since the control plane and the user plane are handled separately, changes inthe MSS pool configuration mainly affect the control plane while physical transmissionand connectivity between the MGW and the RAN node can be handled separately.

The ability to enable local switching is another advantage in the MSC Server architec-ture as compared to the MSC architecture. Local switching in MGWs saves transmissionand interconnect costs. MGWs can be situated closer to the subscribers. Local calls canbe switched locally without long transmission legs to the MSC and back. With multipoint,a call between subscribers under the same MGW, but controlled by MSS nodes that aregeographically distant from each other, can still be switched locally.

For further information about MGW selection in general, see Planning of control anduser plane analysis in the document MSS System Network Planning .

Virtual MGW concept

In MSC Server architecture, compared to MSC architecture, the MGW is an additionalnetwork element between the BSC and the MSS. Additionally, the virtual MGW (vMGW)concept can be introduced. One physical MGW (pMGW) can be divided into vMGWs.With the vMGW concept, one MGW can be connected to more than one MSS. Thismultiple connection is a prerequisite of the multipoint feature.

Without the vMGW concept (and multiple vMGWs in one physical MGW), one pMGWcan be connected to only one MSS. The vMGW concept makes network configurationflexible and less complex. Each of the vMGWs can register itself to the pool area MSSsto create a meshed Mc interface. A meshed A interface is not then required.

One physical MGW can be divided into up to 85 virtual MGWs and up to 30 vMGWs canbe configured in to one ISU unit. Therefore, the MSC Server architecture enables moreflexible pool area configuration and connectivity compared to MSC architecture. WhenH.248 load balancing in the MGW is not in use each vMGW must be a division of a singleISU. When H.248 load balancing is in use, the operator is able to attach as many Inter-face Signaling Units (ISU) as is required for one virtual MGW.

g One physical Open MGW can be divided into up to 85 virtual MGWs and up to 60vMGWs can be configured into one CLA/ISU node pair and up to 30 vMGWs can beconfigured in to one HCLB recovery group. H.248 connections are configured into HCLBrecovery groups in Open MGW and into ISU functional units in MGW based on IPA2800.





85



Id:0900d805809d6ed0

A particular ISU can have H.248 connections to the same MSS or to different MSSs.Even though the MGWs IP address is the same, the port number is assigned on avMGW basis. The MSS differentiates each vMGW using both the IP address and theport number so that in an ISU there can be one set of SCTP IP addresses. Each signal-ing unit in the MSS can determine multiple vMGWs from the same SCTP ISU/IPaddresses.

Virtual MGW control related to multipoint features is described in more detail in theSection Virtual MGW and MGW control .

For further information about the vMGW concept, see Planning of control and user planeanalysis in MSS System Network Planning .

For further information about signaling unit limitations (CCSU/SIGU/GISU) and thevMGW concept, see Planning of control and user plane analysis in the document MSSSystem Network Planning .

User plane connectivity in Multipoint A (over TDM)

Configuring Time Division Multiplexing (TDM) resources to more than one vMGW toachieve resilience and enable ISU load sharing is recommended. From the perspectiveof MGW internal resilience, it is sufficient if TDM resources are configured to twovMGWs that are located in different ISU units within the pMGW.

From a load sharing perspective, it is recommended that TDM resources are sharedevenly between all vMGWs in all available ISU units, and that sequential hunting is usedfor the MGW’s TDM resources in the MSC Server.

g It is recommended to configure the sequential hunting method, as the normal huntingmethod results in multiple circuit hunting attempts at busy hours and thus increasedH.248 traffic.

To achieve MGW network element level resiliency, it is recommended a BSC is con-nected to more than one pMGW. However, in MSC Server architecture, the BSC doesnot have to be physically connected to all MGWs within the MSS pool area.

From the perspective of the MSS, it is preferable that each parallel MSS can select andcontrol at least one vMGW in each of the pMGWs connected to the BSCs in the poolarea. This is not required, however, if POIs can be accessed through more than onepMGW.

The topology aspects before and after introduction of a pool are illustrated in the follow-ing examples.





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 37 TDM resource configuration before the MSS pool concept is introduced.

When introducing the MSS pool concept into the network, a Circuit Group (CGR) fromthe BSC to the MGW is required for each of the pool MSSs. Therefore, the total numberof CGRs required reflects the number of pool MSSs. If one BSC is connected to morethan one pMGW or vMGW, the CGRs may belong to the same route in the MSS.





87



Id:0900d805809d6ed0

Figure 38 TDM resource configuration after the introduction of the MSS pool concept

Each vMGW can have up to 10 circuit groups.

The number of circuit groups, which can be attached to virtual MGW, is up to 285 bothin Open MGW and MGW based on IPA 2800.

If a fractional E1 is defined in one CGR within a vMGW, the remaining timeslots in thesame E1 cannot be used in another CGR attached to other vMGWs. It is, however,possible to use the remaining timeslots for uses other than vMGW use. For example,signaling channels and timeslots for semi-permanent connections are not configured forvMGW use. The Ater interface (2G Transcoder) in the MGW feature enables more

flexible E1 usage, as described in the Section A/Ater connectivity alternatives .It is recommended that the BSC-MGW transmission link is protected. The protectionmechanisms are described in the document MSS SystemNetwork Resilience .

TDM circuit groups in the MSS and the MGW

The role of circuit groups in the MSS are very different to those in the MGW. Circuitgroups in the MGW are on a different level than in the MSS. In the MGW they are on theuser plane handling level and in the MSS on the control plane level.

In the MGW, circuit groups are used for two purposes:

1. To group circuits with the same kind of user plane level parameters (for example,DSP-related, ECHO cancellation);

2. To dedicate TDM circuits to the correct MSS through the vMGW configuration.





Issue 9-0 draft


Id:0900d805809d6ed0


In the MGW, the circuits attached to the same CGR do not have to lead to the sameadjacent entity, they only have to have the same kind of use. There can be, for example,circuits from the many BSCs in the same MGW CGR providing that they have the similaruser plane related parameters (that is, same DSP pool, ECHO and vMGW).

The most important issues related to TDM CGRs in the MGW are:

1. TDM network maintenance issues .When a TDM connection fails (or starts working after a failure), the circuits status iscommunicated to the MSS through the vMGW to which the CGRs are attached.Based on the information the MSS knows if these circuits can be hunted.

2. Optimization of DSP usage .By defining different properties for each CGR, it is possible to reserve DSPresources so that unused DSP services are not allocated optimizing MGW capacity.In the CGR configuration, the interface type (PSTN, A/Ater, other) has an effect onthe capacity as well as the use of, for instance, Acoustic Echo Canceller (AEC) and

Echo Canceller (EC). For example, MGW capacity can be saved if the EC is not con-figured for A/Ater interfaces and the AEC for the PSTN interface.

In the MSS, circuit groups are used to group circuits going to the same adjacent entityand must have the same signaling/call control related parameters. In the MSS, circuitgroups are also used to connect circuits to the correct vMGW through MGW_IDs. Thedifference is that in the MSS all the circuits attached to the same CGR should lead tothe same adjacent entity. In one CGR, for example, there can be circuits/term IDs onlyfrom one BSC.

If the number of circuit groups from one MSS system to the other end is planned to equalthe number of ISU units, this means perfect load sharing between the ISUs. However,the management of the CGRs becomes very difficult. There are network planning

options:1. Decrease the number of CGRs in one route direction to between 2 and 4. 4 should

be enough as one type of circuits should be allocated to one CGR from the MGW'spoint of view (for example A interface, PSTN with echo cancellation, PSTN withoutecho, and other TDM).

2. CGR number/division does not need to be the same as on the MSS side.

The figure Example of CGRs in the MSS and MGW, illustrates an example of the differ-ent kinds of CGR use in the MSS and in the MGW:





89



Id:0900d805809d6ed0

Figure 39 Example of CGRs in the MSS and MGW

In the MSS, there are as many CGRs as there are BSSs/destination elements, and inthe MGW there is a CGR for each type of use. For example, all the BSSs in the figureExample of CGRs in the MSS and the MGW , belong to the MGW As‘ CGR1.

From the perspective of the CS core, one CGR for each BSS is sufficient. However, fromthe BSSs perspective more than one CGR for each BSS may be needed, if, for example,certain codecs require a dedicated circuit pool. Such a situation is illustrated in the figureExample of CGRs in the MSS and the MGW from the perspective of a BSC and providesan example of where a dedicated circuit pool for wideband codec is required.

310-313

314-317

318-321

322-326

MSSMSS can have 0-286 CGRsper (v)MGW.CGR has to be uniqueper pMGW.

CGR 310-313

CGR 314-317

CGR 318-321

CGR 322-326

MGW1

vMGW 12(0-10 CGRsper each vMGW)

B CGR 1

vMGW 11(0-10 CGRsper each vMGW) A CGR 2

A CGR 1


PSTN / PLMN

MSC/BSS or other TDM elements

PSTN / PLMN


PSTN / PLMN


BSS1

BSS2

BSS3

BSS4

C CGR 1

MGW2


B CGR 1

vMGW 21(0-10 CGRsper each vMGW) A CGR 2

A CGR 1


C CGR 1

The CGRs to BSS1-BSS4and to PSTN/PLMNas in MGW1





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 40 Example of CGRs in the MSS and the MGW from the perspective of a BSC

A/Ater connectivity alternatives

There are also different options for multipoint configurations depending on whether(static) resource division at the A or Ater interface is preferred.

In resource division at the A interface, the time slot configuration is static all the time,that is, from BSC-TC-MGW–MSS. This alternative requires minimum changes to theexisting non-pooled network architecture and enables the exploitation of the existingGSM capacity as well as the existing TDM A/Ater transport between the BSS and thecore network.





91



Id:0900d805809d6ed0

Figure 41 Resource division in the A interface

Resource division at the A interface protects against MSS and MGW failures, whereasresource division at the Ater interface also protects against Transcoder (TC) failures.

Static resource division in the Ater interface is illustrated in the figure Resource divisionin Ater interface in the transcoder .

Figure 42 Resource division in Ater interface in the transcoder

g In both alternatives, the E1s cannot be divided, instead E1s are switched between BSC–TC and TC–MGW.

The MGW also supports direct Ater connectivity from the BSC, as illustrated in the figureResource division in the Ater interface in the MGW .





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 43 Resource division in the Ater interface in the MGW

The Ater interface (2G Transcoder) in the MGW is a functionality which comprises the Ater interface towards the BSC and the MGW’s GSM Transcoder (2G TC) functionality.The Ater in MGW feature provides a functionality corresponding to that available usingTCSM2 or TCSM3i.

In the multipoint configuration, the Ater in the MGW enables more flexible E1 usagebecause of the ability to split the Ater interface by dedicating virtual A-interface PCMswithin the Ater to different vMGWs (which may reside in different ISU-units). vMGWsmaybe controlled by different MSSs resulting in additional core network resilience.

g Ater in MGW also requires BSC support of 2GTC in the MGW.

A/Ater connectivity and circuit group configuration is discussed in the Section A/Aterinterface CGRs with RAN Independent Multipoint A .

User plane connectivity in Multipoint Iu and Multipoint A (over IP)

In Multipoint Iu, user plane connectivity is simpler than in Multipoint A (over TDM) dueto ATM or IP transport in the Iu interface and the fact that user plane resources can beshared amongst the pool MSSs. This is so because ATM/Iu resources are shared by theMGW resources and are not tied to each ISU as in the case of TDM (where each CGRis attached to a particular vMGW + IWS1/NIWU).The same also applies when AoIP is used for Multipoint A.

g Note that the Open MGW does not support the ATM-based Iu interface.

In multipoint, MGW resources are shared between the vMGWs, but the user planerouting principles are not changed as compared to a non-multipoint architecture.Roaming number allocation is also done normally by the vMGW. Roaming number allo-cation is described in the document MSS System Network Planning .

For more information about user plane routing in MSS, optimizing MGW selection andvMGWconfiguration planning, see the document MSS System Network Planning .

Protecting RNC-MGW and BSC-MGW transmission is recommended. The protectionmechanisms are described in the document MSS System Network Resilience .





93



Id:0900d805809d6ed0

The RNC or BSC (with AoIP) can be connected to a single pMGW under an MSS’scontrol, or to more than one pMGW under an MSS control. Connection to all pMGWssaves user plane resources significantly since the ingres and egress user plane trafficcan use the same pMGW.

The topology aspects and pMGW resiliency are illustrated in the examples presentedlater.

Signaling connectivity in Multipoint A and Multipoint Iu

A RAN node within a pool area has to have signaling connections to all pool MSSs. Ifthe RAN node is part of an overlapping pool area, it must have signaling connectivity toall MSSs that control the overlapping pool area as well. The RAN node must be able toroute signaling messages to any pool MSS.

The Multipoint A or Iu interface has no effect on the capacity of BSSAP or RANAP sig-naling. The signaling load in a RAN node is correlated to the total traffic served by thatRAN node. The load is not changed due to a multipoint configuration. The load is dis-tributed among the links to each of the MSSs and the load on each link is based on thetraffic that the subscribers generate towards that specific MSS. Signaling link capacityshould be considered not only during normal operation, but also during fault and main-tenance situations. The link capacity required with, in part, depend on the level of MSSredundancy required.

In case of an MSS failure or during maintenance, there is increased load on the remain-ing signaling links. In the worst case scenario, if only one MSS remains in service, theremaining pool MSS must handle the full signaling load generated by all the RAN nodescontrolled by all the pool MSSs.

There are two signaling options for connecting the BSC to the MSSs within the pool

area/overlapping pool areas:1. Using TDM-based or IP-based (SIGTRAN) SS7 to the MGWs, and utilizing the

MGW as a Signaling Transfer Point (STP) to transfer the BSSAP messages to/fromthe targeted MSSs.

2. Using IP-based SS7 (SIGTRAN) connected directly to the MSSs if supported by theBSCs. It is recommended that SCTP multihoming is used for resiliency. IP backboneredundancy is achieved by having duplicate routers. This option cannot be used ifRAN independent multipoint solution is used, because signaling is required to behandled by the MGW for subscriber distribution.

There are two signaling options for connecting the RNC to the MSSs within the poolarea/overlapping pool areas:

1. Using ATM connectivity and ATM AAL5 cells to the MGW.The MGW acts as an STP/SGW to transport RANAP (based on ATM) to RANAPover IP (using SIGTRAN) towards the targeted MSS in the MSS pool.

2. Using IP-based (SIGTRAN) SS7 to connect the RNC directly to the MSS, bypassingthe MGW. This option cannot be used if RAN independent multipoint solution isused, because signaling is required to be handled by the MGW for subscriber distri-bution.

g The RNC must support SIGTRAN signaling

For further information about SIGTRAN routed through an MGW see the document MSS

System Network Planning .





Issue 9-0 draft


Id:0900d805809d6ed0


AAL2 signaling load does not increase due to Multipoint Iu, but it has to be configuredfrom the RNC to all MGWs to which the RNC is connected.

For signaling connectivity in RAN Independent Multipoint A/lu support in MGW solution,

see RAN Independent Multipoint A/lu support in MGW .

g Note that the Open MGW does not support the ATM-based Iu interface.

Virtual MGW and MGW control

The number of vMGWs in one pMGW should reflect the number of MSSs in the pool. Ifthere are 4 MSSs in the pool, for example, each MGW within the control of the MSSsshould be split into 4 vMGWs. The minimum requirement is to have one vMGW for eachMSS in each pMGW. In this example, the service outage period caused by an ISU failurewould be as short as the time it takes for ISU switchover.

Alternatively, there can be two vMGWs for each MSS in each pMGW. As an example,four MSSs result in eight vMGWs in each pMGW. With this configuration there is no totaloutage at all.

In both cases, the TDM resources connected to the failed ISU are unavailable. With ATM/IP-based interfaces, however, such unavailability does not occur.

The fewer vMGWs, the less complex the configuration is, for example, in respect of theconfiguration of TDM resource and Mc interfaces.

g A vMGW must exist within a single ISU, unless the H.248 load balancer is used in thepMGW. In Open MGW H.248 load balancing is always used.

The figure Virtual MGW and multipoint feature illustrates the connections of a vMGWwith the Multipoint A feature within a pool area when A over TDM is used.





95



Id:0900d805809d6ed0

Figure 44 Virtual MGW and multipoint feature

In the figure, both MSSs allocate the roaming numbers from a different number range.LAC-based Roaming Number allocation enables optimal resource utilization in mobile-terminating calls in cases where the BSC is connected to one pMGW. Thus, all BSCsthat belong to the same LAC should be connected to the same pMGW in each MSS toenable the use of LAC-based Roaming Number allocation.

The figure is a simplified example, the size and number of BSCs and their geographicaldistribution has an impact on user plane connectivity. Typically, parallel LACs are alsoconnected to the same pMGWs.

Figure Virtual MGW-MSS connectivity illustrates examples of ISU configurations whenthe MSS pool concept is introduced in to the network.





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 45 Virtual MGW–MSS connectivity

Intra-virtual MGW connection limitation

When a connection is established between different vMGWs within the same pMGWand the vMGWs are controlled by different MSSs, as illustrated in the figure, ISUcapacity is limited to 6500 virtual connections.

Figure 46 Intra-virtual MGW connection limitation





97



Id:0900d805809d6ed0

In the above example, MS-A which is controlled by MSS1, is calling UE-B, which is con-trolled by MSS2. Two normal connections will be required (in each ISU) plus 1 virtualconnection.

Example: Theoretical calculationTraffic input: ~ 9.000 Erlang per MGW

70% local traffic => 6.300 Erlang within the physical MGW. Note that the amount of localtraffic used in this calculation is very high compared to the normal network, because typ-ically a large portion of the traffic goes out from the pool area and is thus not handled bythe MGW.

• 7 MSSs in one MSS pool • All BSCs/RNCS connected to 1 pMGW only

=> 6/7 (86%) of calls are inter-MSS calls = 5.400 calls

Assume 7+1 ISU in the MGW (that is, 7 vMGWs), all of them handling the same trafficload.

There are 21 different combinations (i,j) with i,j = 1,…7.

=> Each combination handles ~257 calls (5400/21)

Each ISU must handle ~1500/2= ~750 inter-MSS calls (~257*6/2)

5400 calls in the pMGW may be controlled by two different MSSs. For a single call, theISUs reserve two normal resources from the two vMGWs (one resource in each ISU) +1 one virtual resource in one vMGW, therefore 1500/2=750.

In vMGW cases, one call must be calculated as 1.5 BHCA and not 1 BHCA when ATMis used at the Nb interface and BICC is used between the MSSs. If IP is used at the Nbinterface and BICC or SIP is used between MSSs, then one call must be calculated as2 BHCA.

For more information about MGW dimensioning, see the document MGW Release U6Capacities in U-release Documentation.

Conclusion:

7+1 ISUs are still enough, even though the amount of local traffic is assumed higher thantypical.

g In the case of a TDM-TDM virtual connection, the call passes twice through theTranscoding Unit (TCU) and therefore, also through the Multiplexer Unit (MXU). If thereis only one MSS and several vMGWs, then 'TDM borrowing' can be used if the related

PRFILE parameter is allowed. That functionality uses only one TCU instead of severalTCUs.

Physical MGW level resiliency topology

The operator may prefer resiliency at MGW level, meaning that the RAN nodes need tobe connected to more than one pMGW. This section gives examples of Multipoint A andMultipoint Iu resiliency architectures.

Multipoint A (over TDM) resiliency examples

Alternative 1 presents a BSC single homing scenario, where a BSC is connected to onlyone pMGW. The alternatives 2, 3 and 4 present multihoming scenarios where the BSCis connected to more than one pMGWs.





Issue 9-0 draft


Id:0900d805809d6ed0


Example: Multipoint A topology 1 – no MGW disaster resilience

The figure Multipoint topology without MGW disaster resilience , illustrates a topologyoption with the MSS System architecture, where optimal MGW selection is achieved.

However, the MGW is not protected, for example, from disaster situations.

Figure 47 Multipoint topology without MGW disaster resilience

In this configuration, the likelihood that subscribers have their user plane connectionsthrough the same MGW is smaller than in topology alternatives 2 and 3.

Example: Multipoint A topology 2– with MGW disaster resilience

The figure Multipoint topology with MGW disaster resilience illustrates a topology optionwhere MGW disaster resilience is included.





99



Id:0900d805809d6ed0

Figure 48 Multipoint topology with MGW disaster resilience

To achieve MGW disaster resilience, there are some drawbacks related to the Multipoint A interface:

• Additional A i/f transmission costs between sites; • A i/f trunking is less efficient due to a higher number of smaller CGRs; • No optimal MGW selection for inter-MSS call: two pMGWs can be involved in a local

call within one BSC (unless call routing optimization is used).

The call routing optimization (outgoing resource selection based on incoming side)enhancement introduces an MGW ID-based CGR selection method. Its benefits,compared to the current MGW selection optimization solution, are described in thedocument MSS System Network Planning and include:

• Even without a reserved incoming side resource, a circuit can be hunted on theoutgoing side so that both incoming and outgoing resources will be reserved in thesame MGW;





Issue 9-0 draft


Id:0900d805809d6ed0


• The restriction (one route/one TREE = one MGW) is removed as the CGR selectionmechanism is able to select a CGR based on the MGW ID, so one route can containCGRs which are attached to different MGWs;

•There is easier integration of MGWs into the already existing routing configuration(for example, destination, sub-destination, and route level routing policies are notaffected);

• MGW selection is optimized both on the virtual and pMGW level.

This alternative also requires BSC support quasi-associated signaling in order toprovide MGW level resiliency.

For further information about the Signal Point Management Cluster (SPMC), see thedocument Integrating MGWinto the MSC Server System in U-release product documen-tation library.

Example: Multipoint A topology 3 – 2nd option with MGW disaster resilience

The figure Multipoint topology with MGW disaster resiliency, 2nd option illustrates atopology option where MGW disaster resilience is included.





101



Id:0900d805809d6ed0

Figure 49 Multipoint topology with MGW disaster resiliency, 2nd option

As there are no connections from the RAN nodes to the MGWs located at other sites,this alternative has lower A-interface transmission costs. However, the other drawbacksdescribed for the previous alternative remain valid.

This alternative also requires BSC support for supporting quasi-associated signaling.

Multipoint Iu and multipoint A (over IP) resiliency examples

This section describes the resiliency examples for Multipoint Iu. The same examplesapply to also for Multipoint A, when A-interface over IP is used.





103



Id:0900d805809d6ed0

Figure 51 Multipoint Iu call case with non-meshed Iu

Connectivity example in multipoint configuration

This section presents an example of the multipoint configuration outlining, for example,the vMGW and Point-of-Interconnect (POI) aspects in the multipoint network. Theexample is principally from the perspective of Multipoint A interface (over TDM) config-uration, however, the same principles also largely apply to the Multipoint Iu interface.The differences between the Multipoint A and Multipoint Iu/Multipoint A (over IP) config-urations are indicated where relevant.

The configuration principles for the pool area are:

• One pool area, that is, all BSCs and RNCs distribute subscribers to all MSC Servers; • Physically (transmission) one BSC is connected to one pMGW;• The BSC route is split into circuit groups, one for each MSS;

• Each pMGW is split to 5 vMGWs, one for each MSS.

For more details and the basic functionality, see Control Plane Routing and User PlaneRouting in M-release Product Documentation.

The configuration principles for routing are:

1. Mobile-originating calls are routed on the basis of originating pMGW. • Tree selection is made based on, for example, the cell dependant routing cate-

gory. This causes redundant digit analysis information (digit entries and trees),but provides more flexibility for the future. However, if BSCs are multihomed, the





Issue 9-0 draft


Id:0900d805809d6ed0


location of the caller does not indicate the pMGW. In this case, the next alterna-tive is more suitable.

• Alternatively, routing on pMGW basis using the Local Bearer Control Unit ID(LBCU-ID) enables optimal routing based on the location. Calls to the PSTN, forexample, can be routed using ISUP trunks that are connected to the samepMGW as the A-interface trunk.

As a sub-option, from certain mobile-originating trees number modification cantake the call to another tree. This may be feasible if the routing is identicalcompared to the other tree.

2. A MO call to the PSTN over BICC between MSC Servers: If the local PSTN ISUProute is connected to one MSS only, then for each PSTN ISUP route one BICCcircuit group is created for each MSS-MSS pair. For example, if MSS1 controls theISUP route, a BICC CGR is needed to MSS1 from MSS2, MSS3, and so on. Thereis no need to analyze the B-number in MSS1 since the incoming CGR indicateswhere the call is going. If alternative routing is needed in MSS2, there are twodistinct cases: • Without call routing optimization - outgoing resource selection based on

incoming side: Separate circuit groups are needed, with each CGR tied to thesame optimal pMGW.

• With call routing optimization - outgoing resource selection based on incomingside: there is no need to create CGRs between MSSs just for alternative routing.Both POIs could be on the same route on different CGRs. MSS2 checks theincoming User Plane Destination (UPD). The operator must configure MGW IDbased circuit group selection in MSS2 (Additional Circuit Selection Method,

ACGM).3. MO call to PSTN over SIP-I between MSC Servers: For SIP-I there is only one circuit

group since the Circuit Identification Code (CIC) is not used to identify the CGR. Thecall cases could use prefixes in the called number. Unfortunately, this makes con-figuration and service planning more complex. In the case of SIP-I it is better to usealternative routing if the incoming side is SIP-I. This principle guarantees that alter-native routing is done at the earliest possible node. Call forwarding is an exceptionto this rule.

4. Call forwarding: The redirecting MSS has to alternatively route the forwarded-tonumber (FTN). In this case incoming signaling is not considered. The End of Service(EOS) analysis and EOS attribute analysis have many inputs that can be used todistinguish the attributes.

5. MT call, BICC between GMSS and VMSS-B: BICC signaling conveys the Bearer

Interworking Function (BIWF) address which can be used for optimal MGW selec-tion.

6. MT call, SIP-I between GMSS and VMSS-B: The BIWF address is not conveyed inSIP-I, and there is only one SIP circuit group. Also, MSRN allocation on LAC basiswill not help if the BSCs are multihomed (within the MSS to 2 or more pMGWs). Theonly solution for BSC multihoming is to use the LBCU-ID in the source/gateway MSSto set a prefix to the MSRN. In VMSC-B the prefix can be analyzed in the extendeddigit analysis. The extended digit analysis can then set the Original Dialing Class(ODC), for example. The ODC can, in turn, be utilized in the User Plane Analysispreceding the UPD determination phase. To benefit from this, there must be aseparate UDP for this MGW.If, however, the optional Feature 1879: User Plane Support of 3GPP SIP-I is active,the BIWF address is conveyed in SIP-I messaging in order for the target MSS to be





105



Id:0900d805809d6ed0

able to attempt the selection of a vMGW from the same pMGW as was reserved onthe originating side, thus reducing the number of interconnection reservations andbandwidth usage between pMGWS.For more information, see Feature 1879: UserPlane Support of 3GPP SIP-I, Feature Description in M-release documentation.

g MSRNs are allocated on an MSS basis. This means that if a BSC is multihomed toeach MSS through a single MGW for each MSS, the MSRN range uniquely identifiesthe pMGW (if LACs are assigned on a pMGW basis).

7. Alternative routing is controlled by the originating and redirecting MSS. If the Point-of-Interconnect (POI) is busy, the call is released backwards to the source MSS. Inthe next alternative, the MS may be served by a different MSS.

In the figure Example of pool area network topology , the pool area network topologyused in this example is illustrated.

Figure 52 Example of pool area network topology

In the figure Example of pool area network topology , one pMGW is divided into vMGWs.For example, MSS5 shows one route, one circuit group and one vMGW.

In the Multipoint Iu configuration, it is sufficient to have one AAL2 and AAL5 connectionfor each pMGW. User plane destinations (UPD) have to be created for each RNC orBSC when AoIP is used, and the UPD is required to include all the pMGWs that are con-nected to the RNC/BSC. For UPD configuration aspects and MGW optimization, see thedocument MSS System Network Planning .

The connections of MSS1, MSS2 and MGW as well as MGW to POI connections areillustrated in MSS1-MSS2 and MGW1 connections. The naming convention used in theexample is:

1. 2. 3. 4.

O B M1 POI11. O = outgoing, I = incoming





Issue 9-0 draft


Id:0900d805809d6ed0


2. B for BICC3. Adjacent MSS, M1 = MSS14. POI plus running number.

Figure 53 MSS1-MSS2 and MGW1 connections

In pMGW1, the vertical lines represent vMGW. The PSTN circuits are distributed to allMSSs. In the figure, there is one route in MSS1 and in MSS2, but there could also betwo routes with proportionate routing.

In the figure MSS1-MSS2 and MGW1 connections , POI1 ISUP trunk is controlled byvMGW8 of pMGW1, and POI2 is controlled by vMGW1 of pMGW1. Both vMGW1 andvMGW8 are controlled by MSS1. These two circuit groups (CGR) of MSS1 are on thesame route. When MSS2 needs to route a call to POI1 or POI2, it routes the call to itsOBM1POI1 BICC CGR. In MSS1 these calls are seen as incoming BICC calls from CGRIBM2POI1.

The impact of POI throughout the network is illustrated in the figure Impact of POI innetwork .





107



Id:0900d805809d6ed0

Figure 54 Impact of POI in network

In the figure Impact of POI in network , in MSS4 there is the same incoming tree=x for allthe CGRs. All digits (TON=NAT) go to one destination. As can be seen, each ISUP route(1-5 CGRs) generates one BICC CGR to each MSS. In MSS4 there is the ISUP route,and incoming BICC CGRs from every other MSS in the pool. In every other MSS thereis one outgoing BICC CGR (in each) towards MSS4 for this POI.

In the table CGR to tree number mapping , mobile-originating calls have one digitanalysis tree for each pMGW. The tree is selected based on a cell-dependent routingcategory (CDR). The tree numbers are just examples. For example, all calls made from

Area 1, are analyzed in tree 201.





Issue 9-0 draft


Id:0900d805809d6ed0


In the table CGR to tree number mapping , each POI has one incoming tree to target theMSS for BICC. The table CGR to tree number mapping in MSS1 , illustrates the situationfrom the perspective of MSS1.

Any number is routed to an ISUP destination having the 2 ISUP CGRs. The routing fromany PSTN POI should be identical, that is, the same tree can be used for all POIs.

Calls from BICC CGRs IBM2POI1, IBM3POI1, IBM4POI1 and IBM5POI1 are allanalyzed in tree 301, and every set of digits leads to the same outgoing ISUP route.From the perspective of MSS1, it does not matter what the MSS of origin is. It has noconsequences for billing. However, statistics can be collected on CGR basis if required.

In tree 301 there is no need to analyze digits at all. All Type of Number (TON) valueshave the same result. This is because the MSS of origin has analyzed the callednumber, and it is known based on the incoming CGR where the call should go.

Another key principle is that for these calls MSS1 does not have any alternative routingconfigured in tree 301. If POI1 is busy or unavailable, the call will be returned back tothe MSS of origin. The MSS of origin then initiates alternative routing if applicable.Having the alternative routing in the original MSS ensures that there are no eternal loopsof alternative routing.

Calls from the PSTN can be analyzed, for example, in tree 70.

The figure Digit analysis , illustrates an example of how to build (mobile-originating) digitanalysis in the original switch.

CGR of origin Tree number

Area 1 201

Area 2 202

Area 3 203

And so on

Table 5 CGR to tree number mapping

CGR of origin Tree number

BICC:

IBM2POI1

IBM3POI1

IBM4POI1

IBM5POI1

301

POI1 (ISUP) 70

POI2 (ISUP) 70

And so on

Table 6 CGR to tree number mapping in MSS1





109



Id:0900d805809d6ed0

Figure 55 Digit analysis

In the figure Digit analysis , there are the same digit ranges in both MSS1 and MSS2.

The left-most table in the figure Digit analysis shows that in MSS1, TON=NAT, digits=2,goes to POI1 or POI2 CGR (on the same route). In tree=203 (area 3) national callsstarting with digit 3 also go to the same POI1/POI2. The destination name in this tableis not a real name. The tree=301 is the incoming BICC CGR from other MSSs. This isonly a partial analysis configuration, taking just one POI1/POI2 route into account. Notealso that the digit pre-analysis has removed prefixes from the number, and unified thenumber format.

The upper right table in the figure Digit analysis , shows digit analysis in MSS2. In area3 (tree 203) national digits 2 and 3 go to the BICC CGR OBM1POI1 towards MSS1. Inother areas digits 1 and 2 go to MSS1. Note that in MSS2 tree 301 may be used for someother incoming BICC CGR than in MSS1.

5.2 Multipoint A in MSC architectureThe Multipoint A Interface feature is also available in the traditional MSC architecturemainly as an MSC resilience solution. For Multipoint A in MSC architecture, the main

principles as presented for Multipoint A in MSC Server architecture also apply.





111



Id:0900d805809d6ed0

Extra capacity needs to be reserved for inter-MSC traffic also, due to, for example, theincreased probability of congestion in TDM transport and unoptimized local switching,when the calls are handled as inter-MSC calls.

Figure 57 Increase in inter-MSC traffic

In the figure Increase in inter-MSC traffic , multipoint connectivity at the A-interface isemployed.

On the other hand, in an intra-pool area handover, the inter-MSC traffic is reducedcompared with a non-pooled network. As the multipoint configuration keeps the sub-scriber under the same MSC in normal operation, there is less need for inter-MSC han-dovers within the pool area, which saves backbone transmission resources.

g A-interface over IP is supported only in MSC Server architecture.

5.3 RAN Independent Multipoint A/Iu support in MGW

g For detailed Open MGW specific information, see U- and Ui-release product documen-tation with special respect to the following customer documents:

• Configuring Signaling Connections in Open MGW • RAN Independent A/Iu Multipoint Support in MGW • Integrating Open MGW into the MSC Server System

g Please note that Open MGW does not support Iu-CS over ATM.

This section describes the feature functionality and network configuration aspects whenthe optional feature RAN Independent Multipoint A/Iu support in MGW is used in thenetwork.





Issue 9-0 draft


Id:0900d805809d6ed0


Overview to feature functionality

The core network node selection and related NAS Node Selection Function in the MGW(NNSF in MGW) enables MSS pooling without the radio network supporting multipoint

functionality. The core network node selection in MGW feature implements in the MGWthe same NAS node selection function that would, in the standard multipoint functional-ity, be required in the RAN nodes (BSCs and RNCs).

g Note that both the Chinese and the ANSI variants of Network Node Selection Function(NNSF) for multiple MGWs in cluster are supported by Open MGW in MSS SR5.0 (Ui5.0EP2). The MGW based on IPA2800 supports only the Chinese variant of NNSF formultiple MGWs in cluster. The ANSI variant is not supported by the MGW based onIPA2800.

The MGW initially selects the pool MSS to serve a pool area incoming subscriber basedon the weighted round robin method. Once the pool MSS has been selected, future

transactions - such as location updates, calls - are directed to the same MSS. The MGWNNSF analyses the NRI in the TMSI and directs the transaction to the identified MSS. As in the RAN node-based multipoint solution, the subscriber is served by the sameMSS as long as the subscriber stays in the pool area.

Figure 58 Multipoint A/Iu support in MGW with the NAS node selection function(NNSF) in the MGW

The functionality specified by 3GPP for the RNC and BSC is introduced for the MGWwith the following tasks:

1. NRI masking2. Load balancing and load re-distribution3. Coordination of CS paging (A, Iu or Gs interfaces).

To perform these tasks, RANAP/BSSAP signaling is routed through the MGW. TheMGW analyzes the RANAP and BSSAP messages in order to be able to:

• Receive the NRI value which is embedded in the TMSI and analyze it to find outwhich MSS is dedicated for the transaction. If a valid NRI value cannot be identifiedin the TMSI (for example when the user enters the pool area), the MGW usesweighted round robin to choose the MSS

• Verify that the paging response is sent to the correct MSS for both TMSI and IMSI

pagings





113



Id:0900d805809d6ed0

• If a specific CN node becomes unavailable, the MGW detects the nodes unavailabil-ity

In general, towards the MSSs, the MGW acts in the way that is expected when support-

ing the multipoint concept. Towards the radio network, the MGW acts as if no multipointconcept was in use.

Direct SS7 links between the BSC/RNC and the MSS are not possible. In this configu-ration the MGW is not an SGW/STP but instead, BSSAP/RANAP signaling is terminatedin the MGW. From the perspective of the MGW, there are two separate signaling con-nections for the RAN nodes: one towards the RAN node and one towards the MSS.Combining the separate signaling connections is done at MGW application level.

g The related functionality must be activated in the MSS also. For example, when the RANIndependent Multipoint solution is used, it is necessary to split the MSS allocated Iu Sig-naling Connection Identifier range among the MSSs in the pool area. This is necessaryto prevent the MSSs in pool allocating the same Iu Signaling Connection Identifier forthe signaling connections of an RNC.

For further information, see the document Feature 1778: RAN Independent Multipoint A/Iu support in MGW in M-release Feature Documentation.

Alternative RAN node configurations

Together with the feature RAN Independent Multipoint A/Iu support in MGW, the MGWenables the following RAN node configuration alternatives:

• RAN nodes that are not included in any pool area (for example BSC1 and BSC2 inthe figure RAN Node configuration alternatives below). For these RAN nodes theMGW functions as a Signaling Transfer Point (STP). The RAN node is configured

with the MSS SPCs as the Destination Point Code (DPC). • RAN nodes that support the pool concept and are included in the pool area using

the 3GPP standards based multipoint solution. For these RAN nodes the MGW isworking as an STP. The RAN node is configured with the MSSs SPCs as a DPC.

• RAN nodes that are included to the pool area with feature RAN Independent Multi-point A/Iu support in MGW (for example BSC3 and BSC4 in the figure). For theseRAN nodes the signaling connections are taken up to BSSAP/RANAP applicationlevel for signaling processing in MGW. The RAN nodes are configured with theMGW cluster SPC as the DPC.

These different configuration alternatives are illustrated in the figure RAN Node config -uration alternatives .





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 59 RAN node configuration alternatives

It is possible that more than one of the above configuration alternatives exist simultane-ously in the network, for example, during the migration phase of the configuration ofRAN Independent Multipoint A/Iu support in MGW. Having only one type of poolingsolution in the network is, however, less complex from the perspective of networkplanning and operation.

g A BSC/RNC can be included into an MGW cluster only when it is taken as part of anMSS pool area. This is so because from MSS and MGW aspect BSSAP/RANAP signal-ing handling is fundamentally different in RAN independent multipoint feature and innormal point-to-point A/Iu interface. For BSCs/RNCs that are not yet part of the MSSpool area, the operator has to use MGW as STP for BSSAP/RANAP signaling as in thenormal point-to-point A/Iu interface configurations.

Signaling configuration and SCCP addressing

For the signaling connectivity of RAN Independent Multipoint A/Iu support in MGWfeature, GT addressing is used between the MSS and the MGW interface, and SPCaddressing is used between the MGW and the BSC/RNC interface. The addressingscenario is illustrated in the figure Addressing principle in MGW and MSS for RAN Inde -

pendent Multipoint A/Iu support in MGW .





115



Id:0900d805809d6ed0

Figure 60 Addressing principle in MGW and MSS for RAN Independent Multipoint

A/Iu support in MGWIn the MSS, the RNCs/BSCs are configured using Global Title (GT) addressing. GTanalysis points to the MGW in the MSS and is also used for signaling to the RAN nodes.Between an MSS and MGWs in the MGW cluster, the GT routes towards MGWs consistof primary and secondary routes, and the load is equally shared between the signalingpoints of pool MGWs. The GT analysis in the MGW for RNC/BSC GT addresses pointsdirectly to the MGW and messages are terminated in the MGW application layer. TheMGW itself has a configuration for RNC/BSC GT addresses and the correspondingSPCs. Mapping between the received GT address and the corresponding RNC/BSCSPC is made in the downlink direction.

In the uplink direction when the signaling message is received from BSC/RNC, it is ter-minated in the MGW application layer. In the MGW, selection of an MSS is made usingthe NRI, based on NRI–MSS relationships configured in the MGW. For signalingtowards the MSS, the MSSs GT addresses are configured in the MGW and GT analysisresults points to the corresponding MSS. For resiliency purposes, from the perspectiveof a given MGW there exist two GT routes towards the MSS pool: primary GT route tothe MSS which is indicated by the NRI and secondary GT route towards parallel MSS.GT analysis in the MSS results in the MSS's own point code if the GT address belongsto that MSS, and then the message is terminated in that same MSS.

t For example, in case of 5 MSSs in the pool the secondary GT route provides the follow-ing resiliency scenario:

• MSS2 backs up MSS1 • MSS3 backs up MSS2





Issue 9-0 draft


Id:0900d805809d6ed0


• MSS4 backs up MSS3 • MSS5 backs up MSS4 • MSS1 backs up MSS5

In the RAN nodes, the MGW SPC, (or the MGW clusters SPC when MGW redundancyis used), is configured in the RNC/BSC.

An example configuration is illustrated in the figure Addressing example for RAN Inde - pendent Multipoint A/Iu support in MGW .

Figure 61 Addressing example for RAN Independent Multipoint A/Iu support in MGW

The above example gives an overview of the addressing principles. A more detaileddescription about the configuration for all interface types is given in the documentsFeature 1778: RAN Independent Multipoint A/Iu support in MGW, Feature ActivationManua l in M-release documentation and Integrating MGW into the MSC Server System in U-release documentation.With the A-interface, the BSC is able to use only MGW cluster signaling point codes andfor this reason, the IWF-type of signaling points in MGW are used to build the configu-ration.

For further information about the IWF type of SPCs, see the document Feature 31352: Additional Signaling Point Codes , available in the M-release Feature Documentation.

With Iu-interface over ATM, the RNC must support multiple destination point codes atleast for Application Link Control Application Protocol (ALCAP) routing, which are differ-ent from RANAP destinations. This means that for RANAP signaling the MGW clusterIWF-SPC is used and for ALCAP signaling the PRV-type (Private Virtual) SPCs are

used in the pMGWs.





117



Id:0900d805809d6ed0

With Iu-CS over IP, ALCAP signaling is not used and, therefore, PRV type of signalingpoint codes for this purpose are not needed.

BSCs and RNCs using SIGTRAN, must support multiple SCTP association for each

destination point, to enable MGW redundancy with RAN Independent Multipoint solu-tion.

Functionality example in downlink direction (MSS 1 to RNC 1):

When sending a message in the downlink direction, the MSS 1 packs the target RNC 1GT address (GT 22), a called party address, and its own address (GT 100), a callingparty address, to the SCCP level of the message. The GT address analysis in MSS 1for the called party address points to the MGW.

In the MGW, the GT address analysis of the called party address points to MGW itself.When receiving the message, the MGW unpacks the target RNC GT address from theSCCP level called party address and the corresponding target RNC SPC address (SPC20) is found from the MGW configuration by using the received called party GT address(GT 22).

The message is sent forward to the target RNC using SPC addressing, where the des-tination SPC (DPC) is the target RNC’s SPC (SPC 20) and the originating SPC (OPC)is the MGW’s SPC (SPC 50).

Functionality example in uplink direction (RNC 1 -> MSS 1):

When receiving a message from RNC 1 in the uplink direction, the MGW unpacks theRNC OPC address (SPC 20) from the received message. The corresponding RNC GTaddress (GT 22) can be found from the MGW configuration using the received OPCaddress. After defining the correct target MSS (MSS 1) with the MGW NNSF, the MGWpacks the MSS GT address (GT 200), a called party address, and the RNC GT address(GT 22), the calling party address, to the SCCP level of the message.

The GT address analysis in the MGW to the called party address leads to MSS 1. In theMSS 1, the GT address analysis of the called party address leads to the MSS 1 itself.The application level in the MSS 1 unpacks the sending RNC address (GT 22) from theSCCP level calling party address.

GT address analysis relates to the initiation of connection establishment. Once connec-tion establishment has been initiated, then the subsequent SCCP messages will use thesame route.

MGW resiliency

Multipoint configurations are frequently used as a core network resiliency solution andto provide MGW resiliency. In RAN Independent Multipoint A/Iu support in MGW,avoiding the MGW being a single point of failure is as important as with the other multi-point features. To achieve sufficient core network resiliency, it is possible to route thesignaling from one RAN node through a redundant MGW as illustrated in the figureMGWresiliency solution in RAN Independent Multipoint A/Iu support in MGW .





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 62 MGW resiliency solution in RAN Independent Multipoint A/Iu support inMGW

In the MGW resiliency solution, multiple MGWs may be defined with the same NNSFcapability and the same SPC is shown towards the RNC/BSC. RAN Independent Multi-point A/Iu support in MGW feature enables having more than one MGW in an “MGWcluster” in case the BSC/RNC does not support quasi-associated signaling. This hidesthe SPCs of the individual pMGWs from the BSC/RNC and instead the BSCs/RNCs canbe configured only with the MGW cluster’s SPC.

As far as the maximum number of MGWs in an MGW cluster is concerned, the followingprinciples apply.16 is the maximum number of MGWs per cluster (SPMC) to connectSS7/RANAP/BSSAP between BSC and MGWs/MSS without NNSF in MGW functional-ity, defined by number of SS7 signaling links per signaling link set, per DPC/MSS andper DPC/BSC.4 is the max number of MGWs per MGW cluster together with NNSF in MGW to connectSS7/RANAP/BSSAP between BSC and MGWs, defined by NNSF in MGW functionality.In both cases, the load sharing of SS7/RANAP/BSSAP signaling is equal betweenMGWs of a cluster since there is only one signaling linkset and one DPC betweenMGWs and BSC, assuming that the same number of signaling links are allocated for allMGWs.

However user plane can be connected to any reasonable number of MGWs, defined by

the maximum number of virtual MGWs in MSS User Plane Destination (UPD) configu-





119



Id:0900d805809d6ed0

ration. Especially together with AoIP and/or IuCSoIP, user plane is often connected toall MGWs of an MSS Pool, or to all MGWs of a geographical area. The load sharing ofIP based user plane is controlled by the MSS by virtual MGW weights per User PlaneDestination, configurable by the operator. Usually, equal load sharing is used, unlessremote MGWs are far away, and transmission cost is optimized so that more transmis-sion is available to local MGW(s).

In the RAN Independent Multipoint A/Iu support in MGW feature MGW resiliency solu-tion, the MGWs act in load sharing mode and share the traffic in normal operation. If aMGW fails, all the ongoing transactions through the failed MGW are also lost, however,the transactions can be re-initiated by the redundant MGW(s).

As described earlier in Section MGW–MGW interface , there are situations when signal-ing between the redundant MGWs is required.

• Connection oriented messaging :Once the signaling link through one MGW in the MGW cluster has been selected for

a connection, the subsequent connection oriented messages will use the same sig-naling link. If the signaling link state changes (for example, due to link failure or linkstate change command using MML), the new signaling link may be chosen fromanother MGW in the MGW cluster rather than through the MGW in which signalingwas originally initiated. However, the actual resources handing the connection atMTP, SCCP and application level, are still located in the original MGW. Connectionoriented messages are forwarded from the redundant MGW to the original MGW atMTP level. The original MGW can thus successfully maintain control of the connec-tion.

Another situation when message forwarding between MGWs is need, is when SCCPconnection establishment is started from the MSS direction, for example, because

of a handover. In this situation, the SCCP connection in the uplink direction may beestablished by the RNC/BSC through a different MGW to that established by theMSS to an SCCP in the downlink. This will occur If the RNC/BSC is configured onlywith the MGW cluster SPC and not individual clustered MGWs SPCs and so cannotdifferentiate between the pMGWs in the MGW cluster. In this case, the MGW–MGWinterface and message forwarding at MTP level, ensures that connection related sig-naling can be successfully handled by the original MGW.Some RNCs/BSCs that support quasi-associated signaling may optionally be con-figured with pMGW SPCs instead of MGW cluster SPC only. Prioritization betweensignaling routes towards MGWs may then be utilized. For MGW-MGW interface sig-naling, Base Station System Application Part (BSSAP) signaling is used betweenthe MGWs and thus BSSAP subsystem has to be configured in the MGWs.

• Connectionless messaging :The application layer in the MGW has additional mechanisms to handle the differentconnectionless procedures in a redundant MGW configuration. Such connectionlessprocedures are, for example, BSSAP/RANAP Reset, BSSAP Reset Circuit, BSSAPBlock/Unblock, BSSAP Circuit Group Block/Unblock, BSSAP Unequipped Circuit,RANAP Reset Resource.MGW–MGW signaling is utilized for connectionless signaling procedures. WhenIMSI is used as a subscriber identity in the paging response, MGW-MGW signalingcoordinates the response to the MSS that sent the paging. Also in MSS originatedReset situations, the MGW–MGW interface is used to inform all the redundantMGWs in the MGW cluster to release the connections related to the reset MSS.





Issue 9-0 draft


Id:0900d805809d6ed0


With Iu-interface over ATM, the RNC must support multiple destination point codes for Access Link Control Application Part (ALCAP) routing, which are different from (Radio Access Network Application Part) RANAP destinations.

Signaling connectivity resiliency in an MGW cluster is created by adding to the signalingroute set towards the RAN node, a direct link set from one MGW to the RAN node andan additional redundant link set from the MGW through the redundant MGW(s) in thecluster. This is required for providing resiliency in situations where the direct linksbetween RAN node and one of the clustered MGWs is unavailable. The pre-createdredundant link through another MGW in the cluster can be used for signaling.

The figure Signaling link set configured with RAN independent multipoint for a BSC illus-trates a principle-level example how signaling link sets are configured with RAN inde-pendent multipoint for a BSC.

Figure 63 Signaling link set configured with RAN independent multipoint for a BSC

In this example, one 16-link signaling link set is configured in the BSC so that 8 links witheven SLC values lead to MGW_1 and 8 links with odd SLC values lead to MGW_2. Sucha combined link set is necessary in order to ensure correct node identification forongoing SCCP dialogs (connections).

If there are, for example, additional 16 signaling links as in this example, those can bedivided into two 8-link link sets. One link set leads to MGW_1 with additional SPC PRV1and the other link set leads to MGW_2 with additional SPC PRV2. In the MGW nodes,the type of these additional SP codes is PRV when the link sets are terminated to theBSC SPC.





121



Id:0900d805809d6ed0

The route set in the BSC, in this case, consists of three signaling routes, which sharethe load: through 16-link link set to IWF SPC (MGW_1 & MGW_2), through 8-link linkset to PRV1 (MGW_1) and through 8-link link set to PRV2 (MGW_2).

Overlapping MGW clustersMGW clusters may also overlap as illustrated in the figure Overlapping MGW clusters .

An MGW can belong to more than one cluster. If, however, overlapping pool areas andthe RAN Independent Multipoint solution is implemented, as is illustrated in the figureOverlapping pool areas with RAN Independent Multipoint A/Iu Support in MGW , withMGW clustering, the entire MGW cluster must belong to both (all) MSS pool areas.

Figure 64 Overlapping MGW clusters

User plane connectivity in RAN Independent Multipoint A/Iu support in MGW

User plane connectivity principles for RAN Independent Multipoint A/Iu support in MGWare essentially the same as described in the Section Multipoint A/Iu in MSS Systemarchitecture .

When TDM transport is used at the A-interface, each MSS in the pool area must havededicated CGRs in the RAN Independent Multipoint A/Iu support in MGW solution. Thisis similar to the RAN-based multipoint solution.





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 65 CGR configuration in RAN Independent Multipoint A/lu support in MGW

In the MSS, there are, as a minimum, as many CGRs as there are BSSs. For MGW resil-iency, connectivity through a redundant MGW is needed, which doubles the number ofCGRs from the perspective of the MSS.

In the MGW, it is possible to have an identical CGR configuration as to that in the MSS,or to have a CGR for each use type. This is described in more detail in the Section User

plane connectivity in Multipoint A (over TDM) . In the example, CGRs for each type ofusage are shown (A, B, C, D CGR). In the MGW, as a minimum, as many CGRs areneeded as there are vMGWs.

In principle, there are as many vMGWs in a physical MGW as there are MSSs in the poolarea. If, however, ISU/vMGW capacity is exceeded, more vMGWs for each MSS are

needed, which may require additional CGRs.When configuring the CGRs to the BSCs, the SPC given in the MML commands is theMGW common cluster SPC (in this example SPC=100).

When certain codecs (for example, WB-AMR) are used dedicated circuit pools arerequired and so more CGRs are needed for each BSC. This is explained in more detailin the Section User plane connectivity in Multipoint A (over TDM) .

In the figure Example of CGRs with RAN Independent Multipoint A/Iu support in MGW ,an example of A-interface CGR configuration is illustrated when RAN Independent Mul-tipoint A/Iu support in MGW is in use.





123



Id:0900d805809d6ed0

Figure 66 Example of CGRs with RAN Independent Multipoint A/Iu support in MGWIn the MSS, the SPC given in the CGR configuration is the BSC SPC (SPC 10) and inthe BSC the MGW SPC, or MGW cluster SPC if MGW resiliency is included, is defined.For MGW-MGW interface signaling, BSSAP signaling is used between the MGWs andthus the BSSAP sub-system must be configured in the MGWs.

For RNCs, user plane definitions are configured according to the document User PlaneRouting in M-release product documentation.

Ater interface CGRs with RAN Independent Multipoint A

The MGW Ater feature does not require that a dedicated E1/T1 is allocated for eachCGR/vMGW. A physical Ater E1/T1 can be split to virtual APCMs and these can be allo-cated for different CGRs/VMGWs and pool MSSs. The amount of virtual APCMs per





Issue 9-0 draft


Id:0900d805809d6ed0


E1/T1 depends on the used A-interface circuit pool. In case of a circuit pool where 16k Ater is used, a physical Ater E1/T1 can be divided to a maximum of four APCMs. In caseof circuit pools with 32k Ater, a physical Ater E1/T1 can be divided to two APCMs andwith circuit pools with 64k Ater, one APCM can be used. Also a mixture of these can beused on the same E1/T1.

Compared to the A-interface configuration presented in the previous Section, when Ateris used for the RAN Independent Multipoint solution, there is only one CGR configuredin the BSC and the CICs are unique at pool level. The Ater-based alternative is illus-trated in the figure A/Ater-interface CGRs with the RAN Independent Multipoint Afeature - simplified CGR management in BSCs .

Figure 67 A/Ater-interface CGRs with the RAN Independent Multipoint A feature -simplified CGR management in BSCs

From the BSCs perspective, the MSS Pool is visible as a single Destination Point Codebelonging to multiple MGWs. Therefore, all the BSC circuits are in a single CGR even ifa BSC is connected to multiple physical MGWs and multiple MSSs. When a BSC has asingle CGR, the CICs must be unique on MSS pool level. For example, MSS1 andMSS3 can not have the same CIC value for the same BSC.

Compared to A-interface configuration presented in the previous section, when Ater isused for RAN Independent Multipoint solution, there is only one CGR configured in aBSC and CICs are unique at pool level.

In this configuration, each MSS has circuits from each BSC in a dedicated CGR. Eachvirtual MGW has circuits from all BSCs in a single CGR. Alternatively, CGR manage-ment in the MGW can be the same as in the MSS, a CGR for each BSC.





125



Id:0900d805809d6ed0

For further information about Ater interface configuration, see Integrating MGW into theMSC Server System in U-release documentation and Command Group R2 - Ater Inter-face Configuration Handling in M-release documentation.

For more details regarding RAN Independent Multipoint A/Iu support in MGW, see thedocument RAN Independent A/Iu Multipoint support in MGW , available in the U-releasedocumentation library.

5.4 TDM A interface control in MGW for MSS poolThe optional feature functionality TDM A interface control in MGW for MSS pool simpli-fies the configuration and management of the A interface circuit. The management ofthe A interface is moved from the MSS to the MGW. Circuit sharing and more optimalcircuit utilization are enabled.

This new optional functionality can be activated with a new license.

g Note that the TDM A interface control in MGW for MSS pool functionality is supportedonly for the MGW based on IPA2800. For the Open MGW there is no plan to supportthis feature at the current stage. The feature is supported both the MSS based on DX200and the Open MSS.

Operator benefits

• The TDM A interface control in MGW for MSS pool functionality provides simplifiedcircuit group configuration and circuit sharing inside the same physical MGW(pMGW), and more optimal circuit utilization within the MSS pool concept

• In the event of the failure of a pooled MSS, the remaining pooled MSSs can re-usethe A interface circuits previously used by the failed MSS. Deliberate over-provision-ing of A interface resources is not required anymore.

• Less A interface capacity in the BSC, MGW and TC is required; simplifying configu-ration and maintenance.

• Expanding radio network capacity is simplified. • Less TDM circuit groups are to be maintained. • Adding a new MSS is very simple. The same configuration exists in all MSSs. There

is no effect to BSC configuration.

Currently, when RAN Independent Multipoint A is configured, the operator must creatededicated circuit groups (CGR) between each BSC and MSS. Additionally, a circuitgroup is required for each speech codec pool. This makes the configuration compli-cated, because many small CGRs are needed in the MSS pool. Also, more timeslots areneeded in total because the operator needs to configure spare circuits for each singlecircuit group to avoid overload. Figure Current pool network topology shows the currentnetwork topology in a case where there is a pool of three MSSs and each BSC is single-homed.





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 68 Current pool network topology

With TDM A interface control in the MGW, the configuration of the circuit groups is sim-plified and the use of resources is optimized because only one CGR is needed betweena pMGW and the BSC. This case is illustrated in the figure Network topology with TDMa interface control in the MGW .

Figure 69 Network topology with TDM A interface control in the MGW

Operational aspects

There are some operational aspects that need to be considered regarding the imple-mentation of the TDM A interface control in MGW for an MSS pool functionality.





127



Id:0900d805809d6ed0

• This is an optional functionality and can be activated with a new license. • The TDM A interface control in the MGW for an MSS pool is supported only for the

RAN INdependent Multipoint A feature, which is also a license-based feature (that

is, can be activated with a new license). • New functionality is required to be activated in the MSS. • New functionality is required to be activated in the MGW. Requires a new license. • No specific support is required from RAN nodes or terminals.

5.5 LTE interworking

5.5.1 CSFB interworking

Introduction

The Long Term Evolution (LTE) concept defines a mobile communication system forpacket switched services that is flexible, future-proof and best leverages existingnetwork infrastructure and investments through the CSFB functionality. The Long TermEvolution (LTE) concept incorporates E-UTRAN and the Evolved Packet Core (EPC).The EPC consists of the Mobility Management Entity (MME), the eNodeB, and theSystem Architecture Evolution Gateway (SAE-GW). The SAE-GW is divided into theServing GW and the Packet Data Network (PDN)-GW. The eNodeB performs all theradio network functions currently performed by RNCs/NodeB's in UTRAN. EvolvedUTRAN (E-UTRAN) is a radio access network specification that offers cost effective-ness, speed and efficiency. The CSFB concept introduces the SGs interface betweenthe MME and the MSS. CSFB architecture is illustrated in figure CSFB architecture .

Figure 70 CSFB architecture

User equipment configurations prevent user equipment (UE) from being simultaneouslycamped both on GERAN/UTRAN and E-UTRAN radio networks. 3GPP specifies the CS





Issue 9-0 draft


Id:0900d805809d6ed0


Fallback functionality to ensure seamless voice service and mobility management.With the CS Fallback functionality, the existing CS network deployment (MSS System)can be reused for voice/location/USSD services. When such services are initiated fromor terminated to the UE camped on LTE, the network compels the UE to fall back to theGERAN/UTRAN radio access network where CS procedures are performed. CSservices are then performed in the GERAN/UTRAN radio access network, enablingoperators to provide key revenue generating voice service seamlessly and to usealready deployed CS services for subscribers.

Separate Location Areas

In the CSFB concept with MSS pooling, the separation of different Location Areas (LAs)is a key issue. The basic principle is that if the GSM/UMTS LAs are pooled, then if thesame LA is used for LTE, it shall also be in a pool configuration. However, especially incase of CSFB overlay solution, where the LTE TAs (Tracking Areas) are not pooledbecause LTE access is part of only one of the MSSs' network configuration, it is man-

datory to use separate LAs if GSM and/or UMTS LAs are pooled.For information on a similar scenario where one access type (GSM or UMTS) is pooledand the other is not, see sub-section Dual GSM/UMTS access in Section MSC/MSS

pool planning aspects .

For information on the general aspects of mapping GSM/UMTS LAs to LTE TAs, seeSection Planning LTE and CSFB in the document MSS System Network Planning .

5.5.1.1 CSFB architecture scenarios with MSS PoolingNokia Siemens Networks supports the following MSS Pooling and CSFB interworkingscenarios. These scenarios vary in how many MSSs are provided with CSFB capability

and whether the CSFB-capable MSS is part of the pool area or not. Some scenarios areeasier to implement based on the existing (CS) network infrastructure, however, not a llof these scenarios offer the general benefits of MSS pooling.

The below scenarios are based on the following assumptions:

• In these examples, RAN independent multipoint solution is shown. It is also possibleto use RAN based multipoint solution with CSFB and MSS pooling.

• When the MME has support for MSS pooling, the MME functionality is expected touse IMSI hash algorithm for MSS selection from the pool area. The MME should alsosupport MSS off-loading and MSS failure cases by choosing another MSS from thepool area in these situations (for example, via modification of the IMSI hash algo-rithm).

• When MMEs are pooled, MME Pool support on SGs interface in MSC Server func-tionality is required. Re-attach on SGs during paging (included in CS Fallback Rel11Enhancements functionality) is a pre-requisite for this functionality. In general, thesetwo functionalities provide better end user experience (fast return to E-UTRAN) andmore robust CSFB solution. For further information, see the Feature Descriptiondocument Feature 1914: CS Fallback in EPS for MSS , available in the M-releasedocumentation library.

• As indicated in sub-section Separate Location Areas in the general introduction ofthis section, it is recommended that LTE LAs are different from 2G/3G pool areas.





129



Id:0900d805809d6ed0

Scenario A - CSFB overlay MSS inside the pool

Figure 71 CSFB overlay MSS inside the pool

In this scenario, the CSFB functionality resides in only one of the MSSs (MSS1) in thepool. Therefore, LTE TAs (Tracking Areas) are part of the CSFB-capable MSS's ownradio network configuration. That is, they do not belong to the pool area configuration.From the MMEs, the SGs interfaces exist only to the single CSFB-capable MSS. There-fore, MSS pooling support in the MME is not required.This scenario offers no MSS pooling benefit for LTE subscribers, since if, for example,the CSFB MSS fails, subscribers cannot be served by any other MSS in the pool. Sim-ilarly, off-loading of LTE subscribers is not possible from the CSFB MSS.

NRI validity checking may be used for subscriber balancing in the pool area to reducethe impact of the above mentioned limitations resulting from the concentration of LTEsubscribers to the single CSFB MSS.

For detailed information on the interworking of the LTE overlay solution with MSSpooling, see Section Interworking of LTE overlay solution and MSS pooling .

Scenario B - CSFB overlay MSS outside the pool

Figure 72 CSFB overlay MSS outside the pool - no A/Iu interface





Issue 9-0 draft


Id:0900d805809d6ed0


In this scenario, the CSFB functionality resides in only one MSS, and this single MSS isoutside an MSS pool.

From the MMEs, the SGs interfaces exist only to the single CSFB-capable MSS. There-

fore, MSS pooling support in the MME is not required.This scenario offers no MSS pooling benefit for LTE subscribers, and off-loading of LTEsubscribers is not possible from the CSFB MSS.

g Please note that Pre-MTRF or MTRR feature support is needed to manage call set-upin a different MSS. Also the use of CSMT flag is recommended.

Scenario C - CSFB in every MSS of the pool

Figure 73 CSFB in every MSS of the pool - IMSI hash selection in MME

In this scenario, the CSFB functionality exists in all MSSs of the pool area. Therefore,LTE LAs (TAs) are part of the pool area configuration.

From the MMEs, the SGs interfaces exist to all MSSs in the pool. Consequently, MSSpooling support in the MMEs is required.

This scenario offers the benefits of MSS pooling resiliency for LTE subscribers too. Forexample, if MSS1 fails, LTE subscribers can be served by the other MSSs in the pool.In this scenario, MSS selection is based on IMSI hash among all the MSSs of the pool.

Therefore, local MSS selection based on LA configuration in the MME is not possible.Off-loading of also LTE subscribers (besides 2G/3G subscribers) is possible if the MMEsupports IMSI hash modification when an MSS is set into off-loading mode. For moreinformation on off-loading with Null-NRI, see sub-section MSC/MSS off-loading in a poolwith Null-NRI in Section Off-loading an MSC/MSS in a pool .

5.5.1.2 SGs interface interworking with MSS PoolingIf an LTE User Equipment (UE) performs combined EPS/IMSI (CS) attachment intoEvolved Packet System (EPS), the SGs interface between the Serving Mobility Manage-ment Entity (MME) and the MSS/VLR is used for co-ordinating an LTE UE that is bothLTE-attached and IMSI-attached. The SGs interface functionalities include, for example,paging of the terminal for reception of Mobile Terminated Short Message Service.





131



Id:0900d805809d6ed0

In order to achieve this combined mobility management, an MME-VLR association iscreated by the MME on the SGs interface toward the MSS/VLR when a mobile makesa combined mode EPS/IMSI attach, or a combined TA/LA update through the MME.

Figure 74 SGs interface interworking with MSS pooling

CS and EPS pool areas in an operator’s network are handled independently, however,

the SGs interface creates some dependency between the planning and operation of theCS and the EPS pool areas. When EPS pool areas are introduced to the network, theappropriate MME is first selected by the NAS node selection function (NNSF) in theevolved Node B, based either on:

• the MME value in the Globally Unique Temporary Identity (GUTI) which is indepen-dent of the MSC/MSS NRI value range, or

• the RAN node subscriber distribution function.

When MSSs are in pool configuration and there is more than one MSC/MSS serving therelevant LAI, the MME has to select an MSC/MSS from the MSC/MSS pool to serve thesubscriber during the combined mobility procedure.Typically, this is done with the so called IMSI hash algorithm defined in 3GPP TS 23.236(Intra-domain connection of Radio Access Network (RAN) nodes to multiple CoreNetwork (CN) nodes).If MSSs are not pooled, then the MME performs the selection ofthe MSS serving the relevant LAI based on, for instance, Tracking Area Identity(TAI).With the IMSI hash algorithm [(IMSI div 10) modulo 1000], the MME derives avalue (V) ranged between 0 and 999. Each value (V) corresponds to a specific MSS inthe MSS pool area. Usually, a range of values (V) are allocated to each MSS in the MSSpool area. The MSS selection process during the Combined TA/LA update procedurewhen the SGs interface is used is illustrated in figure MSC/MSS selection duringCombined RA/LA Update procedure when SGs interface is used .





Issue 9-0 draft


Id:0900d805809d6ed0


Figure 75 MSC/MSS selection during Combined RA/LA Update procedure when SGsinterface is used

If Combined TA/LA update procedure, as defined in 3GPP TS 23.272 "Circuit Switched(CS) fallback in Evolved Packet System (EPS); Stage 2" is used, then it takes place inEPS when, for example, the LTE UE attaches to EPS or enters a new TrackingArea(TA).

When an MME supports pooling, the MME makes the MSS selection according to theMME subscriber distribution functionality (for instance, with IMSI hash) and initiates theestablishment of the SGs association towards the selected MSS by sending theLocation Update Request to that MSS.

The selected MSS includes a new TMSI with its NRI value in the Location Update

Accept message and sends it to the MME over the SGs interface. The MME completesthe Tracking Area procedure and responds to the LTE UE with a TA Update Accept or

Attach Accept message containing both the new GUTI and the TMSI. The respectiveMME and MSS NRI values are available in the TMSI/GUTI for later transactions to makethe corresponding CN node selection for the subscriber. The subscriber distributionfunctionality may either be located in the RAN node, or in the MGW when the RAN Inde-pendent Multipoint solution is used.

For more information on the Evolved Packet System (EPS), see Section LTE/SAEnetwork core site solution in the document IP Connectivity in MSS System .

SGs interface resiliency requirement when MSC/MSS pooling is used

When multiple MSSs are configured for a TAI in the MME and the MSSs are in a poolconfiguration, it must be possible to distribute the subscribers between the pooled MSSs





133



Id:0900d805809d6ed0

using the MME when creating the SGs association. Subscriber distribution by the MMEcan be achieved, for example, using the IMSI hash algorithm.The MSS selection mechanism in the MME must also prevent unnecessary MSSchanges for the subscribers.

The MME must provide sufficient resiliency when one or more of the pool area MSSsare unavailable for subscriber distribution to guarantee service availability for thecombined subscribers during MSS failure situations. The MSS selection algorithm in theMME must be modified accordingly in order to select a different pooled MSS to thatwhich is unavailable.

t The SGs interface solution in MSS failure situations may be vendor specific.

If the MME does not support multipoint functionality and the related MSS selection func-tion, only one default MSS from the MSSs serving the related LA can be used forcombined mobility procedures. MSS resiliency is not achieved because MSS pooling is

not possible if the MME does not support multipoint. Similarly, SGs association loadsharing is not possible either. The SGs association has to be updated when an LTE UEchanges VLR or when an LTE UE changes MME. In optimal pool area planning, unnec-essary MSS changes are avoided. Although the EPS and CS pool areas can be definedindependently, from the perspective of network planning and signaling saving, it is ben-eficial if the MME does not need to unnecessarily change the SGs association towardsa new MSS within the same CS pool area when the LTE UE remains in the same MSSservice area. Effective radio network planning reduces the number of unnecessary MSSchanges by, for example, restricting the MME area to that of the CS pool area. The LUmode always changes if the mobile attaches between LTE, 2G and 3G. Similarly, theSGs-association breaks if the mobile makes a CS LU directly to the VLR. For thereasons mentioned above, the SGs interface can be used together with the Multipoint Aand Iu features only if the MME also supports the multipoint functionality and the relatedsubscriber distribution to the pool MSSs. If the SGs interface is used in a network wherethe Multipoint A or Iu feature is planned to be implemented, it is necessary to have mul-tipoint-related subscriber distribution and SGs interface resiliency solution support forMSS failure and subscriber off-loading situations in the MME as well.

SGs interface and MSS off-loading

When the SGs interface is implemented in the network and the operator uses the loadredistribution functionality to off-load one or more MSSs in the pool area, the MSS allo-cates a null-NRI to the TMSI provided to the terminal via SGs interface. However, thisdoes not trigger off-loading of the UE as would be done in case of NMO1 and Combined

RA/LA update. For proper network functionality it must be ensured that the MME's MSSselection mechanism does not re-select the MSS that is being off-loaded for succeedingLocation Update procedures performed via SGs interface. This can be achieved byusing O&M commands to exclude the address of the MSS being off-loaded from theMMEs` MSS selection process. Additionally, the MME is required to modify its IMSI hashtable to reflect the change. If MMEs are also configured in a pool, this change must berepeated in every MME connected to the off-loaded MSS. From the MME's perspective,MSS offloading needs to be performed in the following way.

The MME should scan its SGs associations to identify which LTE UEs must be moved.To force the LTE UEs to move, the MME first should send a Detach Request to the LTEUEs, which triggers the LTE UEs to re-attach to non-EPS service.

When the Combined EPS/IMSI updating with IMSI is received in the MME and the LTEUE is identified as one that must be moved, the MME should perform the MSS selection





Issue 9-0 draft


Id:0900d805809d6ed0


according to the modified IMSI hash table. Therefore, for MSS off-loading with SGsinterface, MME support is required. If MME support does not exist (for example, for IMSIhash table reconfiguration), the offloaded subscriber may be directed back to the sameMSS that is being off-loaded. This would generate an undesirable increase in signalingin the network. In the worst case, the subscriber may not be able to access non-LTEservices at all if the MSS which is off-loaded is excluded from the MME subscriber dis-tribution but there is no SGs resiliency support in the MME to enable another pooledMSS to be chosen. For the reason outlined above, without MME redistribution supportat the SGs interface, MSS off-loading may not result in the desired subscriber distribu-tion in the MSS pool area. Thus, MSS off-loading scenarios must be carefully consid-ered during the network planning phase, taking into account, in particular, the availabilityof MME support for off-loading.

5.5.1.3 Interworking of LTE overlay solution and MSS pooling

In general, the use of pooling improves CSFB behavior, while the probability for VMSSchange during call setup is reduced if the users’ LTE area is mapped to the same poolarea. Basically, the functionality is the same as with one MSS area, but if pooling isused, the pool area is bigger than the area served by one MSS and, therefore, thechange of pool area is less frequent.

The use of pools also gives other deployment possibilities, while the radio access canroute LTE terminals’ signaling sessions to the original MSS inside the pool area.It is also possible to concentrate the LTE support to one MSS or a limited number ofMSSs inside one pool area. This solution is called “Overlay CSFB architecture”. Overlayarchitecture for CSFB is required in order to introduce support for CSFB without causingany significant impact (beyond, for example, routing configurations or charging modifi-

cations) to existing mobile CS core network.Overlay architecture means that a few MSC Servers are introduced in order to provideSGs interface towards EPS. These MSSs providing the SGs interface may even run adifferent software release than that in use within other MSC Servers/MSCs in thenetwork. This means that the SGs interface is centralized for complete CSFB in a waythat is similar to what was originally possible for short message service over LTE/SGsin the first phase. An example of Overlay CSFB architecture is shown in figure OverlayCSFB architecture :





135



Id:0900d805809d6ed0

Figure 76 Overlay CSFB architecture

When the subscriber resides in LTE access (Step 1 in figure Overlay CSFB architec -ture ), the MME performs the location update (LU) to a selected MSS as a result of

combined IMSI/EPS attachment initiated by the terminal. Selection logic for MSS (SGsinterface) is MME-dependent, but it can be based on, for example, mapping of Location

Area (MSS/VLR) from currently used Tracking Area (known by MME). Overlay CSFBarchitecture is fully based on standardized mechanisms.

The MSS acting as the overlay SGs entity in the MSS pool area needs to be configuredwith a radio access configuration that contains those Location Areas that can be usedby those MMEs which are connected to this MSS via SGs. This configuration is achievedby using the existing radio access network configuration management of the MSS. Iflocation areas are not known by the MSS in overlay architecture, then location updatevia SGs interface is rejected.

If location update to the overlay CSFB MSS is performed when the subscriber is residing

in LTE access, overlay CSFB MSS allocates its NRI in the subscriber TMSI. In theexample indicated in figure Overlay CSFB architecture , CSFB MSS NRI = 1. Asdescribed above, this is beneficial because CSFB is provided in a centralized way byone or a limited number of MSSs in the network. Additionally, when CSFB to 2G/3Gaccess is performed (Step 2 in figure Overlay CSFB architecture ), the allocated NRIvalue in TMSI directs the subscriber to the same MSS in the pool area, which improvesthe CSFB behavior by reducing the call establishment time, because the MSS is notchanged during the process.

This also implies that LTE subscribers are concentrated to the overlay CSFB MSS in thepool area also while residing in 2G/3G access. In the starting phase of LTE, the numberof LTE subscribers is likely to be moderate compared to the amount of all subscribers in

the network. However, since the amount is estimated to increase rapidly, this aspect hasto be taken into account when designing CSFB architecture together with MSS pooling.





Issue 9-0 draft


Id:0900d805809d6ed0


It is possible to reduce the subscriber concentration to the overlay CSFB MSS within theMSS pool by using NRI validity checking for the subscribers arriving into the 2G/3Gaccess to achieve the desired subscriber distribution.

5.5.2 SRVCC interworking

5.5.2.1 Single radio voice call continuity (SRVCC)The core network needs to support VoIP capable LTE handsets to continue ongoingvoice calls even when the user moves outside of LTE access coverage area and thevoice call is moved to CS domain using 2G/3G. This 3GPP Rel-8 functionality is calledsingle radio voice call continuity (SRVCC). This functionality enables operators to reuseexisting CS voice infrastructure in areas where LTE is not deployed yet.

SRVCC refers to continuity of the ongoing voice call from LTE PS access to 2G/3G CS

access. The call is anchored in IMS and the UE is capable of transmitting and receivingon only one of those access networks at a time.

The MME makes handover for PS voice bearer towards the MSS over the Sv interfaceand for non-voice bearers towards SGSN over the Gn interface.

5.5.2.2 Sv interface and MSS Pool overviewThe Sv interface is used between the MME and the MSS to support single radio voicecall continuity (SRVCC) from PS access to CS access in areas where PS coverage islimited so that voice service over LTE PS access can be provided and 3G/2G CSnetwork can be used until PS coverage is country wide.

The current 3GPP specifications do not address the Sv interface and MSS Pool inter-working.

However, MSS Pool and Sv interface interworking has to be taken into consideration,because MSS Pool is widely used and also amount of LTE references is rapidly increas-ing.

The following architecture options are possible:

• MSSs in pool including one SRVCC MSS in pool; MME/SGSN not in pool • MSSs in pool where all MSSs are SRVCC capable; MME/SGSN not in pool • MSSs in pool where all MSSs are SRVCC capable; MME/SGSN also in pool • MSSs in pool including one SRVCC MSS in pool; MME/SGSN also in pool





137



Id:0900d805809d6ed0

MSSs in pool including one SRVCC MSS in pool; MME/SGSN not in pool

Figure 77 SRVCC and MSS pooling architecture – MSSs in pool, one SRVCC MSSin pool; MME/SGSN not in pool

In this architecture scenario, the MSSs are in pool configuration. Only one of the MSSshas the SRVCC capability and provides the Sv interface connectivity from the MME.Therefore when the PS to CS handover for SRVCC takes place, the MME contacts theSRVCC capable MSS in the pool area. Since the SRVCC MSS belongs to the pool con-figuration, no further inter-MSS handover is required. During the PS to CS handover,TMSI reallocation is done, during which the NRI of the SRVCC MSS is included in theTMSI. When the UE returns to idle state after the call, the subscriber is routed to thesame MSS for further transactions within 2G/3G access based on the SRVCC capableMSS NRI, or the UE may return to 4G.

Pool area

IMS

SCC AS

2G/3G

LTE

Handover / Relocation

UE

UE

Sv

MSS 3(SRVCC)

MSS 1

MSS 2

MME/SGSN





Issue 9-0 draft


Id:0900d805809d6ed0


MSSs in pool where all MSSs are SRVCC capable; MME/SGSN not in pool

Figure 78 SRVCC and MSS pooling architecture – MSSs in pool, all MSS are SRVCCcapable; MME/SGSN not in pool

In this architecture scenario, all the MSSs in pool have the SRVCC capability and thusprovide the Sv interface connectivity from the MME. It is at the responsibility of the MMEto perform load balancing when the target MSS from the pool area for the PS to CShandover is selected. The functionality during and after the PS to CS handover in thisscenario is the same from the MSS pool viewpoint as in the previous scenario.

Pool area

IMS

SCC AS

2G/3G

LTE


UE

UE

Sv

MSS 1

(SRVCC)

MME/SGSN

Sv

Sv

MSS 2(SRVCC)

MSS 3(SRVCC)





139



Id:0900d805809d6ed0

MSSs in pool where all MSSs are SRVCC capable; MME/SGSN also in pool

Figure 79 SRVCC and MSS pooling architecture – MSSs in pool, all MSS are SRVCCcapable; MME/SGSN also in pool

In this architecture scenario, all the MSSs in pool have the SRVCC capability and thusprovide the Sv interface connectivity from the MME. Also the MMEs are in a pool con-figuration, and a mesh of Sv interface connections is formed between the MME andMSS pools. It is the responsibility of the MMEs in the MME pool to perform load balanc-ing when the target MSS from the MSS pool area for the PS to CS handover is selected.The functionality during and after the PS to CS handover in this scenario is the samefrom the MSS pool viewpoint as in the previous scenarios.

P o o l

a r e a

IMS

SCC AS

2G/3G

LTE


UE

UE

Sv

MSS 1

(SRVCC)

P o o

l a r e a

MME/SGSN 2

MME/SGSN 3

Sv Sv Sv

SvSv

Sv

Sv Sv

MME/SGSN 1

MSS 2(SRVCC)

MSS 3(SRVCC)





Issue 9-0 draft


Id:0900d805809d6ed0


MSSs in pool including one SRVCC MSS in pool; MME/SGSN also in pool

Figure 80 SRVCC and MSS pooling architecture – MSSs in pool, one SRVCC MSSin pool; MME/SGSN also in pool

It is also possible, that both MMEs and MSSs are pooled, but in the MSS pool area onlyone MSS has the SRVCC capability. Thus the SRVCC capable MME provides the Svinterface connectivity from the MMEs of the MME pool area. Therefore when the PS toCS handover for SRVCC takes place, all the MMEs in MME pool contact the SRVCCcapable MSS in the MSS pool area. The functionality during and after the PS to CShandover in this scenario is the same from the MSS pool viewpoint as in the previousscenarios.

5.5.2.3 MSS Pool and Sv interface interworkingLoad distribution/re-distribution related requirements are not included in 3GPP specifi-cations for Sv interface. To enable successful subscriber distribution at the MSS poolarea, load distribution and load re-distribution is required to be done in MME/SGSN alsoat Sv interface.

In other cases, for example, with A/Gb/Iu/Gs/SGs interfaces, when subscribers are allo-cated into the pool area, load distribution is required to be performed by the NNSF.

Load distribution method itself is typically implementation specific, that is, it is notdefined in 3G PP specifications.

An exception is the Gs interface, where IMSI hash based load distribution is defined in3GPP TS 23.236 for SGSN. For MME, the same IMSI hash method is utilized accordingto TS 23.272.

Practical Iu/A/Gb implementations typically make, for example, weighted round robinselection among the available CN nodes, IMSI hash.

P o o l

a r e a

IMS

SCC AS

2G/3G

LTE


UE

UE

Sv

MSS 3(SRVCC)

MSS 1

MSS 2

P o o

l a r e a

MME/SGSN 2

MME/SGSN 3

SvSv

MME/SGSN 1





141



Id:0900d805809d6ed0

3GPP TS 23.236 also defines load re-distribution functionalities. The purpose of load re-distribution is to move subscribers from one CN element within a pool to another, forexample, if one of the CN elements is taken out of use or if the subscriber load needs tobe partially reduced.





Issue 9-0 draft


Id:0900d805809d6ed2

Pooling and Multipoint configuration and management

6 Pooling and Multipoint configuration andmanagementThe preparatory steps for multipoint configuration, management and additional usecases are presented below. The main emphasis is on radio network configuration man-agement in the multipoint network.

For detailed multipoint feature activation and configuration instructions (including theoptional enhancements) in the MSC/MSS, see the feature activation manuals forFeature 1564: Multipoint A Interface and Feature 1449: Multipoint Iu in MSS Concept inM-release Feature documentation. For the optional RAN Independent Multipointsolution activation and configuration instructions, see the feature activation manual forFeature 1778: RAN Independent Multipoint A/iu support in MGW .

Additionally, signaling and user plane network configurations have to be made. See M-release Product Documentation, for example Cellular Radio Network Management ,MSC Server Integration , Routing and Analysis , and Announcements .

For instructions on BSC and RNC configuration, see Activating and Testing BSS20092:Multipoint A Interface in Nokia Siemens Networks GSM/EDGE BSS, BSC and TCSMProduct Documentation and Feature RAN834: Flexible Iu, Feature Activation Manual inWCDMA RAN System Library.

For an overview of SGSN functionality see SGSN Feature Overview in SG-release Doc-umentation. For instructions on SGSN configuration, see Feature SG02002: NokiaSiemens Networks Features SG01023 and SG01075: Multipoint GB and A in SGSNSG-release Product Documentation.

An example configuration is illustrated to provide familiarization with the terms used in

the descriptions. The preparatory steps for a multipoint configuration are described,followed by a number of configuration management use cases.

The preparatory steps are:

• Creating a pool; • Preparing the radio network configuration of primary and secondary MSCs/MSSs

when creating a pool; • Creating a pool when RAN independent multipoint A/Iu support in MGW is used, and

adding secondary MSSs and additional BSCs and RNCs into the configuration.

g A BSC/RNC can be included into an MGW cluster only when it is taken as part of anMSS pool area. This is so because from MSS and MGW aspect BSSAP/RANAP signal-

ing handling is fundamentally different in RAN independent multipoint feature and innormal point-to-point A/Iu interface. For BSCs/RNCs that are not yet part of the MSSpool area, the operator has to use MGW as STP for BSSAP/RANAP signaling as in thenormal point-to-point A/Iu interface configurations.

These preparatory steps are essential for multipoint configuration, and are consideredas prerequisites for the presented configuration management use cases:

• Adding an MSC/MSS with part of its radio network to the MSC/MSS pool; • Adding an MSC/MSS and its whole radio network to the MSC/MSS pool; • Adding a new MSC/MSS to MSC/MSS pool; • Adding an LA, BSC, RNC, BTS, or SA to the MSC/MSS pool;

• Removing an LA, BSC, RNC, BTS, or SA to the MSC/MSS pool;





143



Id:0900d805809d6ed2

• Moving an LA from the MSC/MSS pool into the MSC/MSS own radio network; • Moving a BSC/RNC from the MSC/MSS pool to another MSC/MSS pool; • Managing neighbor MSC/MSS pool areas for pool MSC/MSSs;

• Multipoint feature deactivation.The following pool operability use cases are presented:

• Off-loading a pool MSC/MSS; • On-loading a pool MSC/MSS.

6.1 Configuration exampleHigh level configuration examples where a non-pooled network configuration is modifiedinto a pool area configuration are described here.

For a detailed example of Multipoint A configuration in MSS System, see Section

Building Multipoint Iu and A interfaces in the document Feature Migration for MSS/VLR .The figure, Example of a network without pool areas (non-pooled network) , illustratesnetwork architecture before the multipoint configuration is implemented in the network.

Figure 81 Example of a network without pool areas (non-pooled network)

The multipoint configuration is implemented in the network as illustrated in the figureExample of pool areas in the network.

Figure 82 Example of pool areas in the network

In this example there are 3 groups of MSCs/MSSs.





Issue 9-0 draft


Id:0900d805809d6ed2


• MSC/MSS 1, MSC/MSS 2 and MSC/MSS 3 are parallel MSCs/MSSs because theybelong to the same pool area. After the configuration has been completed, they willhave the same radio configuration. One of these MSCs/MSSs is selected as theprimary MSC/MSS, and all those not the primary are secondary MSCs/MSSs. Theprimary MSC/MSS is the one from which the radio configuration will be exported tothe secondary MSCs/MSSs.

• The same applies to MSC/MSS 4, MSC/MSS 5, and MSC/MSS 6.• MSC/MSS 7 does not support the multipoint feature and, therefore, is not part of a

pool area.

The network consists of two pool areas (CS pool area 1 and CS pool area 2) where bothpool areas contain 4 RAN areas. CS pool area 1 and CS pool area 2 also overlap at RAN

Area 2 and RAN Area 6, to form an overlapping pool area.

The configuration is different for each MSC/MSS group as shown in the table Pool areaconfiguration.

One MSC/MSS in the pool area is defined as the primary MSC/MSS, and it must containthe master radio network configuration for the pool area. The pool also contains one ormore secondary MSC/MSSs. The pool area configuration in the secondary MSC/MSSsmust conform to that of the primary MSC/MSS.

The primary and secondary MSC/MSS concepts are used to avoid conflicts between thepool MSC/MSS configurations. Configuration transfer between the primary MSC/MSSand the secondary MSCs/MSSs is allowed, but configuration transfer between the sec-

ondary MSCs/MSSs is not.Pool area configurations can be modified either manually, or by using the export andimport procedures. The most convenient method depends on the number of changesand the existing pool configuration. When export/import is initiated, the sequence ofexport and import in the pooled MSCs/MSSs depends upon the specific pool area con-figuration management use case in question.

To make the configuration of parallel pool MSCs/MSSs easier, a transfer file can beused during the export/import procedure. The NCPFIL is a diskfile that is used for trans-ferring the GSM and UMTS-related radio network configuration between theMSCs/MSSs. Only the radio network configuration data (including BSC, RNC, LA, SAI,Cell Identifier, Network LA, Auxiliary LA) is transferred.

MSC/MSS 1,MSC/MSS 2, andMSC/MSS 3

MSC/MSS 4,MSC/MSS 5, andMSC/MSS 6

MSC/MSS 7

Pool Area CS pool area 1 CS pool area 2 Not applicable

Own LA Area 1, Area 2, Area 5, Area 6

Area 2, Area 3, Area 6, Area 7

Area 4, Area 8

Neighbor Pool Area CS pool area 2 CS pool area 1 Not applicable

Network LA Area 3, Area 7 Area 1, Area 5 Area 3, Area 7

Network LA (does not

belong to any poolarea)

Area 4, Area 8 Area 4, Area 8 Not applicable

Table 7 Pool area configuration





145



Id:0900d805809d6ed2

Export/import procedure

• Export :Copies the marked pool area radio network configuration data from an MSC/MSS

into transfer files, which will then be imported to the primary or the secondary pooledMSC/MSS.

• Import :Copies the pool area radio network configuration data from the transfer files intotemporary files. The temporary files automatically contain the non-pool area radionetwork configuration of the MSC/MSS where import is executed. Thus, thecomplete temporary file content includes both the MSC/MSS-specific non-pooledradio network configuration and the imported pool area radio network configuration.

• Activate: Activates the new radio network configuration based on the temporary files whichwere created during import phase in the MSC/MSS. A system reset is not required

for activation.

g After using the export/import procedure, the imported radio network configuration mustbe activated before making any additional changes to the radio network configuration. Ifchanges are made before activation, there can be serious discrepancies in the radionetwork configuration.

g All sequential imports of data to the primary MSC/MSS must be executed successfully.If an error occurs, the root cause must be solved and the sequential import procedurere-started from the first step.

The import and export procedures are explained step by step in Section Pooling andMultipoint import/export procedure .

If a large pool area radio network configuration is created, it is difficult to remove all thedefinitions if the pool area configuration is dismantled. Creating backups of the systembefore the configuration of the pool area is recommended. It is simpler to revert back tothe configuration before the pool area concept was activated than to dismantle anexisting pool area configuration.

As described in Section TMSI re-allocation, before the feature is activated in the RANnodes, ideally, all the subscribers have an NRI value allocated as part of the TMSI. Thisavoids unnecessary subscriber distribution within the pool area due to an unknown NRI.When the multipoint configuration is activated in the RAN nodes, the subscribers thatare served by a particular RAN service area will initially be directed to the MSC/MSS thathas allocated the TMSI with the NRI value.

In the initial phase of the activation of Multipoint A configuration, the A-interface CGRconfiguration has to be built to support the subscriber distribution based on earlier BSCservice areas (almost all subscribers within the BSC are directed to the same MSS geo-graphically). The A-interface resources towards the pool area MSCs/MSSs must beconfigured according to how the subscribers should be distributed among theMSCs/MSSs. This ensures that there are sufficient resources available when the poolarea load is balanced over time to achieve the required distribution of subscribers.

When Feature 1778: RAN Independent Multipoint A/Iu support in MGW is used, thesame MSS radio network configuration is used as in the RAN node-based multipointsolution. The user plane configuration, including A-interface circuit management, is also

similar to the RAN node based multipoint solution. In addition, GT addressing is definedboth in the MSS and the MGW in this configuration.





Issue 9-0 draft


Id:0900d805809d6ed2


GT addressing is described in the Section Signaling configuration and SCCP address -ing . Subscriber distribution functionality related MGW configurations are described inIntegrating MGW into the MSC Server System and Configuration Data Management inMGW in U-release documentation.

6.2 Preparatory steps for multipoint configurationThe preparatory steps are a prerequisite for the multipoint configuration managementuse cases.

g The export and import procedures also handle the default MSC/MSS configurationsautomatically when appropriately selected into the configuration.

Creating a pool

The creation of an MSC/MSS pool requires careful planning.

It is recommended that all LAs that are planned to be included in the pool area are con-figured to the MSCs/MSSs as soon as possible. This is important so as not to overloadthe pooled MSCs/MSSs.

Network Resource Identifiers (NRI) should be configured in the MSCs/MSSs in advanceof the feature being taken into use, that is, before the BSC/RNC starts to distribute sub-scribers according to the NRI. The MSC/MSS starts to allocate the NRI to the TMSIwhen the NRIs are configured. There will, therefore, already be a population of subscrib-ers with a valid NRI in the TMSI when the feature is taken into use.

g Nokia Siemens Networks Multipoint Configuration Assistant simplifies the creation ofpools and multipoint configuration. For further information see the Section NetAct

support for multipoint features .In this use case, illustrated in the figure Creating a pool, a pool area configuration doesnot exist and the target is to include the MSS1 and MSS2 into the pool area (with at leastpart of their radio network). In the Section Pooling and Multipoint configuration manage -ment use cases , further use cases are outlined for adding elements into the pool area.





147



Id:0900d805809d6ed2

Figure 83 Creating a pool

The steps for creating a pool are as follows:1. Check that Feature 1449: Multipoint Iu or Feature 1564: Multipoint A has been acti-

vated. For Feature 1449 and Feature 1564 activation, see the related Feature Acti-vation Manuals in Nokia Siemens Networks M-release Documentation.

2. Determine the NRI length based on, for example, the number of pool MSCs/MSSsand the number of NRIs for each MSS, as explained in the Section NRI planning andmanagement . Considering future expansion is recommended.

3. Configurations in each pool MSCs/MSSs, including pool NRIs and neighboring poolNRIs, are completed. After the NRIs have been created, the VLR starts to includethe NRI value in the TMSI allocation process. The parameters can also be createdusing Nokia Siemens Networks NetAct.

4. Create MGW routing and signaling data for the pool area.5. Configure the pool LAs in each MSC/MSS. All LAs that have a relationship with a

certain RAN nodes must be exported into the pool at the same time because it is notpermissible for only parts of LAs to be inside the pool area concept.Use LAC analysis to check that the selected radio network configuration is suitablefor the pool.

g It may be necessary to make adjustments to the configuration based on this analy-sis. For example, it is recommended that different LACs are used for GSM andUMTS accesses.

It is also possible to create the LAs and add these into the pool using NetAct.





Issue 9-0 draft


Id:0900d805809d6ed2


g The default MSC/MSS configurations are automatically exported. This way thedefault MSC/MSS will be the MSC/MSS which in a non-pooled architecture hadbeen the neighboring MSC/MSS handling the related LA.

This automatic default MSC/MSS export (when appropriately selected into the con-figuration) also avoids load concentration on one pool area MSC/MSS node, see theSection Default MSC/MSS .

6. Export the RNC/BSC radio network data configuration from all the MSCs/MSSs into the primary MSC/MSS. The duration of the export and import process dependson the size of the radio network, but typically it takes less than one hour.

Preparing the radio network configuration of the primary and the secondaryMSCs/MSSs when creating a pool

The pool configuration of the primary MSC/MSS will first be collected into a temporaryfile. The temporary file also contains the radio network for areas that will not belong to

the pool area.The existing radio network in the primary MSC/MSS must also first be exported andimported to the temporary files. This step is vital in the pool area configuration copyprocess. If the radio network of the primary MSC/MSS is not exported and imported backto the primary MSC/MSS first, all the radio networks that have been defined in the poolarea configuration are removed from the pool area configuration when the new config-uration is activated.





149



Id:0900d805809d6ed2

Figure 84 Preparing the primary MSC/MSS radio network

The steps for preparing the primary MSC/MSS radio network are:

1. Import the radio network configuration back to the temporary files of the primaryMSC/MSS.

2. Import the radio network configuration of one, or more, secondary MSC/MSSs to thetemporary files of the primary MSC/MSS.

3. Activate the configuration.

g All the new objects (not in the current configuration of the MSC/MSS) will still be ina locked state after the activation.

During this phase, the configuration can be interrogated using MML commands.4. Add the remaining user plane and control plane definitions for the added radio

network configuration. Check that, for example, emergency call routing definitionsare correctly set up in the pool.

5. Unlock the added radio network objects in the MSC/MSS. It is also possible tounlock the objects using NetAct.

6.Export the configuration of the primary MSC/MSS and import it to the secondaryMSSs.





Issue 9-0 draft


Id:0900d805809d6ed2


g Execute steps 2-5 in every secondary MSC/MSS.

7. Ensure that the necessary configuration in the BSCs/RNCs has been created includ-ing the routing information in the NAS Node Selection Function (NNSF), and activatethe NNSF in the BSCs/RNCs.

Creating a pool when RAN Independent Multipoint A/Iu support in MGW is used–primary MSS

This process is relevant only when Feature 1778: RAN Independent Multipoint A/Iusupport in MGW is used.

g Nokia Siemens Networks Multipoint Configuration Assistant simplifies the creation ofpools and multipoint configuration. For further information, see the Section NetActsupport for multipoint features .

In the example, a multipoint configuration with RAN Independent Multipoint A/Iu supportin MGW feature, as shown in the figure Creating a pool when RAN independent Multi-point A/Iu support in MGW is used–primary MSS, is implemented in what was originallya non-pooled network. An example of a non-pooled network is shown in the figureExample of a network without pool areas (non-pooled network) .

In some non-pooled network implementations, signaling connectivity is already enabledthrough two MGWs for resiliency, but there are also non-pooled networks where signal-ing is through only one MGW. The same approach is possible also with the RAN inde-pendent multipoint A/Iu support in MGW feature. It is possible to use more than oneMGW in an MGW cluster to provide MGW resiliency. Alternatively, it is possible that onlyone MGW is used in the configuration. If MGW level resiliency is not required in thenetwork, the MGW resiliency related steps in the description below are not relevant.

When MGW resiliency is implemented in the network, it is recommended that signalinglinks and user plane routes are split between the (two or more) MGWs that will be theredundant MGWs before the configuration of RAN Independent Multipoint A/Iu supportin MGW is started. This preparatory step is required so that the necessary configurationsare available. The signaling links and user plane routes through redundant MGW are notin use until they are activated.

For further information about control and user plane routing, see User Plane Routing aswell as Control Plane Routing documents in M-release Product Documentation.

When implementing the pool configuration, the import/export procedure may be utilizedfor radio network configuration handling as described earlier in this document, but themigration towards RAN independent multipoint A/Iu support in MGW can also be donein smaller steps. The minimum is that the BSCs/RNCs that belong to one LA aremigrated, as illustrated in the figure Creating a pool when RAN Independent Multipoint

A/Iu support in MGW is used–primary MSS.





151



Id:0900d805809d6ed2

Figure 85 Creating a pool when RAN Independent Multipoint A/Iu support in MGW isused–primary MSS

The steps for the preparation of the primary MSS are:

1. Check that Feature 1449: Multipoint Iu or Feature 1564: Multipoint A has been acti-vated in the MSS, and Feature 1778: RAN Independent Multipoint A/Iu support inMGW has been activated both in the MSS and the MGW. For further information

about FN1449, FN1564 and FN1778 activation, see the related Feature ActivationManuals in M-release Documentation as well as Integrating MGW into the MSCServer System and Configuration Data Management in MGW in U-release docu-mentation.

2. Prepare the radio network configuration in the primary MSS for pool configuration asdescribed above in Creating a pool and Preparing the radio network configuration of

primary and secondary MSCs/MSSs when creating a pool . Create the GT analysisin the MSS for the BSCs/RNCs so that the addresses point to the MGW. For theRNCs, create the unique Iu signaling connection identifier range for each MSS.Create the alternative GT addressing for the BSCs/RNCs in the MSS through theredundant MGW.

3.In the MGW, create the configuration for RAN Independent Multipoint A/Iu supportin MGW feature including, for example, addressing for BSCs/RNCs and NRI config-





Issue 9-0 draft


Id:0900d805809d6ed2


uration for the MSSs as described in U-release documentation MGW and Configu-ration Data Management in MGW . In the case of Iu-CS over ATM, it is possible tocreate in this phase the PRV-SPC/MIRAGE-SPC type of SPC configuration for

ALCAP signaling.For further information, see Feature Additional Signaling Point Codes and Integrat-ing MGW into the MSC Server System in U-release documentation.

4. Set the BSCs/RNCs into locked state in the MSS. If possible, prevent traffic throughthe BSC/RNC in the BSC/RNC.

5. Modify the MSS BSCs/RNCs addressing from the previously used SPC addressingto GT addressing.

6. Modify, in the BSCs/RNCs, the SPC address to point to the MGW cluster SPC,instead of the MSS SPC address. In the BSC, modify the user plane route addressto point towards the MGW cluster SPC. Also, make the necessary modifications foruser plane configuration in both the RNC and in the MGW. In the RNC the earlierconfigured MGW PRV-type SPC is used for ALCAP and in the MGW MIRAGE-typeSPC is used.

7. Activate the new BSSAP links for the A-interface and/or RANAP and ALCAP linksfor Iu-CS over ATM. Create the IWF-SPC for RANAP/BSSAP signaling.

8. Unlock the BSCs/RNCs in the MSS. Allow traffic through the BSC/RNC in theBSC/RNC.

9. For the redundant MGW, repeat step 3. Create the MGW-MGW interface asdescribed in U-release documentation Integrating MGW into the MSC ServerSystem and Configuration Data Management in MGW .

Adding a secondary MSSs into the configuration when RAN Independent Multi-point A/Iu support in MGW is used

This process description is relevant only when Feature 1778: RAN Independent Multi-point A/Iu support in MGW is used.

In this step, secondary MSSs are added into the configuration to form the MSS poolwhich shares pool area traffic.

The user plane configuration in RAN Independent Multipoint A/Iu support in the MGWutilizes the same principles as are presented in the Section Pooling and Multipoint con -figuration and connectivity guidelines .





153



Id:0900d805809d6ed2

Figure 86 Adding secondary MSSs into the configuration when RAN IndependentMultipoint A/Iu support in MGW is used

The steps for the adding secondary MSSs are as follows:

1. Prepare the radio network configuration in the secondary MSSs for pool configura-tion as described in Creating a pool and Preparing the primary MSC/MSS radionetwork . Create the GT analysis in the secondary MSSs for BSCs/RNCs so thatthey point to the MGWs, as was done earlier in the primary MSS;

2. Set the BSCs/RNCs into locked state in the secondary MSSs and prevent traffic inthe BSCs/RNCs if possible. If the import/export procedures were used in step 1, thenew objects will, by default, be in locked state in the MSS.

3. Modify the BSC/RNC addressing in the secondary MSSs from SPC addressing toGT addressing;

4. Add the NRI configuration for the secondary MSSs in the MGWs to distribute thetraffic among the MSSs;

5. Unlock the BSCs/RNCs in the secondary MSSs and allow traffic also in theBSCs/RNCs if these were locked in step 2.





Issue 9-0 draft


Id:0900d805809d6ed2


Adding a BSC or an RNC in the MSS pool when RAN Independent Multipoint A/Iusupport in MGW is used

This process description is relevant only when Feature 1778: RAN Independent Multi-

point A/Iu support in MGW is used.

Figure 87 Adding BSC or RNC into the configuration when RAN Independent Multi-point A/Iu support in MGW is used

The steps for adding BSC or RNC are as follows:

1. Configure the new BSC or RNC that is to be added to the primary MSC/MSS. Ifexport/import is used, only the unlocked radio network elements are exported. Usethe export procedure to generate the radio network configuration transfer files in theprimary MSS. Import the configuration from the primary MSS to the secondaryMSSs.

2. Set the BSC/RNC into locked state in the MSS. Modify the BSC/RNC addressing inthe MSS to use GT addressing. Add the user plane and control plane definitions forthe added radio network configuration, for example, the vMGWs.

3. Ensure that the necessary configuration for the new BSC/RNC has been created,including the routing information in the MGW.

4. Activate the imported radio network configuration in the secondary MSSs and unlockthe added radio network objects. Allow traffic through the added BSC/RNC.





155



Id:0900d805809d6ed2

6.3 Pooling and Multipoint configuration management usecasesThe following use cases are presented for the RAN node based Multipoint solution:

6.3.1 Adding an MSC/MSS with its whole radio network to the MSC/MSSpoolIn this example, a new MSC/MSS with its whole radio network (all location areas) istransferred to the existing pool. One pool MSC/MSS is defined as the primaryMSC/MSS, the remainder are secondary MSCs/MSSs.

Figure 88 Adding an MSC/MSS with its whole radio network to the MSC/MSS pool

The steps for adding an MSC/MSS with its whole radio network to the pool are:





Issue 9-0 draft


Id:0900d805809d6ed2


1. Prepare the primary MSC/MSS radio network as a basis for importing the poolareas. Export and then import the primary MSC/MSS configuration so that theexisting pool configuration is preserved.For more information, see Preparing the radio network configuration of primary andsecondary MSCs/MSSs when creating a pool .

2. Select all LACs in the new secondary MSC/MSS and export the configuration. It isalso possible to add LAs into the pool using NetAct.

3. Import the added secondary MSC/MSS radio network configuration to the temporaryfiles of the primary MSC/MSS.


g The new objects (not in the current configuration of the MSC/MSS) will still be in alocked state after activation.

During this phase, the configuration can be interrogated using the normal MML com-

mands.5. Add the remaining user plane and control plane definitions for the added radio

network configuration, for example, the vMGWs. Check that, for example, the defi-nitions for emergency call routing are correctly configured in the pool.

6. Unlock the added radio network objects. It is also possible to unlock the objectsusing NetAct.

7. Export the configuration of the primary MSC/MSS and import it to the secondaryMSCs/MSSs.

g Execute steps 4-6 in every secondary MSC/MSS and the related MGWs.

8. Ensure that the necessary configuration in the new BSCs/RNCs that are added tothe pool area has been created including the routing information in the NAS NodeSelection Function (NNSF), and activate the NNSF in the BSCs/RNCs.

9. In the BSCs/RNCs that have already previously been included in the pool area, addthe new NRI values into the NNSF.

6.3.2 Adding an MSC/MSS with part of its radio network to the MSC/MSSpoolIn this example, a new MSC/MSS is transferred to the pool with part of its radio network(selected location areas).





157



Id:0900d805809d6ed2

Figure 89 Adding an MSC/MSS with part of its radio network to the MSC/MSS pool.

The steps for adding an MSC/MSS with part of the radio network are as follows:

1. Prepare the primary MSC/MSS radio network as a basis for importing the poolareas.For more information, see Preparing the radio network configuration of primary andsecondary MSCs/MSSs when creating a pool .

2. Select the LACs in the secondary MSC/MSS that will be included in the pool andexport the configuration. It is also possible to add LAs into pool using NetAct.

3. Import the added secondary MSC/MSS radio network configuration back to the tem-porary files of the primary MSC/MSS.


g The new objects (not in the current configuration of the MSC/MSS) will still be in alocked state after the activation.

During this phase, the configuration can be interrogated using the normal MML com-mands.

5. Add the remaining user plane and control plane definitions for the added radionetwork configuration, for example, the vMGWs. Ensure that the definitions foremergency call routing are correctly configured in the pool.





Issue 9-0 draft


Id:0900d805809d6ed2


6. Unlock the added radio network objects. It is also possible to unlock the objectsusing NetAct.

7. Export the configuration for the secondary MSCs/MSSs from the primary MSC/MSS

and import it to the secondary MSCs/MSSs.

g Execute steps 4-6 in every secondary MSC/MSS and the related MGWs.

8. Ensure that the necessary configuration in the new BSCs/RNCs that are added tothe pool area has been created including the routing information in the NNSF, andactivate the NNSF in the BSCs/RNCs.

9. In the BSCs/RNCs that have already previously been included in the pool area, addthe new NRI values into the NNSF.

6.3.3 Adding a new MSC/MSS to the MSC/MSS pool

In this case, a new MSC/MSS without an existing radio network is added to the pool.

Figure 90 Adding a new MSC/MSS to the MSC/MSS pool.

The steps for adding new MSC/MSS are as follows:





159



Id:0900d805809d6ed2

1. Export the primary MSC/MSS radio network configuration and import the configura-tion from the primary MSC/MSS to the new secondary MSC/MSS.


g The objects will still be in a locked state after the activation.

During this phase, the configuration can be interrogated using MML commands.3. Add the remaining user plane and control plane definitions for the added radio

network configuration, for example, the vMGWs. Check that, for example, the defi-nitions for emergency call routing are correctly configured in the pool.

4. Unlock the added radio network objects in the new MSC/MSS. It is also possible tounlock the objects using NetAct.

5. Add the new NRI values into the NNSF in the BSCs/RNCs in the pool area.

6.3.4 Adding an LA, BSC, RNC, BTS or SA to the MSC/MSS pool An LA, BSC, RNC, BTS or SA can be added to the pool manually, or by using the exportand import procedures. If only a few elements are to be added this can be done manu-ally. If many LAs, BSCs, RNCs, BTSs or SAs are added to the pool, it is better to usethe export and import procedures. In this example, the new LA5/RAN5 is added.

g When a pool area configuration is created and/or changed, for example, by adding aRAN node, there may be handover disturbances when configuring the network locationareas in the parallel MSCs/MSSs.





Issue 9-0 draft


Id:0900d805809d6ed2


Figure 91 Adding LA, BSC, RNC, BTS or SA to the MSC/MSS pool

The steps for adding an LA, BSC, RNC, BTS or SA to pool are as follows:

1. Configure the LA, BSC, RNC, BTS or SA in the primary MSC/MSS. It is also possibleto configure these using NetAct. Only the unlocked radio network elements areexported in step 2.

2. Use the export procedure to generate the radio network configuration transfer filesin the primary MSC/MSS.

3. Import the configuration from the primary MSC/MSS.4. Activate the imported radio network configuration in the secondary MSCs/MSSs and

unlock the added radio network objects. It is also possible to unlock the objectsusing NetAct.

5. Add the remaining user plane and control plane definitions for the added radionetwork configuration, for example, the vMGWs. Check that, for example, the defi-nitions for emergency call routing are correctly configured in the pool.





161



Id:0900d805809d6ed2

6. Ensure that the necessary configuration in the new or modified BSCs/RNCs hasbeen created including the routing information in the NNSF, and activate the NNSFin the BSCs/RNCs.

If, for example, an existing non-pooled BSC/RNC is to be included into the pool areafrom within an MSC/MSSs own radio network configuration, the process is different ifthe BSC/RNC originally belonged to the primary MSC/MSS own radio network configu-ration or to the secondary MSC/MSS radio network configuration. If the BSC/RNC wasin the primary MSC/MSS radio network configuration, then the process follow the aboveuse case from step 2 onwards. If the BSC/RNC was in secondary MSC/MSS radionetwork configuration, then the BSC/RNC configuration is exported/imported to theprimary MSC/MSS first and after that it is then imported to the other secondaryMSCs/MSSs.

g Exporting to the originating secondary MSS is not required because the BSC/RNC con-figuration already exists there.

6.3.5 Removing an LA, BSC, RNC, BTS or SA from the MSC/MSS pool A BSC, RNC, BTS or SA can be removed from the pool manually, or by using the exportand import procedures. When an LA (including BSCs/RNCs) is to be removed, this hasto be done manually in each pooled MSS. Removing a few elements can also be donemanually. If many BSCs, RNCs, BTSs or SAs are removed from the pool, it is better touse the export and import procedures. In this example, RAN5 is removed.





Issue 9-0 draft


Id:0900d805809d6ed2


Figure 92 Removing a BSC, RNC, BTS or SA to the MSC/MSS poolThe steps for removing a BSC, RNC, BTS or SA from a pool are as follows:

1. Deactivate the BSC/RNC or BTS/SA that will be removed from the pool area.2. Lock the object in the MSC/MSS. It is also possible to unlock the object using

NetAct.3. Remove the BSC, RNC, BTS or SA in the primary MSC/MSS. It is also possible to

remove these using NetAct. The related vMGW configurations are also removed.4. Remove the existing temporary files and import the new configuration from the

primary MSC/MSS.5. Activate the imported radio network configuration in the secondary MSCs/MSSs.





163



Id:0900d805809d6ed2

6.3.6 Moving an LA from the MSC/MSS pool into the MSC’s/MSS’s ownradio network

An LA can be removed from the pool area concept and into an MSC’s/MSS’s non-pooled

radio network configuration. In this example, LA5 is moved out of the pool area andincluded in the MSS3 own radio network.

Figure 93 Moving an LA from the MSC/MSS pool into the MSC/MSS own radionetwork

The steps for moving an LA from the pool to the MSC’s/MSS’s own, non-pooled, radionetwork configuration are as follows:

1. Select the LA to be moved and decide to which MSC/MSS radio network it will bemoved into.

2. Change the NNSF configuration in the BSC/RNC related to the LA to be removed

from the pool area so that only the chosen MSC/MSS can be selected.3. Lock the LA-related objects in all MSCs/MSSs, except in the MSC/MSS that was

chosen. It is also possible to lock the objects using NetAct.4. Change the LA status as 'included in the pool' = 'no' in all the MSC/MSSs. The status

can also be changed using NetAct.5. Manually remove the LA with all its radio network configuration from the primary and

the secondary MSC/MSS except from the one that was selected to host the LA. It isalso possible to remove the LA using NetAct.

6. Ensure that the neighboring LA definitions are correctly set in the pooled MSC/MSSsfor the LA that has been moved and that the related vMGW configurations are alsoremoved. In the figure Moving LA from the MSC/MSS pool into the MSC/MSS own

radio network, the orange dotted lines represent the connections that will beremoved. The related vMGW configurations are also removed.





Issue 9-0 draft


Id:0900d805809d6ed2


7. Make a final check that the neighboring LA definitions are correctly set.

6.3.7 Moving a BSC/RNC from the MSC/MSS pool to another MSC/MSSpool

A BSC/RNC can be moved from one pool to another pool. It is recommended that thechange is made first in the primary MSC/MSS.

This procedure consists of adding the BSC/RNC in the new pool and removing it fromthe old pool.

g The related LAC(s) cannot be divided between two pool areas, the LAC(s) must belongto only one pool area.

The steps for moving the BSC/RNC from one pool to another pool are:

1. Configure the BSC/RNC to the new pool. It is also possible to configure the BSCusing NetAct.

2. Deactivate the BSC/RNC.3. Lock the BSC/RNC in the old MSC/MSS. It is also possible to lock the BSC/RNC

using NetAct.4. Remove the BSC/RNC from the old pool. It is also possible to remove the BSC using

NetAct.5. In the new pool, export the radio network configuration in the primary MSC/MSS and

import the configuration in all secondary MSC/MSSs. Activate the configuration inthe MSC/MSSs.

6. Ensure that the necessary configuration in the BSC/RNC that is moved to anotherpool area has been created including the routing information in NNSF, and activatethe NNSF in the BSCs/RNCs.

7. In the old pool, export the radio network configuration in the primary MSC/MSS andimport the configuration in all secondary MSCs/MSSs. Activate the configuration inthe MSCs/MSSs.

6.3.8 Managing neighbor MSC/MSS pool areas for pool MSCs/MSSsYou can add and remove a neighboring MSC/MSS for the pool MSCs/MSSs, or add anLA in a neighboring pool area.

The new neighboring LAC has to be added into all pool MSCs/MSSs.

The steps for managing neighbor MSC/MSS pool areas for MSCs/MSSs in the pool areas follows:

1. Check that the network (neighboring) LA definitions are correctly set in the primaryMSC/MSS. If changes are needed, the following must be done after the changeshave been completed: export the configurations from the primary MSC/MSS, importthe configuration to the secondary MSCs/MSSs, and activate the configuration inthe secondary MSCs/MSSs. It is also possible to manage the LA configuration usingNetAct.

2. Define the neighbor pool area and neighbor LA relations in all MSCs/MSSs.

g During the pool area migration phase, temporarily defining Network LACs for theMSCs/MSSs within pool area maybe required. This must be done manually, because





165



Id:0900d805809d6ed2

from the perspective of export/import pooled Network LAC parameters relate to neigh-boring LACs over the border of the pool area.

6.3.9 Multipoint feature deactivationThe deactivation of multipoint features requires removing the pool area-related configu-ration in the MSCs/MSSs (and in the MGWs when RAN Independent Multipoint A/Iusupport in MGW is used). The removal procedure is essentially the same steps but inreverse order. Removal also means that all radio network configurations and signalingconnections have to be reconfigured back to the same configuration as before the poolarea concept configuration was implemented in the network. During the reconfigurationthe MSCs/MSSs capability to handle traffic can be affected.

If a large pool area radio network configuration has been made, it is difficult to removeall the related definitions. Therefore, making backups of the system before the configu-ration of the pool area is recommended. It is then simpler to revert to the situation beforethe activation of the pool area concept.

g If backups are used for reverting to the old non-pool configuration, system restarts arerequired.

Subscriber authentication and ciphering settings

The authentication and ciphering settings are set back to the settings which were activebefore the pool concept activation. Depending on the original configuration it is possiblethat no modifications are needed.

TMSI allocation settings

The TMSI allocation settings do not need any modifications, because it is recommendedto use the earlier defined TMSI allocation methods regardless of the use of the poolconcept.

6.4 Pool operability use cases

6.4.1 Off-loading an MSC/MSS in a poolThe following cases of off-loading an MSC/MSS in a pool are introduced:

• MSC/MSS off-loading in a pool with Null-NRI; • MSC/MSS off-loading in a pool using MSC/MSS controlled load redistribution;

t In the above two cases, it is alternatively possible to initiate the subscriber off-loading from indicated LAs instead of off-loading subscribers from all the pool areaLAs that are attached to the off-loaded MSC/MSS.For further information, see the documents Feature 1449: Multipoint Iu in MSSConcept, Feature Activation Manual and Feature 1564: Multipoint A Interface,Feature Activation Manual in M-release feature documentation.

• MSS off-loading with MGW off-loading mode when RAN independent multipoint A/Iusupport in MGW is used.

• MSS off-loading with SGs interface





Issue 9-0 draft


Id:0900d805809d6ed2


MSC/MSS off-loading in a pool with Null-NRI

Load redistribution functionality can be used when, for example, a pool MSC/MSS istaken out of use for maintenance or for reducing the load on a pool MSCs/MSSs.

Load redistribution does cause additional signaling load within the network. Pool areacapacity and connectivity must be dimensioned to cope with situations where traffic isdistributed unevenly compared to the normal operation of the pool.

The prerequisite for load redistribution is that during the NRI definition phase the Null-NRI for each pool MSC/MSS and the non-broadcast LAI have been configured. Forfurther instructions on the Null-NRI and non-broadcast LAI configuration, see the featureactivation manuals Feature 1449: Multipoint Iu and Feature 1564: Multipoint A in M-release documentation.

In this example, illustrated in the figure MSC/MSS off-loading in a pool , the load in MSS2is reduced.

Figure 94 MSC/MSS off-loading in a pool

The steps for MSC/MSS off-loading in a pool are as follows:





167



Id:0900d805809d6ed2

1. Check that the LAC configuration is correctly defined in the MSC/MSS. The LACsthat belong to the pool area also need to be identified as part of the pool area in theradio network configuration.

2.Set the MSC/MSS into the off-loading mode using MML commands. When in off-loading mode, the MSC/MSS allocates the Null-NRI and indicates a non-broadcastLAI to the MS in the LU signaling phase. This triggers the MS to initiate a new LU;

3. Set the MSC/MSS into the off-loading mode in BSCs/RNCs (or in the MGWs whenRAN Independent Multipoint A/Iu support in MGW is used) using O&M commands.This causes the MSC/MSS to be unavailable for subscriber distribution.

g If the Gs interface is implemented in the network, the MSC/MSS should also be setinto the off-loading mode in the SGSNs by taking the related MSC/MSS address offthe SGNSs subscriber distribution functionality. This is necessary to avoid theSGSN selecting the same MSC/MSS from which the subscribers are being off-loaded.

4. Due to the Null-NRI and the off-loading mode set using O&M commands, theBSCs/RNCs or MGWs direct the user to another MSC/MSS in the pool.

5. Change in the VLR load can be monitored using the VLR load measurement.6. If an MSC/MSS is off-loaded for maintenance, the MSC/MSS can be taken out of

use when a sufficient number of subscribers have been directed to otherMSCs/MSSs in the pool.For further instructions on taking an MSC/MSS out of use for maintenance, see M-release Product Documentation.

7. If only the MSC/MSS subscriber load needs to be reduced, off-loading mode can beswitched off in the BSCs/RNCs and the MSC/MSS when the target load level has

been reached. It is recommended to take the MSC/MSS into normal use first in theBSCs/RNCs (or in MGWs), and after that in the MSC/MSS.

MSC/MSS off-loading in a pool using MSC/MSS controlled load redistribution

The MSS/MSC controlled load redistribution functionality can be used when, forexample, a pool MSC/MSS is taken out of use for maintenance or for reducing the loadon the pool MSCs/MSSs.

The prerequisite for MSC/MSS controlled load redistribution is that during NRI definitionphase also NRIs of other MSCs/MSSs in the pool have been configured with relativeweights as well as non-broadcast LAI. For further instructions about NRI and non-broad-cast LAI configuration, see the feature activation manuals of Feature 1449: Multipoint Iuand Feature 1564: Multipoint A, in M-release documentation.

If Gs interface is in use, the MSC/MSS selection depends on the RAN node selection ofthe SGSN and SGSN selection of the MSC/MSS for Gs association during CombinedLA/RA Update procedure as described earlier in this document. Thus, before using thisfunctionality when Gs interface is in use, ensure that the MSC/MSS selection function inthe SGSN can support MSC/MSS selection based on the MSC/MSS NRI value includedwithin the TMSI. In the following description it is assumed that the Gs interface is not inuse.

In this example, MSS2s` load is reduced.





Issue 9-0 draft


Id:0900d805809d6ed2


Figure 95 MSC/MSS off-loading in a pool with MSC/MSS controlled load redistribu-tion.

The steps for MSC/MSS off-loading in a pool using MSC/MSS controlled load redistri-bution are as follows:

1. Check that the LAC configuration is correctly defined in the MSC/MSS. The poolarea LACs must be identified as part of the pool area in the radio network configu-ration also.

2. Set the MSC/MSS into off-loading mode using MML commands. When in off-loadingmode, the MSC/MSS allocates the NRIs of other pool MSCs/MSSs on a weightedround robin basis, and indicates non-broadcast LAI to the MS in the LU signalingphase. This triggers the MS to initiate a new LU.

3. Optionally set the MSC/MSS as unavailable for subscriber distribution inBSCs/RNCs (or in MGWs when RAN Independent Multipoint A/Iu support in MGWis used) using O&M commands. This causes the MSC/MSS to be unavailable forsubscriber distribution for subscribers without valid NRI, for example, subscriberscoming into the pool.





169



Id:0900d805809d6ed2

4. Due to the newly allocated NRI, the BSCs/RNCs direct the user to the indicated poolMSC/MSS.

5. The change in VLR load can be monitored using the VLR load measurement.

6. If the MSC/MSS is off loaded for maintenance, the MSC/MSS can be taken out ofuse when a sufficient number of subscribers have been directed to other MSC/MSSsin the pool.For detailed instructions on off-loading an MSC/MSS, refer to M-release productdocumentation.

7. If only the MSC/MSS subscriber load needs to be reduced, the off-loading mode inthe BSCs/RNCs can be switched-off when the target load level in the MSC/MSS hasbeen reached. The off-loading can be stopped at the desired level with the optionalfunctionality that allows the definition of the desired load level in MSC/MSS at whichoff-loading stops.

MSS off-loading with MGW off-loading mode

This process description is relevant only when Feature 1778: RAN Independent Multi-point A/Iu support in MGW is used.

The following off-loading method can be used with the RAN Independent Multipoint A/Iusupport in MGW feature when, for example, taking an MSS out of use for maintenance.

g These actions cause additional signaling load in the network. The pool area capacity aswell as connectivity must be dimensioned to be able to handle situations where thetraffic is distributed in an unbalanced manner compared to a normal situation within thepool.





Issue 9-0 draft


Id:0900d805809d6ed2


Figure 96 MSS off-loading with MGW off-loading mode

The steps for MSS off-loading in a pool using MGW off-loading mode are as follows:

1. Switch on the Off-loading mode in all pool area MGWs using O&M commands forthe MSS that is to be off-loaded. In off-loading mode, all initiating transactions(except paging responses) are routed by the MGW to other pool MSSs. For furtherinformation about Off-loading mode configuration in the MGW, see the document

Integrating MGW into the MSC Server System in U-release documentation.2. The change in VLR load can be monitored with the VLR load measurement during

the off-loading phase.3. When the desired subscriber load has been reached in the MSS that is off-loaded,

the Off-loading mode in the MGWs can be switched off and the MSS can be takenout of use.

MSS off-loading with SGs interface

The minimum prerequisite for load redistribution with SGs interface is that the MMEsconnected to the pool area MSSs should be able to modify the MSS selection algorithm(IMSI hash) at the SGs interface in order to prevent the selection of the MSS that is beingoff-loaded. The MSS selection algorithm modification in the MME can be based, forexample, on O&M actions.





171



Id:0900d805809d6ed2

g According to 3GPP TS 23.236 Intra-domain Connection of Radio Access Network(RAN) Nodes to Multiple Core Network (CN) Nodes , Section 4.5a.2 "Network Mode ofOperation=1" , the MME may provide more advanced support for MSS off-loading by theMME itself triggering the MSS off-loading.

Additionally, each MSS in the pool area is configured with a Null-NRI and/or parallelMSS NRI value and with a Non-Broadcast LAI. For off-loading non-LTE subscribersfrom the MSS, the procedures described in Section Off-loading an MSC/MSS in a pool can be applied simultaneously.

Figure 97 MSS off-loading with SGs interface

The steps for MSS off-loading with SGs interface are as follows:

1. Check that the LAC configuration is correctly defined in the MSS. The LTE areaLACs that belong to the pool area also need to be identified as part of the pool areain the radio network configuration. Null-NRI and Non-broadcast LAI are allocated

only to subscribers that belong to the pool area configuration.2. Set the MSS into off-loading mode in all the MMEs that are connected to the off-loaded MSS by, for example, using O&M commands. This causes the MSS to beunavailable for subscriber distribution over SGs interface in the MMEs and, thus, itis possible to avoid the selection of the same MSS from which the subscribers arebeing off-loaded.

g The method for setting the MSS into off-load mode and/or modifying the MSS selec-tion algorithm is MME implementation specific.

3. Set the MSS into off-loading mode using MML commands. When in off-loadingmode, the MSS allocates the Null-NRI (or parallel MSS NRI depending on which

MSS off-loading method is in use) and indicates a non-broadcast LAI to the UEwhen the UE makes a Combined EPS/IMSI attach procedure.





Issue 9-0 draft


Id:0900d805809d6ed2


4. When CSFB to 2G/3G happens, a new Location Update in the 2G/3G area is initi-ated by the non-broadcast LAI stored in the UE. The subscriber is, therefore, distrib-uted to an MSS in the pool area based on the Null-NRI in the TMSI.

5.Change in the VLR load can be monitored using the VLR load measurement.

6.4.2 On-loading an MSC/MSS in a poolThe following cases of on-loading an MSC/MSS in a pool are introduced:

• MSC/MSS on-loading with Multipoint Iu • MSC/MSS on-loading with Multipoint A • MSC/MSS on-loading in a pool using the optional MSC/MSS controlled load redis-

tribution • MSS on-loading with MGW on-loading mode when RAN Independent Multipoint A/Iu

support in MGW is used.

MSC/MSS on-loading with Multipoint Iu

The following on-loading methods can be used with the RNC when faster MSC/MSS on-loading is required, for example, when adding a new MSC/MSS to the pool or whentaking an MSC/MSS back into use after maintenance.

On-loading causes additional signaling load in the network. The capacity of the poolarea as well as connectivity must be dimensioned to be able to handle situations wherethe traffic is distributed in an unbalanced manner compared to the normal operation ofthe pool.

For on-loading, the MSC/MSS NRI allocation can be adjusted in the RNC subscriber dis-tribution so that all subscribers without a valid NRI are directed to the MSC/MSS that is

being on-loaded. When this method is used, after on-loading has been completed, theweight factors must be changed back to the normal subscriber distribution situationwithin the pool.

On-loading of a particular MSC/MSS can be hastened by temporarily excluding theother pool MSCs/MSSs from the RNC subscriber distribution functionality. Thedescribed methods are alternatives to setting the NRI allocation in the RNC to thenormal subscriber distribution situation and allowing the traffic to be divided between theMSCs/MSSs.

MSC/MSS on-loading with Multipoint-A

On-loading can be hastened by using the on-loading mode in the BSC, for example

when adding a new MSC/MSS to the pool or when taking an MSC/MSS back into useafter maintenance. Subscribers can also be reallocated amongst the MSCs/MSSs withinthe pool manually, for example, for load balancing between the pool MSCs/MSSs.

For faster on-loading the distribution of all traffic, not only subscribers without a validNRI, can be made using the BSCs NAS Node Selection Function, based, for example,on the weight factor method.

Additional signaling load within the network is caused. Pool area capacity as well as con-nectivity must be dimensioned to cope with situations where the traffic is unevenly dis-tributed compared to typical pool operations.

Alternatively, the MSC/MSS weighting factors can be adjusted in the BSC subscriberdistribution so that all subscribers without a valid NRI are directed to the MSC/MSS thatis on-loaded. When using this method, the weight factors have to be changed back to





173



Id:0900d805809d6ed2

the normal subscriber distribution situation within the pool after the on-loading has beencompleted. This is an alternative method to setting the weight factors in BSC to thenormal subscriber distribution situation and letting the traffic be divided accordingly.

Figure 98 MSC/MSS on-loading with Multipoint A

The prerequisite for on-loading is that weight factor parameters have been set for eachMSC/MSS according to the required traffic distribution.

The steps for MSC/MSS on-loading with Multipoint A are as follows:

1. Switch on Forced Mode in all (or selected) BSCs within the pool area using O&Mcommands. In forced mode, the BSC uses the defined weight factors for all traffic,not only for subscribers without valid NRI in the pool area. The BSC weight factorscan be modified to direct more traffic to the MSC/MSS than would be directed in atypical subscriber distribution situation;

2. Change in VLR load can be monitored with the VLR load measurement during theon-loading phase;





Issue 9-0 draft


Id:0900d805809d6ed2


3. When the desired subscriber load has been reached in the MSC/MSS that is on-loaded, Forced Mode can be switched off in the BSCs.

MSC/MSS on-loading in a pool using MSC/MSS controlled load redistribution

MSC/MSS controlled on-loading can be used when faster MSC/MSS on-loading isrequired, for example, when a new MSC/MSS is added into the pool or when anMSC/MSS is taken back into use after maintenance. Subscribers an also be reallocatedamong the MSCs/MSSs within the pool, for example, for load balancing between theMSCs/MSSs in the pool area.

This can be achieved by using the optional MSC/MSS off-loading in a pool withMSC/MSS controlled load re-distribution in one or more pool MSC/MSS, and by allocat-ing a set number of subscribers from each MSC/MSS to the MSC/MSS that is to be on-loaded.

The prerequisite for MSC/MSS controlled on-loading is that weight factor parameters

have been set in the MSC/MSS from where the subscribers are moved, according to thedesired traffic distribution.

Additional network signaling load is caused. The capacity of the pool area, as well asconnectivity, must be dimensioned to cope with situations where the traffic is unevenlydistributed compared to typical pool operation.





175



Id:0900d805809d6ed2

Figure 99 MSC/MSS controlled on-loading

The steps for MSC/MSS on-loading in a pool using MSC/MSS controlled load redistri-bution are:

1. Set the desired load redistribution and switch on the off-loading mode in theMSC/MSS from where traffic is to be moved from to the MSC/MSS to be on-loaded.Traffic from more than one MSC/MSS at the time can be moved;

2. Changes in VLR load at the target MSC/MSS during the on-loading phase can bemonitored with the VLR load measurement;

3. When the desired subscriber load has been reached in the MSC/MSS that is on-loaded, off-loading mode in the MSCs/MSSs from where the subscribers weremoved from, can be switched off. The optional functionality that allows the desiredload level to be set in the MSC/MSS that is off-loaded reduces operator effort.

MSS on-loading with MGW on-loading mode

This process description is relevant only when the optional Feature 1778: RAN Indepen-dent Multipoint A/Iu support in MGW is used.





Issue 9-0 draft


Id:0900d805809d6ed2


The following on-loading methods can be used with the RAN Independent Multipoint A/Iu support in MGW when faster MSS on-loading is required, for example, when addinga new MSS to the pool or when taking an MSS back into use after maintenance.

Additional signaling load in the network is caused. Pool area capacity as well as connec-tivity must be dimensioned to be able to handle situations where the traffic is distributedin an unbalanced manner compared to a typical situation within the pool.

Figure 100 MSS on-loading with MGW on-loading mode.

The steps for MSS on-loading in a pool using MGW on-loading mode are:

1. Switch on On-loading mode in all (or selected) MGWs within the pool area usingO&M commands. In on-loading mode, the MGW uses the defined weight factors forall traffic (except for paging responses, which are still routed to the original MSSaccording to the NRI value in TMSI in order to provide MT services availability), notonly for subscribers without valid NRI in the pool area. The MSS weight factors inMGW can be modified to direct more traffic to the MSS than would be directed therein a typical subscriber distribution situation. For further information about On-loadingmode configuration in the MGW, see the document Integrating MGW into the MSCServer System in U-release documentation.





177



Id:0900d805809d6ed2

2. Monitor the change in VLR load during the on-loading phase with the VLR load mea-surement.

3. When the desired subscriber load has been reached in the MSS that is on-loaded,

On-loading mode in the MGWs can be switched off.





Issue 9-0 draft


Id:0900d805809d6ed4

Pooling and Multipoint capacity

7 Pooling and Multipoint capacityMSC/MSS capacity

The MSC/MSS capacity figures listed here are on the M16 release level.MSC/MSS pool area related capacity information is as follows:

• There can be a maximum of 10 parallel MSSs handling the same pool area. • A maximum of 10 NRIs and one Null-NRI can be defined for one MSS. Also see

Section Load re-distribution using a Null-NRI. • There can be a maximum of 20 neighbor pool areas for one MSS. • Only one pool area can be configured in an MSC/MSS. • In case of LAC based off-loading functionality, the maximum number of simultane-

ously off-loadable LACs is 10.

The radio network configuration per network element may increase significantly

because one MSC/MSS is required to handle the pool area wide radio network config-uration:

• Maximum 5000 own LAs • Maximum 20000 network LAs • Maximum 50000 cells/SAs • Maximum 150 BSCs/500 BSCs (optional) • Maximum 500 RNCs • Maximum 8000 Flexi Direct BTSs (Open MSS)

The measurement-related restrictions (assuming a near maximum configuration isused) are as follows:

• The maximum number of simultaneous objects in the handover measurement is 64BSCs, 64 RNCs, and 5000 cells/SAs.

• VLR measurement report, paging per LAC (M353): 2000 LACs per one measure-ment period.

• VLR measurement, location updates per LAC (M240): 5000 LACs per one measure-ment period.

The total number of roaming numbers (MSRN) in the VLR is 7000 (classic MSS) or15000 (Open MSS).

g The document Dimensioning Guidelines for the MSS is available on request and is notpublished as part of the standard documentation set.

MGW capacity

For detailed MGW capacity information, see:

• MGW Release U6 Capacities in U-release documentation • Open (ATCA) MGW Capacities in Ui-release documentation • Section Capacity in the document RAN Independent A/Iu Multipoint Support in

MGW in Ui-release documentation

Internal MGW capacity usage will most likely increase with the pool concept. Thishappens because the physical MGW is divided to a number of virtual MGWs each con-trolled by different MSSs, and as a result, the number of intra-virtual MGW connectionsincreases. In many cases, two different virtual MGWs are selected.





179



Id:0900d805809d6ed4

From the perspective of H.248, a call using one context corresponds to 1 BHCA and avirtual connection corresponds to 1.5 BHCA (that is, a connection between contexts intwo virtual MGWs, meaning that two MSSs are involved in a call). When one MSScontrols an MGW, one context is needed. If two MSSs control the same call in a physicalMGW, two contexts are needed and, additionally, one virtual connection resource asexplained in the Section Virtual MGW and MGW control .

When a virtual connection is used, double the amount of MXU bandwidth is usedcompared to a one context connection. MXU bandwidth may be a limiting factor in TDM-TDM call cases.

In cases where two MSC Servers are controlling the call and two virtual MGWs withinternal IP connection is used in physical MGW, it results from MGW viewpoint to 2BHCA capacity effect and generally 50% of TCU capacity reduction.

When RAN Independent Multipoint A/Iu support in MGW is used, the following limita-tions apply:

• The MGW can be connected to maximum of 16 MSSs. • In MGW resiliency solution it is possible to have 4 MGWs.

If, however, MGW resiliency solution is used with M3UA linkset, the limitation is 3MGWs in a cluster. If a fourth MGW node is necessary in this configuration, value204 of the NB_OF_SOR_REF_AREAS parameter is recommended provided that noneof the MGW nodes has more than 51 distributed CCS7/SORPRO ISU units.

• RAN independent multipoint solution is not supported with Flexi Direct flat radioaccess network. With Flexi Direct the RAN based multipoint solution can be usedinstead.

For further information about MGW capacity together with RAN Independent Multipoint A/Iu support in MGW, see the document MGW Release U6 Capacities in U-release doc-umentation.

SS7 signaling in MGW

The amount of A and Iu interface signaling traffic does not increase because of multi-point A/Iu. In the MGW the limiting factor is the number of messages.

When RAN Independent Multipoint A/Iu support in MGW is used, the BSSAP/RANAPsignaling is terminated in the MGW at application level, which consumes more signalingcapacity compared to the situation where the MGW would act as an STP for the signal-ing traffic between a RAN node and the MSS.

In RAN Independent Multipoint A/Iu support in MGW, all connectionless messages arehandled at MGW application level, but only initial messages for signaling connectionestablishment are analyzed in MGW for correct routing. After this, the rest of connectionoriented messages for the signaling connection are transmitted transparently at theMGW BSSAP/RANAP application level. The main application level functionality for sig-naling handling is located in ISU units and thus the ISU is the main subject for the loadimpact in MGW.

For further information about MGW signaling capacity together with RAN IndependentMultipoint A/Iu support in MGW, see MGW dimensioning documentation.

With RAN Independent Multipoint A/Iu support in MGW, a maximum of 600 RNC/BSCper MGW are supported.





Issue 9-0 draft


Id:0900d805809d6ed4


BSC

• BSS product family BSCOn BSS14.0 release level one BSC can be connected to a maximum of 16

MSCs/MSSs. The multipoint A interface has no effect on the signaling capacity inthe BSC.

• BR product family BSCOn BR10.0 release level, the maximum number of MSCs/MSSs in the pool is 10.

WCDMA RNC

On RAS06/RN3.0 release level, the maximum number of MSC/MSSs to be connectedto one RNC is 16. This limit consists of MSC/MSSs connected to the RNC in the caseof overlapping pool areas.

Flexi Direct BTS

Flexi Direct implements the streamlined RNC functionality in Flexi Direct Adapter whichis part of Flexi WCDMA BTS. Flexi Direct BTS can be connected to 16 MSCs/MSSs andSGSNs.

SGSN

The following restrictions are relevant to multipoint features in the Nokia SiemensNetworks SG releases SGSN:

• Restrictions for Multipoint A • One LA can be served by 32 different MSC/MSS addresses. The MSC/MSS

address has the format of the MSISDN number, which is allocated by the ITU-Taccording to the E.164 numbering plan, so the maximum length of theMSC/MSS address is 20 octets.

• Restrictions for Multipoint Iu • The size of the pool areas is limited due to the limited size of the NRI (10 bits).

A 10-bit NRI is used to assign Packet Processing units (PAPU) inside the SGSNthat has one IP address. When LRAS is in use, a 5-bit SGSN_ID is used toassign the SGSNs that have from 1 to 16 PAPU IP addresses.

• The NRI must be unique in each of the overlapping pool areas, and the lengthof the NRIs has to be the same in these pool areas.

• The size of the pool area is restricted to 256 RNCs for multipoint Iu. • Restrictions for Multipoint Gb

• The size of the pool areas is limited due to the limited size of the NRI (10 bits). A 10-bit NRI is used to assign PAPU units inside the SGSN that has one IPaddress. When LRAS is in use, a 5-bit SGSN_ID is used to assign the SGSNsthat have from 1 to 16 PAPU IP addresses.

• The NRI must be unique in each of the overlapping pool areas, and the lengthof the NRIs has to be the same in these pool areas.

• A PCU can be connected to one standalone PAPU or PAPU group only in anSGSN.This restriction is needed to avoid the PCU creating the same cells with thesame RAs in several PAPUs. An SGSN must reject cell creation if the specifiedRA, controlled by another PAPU, already exists in the SGSN.

• If a PCU is connected to several PAPUs with the same RAs, Feature SG01060:SGSN Large Routing Area Support (LRAS) is required, which makes it possiblethat several PAPUs serve the same RAs in an SGSN.





181



Id:0900d805809d6ed4

• The Nokia Siemens Networks BSS release BSC supports eight NSEs per PCU,therefore, a PCU can be connected to a maximum of eight SGSNs in a poolarea.

The following restrictions are relevant to multipoint features in the Nokia SiemensNetworks SG releases SGSN:

• The maximum size of a pool area is 256 RNCs. • There can be only one NRI for one SGSN. • There can be only one NRI length for one pool. • All pool areas should use the same NRI length to avoid unnecessary default SGSN

actions.

MME

From the perspective of the MME, there is no limitation on the number of MSSs in a poolbecause the MME - MSS relations are configured via an .ini file in the MME.





Issue 9-0 draft


Id:0900d805809d6ed6

Pooling and Multipoint System limitations

8 Pooling and Multipoint System limitationsThe following system limitations must be considered in multipoint network planning:

• For the Nokia Siemens Networks BSS release BSC, it is required that all MSCs (inthe traditional MSC architecture) and MGWs (in the MSC Server architecture)belong to the same signaling network (NA0, NA1, IN0, IN1).

• In RAN Independent Multipoint A/Iu support in MGW, the RNC is required to supportmultiple destination SPCs for ALCAP routing. ALCAP signaling forwarding via theMGW-MGW interface is not supported in the current release.

• When an Flexi Direct radio network is used in a multipoint configuration, due to sig-nificantly higher connectivity capacity and signaling load, the RAN based multipointsolution is recommended.





183


Summary of Pooling and Multipoint parameters

Id:0900d805809d6ed8

9 Summary of Pooling and Multipoint parame-tersThe multipoint parameters in different network elements are summarized in the followingsections. Check them latest available network element product documentation set forpossible changes.

MSC/MSS parameters

There is a parameter to control the inter-MSC handover within a pool area:

• 002:1394 INTER_MSS_HO_ALWD_FLEXIf a circuit cannot be reserved when performing a handover inside the multipoint Ainterface pool area, an inter-MSS handover to another MSS handling the same poolarea can be made to save the call. For this, the parameter value is set to the defaultvalue T.

There is a parameter to control the (optional) load redistribution enhancement.

For detailed information about the MSC/MSS parameters, see Feature 1564: Multipoint A Interface and Feature 1449: Multipoint Iu in MSS Concept and Feature 1778: RANIndependent Multipoint A/lu support in MGW in M-release Feature documentation.

MGW parameters for RAN Independent Multipoint A/Iu support in MGW

For Feature 1778: RAN Independent Multipoint A/lu support in MGW, the MGW param-eters are described in the documents Integrating MGW into the MSC Server System and Configuration Data Management in MGW in U-release documentation, and thedocument RAN Independent A/Iu Multipoint support in MGW , available in the U- and Ui-release documentation.

BSC parameters

• The BSC parameters for the Multipoint A feature are described in Multipoint A Inter-face in BSC and BSS Radio Network Parameter Dictionary in Nokia SiemensNetworks GSM/EDGE BSS, BSC and TCSM (BSS-releases) Product Documenta-tion.

• The BSC parameters are described in Flexible A-Interface\FD10556 featuredescription, in Nokia Siemens Networks Base Station Subsystem (BR releases)Operating Documentation.

RNC parameters

The RNC Multipoint Iu related management parameters are described in WCDMA RANParameter Dictionary in WCDMA RAN System Library .

Flexi Direct BTS parameters

The Flexi Direct BTS (previously known as I-BTS) parameters for feature RAN834:Flexible Iu are described in the document WCDMA RAN, Rel. RAS06, Feature Descrip-tions , available in the WCDMA RAN Operating Documentation.

SGSN parameters

There are no parameters visible to the operator related to the Multipoint A, Multipoint Gbor Multipoint Iu features in the SGSN.





Issue 9-0 draft


Id:0900d805809d6ed8

Summary of Pooling and Multipoint parameters

MME parameters

For information about MME parameters relevant for MSS pooling, see sub-section MME in Section Appendix .

For more information about the MME functionality regarding MSS pooling, see UserGuide in Flexi NS - MME operating documentation.





185


Pooling and Multipoint import/export procedure

Id:0900d805809d6eda

10 Pooling and Multipoint import/export proce-dureThe following is a high level simplified Pooling and Multipoint import/export procedure.In this example, three MSSs are to be included into a pool configuration together. Thepurpose of the example is to highlight the most important principles of the import/exportprocedure, but not to provide detailed product-based configuration procedures.

For more detailed multipoint configuration management use cases, see the SectionPooling and Multipoint configuration and management .

For further information, see E3 Command Group-NRI And Pool Area ConfigurationHandling in M-release documentation.

g All sequential imports of data to the primary MSC/MSS must be executed successfully.If an error occurs, the root cause must be solved and the sequential import procedurere-started from the first step.

1. Make the pool area-related configurations.This phase includes the configuration of own pool area and neighbor pool areas (forexample, the NRI values of the MSSs). One MSS is defined to be the primary poolMSS and all the other MSSs are defined as secondary pool MSSs. Primary MSSmeans that pooled Radio Network (RN) data is collected to this MSS and from therethe data is exported to the secondary pool MSSs. Moreover, the location areas thatbelong to the pool area and the network location areas that belong to the neighbor-ing pool(s) are defined.

Figure 101 Making the pool area-related configurations.2. Export RN data from the primary and the secondary MSSs.

All Radio Network (RN) data that is to be included in to the pool is copied from theactive configuration files to the transfer files. The data to be included is that whichrelates to the Location Areas (LAs) that will be included in the pool. Data that relatesto LAs that are not to be included in the pool, is not copied.





Issue 9-0 draft


Id:0900d805809d6eda


Figure 102 Exporting RN data from the primary and the secondary MSSs3. Import data to the primary MSS from one MSS at a time

In this phase, all the RN data related to the LAs that will be pooled is collected in the

primary MSS by importing transfer files from each MSS (including the transfer filesfrom the primary MSS), one after the other. The resulting temporary RN files includeRN data relating to LAs controlled by the primary MSS that will not be included in thepool area, supplemented by the RN data related to the LAs that will be included inthe pool from all three MSSs (primary and two secondary).

Figure 103 Importing data to the primary MSS from each MSS, one at a time4. Activate the configuration in the primary MSS

In the primary MSS, the enlarged pooled RN is activated. Existing RN configurationsare unaffected by the activation of the new configuration. The new pooled RN con-figuration (consisting of the pooled RN data from the secondary MSSs) remain ininactive mode and requires further configurations before bringing them in to activemode.





187



Id:0900d805809d6eda

Figure 104 Activating the configuration in the primary MSS5. Make configurations (for instance, UP, unlock).

The imported new RN configuration in the primary MSS requires additional configu-rations before the RN objects can be unlocked and brought into active mode.

Figure 105 Making configurations (for instance, UP and unlock)6. Export RN data from primary MSS

All RN data relating to location areas to be included in the pool concept, is copiedfrom the active configuration files to the transfer files. In this phase, the transfer filesshould include the entirety of the pool area related data for all three MSSs. If thereis RN data relating to LAs under the primary MSS but not to be included in the pool,that is not copied to the transfer files.





Issue 9-0 draft


Id:0900d805809d6eda


Figure 106 Exporting RN data from the primary MSS7. Import data to the secondary MSSs

In this phase, the transfer files (including all RN data relating to pool LAs) that wereexported from the primary MSS are exported to each secondary MSS. After import,the resulting temporary RN files include the RN data relating to LAs under the sec-ondary MSSs that will not be pooled (if case such exist) supplemented by the RNdata relating to the LAs under all three MSSs, that will be pooled.

Figure 107 Importing data to the secondary MSSs8. Activate the configuration in the secondary MSSs

In the secondary MSSs, the enlarged RN configuration is activated. All RN configu-rations that already exist in the secondary MSS remain active. All new RN configu-rations (consisting of the pooled RN data from the primary MSS and the othersecondary MSS) will be in inactive mode and requires further configurations beforebringing them in to active mode.





189



Id:0900d805809d6eda

Figure 108 Activating the configuration in the secondary MSSs9. Make configurations (for instance, UP and unlock)

The imported new RN configuration in the secondary MSSs requires additional con-figurations before the RN objects can be unlocked and brought in to active mode.

Figure 109 Making configurations (for instance UP and unlock)





Issue 9-0 draft


Id:0900d805809d6edc

Appendix

11 Appendix

11.1 Subscriber distribution in the pool area in Nokia SiemensNetworks’ RNC, BSC, SGSN and Flexi Direct BTSSubscriber distribution in the pool area in Nokia Siemens Networks WCDMA RNC, BSSand BR releases BSCs, SG releases SGSN, and Flexi Direct BTS (I-BTS) is describedin the following sections.

11.1.1 WCDMA Radio Network Controller (RNC)When available, the NRI value is always used for subscriber distribution in the RNC. Ifthe MSC/MSS indicated by the NRI is not available, or the MSC/MSS is not found withthe given NRI or the NRI is the 'Null-NRI', the NRI-weighted subscriber distribution is

done by the RNC among the pool MSCs/MSSs during Location Update and IMSI Attachprocedures.

If the NRI is not found and the MSC/MSS has to be selected by the RNC's NNSF, thesubscriber distribution is done with round robin between the configured NRI values ofthe available MSC/MSSs. For example, if MSC/MSS 1 has three NRI values andMSC/MSS 2 has only one NRI value, MSC/MSS 1 gets 75% of the MSS and MSC/MSS2 gets 25% of the MSS when the NRI-weighted subscriber distribution is used. Simply,the more NRIs are assigned to an MSC/MSS, the more subscribers are directed to it.

It is possible to gain more granularity for the subscriber distribution via configuring theNRI value multiple times in the RNC for the related MSC/MSS. This enables theweighted round robin selection of the MSC/MSS for the subscriber distribution in theRNC.

The Iu signaling entity chooses one of the available MSCs/MSSs from the list of the Iuitems with the concerned CN domain. The availability of the MSC/MSS is defined withthe IuState parameter for each MSC/MSS.

The normal Iu state is WO-EX, working. CN nodes in states BAL-US and BAR-US arenot available for load balancing. The BAL-US value is used for barring only from the loadbalancing function, which means that old MSS with the correct NRI value are allowed toestablish a connection to the CN node but new MSS, MSS with unknown NRI, or MSSwith the Null-NRI are not allowed. The BAR-US value means that the CN node is totallyblocked from all connection establishments.

The subscriber distribution in the RNC works with the same method during a case wherean MSC/MSS in the pool fails.

The RNC also supports the load redistribution functionality.

11.1.2 Base Station Controller (BSS releases)The BSC distributes the new incoming subscribers to an available MSC/MSS based onthe circuit group load of each SPC. It is used in the following cases:

• The NRI cannot be derived from the TMSI. • The null-NRI is received in the TMSI. • The MS indicates an NRI for which an MSC/MSS has not been configured.





191


Appendix

Id:0900d805809d6edc

• The BSC cannot find direct mapping between the NRI and MSC/MSS for some otherreason.

• NAS node selection has been defined to be used for all traffic with the forced mode

parameter.The operator can select NAS node selection to be performed either on the basis of thecircuit group load of each SPC or by using a weighted round robin method. In the lattercase, each SPC must be given a weight factor between 0 and 100. See the followingtable for an example:

Because the weighted round robin method is used independently in each WO-EX BCSUunit, the number of subscribers required until the next MSC/MSS is selected for distri-bution in the BSC is approximately the number of WO-EX BCSUs multiplied by theMSC/MSS's weight factor. This means, for example, that a total of 150 000 subscribers,routed during a certain period of time, are eventually distributed as shown by the VLRload percentages in the table.

Load redistribution and forced mode

The BSC also supports load redistribution that enables the operator to remove trafficload from one or several MSCs/MSSs in an orderly manner, for example, to performscheduled maintenance or avoid overload. In load distribution, the MSC/MSS to be off-loaded allocates TMSIs that contain a null NRI. This causes mobile stations to performa new location update and they are therefore directed to another MSC/MSS.

The null NRI value is defined for each MSC/MSS in the BSC. When the BSC receives amessage with a null NRI, it uses the NAS node selection to determine to whichMSC/MSS the message should be forwarded.

MSCs/MSSs can be excluded from NAS node selection with the MSC state (STATE)parameter. If the state of an MSC/MSS is set as BAL-US only mobiles with a correct NRI

value are allowed to establish a connection to it. If the state is BAR-US, no connectionscan be established. In forced mode, NAS node selection is used for all traffic. It can be

Weight factorvalue 1-100

VLR load %(from total poolarea load

VLR load %(from total poolarea load)when oneMSC/MSS outof use

VLR load %(from total poolarea load)when twoMSCs/MSSsout of use

MSC/MSS 1 100 100/(50+50+100+20)

=>~45%

0%, out of use 0%, out of use

MSC/MSS 2 50 50/(50+50+100+20)

=>~23%

50/(50+50+20)

=>~42%

0%, out of use

MSC/MSS 3 50 50/(50+50+100+20)

=>~23%

50/(50+50+20)

=>~42%

50/(50+20)

=>~71%

MSC/MSS 4 20 20/(50+50+100

+20)=>~9%

20/(50+50+20)

=>~16%

20/(50+20)

=>~19%

Table 8 Example of traffic distribution with weighted round robin method





Issue 9-0 draft


Id:0900d805809d6edc

Appendix

used, for example, when one or more MSCs/MSSs recover and subscribers must bemoved swiftly between MSCs/MSSs to achieve the original situation. Even thoughforced mode has been set, the PAGING RESPONSE message is not routed with NASnode selection.

Load balancing in case of MSC/MSS failure

Load balancing is used if one or more MSCs/MSSs becomes unavailable or is taken outof use and one or more SPCs become therefore unavailable. Load balancing ensuresthat the signaling load is distributed equally between the remaining MSCs/MSSs. Loadbalancing is controlled with the load balancing value (LOAD) parameter. By changingthe value of this parameter you can select the type of algorithm that is used for load bal-ancing. The following values are possible:

The BSC does not assign traffic to the MSC/MSS that is out of service until it has beenrecovered. For more information and examples of load balancing in MSC/MSS failure,see Multipoint A Interface in BSC in GSM/EDGE BSS, BSC and TCSM (BSS-releases)Product Documentation.

MSC/MSS overload

If the BSC is connected to more than one MSC/MSS and receives an OVERLOADmessage from one MSC/MSS, it stops routing any more traffic to that MSC/MSS androutes it to the other MSC/MSSs instead using the NAS node selection function.Whenever an MSC/MSS sends an OVERLOAD message, the BSC starts an internaloverload timer (which is half of the time of T17) for the MSC/MSS. If the internal timer

expires before another OVERLOAD message from the same MSC/MSS, the BSC con-tinues routing calls to it. Otherwise the BSC sets the internal timer again.

If several MSCs/MSSs send an OVERLOAD message, the BSC checks each timewhether the number of overloaded circuits exceeds the predefined limit, which is bydefault 2/3 of the total number of circuits. If the limit is exceeded, the BSC sets timersT17 and T18 for the MSC/MSS that initiated the OVERLOAD message and reduces thetraffic by one step. After that the BSC sets the timers T17 and T18 timers for eachMSC/MSS that resends an OVERLOAD message, and reduces traffic further one stepat a time. For more detailed information on overload control procedure and the timersT17 and T18, see BSS overload protection and flow control in BSS (BSC) TrafficHandling Capacity, Network Planning and Overload Protection . For an example of the

overload procedure, see Multipoint A Interface in BSC . Both are available inGSM/EDGE BSS, BSC and TCSM (BSS-releases) Product Documentation.

Value Meaning

0 Load balancing is not used. If one or more

MSCs/MSSs are out of service, the callsare routed to the remaining MSCs/MSSsusing the NAS Node Selection function.

1 Load balancing is based on the actual NRIvalues related to one SPC.

2 Load balancing is based on the number ofavailable circuits. This method is alwaysused in NAS Node Selection (irrespectiveof the value of the load balancing methodparameter).

Table 9 Values for the load balancing value parameter.





193


Appendix

Id:0900d805809d6edc

11.1.3 Base Station Controller (BR releases)The selection of the specific MSC/MSS from the pool to which the traffic has to be routedis done by the NAS Node Selection function in the BSC. This function checks if there is

MSC/MSS address configured for the NRI. • If a valid TMSI/NRI is present, the NAS Node Selection function routes this message

to this address. • If no NRI can be derived (for example because in a new MS initial message there is

no valid TMSI/NRI contained in the MS identity), the NAS Node Selection functionselects an available (i.e. not marked as “non-operational”) MSC/MSS and routes thetraffic to this MSC/MSS.

The selection depends also on the overload status of the MSC/MSS. This overload infor-mation is derived from the signaling information on the A-interface and is kept in the BSCas balanced load information per MSC/MSS in the pool. This means that the NAS NodeSelection function in the BSC balances the load between the available MSCs/MSSs.

Via an O&M command it is possible for network operators to exclude an MSC/MSS fromload balancing. This means that the excluded MSC/MSS is not chosen by the NAS NodeSelection function.

Default MSC and load sharing

MSC/MSS selection can be done with the following available load balancing methods:

• Capacity/time-based load sharing (standard method). • Weight-based load sharing.

Capacity/time-based load sharing (standard method)

In the capacity/time-based load sharing method, load balancing is achieved on the basis

of the overload information that is available within the signaling information betweenBSS and MSC/MSS. Each MSC/MSS has its own overload level and correlatedoverload indication towards BSS. Whether an MSC/MSS is selected depends on thisoverload level compared to the overload level of all available MSCs/MSSs in the pooland the availability of the MSC/MSS. The MSC/MSS selection frame is a variable timeslice during which the MSC/MSS remains as the selected MSC/MSS, is called persis-tency of the default MSC/MSS. For further information about this method, see Flexible

A-interface\FD10556 in Nokia Siemens Networks Base Station Subsystem (BRreleases) Operating Documentation.

Weight-based load sharing

In the weight-based load sharing method, the MSC/MSS selection depends on a config-

urable weight. This load sharing method is recommended, for example, in case of differ-ent VLR capabilities and/or support of 2G and 3G users. There are 2 alternatives todefine this weight:

• As a relative number of attempts that are routed to this MSC (relative weight).• As an absolute number of attempts that are routed to this MSC (absolute weight).

In the relative weight method, an attempt interval of 100 is used to convert the relativeweights of the MSCs/MSSs into an absolute attempt number. This attempt interval isfixed. It prevents that individual MSCs/MSSs are loaded too fast during peak traffic. Themaximum relative weight for an MSC/MSS is 100, but the sum of the relative weights ofall MSCs/MSSs in the pool may be higher than 100.

For MSC/MSS selection, the MSCs/MSSs are ranked according to their relative weights.How many attempts are then in fact assigned to the MSC/MSS depends on its relative





Issue 9-0 draft


Id:0900d805809d6edc

Appendix

capacity (defined as weight) compared to the pool considering also overload levels. Theweight is modified by a factor that is reverse proportional to the overload level.

In the absolute weight method, the sum of the absolute weights of all MSCs/MSSs in the

pool may not be higher than 100. This corresponds to the attempt interval of 100. ForMSC/MSS selection, the MSCs/MSSs are ranked according to their absolute weightsconsidering also the overload level.

For further information about these weight methods, see Flexible A-interface\FD10556 in Nokia Siemens Networks Base Station Subsystem (BR releases) Operating Docu-mentation.

Overload handling

To handle overload situations when pool area configuration is not implemented in thenetwork, the flow control procedure is used as defined in 3GPP TS 48.008. If the firstoverload message is received, the traffic is reduced by one step.

The traffic reduction is achieved by discarding a percentage of Channel Required mes-sages. Each step equals to 10% step of discarded Channel Required messages. At thesame time, the timers T17 and T18 are started. During T17, all overload messages orsignaling point Congested messages are ignored. This avoids that the traffic is reducedtoo quickly. During T18, the messages cause the reduction of the traffic by one morestep. At the same time, the timers are started again. The step by step reduction of trafficis carried out until the maximum reduction is reached (zero level). If T18 expires(meaning that no overload message is received during T18) the traffic will be increasedby one step and T18 is started again.

If pool area configuration is implemented in the network, each MSC/MSS has its ownoverload level and correlated overload alarm. The load is balanced according to the loadbalancing function as described in the previous section. If the overload level of allMSCs/MSSs in the pool exceed a certain level, the same overload measures are takenas for configurations without the flexible A-interface.

Off-loading function for CS and PS domain

The BSC also supports load redistribution that enables the operator to remove trafficload from one or several MSCs/MSSs in an orderly manner, for example, to performscheduled maintenance or avoid overload. In load distribution, the MSC/MSS to be off-loaded allocates TMSIs that contain a null NRI. This causes mobile stations to performa new location update and they are therefore directed to another MSC/MSS.

When the BSC receives a message with a null NRI, it uses the NAS node selection todetermine to which MSC/MSS the message should be forwarded. It is possible to

remove the load from an MSC/MSS by setting the attribute BARINNASNS (“barred inNAS node selection”) to “TRUE” via O&M. When an MSC/MSS is barred in NAS nodeselection, it is excluded from the MSC/MSS selection and cannot be assigned for initialMS messages received without TMSI or with TMSI including non-configured NRI values(for example Null-NRI).

For further information, see Flexible A-interface\FD10556 in Nokia Siemens NetworksBase Station Subsystem (BR releases) Operating Documentation.

11.1.4 SGSN (SG releases)During a combined mobility procedure, the SGSN needs to select an MSC/VLR from the

available MSC/VLRs serving the current location area of the MS. When multipleMSCs/MSSs are configured for the relevant LAI, the MSC/MSS selection in the SGSN





195


Appendix

Id:0900d805809d6edc

is based on a hash value derived from the IMSI. It is configured in the SGSN which rangeof the hash values relates to which MSC/VLR.

This selection mechanism avoids a random change of the MSC/VLR for subscribers

using combined procedures, when an SGSN fails. When the selection is made basedon the IMSI, the new SGSN selects the same MSC/VLR. In the SGSN, it is possible toconfigure 5 MSCs/MSSs per LAI and thus distribute the subscribers accordinglybetween the MSCs/MSSs in the pool when creating the Gs association.

For more information about the 2G SGSN functionality regarding multipoint features,see the feature descriptions of Features SG01023 and SG01075: Multipoint GB and A ,in SGSN (SG releases) Product Documentation.

11.1.5 Flexi Direct BTSThe NAS Node Selector function (NNSF) is a mechanism used for selecting the CNnode for the UE. The UE derives the value of the parameter NRI from the (P)-TMSI orIMSI and sends the NRI to the Flexi Direct Adapter in the Initial Direct Transfer message.The Adapter selects the CN node corresponding to the NRI value configured in its data-base.

The NNSF in the Flexi Direct Adapter also contains the CN node recovery functionality,which balances the load between the CN nodes of a pool in different cases, for example,with CN node failure, SW/HW update or adding/removing a CN node to/from the pool.

For more information about the Flexi Direct BTS (previously known as I-BTS) featureRAN834: Flexible Iu, see the document WCDMA RAN, Rel. RAS06, Feature Descrip-tions , available in the WCDMA RAN Operating Documentation.

11.1.6 MMEWhen MSSs are pooled, during a combined mobility procedure (EPS/IMSI) the MMEneeds to select an MSS/VLR from the pool of available MSS/VLRs serving the currentlocation area of the UE. If the MME_MULTIPOINT_MSCVLR (012:2023) parameter isenabled in MME, the MME uses IMSI hash function to identify the MSC/VLR. From theIMSI the MME derives a value (V) using algorithm [(IMSI div 10) modulo 1000]. Everyvalue (V) from the range 0 to 999 corresponds to a single MSS. Typically, many valuesof (V) may point to the same MSS. It is configured in the MME which range of the hashvalues relates to which MSS/VLR. Once an MSS/VLR number is derived, the value isstored in the MME for the UE.

This selection mechanism avoids a random change of the MSS/VLR for subscribersusing combined procedures when an MME fails. When the selection is made based onthe IMSI, the new MME selects the same MSS/VLR.

For more information about the MME functionality regarding MSS pooling, see UserGuide in Flexi NS - MME operating documentation.

11.2 Related documentsThe following documents are related to this feature in the scope of MSS System:

• MSS System documentation: – Feature Migration for MSS/VLR

– MSS System Network Resilience



DRAFT_3rd October 2013MSS Pooling and Multipoint Guidelines for MSS Sys-tem

Appendix

– MSS System Network Planning • M-release feature documentation

– Feature 1449: Multipoint Iu in MSS Concept, Feature Description

– Feature 1449: Multipoint Iu in MSS Concept, Feature Activation Manual – Feature 1564: Multipoint A Interface, Feature Description – Feature 1564: Multipoint A Interface, Feature Activation Manual – Feature 1778: RAN Independent Multipoint A/Iu Support in MGW, Feature

Description – Feature 1778: RAN Independent Multipoint A/Iu Support in MGW, Feature Acti-

vation Manual – Feature 1879: User Plane Support of 3GPP SIP-I, Feature Description – Feature 1879: User Plane Support of 3GPP SIP-I, Feature Activation Manual – Feature 1881: VLR Backup, Feature Description – Feature 1881: VLR Backup, Feature Activation Manual – Feature 1914: CS Fallback in EPS for MSC Server, Feature Description – Feature 1914: CS Fallback in EPS for MSC Server, Feature Activation Manual

• U release product documentation:

mss pooling

Documents