CS CoreNet Planning

CS Core Network Planning

DN0534754Issue 4-0 en

# Nokia Siemens Networks 1 (160)

CScore1.2CS Core System Documentation, Version 1.2

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 theuse 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 transmitted inany 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, orperformance 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 whichmay 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 THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAYARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN 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 trademark ofNokia Corporation. Siemens is a registered trademark of Siemens AG.

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

Copyright © Nokia Siemens Networks 2007. All rights reserved.

2 (160) # Nokia Siemens Networks DN0534754Issue 4-0 en


Contents

Contents 3

1 Changes in CS Core Network Planning 5

2 CS core network planning overview 7

3 Nokia Siemens network planning services 11

4 Resilience in network planning 15

5 Inter and intrasite connectivity 175.1 Backbone alternatives 175.2 Network topology 23

6 Planning of control and user plane analyses 316.1 Minimising hops on user plane 436.2 SS7 Signalling Transport over IP (SIGTRAN) 506.3 Signalling Management Cluster 546.4 Planning virtual MGW configuration 556.5 Comparison between late and early RAB assignment in Iu/3G 64

7 Planning of services and features 657.1 Selecting signalling protocol for call control 657.2 Planning CDS network configuration 667.3 Video calls requiring protocol/codec conversion 717.4 Planning IN services 717.5 Planning TFO/TrFO 727.6 Planning Voice Mail System (VMS) 737.7 Planning Selective Ring Back Tone (SRBT) 737.8 Planning charging 747.9 Planning Supercharger 797.10 Planning semipermanent cross-connection configurations 797.11 Planning Channel Associated Signalling (CAS) 807.12 Planning Signalling Point Codes (SPC) 807.13 Planning Multipoint A/Iu 817.14 Planning synchronisation and timing 817.15 Planning Mobile Number Portability/Service Routing Register (SRRi) 84

8 Planning of convergence solutions 918.1 Planning Indirect Access services (IDA) 918.2 Planning Unlicensed Mobile Access (UMA) 918.3 Planning SIP services 958.4 Planning Session Border Controller (SBC) 1018.5 Planning Light Directory Access Protocol (LDAP) 101

9 CS core network dimensioning 1039.1 Dimensioning of MSC Server System 1069.2 Dimensioning MSC Server 108



Contents

9.3 Dimensioning of MGW 1139.4 Dimensioning IP network 1179.5 Estimating the needed bandwidth 1199.6 IP over ATM 1379.7 ATM over TDM (IMA) 1399.8 Connection rate based CAC by BICC CIC configuration 1399.9 Detailed planning of CS core network 144

10 Network management system planning 14910.1 Planning O&M network for CS core network 154

11 Using KPIs for network planning and performance monitoring 159



1 Changes in CS Core Network Planning

The following changes have been made since the last documentationrelease. The changes are detailed in the table below.

Table 1. Changes in CS Core Network Planning

Change See

Multipoint A/Iu –related information has beenremoved.

A separate description on Nokia CS CoreMultipoint configuration has been included in CSCore System Documentation.

PDF: CS Core Multipoint Configuration Guidelines

In MSS, user plane analysis is not generallyneeded for TDM resources except when MGWsare controlled by the same MSS and theinterconnection between MGWs is TDM-based.

Planning of control and user plane analyses

Inter-MSS handover requires some specialattention in the interconnecting BNC determinationanalysis phase. A table listing the attributes of theuser plane analysis phases has been added.


Information has been added about the Nokiaproprietary Nb' user plane that can be used forG.711 codec or for data calls with non-speechTransmission Medium Requirements (TMRs).


Guidelines have been added for optimising userplane routing when the VMSS controls more thanone physical MGW (if MSRN is allocated on a LACbasis).

Minimising hops on user plane in Planning of controland user plane analyses

To avoid unnecessary retransmissions, SCTPretransmission parameters have to be configured toaccommodate for round-trip delays.

SCTP parameters for satellite IP links in Planning ofcontrol and user plane analyses

Principles guiding VMGW configuration have beenadded.

Planning virtual MGW configuration in Planning ofcontrol and user plane analyses

Comparison between early and late RABassignment in Iu/3G has been added.

Comparison between early and late RAB assignment

in Iu/3G in Planning of control and user planeanalyses



Changes in CS Core Network Planning

Table 1. Changes in CS Core Network Planning (cont.)

Change See

The basic rules for selecting signalling protocol(SIP/ISUP or BICC) have been complemented.

Selecting signalling protocol for call control in Planningof services and features

An overview of defining the pricing model ofdifferent calls cases has been added.

Planning charging in Planning of services andfeatures

Nokia-Siemens Subscriber Repository (NSR) hasbeen introduced.

Figure: Nokia CS core network architecture in CSCore network planning overview



2 CS core network planning overview

The purpose of this document is to provide a general guideline for CS corenetwork planning issues, with the focus on MSC Server System -specifictopics.

MSC Server System brings many new aspects into core network planningwhen compared to MSC. In the circuit switched core network, the biggestchanges result from the introduction of a new network element, theMultimedia Gateway (MGW), and the new radio network interface, Iu-CSinterface, introduced by the 3G network. Furthermore, the separation ofcontrol and user planes is introduced: the MSC Server (MSS) handles thecontrol plane while the user plane is switched in the MGW. IP MultimediaSubsystem (IMS) implements the functionality specified in 3GPP, andadditionally, offers service execution, creation and deploymentenvironment to introduce new Session Initiation Protocol (SIP) services.CS core requires some new planning regarding IMS and convergence.

Also, convergence and Unlicensed Mobile Access (UMA) are coveredhere from the core network point of view.

Good network quality is a combination of infrastructure, planning anddeployment quality. It is also important to achieve the targeted Quality of

Service (QoS) levels from the start, and this can be done by paying specialattention to the network planning phase. For more information on QoS, seeQuality of Service in CS Core Network.

CS Core Network Planning introduces some issues that must be taken intoaccount when planning and dimensioning CS core networks. However,very detailed instructions cannot be given because network planning hasto be carried out case by case.



CS core network planning overview

Circuit switched core network planning

Circuit switched (CS) core network planning covers the planning of the CScore network elements and interfaces required for the functionality of thenetwork. It also gives a short introduction to the aspects that need to beconsidered when planning a network where the Service Routing Register(SRRi) and/or Mobile Number Portability (MNP) are implemented, and howMNP affects the detailed CS core planning.

The purpose of the CS core network planning is to plan the CS core anddatabase network elements required for the functionality of the network.The aim is to take into account, for example, the available switchingequipment both at the time of the network construction and in the future.Also future changes in services and capacity demand must be considered.The CS core part of the network is shaded in grey in figure Nokia CS corenetwork architecture.

The figure below illustrates the architecture of Nokia CS core network:

BSCUNC

RNC

MGW

External IPnetworks

BSC

SGSN

MGWSGSN

MSS/GCS

SCP

MSS

GGSN

IP/ATM/TDMbackbone

IMR

DSLAM

CPS

PSTN/ISDN

GsA/Ater

Iu

(BSSAP+)

VoIP

(MAP) D(MAP)

(ISUP)

Nc

(SIPBICC CS2ISUP)

(CAP,INAP)

Mc(H.248)

(CAP,INAP,MAP)

Nb

Mb

Nb

(MAP)

Gi

Gi(Gm)

(SIP)

CxMj/Mg/ISC

Mc Mn(H.248)

HLR

IP/ATMbackbone

NSR



In the Nc interface:

. ISUP is required if the user plane is TDM

. BICC is required if the user plane is ATM

. SIP or BICC is required if the user plane is IP.

Figure 1. Nokia CS core network architecture

In the CS core network planning, the focus is on the MSC Server System,but the MSC network architecture is supported, too. In the latter case thetraffic is switched through the MSC, and the MGW is used only forconnecting the Iu-CS to the MSC. In addition, CS core Network Planninggives information on what must be taken into account in respect ofcapacity and dimensioning when planning the intelligent network services,and network management system (Nokia NetActTM). It is assumed thatyou are familiar with the basic concepts and network elements related tonetworks.

CS Core Planning does not discuss the following areas in detail:

. For information on the connectivity of MSC Server System networkelements (MSS, MGW and CDS) to the backbone network, as wellas planning core sites and remote media gateway sites, potentiallyco-located with RNC and/or BSC, see Site connectivity solution

overview in Site Connectivity Guidelines for CS Core Network.

. For more information on backbone network planning in CS corenetwork and Nokia backbone transport solutions, see Backbone

connectivity solution in IP Connectivity in Core Networks.

. Network resilience targets must be taken into account in the networkplanning process. Some of the targets have a significant effect onthe overall network design, and must be known in the early stages ofnetwork planning (for example, the number of core sites and howthey back up each other, and the use of independent alternativeroutes in the transport network). For details of the Nokia CS coreresilience solution, see CS core network resilience in CS CoreNetwork Resilience.

. For information on planning the migration of MSC Server System toan existing network, see Migration to MSC Server System.

. Attention must also be paid to planning the security solutions.Building up a common IP transport network opens the door to a lot ofnew threats. The security solutions used in the core network areexplained in more detail in Security in CS core network in CS CoreSystem Overview.



CS core network planning overview

. For Quality of Service (QoS), see QoS in CS core network in Qualityof Service in CS Core Network.

. For more information on radio network and cellular transmissionplanning, see Nokia WCDMA RAN System Information Set,available in NOLS.

CS core network elements and interfaces

The most important elements and interfaces of the circuit switched corenetwork are shown in figure Nokia CS core network architecture above.See also Overview of the CS core network interfaces in CS Core SystemOverview.

For more information on the CS core elements and functionalities, see CS

core network architecture also in CS Core System Overview. Fordescriptions of the core network elements and their functionalities, seenetwork element product documentation.

The major difference between 3GPP MSC Server CS core network andMSC architecture is the introduction of packet-based Nb and Ncinterfaces. The effects of these are described in Dimensioning of MGW.



3 Nokia Siemens network planningservices

Nokia Siemens offers a wide range of support services and solutions forhelping you plan the network. The services include the entire process ofplanning, building and operating a network and developing, managing andoptimising network services.

The network planning modules and services are shown in the figure below.Each of these modules is further divided into submodules (networkassessment, dimensioning and detailed planning) according to theplanning process:

Figure 2. Nokia Siemens network planning modules and services

MSC Server systemoptimization

MSC Server system planning

Assessment Dimensioning Detailed planning

Transition planning

Migration NSS to Rel-4

Replacement R99 to Rel-4

CS Core evolutionconsulting

CS Core performance management

IP backbone planning

VisionStrategy

SolutionDesign

Implementation Operation

IP performance management



Nokia Siemens network planning services

Note

Note that Multimedia Core Network Planning, IP/ATM Planning, and INPlanning are covered in Circuit Switched and Packet Switched CoreNetwork Planning services.

The modular planning process has, for example, the following advantages:

. it supports project management

. it facilitates the acquisition of necessary source data

. it is easier to make worktime estimates for the various steps of theprocess

. there are uniform measures for evaluating the success of the project

. operators get a better understanding of the content of the networkplanning project and more visibility to the incurred costs.

Nokia Siemens offers two paths for the mobile network planning service.The first path is for operators that prefer a complete service for the networkplanning activities. This means that Nokia Siemens has the fullresponsibility of the network planning tasks. The second path is foroperators that have their own planning personnel but need some expertisesupport.

This freedom of choice offers the operator clear benefits in getting thenetwork ready on time and their own personnel educated during theplanning and implementing phases. While Nokia MSC Server System canmerge the core network to a single IP network, the migration needs to bewell-planned to avoid any unnecessary service breaks. Nokia Siemensplanning services are quantified to fit the operator's needs and to ensure asmooth evolution path.



Figure 3. Nokia Siemens network planning and performance services for MSCServer System

Network Evolution Service combines Nokia Siemens' knowledge of mobilenetwork technology evolution with a current state analysis of the mobilenetwork. The outcome of the service specifies the foundation for theoperator network evolution, the cornerstones and main decisions of howthe network will evolve. This includes support on, for example, backbonetype, pace of modernisation, high level architecture an so on. Planning andoperating a network can be seen as a continuum and mobile networks aredeveloped in cyclical steps. Optimising a network consists of a follow-up of

RolloutNetworkPlanningConsulting

Pre-planning

Planning

Pre-launch Optimisation

NetworkPlanning forReplacement

Network Evolution Consulting

Network Planning Project Management

Network Optimisation

Quality Benchmarking andPerformance Analysis

Process Development

Network Evolution Consulting

Mobile Services OptimisationNetwork

PlanningServices

Network

Perform

ance

Services



Nokia Siemens network planning services

how the planned services are actually provided so as to ensure an efficientuse of the network resources. It also provides a follow up of the businessplan, subscriber and services penetration forecast in order to plan theeventual upgrading of the network when necessary.

The CS core network has to support all required end-user services and toprovide enough flexibility to support future needs in terms of capacity,topology, hierarchy and services. The CS core network rollout planning isusually carried out as a modular project. Each of the following modulescan also be carried out separately, if the preconditions are met:

Figure 4. The structure of CS core network rollout planning project

Network assessment

Dimensioning principles

Network dimensioning

Master plan

Detailed network planning

Source data

Implementation

Operation

Feasibility study

Business plan



4 Resilience in network planning

Network resilience targets must be taken into account in the networkplanning process. Some of the targets have a significant effect on theoverall network design, and they must be known in the early stages ofnetwork planning (for example, the number of core sites and how theyback up each other, and the use of independent alternative routes in thetransport network).

Network pre-planning and dimensioning

Solution principles and a rough network structure are determined in theearly stages of network planning. The main inputs in this phase are relatedto the operator and network environment and include, for example:

. existing 2G and/or 3G networks (GSM/GPRS/EDGE/WCDMA):when existing, number of sites, equipment used (MSCs, CPSs,SGSNs, GGSNs, RNCs), and amount of equipment

. network evolution: growth estimates and other targets

. possible current transport networks: when existing, what kind ofproducts are used; planned future network development; possibleexisting transmission infrastructure (SDH/PDH/WDM, own orleased, coverage of the network)

. network strategy: desired speed of evolution to All IP and/or to IP-RAN

The aim of dimensioning is to produce the most cost-effective andtechnically optimised network plan. The plan indicates the selectednetwork architecture and the amount of equipment needed during the roll-out of the network.



Resilience in network planning

Detailed network planning

The purpose of detailed planning is to get the exact equipment lists,including interface cards, for the network and the resilience solutions.Detailed planning is based on the results of the earlier phases and onmore accurate traffic estimates, and more detailed availability targets (forservices and/or network elements).

Network planning tools

Nokia CS core network planning and optimisation is supported byadvanced tools that enable seamless migration from GSM to GPRS,EDGE, WCDMA, and IP technologies. Nokia NetAct Planner for both 3Gradio and transmission networks is software aimed for advanced networkdesign and optimisation.

. NetAct Radio Planner offers effective support for all phases of theradio network planning process.

. NetAct WCDMA Planner is designed to provide comprehensiveradio planning functionality for the new 3rd Generation mobilenetworks.

. NetAct Transmission Planner helps to plan transport networks, suchas IP, ATM, and SDH.

. NetAct Link Planner is an efficient and flexible solution formicrowave link and transmission network planning.

. NetAct Quality Planner is an intelligent software package for fieldmeasurement analysis.

Nokia services

Nokia provides a full set of services for the CS core network planning,optimisation, and implementation. These services are also available forthe resilience part of the system solution, including Nokia's own andpartnered equipment used in the solutions.



5 Inter and intrasite connectivity

5.1 Backbone alternatives

Nokia MSC Server System provides many alternatives for creatingbackbone connectivity between sites. The backbone connectivity can bebased on:

. IP

. ATM

. TDM interfaces

. a combination of the above.

When selecting a suitable backbone solution, there are many things toconsider:

. Strategy and long range plan.

. Interface requirements (for example Iu is still over AAL2).

. Requirements set by other solutions using the same backboneelements.

. Resiliency requirements.

. QoS requirements. See Quality of Service in the packet backbone inIP Connectivity in Core Networks and QoS in CS core network inQuality of Service in CS Core Network. See also QoS requirements

for IP backbone, in Site Connectivity Guidelines for CS CoreNetwork

. Multi-vendor capabilities.

. Network element (NE) capacity impact.



Inter and intrasite connectivity

CS core can use either IP, ATM or TDM backbone. The connection to IPbackbone is arranged via multilayer site switches / IP routers. MSS controlplane (for example H.248) is connected to the site routers regardless of thebackbone type. The ATM functionality is built-in into MGW, ATM switchescan be used in large networks to simplify the configuration. Existing TDMconnectivity can be used for circuit switched (CS) voice and data even inMSC Server System. PS core always uses IP (or IP over ATM) transport.The following figure illustrates the alternatives:

Figure 5. Backbone alternatives

Requirements for the backbone

ATM backbone shall support two distinct delay variation values, one forcontrol plane and another for user plane. CS core uses Constant Bit Rate(CBR) for user plane. That is configured in MGW. PS core uses UndefinedBit Rate (UBR) for user plane.

IP backbone must support Virtual Private Networks (VPN).

For backbone planning see Backbone connectivity solution in IPconnectivity in Core Networks. See also QoS requirements for IP

backbone, in Site Connectivity Guidelines for CS Core Network

DXC/ADM DXC/ADM

PS and CS core useIP transport

CS core with ATMtransport option

CS core with TDMtransport option

NokiaGGSN

NokiaSGSN

IP router

NokiaGGSN

NokiaSGSN

IP router

ATMswitch

ATMswitch

SDH/SONET

as commontransport

forall

optionsMGW

MGW



Pure IP backbone

For many companies an IP backbone is part of long-haul strategy. Theymay have an IP backbone already in place. IP backbone provides aflexible migration to Voice over IP (VoIP)/SIP and IP Multimedia Services(IMS).

Iu-interface will also move to IP, which removes some of the benefit forAAL2. IP backbone provides simplification in flexibility, configuration andmanagement when compared to AAL2/ATM. Use this option if possible,and if AAL2 does not provide any benefits for you.

Multi-protocol label switching (MPLS) may be used for traffic engineering,fast reroute and VPNs. MGW marks control plane and user plane withDiffServ. MPLS is a router functionality. Site router is capable of mappingDiffServ classes code points into MPLS exp bits.

Figure 6. IP backbone

ATM backbone

As stated for the IP backbone, an ATM backbone may already exist andATM may also be the operator’s long-haul strategy. ATM can be used withSTM-1 or with IMA groups (n* E1/T1).

Core site 1

MGW

DNS

MSC Server

SGSNGGSN...

Core site3

Core siten

Core site2

IP router

User data overRTP/UDP/IP.

Signallingcarriedover IP.

Physical transmissionlayer based onSDH/SONET.

IP backbone

No connection setupsignaling in thebackbone. MPLSmay be used.




ATM in Nokia MGW provides somewhat higher capacities due to internalpacket size handling and IP stack termination issues. AAL2 nodal functionenables efficient use of MSS and MGW resources by enabling a moreoptimised MGW selection. Iur over AAL2 brings synergies through use ofnodal function (no full virtual channel connection (VCC) mesh end-to-endrequired, only point to point).

Figure 7. ATM backbone

In the ATM domain there are the following sub-options:

. Use ATM nodal function of MGW. MGW performs the AAL2switching.

. Use ATM switch functionality in MGW. MGW connects ATM cellsbased on virtual channels and paths.

With SDH/SONET the following applies:

Since MGW includes ATM switch (and AAL2 switch) capability, it ispossible to build ATM backbone without external ATM switches. Withinone MSS all MGWs shall be interconnected. In this option, between MSSareas, dedicated MGWs can be used, or MGWs can be fully meshed. The

Core site 1

MGW

DNS

MSC Server

SGSNGGSN...

ATM PVCmesh and/or

SPVCs

Core site3

Core siten

Core site2

ATM switch

User dataAAL2/ATM.

Signalling carried onIP over ATM, or overIP to ATM switch.

Physical transmissionlayer based onSDH/SONET.

PNNI signalling fordynamic SPVC setup.MPLS over ATM VCscan be used.



target is to minimise MGWs per call while keeping (ATM network)signalling manageable. Nokia MGW supports ATM over SDH, and TDMover SDH. The following figure illustrates the ATM with SDH/SONEToption:

Figure 8. ATM with SDH/SONET

ATM locally, IP long distance

It is possible to combine both ATM and IP connectivity between MGWs. Ifthere are several MGWs at the same site (or close to one another), it ispossible to connect these MGWs into each other directly by using NIS1units and ATM connectivity. For the long-distance connections IPbackbone can be used.

GSM BSS/UMTS RAN SDH/

SONET

MGW MGWMGW MGW

MGW MGW

MSS2MSS1

PSTN




Figure 9. IP long distance – ATM locally

IP locally, ATM long distance

This approach is also possible. Local traffic is over IP/LAN and wide areatransport is ATM. This is of benefit only if n* E1 transport is available.

TDM backbone

For the operators who already have a large TDM transmission networkusing TDM backbone is a feasible option. Some MSC Server System(MSS) benefits cannot be capitalised on (for example transmissionsavings, Transcoder-free operation (TrFO)), but using the existingtransmission might be beneficial in some migration scenarios. An examplecould be replacing old MSCs or expanding MSC port capacity. Note thatMEGACO/H.248 and O&M traffic require IP connectivity between MGWand MSS. Also SIGTRAN and IWF control may require IP transport. IPover ATM is the solution for that (inter-site). Within a site, site connectivitysolution includes IP routers. Nokia MGW supports ATM over SDH, as wellas TDM over SDH.

The following figure illustrates this solution:

GSMBSC

A

Iu

MGWWCDMA

PSTN/PLMN

RNC

MSC Server

MGW MGW

GSM BSC

A

Iu

MGWWCDMA

PSTN/PLMN

RNC

MSC Server

MGW MGW

Site 1 Site 2

IP/MPLS



Figure 10. TDM backbone

5.2 Network topology

The first step to estimate is the number of subscribers, and the ratio theyuse the circuit switched (CS) services. Also the geographical distribution ofsubscribers is taken into account. Already in the initial planning phase thefinal target network topology should be taken into account.

Logical network topology

The logical topology shows how the sites and network elements areconnected. That is, the connections to other network elements from eachelement’s point of view. For each site and network element the capacityneeds to be considered. In other words, check that the network elementcan handle the required number of subscribers and their service attempts.

The logical topology should be split into control plane and user planetopology. The following figure shows an example of logical control planeconnections:

MSC

ADM

ADMMSC

SDH/Sonet

MSC

ADM

ADM MSSMSC

SDH/Sonet

MSS networkGSM network




Figure 11. Logical Control Plane connection example

For the user plane a similar plan is needed to convey user voice and data/fax.

MGW04 RNC03

BSC04

Site 1 Site 2

Site 3

HLR01

MGW01

BSC01

MGW02

RNC01

SMSC01

BSC02

SCP01

MSS01

MAP/SS7

CAP/SS7

MAP/SS7

MAP+CAP/SIGTRAN

MAP+CAP/SIGTRAN

AAL2+AAL5/ATM

BSSAP, RANAPBICC, ISUP, IWFcontrol/IP

AAL2+AAL5/ATM


RANAP/ATM

BSSAP/7BSSAP, RANAPBICC, ISUP, IWF

control/IP

MGW03

RNC02 BSC03

MSS02

AAL2+AAL5/ATM

MAP+CAP/SIGTRAN

AAL2+AAL5/ATM

HLR02 STP01



Figure 12. Logical User Plane connection example

Physical network topology

LAN topology

The operator needs to assign IP addresses for the computer units,interface units and LAN switches (SWUs). These addresses can beprivate IP addresses. If the MSC Server (MSS) network is connected to anexternal IP network using SIP or BICC, that particular MSS and MGWtaking care of inter-connection need to have public IP addresses. All otherMSSs and MGWs may have internal IP addresses in this case.

One sub-option is to have IPv6 addresses for the inter-connection, anduse IPv4 addresses in intra-network signalling. This is a good option sinceIPv6 addresses suffice and IPv4 addressing saves resources. In thisoption the units are allocated to both IPv4 and IPv6 addresses. In the userplane analysis you define the BNC characteristics (IPv4/IPv6) that areinformed to an adjacent element in the SIP signalling. When the interfaceunit sends packets, it selects the address from the same subnet where itsown address for this call is, that is, IPv6 or IPv4 according to the BNCcharacteristics of the UPD.

Voice/ATM

Voice/TDM

Fax/data/TDM

MGW04 RNC03

BSC04

MGW03

RNC02 BSC03

MSS02

Site 1

Site 2

Site 3

HLR01

HLR02

MGW01

BSC01

MGW02

RNC01

SMSC01

BSC02

SCP01

STP01

MSS01

Voice/ATM

Voice/ATM

Voice/ATMFax/data/TDM

Voice/ATM

Voice/TDM

Voice/ATM

Fax/data/TDM




Note

Nokia CS Core documentation includes instructions for configuringIPv6, but Nokia does not currently support or recommend the use ofIPv6 for commercial CS Core traffic in live networks. Interworking withsite IP infrastructure will be finalised and verified in a later MSS Systemrelease.

For more information on LAN topology, see the description for LANbuilding blocks in Site Connectivity Guidelines for CS Core Network.

For more information on IP addresses, see IP addressing principles for CS

core networks elements in Site Connectivity Guidelines for CS CoreNetwork.

See also Site connectivity solution overview.

Example physical connectivity

In this example we have a site with one MSS, HLR, MGW and CDS.Subnet mask is 24 bits. For each site it is beneficial to plan physical portconnectivity for control plane, charging, O&M and provisioning, and userplane (user plane only if IP backbone). The IP addresses of the computerunits are shown in the figure, and how each SWU is connected to siterouters.

These example figures illustrate how the final plan should look like in asite.



CP VLAN consists of 3 subnets. Addressing is not shown in the figure.

Figure 13. Site – control plane- physical

CP1 VLAN - 10.100.2.0/24

CP2 VLAN - 10.100.3.0/24

IP backbone

MGW01

CAMA-ESA24-SW0ISU1

ISU10

..

CAMA-ESA24-SW0

ETH1

ETH2

ETH1

ETH2

CDS01

GSU1

GSU2

..

IPCC-LANU0-ETH1

IPCC-LANU0-ETH2

IPCC-LANU1-ETH1

IPCC-LANU1-ETH2

..

CCSU1

CCSU32

HLR01STU0-ETH1

STU0-ETH2

STU1-ETH1

STU1-ETH2

HLRU2-SWU1

HLRU6-SWU0

HLRU6-SWU1

HLRU2-SWU0ETH1

ETH2

ETH1

ETH2

ETH1

ETH2

ETH1

ETH2

..

SIGU1

SIGU42

MSS01

IPCG0-LANU2-SW1-ETH1















Separate SWU is an optional feature.

Figure 14. Site – charging – physical

MSS01

IP backbone

Cha VLAN - 10.100.12.0/24

ChargingMediationDevice

CHU0-0

CHU0-1

CHU1-0

CHU1-1

CHU2-0

CHU2-1

CHU3-0

CHU3-1

IPCF-LANU0-SW1ETH1

ETH2

IPCF-LANU1-SW1ETH1

ETH2



Figure 15. Site – O&M – physical

CP1 VLAN - 10.100.14.0/24

CDS01

IPCC-LANU0-ETH2

IPCC-LANU1-ETH2

NEMU

P23

P23

.

.

.

.

Regional OMC

Provisioning

..

MSS01

IPCF-LANU0-SW2-ETH1

IPCF-LANU0-SW2-ETH2

IPCF-LANU1-SW2-ETH1

IPCF-LANU1-SW2-ETH2

OMU1

BDCU1

OMU0

IP backbone

Note:In HLR HLRU0-1, 4-0, 8-0and 8-1 would havesimilar connectivity thanHLRU0-0

MGW01

CAMA-ESA24-SW0

CAMA-ESA24-SW1

ETH1

ETH2

ETH1

ETH2

HLR01CMM0-ETH1

CMM0-ETH2

CMM1-ETH1

CMM1-ETH2

HLRU0-SWU1

HLRU8-SWU0

HLRU8-SWU1

HLRU0-SWU0ETH1

ETH2

ETH1

ETH2

ETH1

ETH2

ETH1

ETH2




Figure 16. Site – user plane – physical

IWS1

MGW01

IP backbone

SDHmux

CDS01

2 E1

PSTN BSC01

4 STM1

MGW - L3SW link: 10.100.9.0/29

IPGEP0-0

IPGEP0-1

IP interface (IPGEP) IPAddress: 10.100.9.1



6 Planning of control and user planeanalyses

Control plane analysis in MSS

Control plane routing in MSC Server (MSS) is fairly similar to the traditionalMSC. For the basics, see Basic Routing Functions. To understand the linkbetween control plane and user plane analyses, see User Plane Routing.Both are available in M-release product documentation library.

BICC signalling with ATM backbone is analogous to ISUP routing. Similaralternative routing applies and dual seizure/glare may occur. SIP andBICC with IP backbone are different in this regard. With SIP signalling theonly limitations are user plane bandwidth and the number of internalprocesses in MSS. Thus there is no alternative routing or dual seizure. Inother words, each destination has only one alternative (subdestination).

User plane analysis in MSS

Compared to the MSC architecture, user plane analysis is usedspecifically in MSC Server System only. It consists of several subanalyseswhich can be chained and linked to different kinds of results. Additionalinformation can be found from User Plane Routing in M-release productdocumentation library.

Generally in MSS System, user plane analysis is not needed for TDMresources. The only exception is the case in which MGWs are controlledby the same MSS, and the interconnection between MGWs is TDM-based.In that case, user plane analysis phase 6 (Interconnecting BNCcharacteristics determination phase) is needed and the ICBNC analysisresult should tell that ICBNC of TDM is used. However, in this case thereare no UPDs but UPDRs are in use.

MSC does not use UP analysis.

The structure of one analysis is depicted in the following figure:




Figure 17. User plane analysis structure

User plane analysis has input attributes to be analysed, similar toextended preanalysis and attribute analysis. Each attribute can beanalysed in one or more subanalyses, and the subanalyses can bechained.

Attribute is a call-related variable. The value of the attribute is the value ofthe variable. In one subanalysis, there can only be one attribute, but thehandling of the different values of this attribute may differ. For example, theanalysis may continue from the next subanalysis with one value ofattribute, but with some other value the analysis goes to the final result.

UNKANA/UNKRES is met when the attribute does not exist in thisparticular call, or a phase of the call. You do not need UNKANA/UNKRESif the handling is the same as in the default case (DEFRES/DEFANA). Theresult goes to default branch if none of the explicitly defined values match.Note that a missing value of an attribute may not be a fault. For example, inan MS- or PSTN-originated call the PUPD is UNK (unknown) because theincoming resource is a TDM resource.

subanalysis

subanalysis

Result_subanalysis

Parameter Default result

subanalysis

subanalysis

Result_subanalysis

Result_subanalysis

Default result

Final result

Parameter

Parameter

Parameter

Default result

Default result



The figure below shows the flow of output/input attributes. For example,the preceding UPD determination sets PUPD, which is used as an inputattribute in three other phases.

Figure 18. User plane analysis phases

The following describes the relationship between the six phases of userplane analysis and its results:

1. Preceding user plane destination:

Identifying the user plane destination for the incoming side.

2. Succeeding bearer network connection (BNC) characteristics:

Indicating what type of bearer is used at the outgoing side.

3. Call Mediation Node:

Indicating whether MSS should act as a transit serving node (TSN)or as a call mediation node (CMN).

4. Succeeding user plane destination:

Identifying the user plane destination for the outgoing side.

5. Succeeding action indicator:

Indicating which bearer establishment method is used at theoutgoing side.

6. Interconnecting bearer network connection identifier (BNC-ID)characteristics:

6. Inter-connectingBNC characteristics

determination

4. Succeeding UPDdetermination

2. Succeeding BNCcharacteristicsdetermination

1. Preceding UPDdetermination

5. Succeeding actionindicator determination

3. CMN determination




Indicating what type of bearer is used between two MGWs controlledby one MSS.

User plane analysis phase analysis results:

. PUPD - Preceding UPD determination

. SBNC - Succeeding BNC characteristics determination

. CMN - CMN determination

. SUPD - Succeeding UPD determination

. SAI - Succeeding Action indicator determination

. ICBNC - Interconnecting BNC characteristics determination

Despite the fact that each subanalysis has multiple input attributes, onlythe necessary attributes are analysed. Parallel to this, despite the multiplesubanalyses only a few of them need to be used in the call scenario. Youare recommended to create a number of final results and a subanalysisand in this way establish a tool set which can be used in differentconfiguration setups.

Example Planning user plane analysis configuration in MSS1

The figure below shows an example user plane analysis configuration inMSS1. In this example there are two backbones: ATM and IP backbone.



Figure 19. Example network for user plane analysis

First you need to create the routes, circuit groups (CGR) and user planedestination references (UPDRs).

. VMGWxx: For each (V)MGW you may assign a BCU-ID parameterwith JG MML group. It is recommended that all Virtual MGWs in aphysical MGW have the same BCU-ID.

. UPD1: AAL2, VMGW11 & VMGW12 (UPD MML).

. UPD3: AAL2, VMGW22.

. UPD4: IP, VMGW21&VMGW22.

. CGR1: UPDR1. Preceeding UPDR is read from incoming circuitgroup data in incoming calls.

. CGR2: No UPDR since this is TDM. A interface channels arereserved independent of UP analyses. Also the MT side circuit isreserved independent of incoming side A interface trunk.

. CGR3: No UPDR.

. RNC CGR4: Does not exist. UPDR4 is read from RNC data.

RNC1

MSS1 MSS2

BSC1 ATMBB

MGW3

VMGW31

VMGW32

IPBB

route1 -> (s)UPDR1CGR1 -> (P)UPDR1

route4 -> (s)UPDR4CGR4 -> (P)UPDR4

No UPDRCGR2, Route2

No UPDRCGR3, Route2

AAL2, UPDR3no CGR4, no Route

AAL2, UPDR1CGR1, Route1

IP, UPDR4CGR4, Route4

MGW1

VMGW11

VMGW12

MGW2

VMGW21

VMGW22




. Route1: CGR1, UPDR1. For outgoing calls, the Succeeding UPDRis read from the route data. If MGW1 and MGW2 both have ISUPconnection to PSTN it is possible to optimise the MGW usage. If youset different BCU-ID values on the routes, MSS compares (v)MGWBCU-ID. For these destination numbers there should be twoalternative routes (RouteX and RouteY). MSS prefers the matchingvalues.

. Route2: CGR2&CGR3. No UPDR since this is TDM.

. RNC Route3: Does not exist.

. Route4: CGR4, UPDR4.

. Note: For UMA solution for MSC Server (A+ interface) the UPDR isdefined into UMA Network Controller (UNC) data. For UMA solutionfor GSM (A interface) the UPDR is not relevant.

It is recommended to create the minimum number of UPDs, that is, whenthere is a real difference between UPDs. And also to add all VMGWs to allUPDs that are supported.

Example Planning subanalyses/phases

Preceeding UPD determination

This phase is executed in the beginning of the call, right after the setupmessage is received by MSS. The purpose of this phase is to enable ATMand IP backbones concurrently and/or allow different speech codecs and/or allow a different IP version addressing on user plane. This phase isexecuted only in the case of calls originating from the BICC/SIP corenetwork. In inter-MSC Server handovers, this phase is executed only in thetarget MSC Server.

In this example the following settings are needed:

. If UPDR=1 => UPD:=1. Call is coming from MSS2 with ATMbackbone.

. If UPDR=4 => UPD:=4. Call is coming from MSS2 with IP backbone.

Calls coming from RNC/Iu read UPD:=1 from RNC data, nothing specific isrequired in user plane (UP) analysis. Design the analyses so thatDEFANA/DEFRES goes to the appropriate handling (CONTINUE withoutany parameter setting in this case).



When calls come from IMS using SIP, the calling user’s IP address type(IPv4 or IPv6) should be checked. Each IP version should have a separatePUPD so that the address is allocated using the same IP version. MSSuses the INVITE’s SDP headers IP address (type) for the Preceeding BNCcharacteristics (PBNC).

Calls coming from BSC read route data. Route2 contains CGR2 or CGR3.MSS knows the VMGW from the CGR data.

Succeeding BNC characteristics determination

This phase is executed once MSS has performed the digit analyses. Thisphase is executed only in calls terminating to the BICC/SIP core network.In inter-MSC Server handovers, this phase is executed only in the anchorMSC Server.

For each alternative this analysis must be re-executed by MSS.

. SUPDR=1 => SBNC:=AAL2.

. SUPDR=4 => SBNC:=IPV4.

CMN determination

For a basic case set value INACTIVE, that is, MSS is not a call mediationnode, CMN. CMN is meant for a big network that is not fully meshed andan intermediate MSS conveys the BICC/SIP signalling to destination MSS.Gateway or redirecting MSS shall never be a CMN. If MSS is a CMN (thatis, sees control plane only), On-line Call Monitoring (OLCM) may have animpact here. In case of a monitored call, CMN may have to be INACTIVE.

For more information, see User Plane Routing in M-release productdocumentation library.

In SIP calls Nokia VoIP Server (NVS) call control has an in-build logic todefine CMN depending on the call case. In most cases SIP-SIP calls aredetermined as CMN calls. Calls terminating to an announcement have nosignificance in this respect. In SIP-SIP call it is possible to change theCMN mode from ACTIVE to INACTIVE during the call setup. This happensin two cases:




. Call forwarding: when the forwarded to number leads to PSTN or toany subscriber in the CS domain (MGW is needed for GSM/UMTSterminating calls also), for example.

. Announcements: CMN mode changes to INACTIVE for theannouncement period and it changes back to ACTIVE after theannouncement. The CMN mode change is not supported duringmidcall.

Succeeding UPD determination

This phase takes place before sending call setup to next/adjacent MSS.For a basic case set the following:

. SUPDR=1 => SUPD:=1.

. SUPDR=4 => SUPD:=4.

Here you can optimise and take the incoming side into account. Forexample, if a call comes from IP backbone, and is routed to another MSS,also the outgoing side could use IP.

Succeeding Action Indicator determination

This phase takes place before sending call setup to next/adjacent MSS.For a basic case set the following:

. SBNC=IP => SAI:=FORW.

. SBNC=AAL2 => FORW or BACK. FORW (forward) is the bestchoice if the originating MGW has E.164 analyses for the targetMGW address. A fully meshed network benefits from using thisoption. In BICC setup source MSS sends IAM (SAI=FORW,BNC=AAL2). The target MSS returns BICC APM (E.164address).The source MGW analyses this address, and sends AAL2 ERQ tothat address. With Transcoder-free Operation (TrFO) and codecnegotiation the establishment method is 'delayed forward tunneling'with this FORW setting.

BACK (backward) is a good choice when the target MGW hasanalyses for the source MGW address. IAM contains the sourceMGW address, and target MGW sends ERQ to source MGW.

DFORW may also be used with AAL2. Here terminationID isreserved when MSS receives acknowledgement from the next MSS.



If SIP signalling is used, FORW is the only option. In SIP -terminatedcalls, the UPANA phase 5 Succeeding action indicator analysis isnever called as SIP does not provide alternatives. Consequently, noUPANA phase 5 settings are required for SIP calls.

Interconnecting BNC characteristics determination

This phase is executed if the (same) MSS controls the 2 MGWs for thecall. In the case of inter-MSC Server handover this phase is executed inthe MSC Server which have to handle two MGWs for the call: it can be inthe anchor and the target MSC Server or both depending on the networkconfiguration.The purpose of the phase is to define whether TDM, IP orATM is used between the two MGWs. If the virtual MGWs belong to thesame physical MGW, MSS uses AAL2 for most cases (see the notebelow). The result value depends on the backbone (BB) between MGWs.If the MGWs are on different sites you must use the BB available.

Note that the behaviour is defined by the 53:13IC_CONF_OPT_IN_PHYS_MGW PRFILE parameter which is set to true bydefault. The MSS uses this parameter in case two MGWs are required fora call. If this parameter is active, the MSS checks whether the selectedvirtual MGWs are within the same physical MGW or not. In case they are,the MSS skips the execution of the User Plane Analysis phase 6. TheICBNC determination assumes that the correct ICBNC is AAL2. Also,topology database is not inquired for interconnection. It is assumed thatthe virtual MGWs automatically have the interconnecting resource.Otherwise, if the MGWs are not in same physical MGW, the ICBNCdetermination is performed and the topology database is inquired. In casethe parameter is not active, the functionality is not in use and the ICBNCdetermination as well as topology database inquiry is performed normallyin each relevant scenario.

In the example with 2 MGWs under MSS1 you could set either IP or ATM.In the example TDM is not an option.

The situation is different if you have 3 or more MGWs under the sameMSS, and some have ATM and some IP connectivity in between them. Insuch a case you need to analyse all combinations of the preceeding UPD(to check the source MGW) and succeeding UPD (to check the targetMGW). The combination indicates which inter-connection hop is needed.To ease the configuration, use the default result (for example ATM), andanalyse/list the exception cases requiring the other value (for example IP)only.

Special cases

Emergency call




Emergency call may use special user plane routing.

Handover

Inter-MSS handover requires some special attention. Even if the SUPDhas other than G.711 default codec, the source MSS sets G.711 forspeech calls. With PRFILE parameter COMP_ROUTES_USED_IN_HO029:0013 you can set Transmission Medium Requirement (TMR) to UDI(64kbit/s). In that case there will be no speech codec.

The Interconnecting BNC determination analysis phase is executed inthose calls that require two MGWs for setting up the call. In inter-MSCServer and intra-MSC Server handovers, the anchor MSC Server will setthe Preceding BNC (PBNC) and Preceding Signalling Type (PSIGT)attributes to UNKNOWN values in the user plane analysis phases.

The above instructions are also valid when the inter-MSC Server handoveris made through an ISUP connection and two MGWs are needed underthe anchor MSC Server. The Interconnecting BNC determination analysisphase is affected by this change.

Inter-MSC Server handover indicator (IMSSHI) can be used in user planeanalysis phases to separate the inter-MSC Server handover calls from thebasic calls. The Succeeding UPD (SUPD), Succeeding UPDR (SUPDR),Succeeding BNC (SBNC) and Succeeding Signalling Type (SSIGT)attributes can be used in non-handover cases by applying IMSSHIattribute. The Preceding UPD (PUPD), Preceding UPDR (PUPDR),Preceding BNC (PBNC) and Preceding Signalling Type (PSIGT) attributescannot be used or modified so that unknown values can also be handled inthe subanalyses which are for the inter-MSS handover calls.

The following table summarises the attributes that can be used in the userplane analysis phases. The columns represent the phases of the analysis.The rows list the possible attributes of the phases. The meanings of thesymbols are:

+ One attribute can be used in one analysis phase.X These attributes have special behaviour in

handovers. They have the value UNKNOWN if theanalysis phase is executed due to a handover.



Table 2. The attributes of the user plane analysis phases

UPAphase

1 2 3 4 5 6

PUPD SBNC CMN SUPD SAI ICBNC

EMCI + + + + +

IMSSHI + +

OLCMI +

ODC + + + + + +

PAI + X X X X

PBNC + X + X X

PBCU + X X X

PSIGT + X + X X

PUPD X X X

PUPDR + X + X X X

SAI +

SBNC + + + +

SBCU +

SSIGT + + + + +

SUPD + +

SUPDR + + + + +

UPBREQ + + + + +

NbUp framing and 5 ms/20 ms packetisation on UPD

When you define a User Plane Destination (UPD) with User PlaneTopology Data Handling (JF) MML, you may also define the packet intervaland user plane framing framing for calls using G.711 codec or for callsusing Transmission Medium Requirement (TMR) of non-speech.

The G.711 codecs with Nb UP framing protocol use 5 ms packetisationperiod, and the GSM FR/GSM EFR/AMR-NB codecs use 20 mspacketisation period (according to 3GPP specifications). The Nokiaproprietary Nb' user plane can be used for G.711 codec or for data callswith non-speech TMRs. In this case, Nb UP is not used, and thepacketisation period used by Nokia MGWs is 20 ms. This functionality canbe activated by the user plane destination-specific TRUNK CAPABILITYparameter, and the Nb UP framing protocol is not used.




The Nb' user plane is only available for IP bearer connections and forspeech calls with G.711 codec or for data calls with non-speech TMRvalue. Furthermore, as the Nb' user plane is an alternative for the standardNb user plane, it is available only with the BICC and SIP-T call controlsignallings, which are all normally used to establish Nb interface bearerconnections. The functionality also has dependency on the UPD SpeechTransmission Optimisation Method and UPD Default Codecparameters. The functionality is available for speech calls only when theSpeech Transmission Optimisation Method is Default Codec and theDefault Codec is G.711.

The Nokia proprietary Nb' user plane is also supported for theinterconnecting leg IP bearer between two MGWs that are controlled bythe same MSS. The Nokia proprietary Nb' user plane for interconnectingIP bearer can be used for speech calls with the G.711 codec or for datacalls with non-speech TMRs. This functionality is controlled by the MSSlevel NO_NBUP_ON_MGW_IC_LEG PRFILE (053:0014) parameter.

The following table summarises the configuration.

Note

5 ms is the standard value in Nb (CS-MGW <-> CS-MGW) interfacewith NbUp framing, whereas IMS uses 20 ms packet interval withoutframing. TRUNK and DCODEC are parameters on an UPD.

Nokia supports also 20 ms packet interval in the NbUp interface. In Nbinterface (where Nb UP is used), the 5ms packetisation period is usedfor G.711 codec, but 20ms is used for other compressed codecs.

Table 3. NbUp framing and 5 ms/20 ms packetisation on UPD

Inputvalues

Result

Signalling Call type TRUNK DCODEC Packet interval(ms)

Framing(NbUp)

Comments

BICC Speech Y G.711 20 No

BICC Speech N G.711 5 Yes

BICC Speech Y ≠ G.711 20 Yes

BICC Speech N ≠ G.711 20 Yes

SIP-T Speech Y G.711 20 No



Table 3. NbUp framing and 5 ms/20 ms packetisation on UPD (cont.)

Inputvalues

Result

Signalling Call type TRUNK DCODEC Packet interval(ms)

Framing(NbUp)

Comments

SIP-T Speech N G.711 5 Yes

SIP-T Speech Y ≠ G.711 20 Yes

SIP-T Speech N ≠ G.711 20 Yes

SIP Mb Any Any Any 20 No

BICC-SIP-T Data Y Any 20 No

BICC/SIP-T Data N Any 20 Yes

Note

Set TRUNK” to “N” when TrFO is used.

See also Selecting signalling protocol for call control.

6.1 Minimising hops on user plane

Optimising MGW selection based on BCU-ID

When BICC call control signalling is used, MGW selection can also beoptimised using the BCU-ID that is received from the peer MSS. The BCU-ID is a logical identifier for the MGW that has been selected for the userplane traffic by the peer MSS. In Nokia implementation it can be configuredto be unique on per virtual MGW basis.

The BCU-ID can affect the MGW selection through user plane analysis,where it is available as an input attribute. Depending on the call case andthe BICC bearer establishment method, it can be used to optimise thepreceding or succeeding user plane destination (UPD) selection. This wayit can be used to select an optimal set of MGWs, identified by the UPD,among which the MGW for the user plane traffic is selected.




Forward establishment with delayed MGW selection is used towards thesucceeding MSS. No MGW is selected for the call before sending an IAMmessage towards the succeeding MSS. The succeeding MSS selects anMGW and sends the BCU-ID and the necessary bearer information for thebearer establishment back in the APM message. The BCU-ID identifiesthe selected MGW and is used in user plane analysis for determining thesucceeding UPD. Note that delayed MGW selection is supported with ATMbearer only. Delayed MGW selection with IP tunnelling (BICC signallingtunnels IPBCP) is not supported.

Figure 20. Delayed MGW selection based on BCU ID

The steps during the backward bearer establishment are the following:

1. MSS A determines the succeeding UPD using the user planeanalysis, but does not select an MGW for the call. An IAM messageis sent to MSS B without any BCU-ID. In case codec negotiation isused, the supported codec list in the IAM is composed based on theminimum set of codecs supported by the MGWs belonging to thesucceeding UPD.

2. MSS B selects MGW1 for the call. It sends back the BCU-ID of theselected MGW and the necessary bearer information for bearerestablishment in a backward APM message.

MSSBMSSA

MGW 2

MGW 3

RNC MGW 1

5. MSSA selectsMGW2 from the UPD.

2. MSSB selectsMGW1.

1. IAM

3. APM (bcu-id of MGW1)

4. BCU-ID of MSSB is used inuser plane analysis to determine

succeeding UPD in MSSA.



3. MSS A re-determines the succeeding UPD by re-executing the userplane analysis. Re-execution of the user plane analysis can resulteither in the same or in a different succeeding UPD which wasdetermined in the first step.

4. MSS A selects an MGW from the succeeding UPD. Note that MGWselection inside the UPD can be further optimised using the BIWFaddress. See Optimising MGW selection based on BIWF addressbelow. Note also that if the succeeding UPD is changed, codecnegotiation is used and no MGW supporting the selected codec isavailable in the new UPD, the call is released.

Similar optimisation is possible when other bearer establishment methodsare used. In case of backward establishment or forward establishment withnon-delayed MGW selection, the preceding UPD selection in thesucceeding MSS can be optimised by using the BCU-ID in the user planeanalysis. For related topics, see User Plane Routing in M-release productdocumentation library.

Port expander for integrated MSS

In some networks GSM BSCs may have TDMs connected to bothintegrated MSS and MGW. In such a case you should minimise TDMusage between MGWand MSS. Also in this case the optimisation is basedon BCU-ID.

. MO call:

MSS has a PRFILE parameter defining the BCU-ID for the PCMsconnected to that particular MSS. For the MGW circuits MSScontains the BCU-ID in the MGW topology database. In the controlplane analyses you define a BCU-ID on the outgoing route. Thetrunks going out to PSTN (in the figure below) have distinct routesdepending on whether the circuit is in MSS or MGW. The BCU-ID onthe route is considered as a property. A matching BCU-ID ispreferred. If no match is found on any alternative (subdestination),any route is accepted. This way the MO call using BSC-MSS trunksprefers MSS-PSTN trunks, and MO call using BSC-MGW trunksprefers MGW-PSTN trunks.

Alternatively, or in addition, in the outgoing circuit reservation MSScan favour either MSS (TYPE=CCS) or MGW trunks (TYPE=ECCS),depending on whether the incoming trunk is connected to MSS orMGW, correspondingly. Note that in this solution all MGWs have acommon handling, that is, they all have the same value for ECCS.




When a BSC is connected to both MSS and MGW, a new huntingmethod can be applied to MO calls. MSS can be configured to huntcircuits from a circuit group which has the most free circuits. Thisensures that MTcalls will succeed even if the CGRs have a differentnumber of time slots.

Figure 21. Port expander

. MT call:

Works like the MO call. In the A-interface circuit hunting MSS prefersmatching BCU-IDs automatically, that is, the preceding BCU-ID ismatched.

Note that the hunting method introduced for MO calls above doesnot apply to MT calls.

Optimising MGW selection for MT call using MSRN/LAC

Mobile Station Roaming Number (MSRN) allocation on a Location AreaCode (LAC) basis is beneficial only if an MSC (not MSC Server) isconnected to PSTN or if TDM backbone is used within PLMN.

This is a special case in which transit MSC (TMSC) (not MSS) isconnected to PSTN. TMSC makes the HLR enquiry for a roaming number(MSRN). The visited MSS is configured to allocate MSRN per LAC. ThusTMSC receives MSRN based on location of the called party. The differentMSRN ranges lead to different route and thus directly to the correct MGW.

MSS default:BCU-ID1

MGW01BSC01

MSS01

BCU-ID2

Route1:BCU-ID1

Route2:BCU-ID2

PSTN



Figure 22. MT call optimisation based on MSRM range

The user plane routing can be optimised when the VMSS controls morethan one physical MGW. This is done in the following way (if MSRN isallocated on a LAC basis):

. Allocate LAC on a physical MGW and BSC basis. This principleaffects radio network planning as well.

. Create one additional UPD, containing all vMGWs of MGW01 andMGW02.

. Create separate UPDs for the MGW01 (connected to BSC01) (seethe figure above) and MGW02 (BSC02). To be precise, these UPDsare for all vMGWs of the physical MGWs that handle this particularMSRN range.

Solution 1 (EXPANA):

The VMSS of the called party detects the MSRN ranges in the extendeddigit preanalysis. The extended digit preanalysis result sets OriginalDialling Class (ODC) which is a numeric value. The ODC can then be usedas an input attribute in UPANA phase 1.

Solution 2 (dedicated CGRs):

T/GMSC01 VMSS02

MGW02

BSC01

BSC02

PSTN

MGW01

MSRN1 ->Route1:

MSRN2 ->Route2:

LAC1: MSRN-range1

LAC2: MSRN-range2




. In the CGR definitions (in MGW01 MSS), define separate UPDRs ineach to highlight the destination for the call. For example, defineCGR1:UPD1 for MGW01 and CGR2:UPD2 for MGW02.

. Create separate BICC CGRs between GMSC01 and VMSS02. Forexample, in VMSS02 create one for traffic incoming to MGW01 andone for traffic incoming to MGW02. These CGRs are created both inGMSC01 and VMSS02.

. Calls from GMSS01 can then be routed via the relevant CGRdepending on whether the traffic is intended for BSC01 or BSC02physical MGW.

. This way the MSS will be able to use the UPDR from each of theCGRs in the PUPD phase of user plane analysis to send MGW01traffic to the MGW01 UPD and likewise for MGW02

Note that FN00906 LAC-based MSRN allocation is not needed for 3GLACs. However, since 2G and 3G cells are recommended to haveseparate LACs, the MSRN ranges will be separate. In the solution 1above, no ODC values for the 3G-specific MSRN ranges have to becreated.

If a BSC is multi-homed to both MGWs, the MSRN range will lead to aUPD that contains all vMGWS of both pMGWs (assuming there are 2pMGWS under the MSS control). At present, MSS is not able to useoptimal MGW selection (before PDC05401).

Optimising MGW selection based on BIWF address

In Nokia implementation the BIWF address represents the address of aphysical MGW. When one physical MGW is split into several virtual MGWs(as in the following example), each virtual MGW is identified by the sameBIWF address. It is possible that the individual virtual MGWs belonging tothe same physical MGW are controlled by the same or a different MSS.

Figure 23. MGW selection based on BIWF address

MSSA BIWF address of MGWV1

RANAPRANAP H.248H.248

Physical MGWP12

Virtual

MGWV1

Virtual

MGWV2

MSSB

RNCRNC



When BICC call control signalling is used between MSSs or in intra-MSScall cases, the BIWF addresses of the virtual MGWs can be used in theMGW selection process to select virtual MGWs from the same physicalMGW for the call. This kind of optimisation benefits from the resourceusage's point of view. In Nokia MGW implementation no external bearerconnection is required between the virtual MGWs belonging to the samephysical MGW. In call cases between MSSs with BICC call controlsignalling the steps in the selection process are the following:

1. BIWF address is received from the preceding node in the IAM orfrom the succeeding node in the APM, depending on the BICCbearer establishment method used.

In case of backward establishment or forward establishment withnon-delayed MGW selection, MSS A first selects an MGW for thecall. In this case MSS B receives the BIWF address of the selectedMGW in the IAM.

2. In case of forward establishment with delayed MGW selection, MSSB first selects an MGW for the call. In this case MSS A receives theBIWF address of the selected MGW in the APM.

3. The received BIWF address is analysed by MSS during the MGWselection procedure. MSS recognises that a virtual MGW with thesame BIWF address is included in the previously determined UPDtowards the other node. Since the BIWF addresses of the MGWs arethe same, this means that the used virtual MGWs are physicallylocated in the same network element.

4. MSS selects the Virtual MGW from the same physical MGW for thecall.

If there are more virtual MGWs in the UPD which belong to the samephysical MGW, MSS selects from those MGWs that are based on thedefined load sharing value.

The BCU-ID-based MGW selection optimisation can be especially usefulwhen CMN nodes are involved in the call between the MSSs that controluser plane resources. In this case determining an optimal preceding orsucceeding UPD towards the peer MSS can be problematic because theCMN node can hide the identity of the peer MSS that controls user planeresources. The BCU-ID can be used to overcome the problem. It canidentify the MGW that was selected for the call by the peer MSS. Thisinformation can be used in user plane analysis to select an optimal UPDthat provides connectivity towards the MGW selected by the peer MSS.

For more information, see User Plane Routing in M-release productdocumentation library.




VMGW selection for SIP calls

When planning the Virtual MGW selection for SIP calls, it is important toensure equal load sharing between VMGWs. Both incoming and outgoingside will have an UPD. The incoming circuit group and thus the incomingUPD is selected by the preceeding network element. In the outgoing sideSIP calls have a special route (SPCROU) record. You need to configureload sharing values for VMGWs for both incoming and outgoing UPD.

VMGW TDM borrowing

TDM borrowing saves TCU’s transcoding capacity. TDM resources arealways tied to a certain Virtual MGW (VMGW). TDM borrowing is a usefulfunctionality when MSS has reserved the H.248 context (for exampleRANAP early assignment, handover, etc.). and the outgoing TDM circuit ishunted thereafter. If the TDM circuit belongs to a different VMGW but thesame physical MGW, TDM borrowing allows to control the TDM using theexisting H.248 context. In MSS the PRFILE parameterIC_CONF_OPT_IN_PHYS_MGW 053:0013 controls the functionality.

6.2 SS7 Signalling Transport over IP (SIGTRAN)

Signalling transport (SIGTRAN) is a set of protocol specifications.SIGTRAN defines a framework for how different (existing) signallings canbe transferred over IP. If the operator has already invested in an IP networkin order to be able to carry voice over IP (VoIP), the efficiency of thenetwork is further enhanced by also transferring all signalling traffic over IP.

If SIGTRAN messages (ISUP/CAP/MAP/INAP over IP) are routed viaMGW, the following is relevant: it is possible to have only one SIGTRANassociation set between MGW and MSS per (physical) MGW. To balancethe load, it is recommended to create the association set in the MSS sideinto a BSU unit for the MGW connection. (H.248/MEGACO uses SCTP butit does not use an association set.)

For SIGTRAN links you need to plan the SCTP associations. The followingfigure shows the associations in a logical level. You should keep in mindwhich MSS computer units control the MGWs. On one hand, multiplevirtual MGWs are recommended to balance the load. On the other hand, ifpossible, the same units should not control MGWs and SIGTRAN links.For example, SIGU-4 to SIGU-6 could control the MGW. In other words,the units should be loaded in a balanced way. For the sake of simplicity,links to foreign PLMN and SCPs are not shown below. For example, SIGU-7 could be used for CAP to SCP and SIGU-8 for roaming via STP.



Figure 24. Logical configuration of MAP signalling links using SIGTRAN

SIGTRAN and TDM parallel use

SIGTRAN network may be backed up with TDM SS7 network. There aredifferent possibilities for this implementation:

1. Primary (usually SIGTRAN) and secondary (usually TDM SS7)transport networks.

2. Separating some signalling messages to SIGTRAN and others toTDM SS7.

3. Separating SCCP traffic from non-SCCP traffic.

4. Separating traffic based on an SCCP field. GTanalysis also providesadditional means for separating traffic. The separation can be basedon any SCCP field that can be analysed:

HLR01

HLRU-0

HLRU-1

HLRU-2

HLRU-3

MSS01

SIGU-0

SIGU-1

SIGU-2

SIGU-3

MSS02

SIGU-0

SIGU-1

SIGU-2

SIGU-3




. Digits. The most usable of these is the division between thedestination GTaddresses (digits). This allows, for example, theseparation of MO-SMS traffic from other MAP traffic (GT-address of the SMSC points to different result than the others).

. Translation Type

. Numbering Plan

. Nature of Address

The separation of traffic to different Signalling Link Sets requires the use ofa separate SPC – either in a different signalling network (NA0, NA1, IN0,IN1) or the usage of an additional point code. Note that you cannot use thesame SPC value in SIGTRAN and TDM networks unless you use separatesignalling networks (NA0 and NA1). It should also be noted that if separatesignalling networks are used for SIGTRAN and TDM SS7 (for exampleNA0 and NA1), it is not possible to configure the TDM links to beredundant to SIGTRAN links, as it is not possible to create a SignallingRoute Set to an adjacent SPC in signalling network X using a transfer SPCin signalling network Y.

If you decide to select additional point codes, Nokia Siemens recommendsthe use of IWF type of Additional Point Code whenever possible.

The IWF method allows the use of two Signalling Link Sets between anetwork element pair.

The IWF method can only be used with Routing Indicator set to GT, sinceSCCP also carries the point code in the data part. DPC+SSN cannot beused as routing indicator. Therefore, for example, separating ISUP/TUPmessages from MAP/CAP/INAP messages is possible. This is done bydefining SP A in circuit groups and SP Aa as the GT result (or vice versa).Therefore ISUP/TUP can be routed in SIGTRAN while MAP/CAP/INAPare routed in TDM SS7 links, or vice versa.



Figure 25. Additional Point Code – IWF Type

In the figure there are Signalling Link Sets from:

. SP A -> SP B

. SP A -> SP Ba

. SP B -> SP A

. SP B -> SP Aa

Note that no link sets originate from Aa or Ba. As in the USP type ofadditional point code, if the DPC=Ba, the OPC is changed to OPC=Aa.Similarly, if the DPC=Aa, the OPC is changed to OPC=Ba. This can beunderstood as a logical link between Aa and Ba, and neither SP A nor SPB is used as transit SPC. Again, this is transparent to the user part.

Now the Signalling Link Set from SP A to SP B can be, for example, TDMSS7, while the Signalling Link Set from SP A to SP Ba can be SIGTRAN.There is no conflict as the SP B is different from the SP Ba; from SignallingLink Set point of view the SPCs can belong to separate network elements.

NE2

User Part

DPC=SP BOPC=SP Aa

DPC=SP BOPC=SP A

NE1

User Part

DPC=SP BaOPC=SP A

DPC=SP BOPC=SP A

SP A

SP Aa

SP B

SP Ba

Signaling link:

OPC = SP AaDPC = SP Ba

Signaling link:

OPC = SP ADPC = SP B




See also Configuring Management Cluster Point Code in Migration toMSC Server System.

SCTP parameters for satellite IP links

Because satellite links are susceptible to delays, SCTP parameters forsatellite IP links must be configured differently from Ethernet connections.

SCTP retransmission parameters have to be configured to accommodatefor round-trip delays. To avoid unnecessary retransmissions, especiallyparameters RTO.min and RTO.max must be adjusted to a value above theround-trip delay caused by a satellite link.

For more information on connectivity over satellites, see Connectivity over

satellites in Site Connectivity Guidelines for CS Core Network. For moreinformation on a pre-packaged SCTP parameter set for satelliteconnectivity, see Network element supervision in Site ConnectivityGuidelines for CS Core Network.

For a more general overview on SCTP parameters, see SS7 SignallingTransport over IP available in network elements’ product documentationlibraries.

6.3 Signalling Management Cluster

Management Cluster is needed if BSC or RNC does not support thesending of control plane and user plane signals to different addresses(signalling point codes, SPC). In MSC Server System this is essentialsince the user plane goes to MGW and the control plane to MSS. BothMSS and MGW support the Management Cluster feature (Feature 31352Additional Signalling Point Codes). BSC/RNC is connected to Gatewaynode (B) which checks the signals from Switch A (BSC/RNC) toApplication Node C. With the NPC MML command you define those MTP/M3UA user parts that are for own handling and those that are to beforwarded to the application node. The main input is the SIO that consistsof network part (NA0, NA1, IN0, IN1) and user part. For example, for NA0(SIO’s is 8xH):

. NA0 SCCP 3 -> SIO=83

. NA0 TUP 4 -> SIO=84

. NA0 ISUP 5 -> SIO=85

. NA0 AAL2 C -> SIO=8C



If MGW is the gateway node, SIO=8C (for NA0) is assigned to own nodefor family 452H, but SIO=83/SCCP (NA0) are forwarded to MSS (MSGSERV is “T”/“TER” in the MML). Note that both BSSAP and RANAP run ontop of SCCP, whereas ALCAP is seen as “AAL2” in the MML.

Figure 26. Signalling Management Cluster

For more information, see Feature 31352: Additional Signalling PointCodes, in M-release feature documentation.

See also Configuring Management Cluster Point Code in Migration toMSC Server System.

6.4 Planning virtual MGW configuration

The virtual Media Gateway (VMGW) concept provides better load sharingand resiliency. It also enables multiple MSC Servers (MSS) to control thesame MGW. This in turn provides more efficient user plane routing, that is,UP does not have to go via 2 MGWs even if the users are in differentMSSs.

OPC=SP ADPC=SP C

Switch A

SP A

OPC=SP ADPC=SP C

OPC=SP ADPC=SP C

Switch C

User Part

OPC=SP ADPC=SP B

Switch B

MTP

OPC=SP ADPC=SP C

SP B

SP C

User Part/MTP




If the physical MGW consists of multiple ISU computer units, it should bedivided into several “virtual MGWs”, each of them controlled by a differentMSS, from which resources are allocated and released using H.248/MEGACO protocol. Each VMGW from the same physical MGW does nothave to be controlled by a different MSS. The advantage of having a virtualMGW is that several MSSs can control the same physical MGW when splitinto several virtual MGWs. It is recommended to use this feature in order tospread the call control equally through all the signalling units. From MSSpoint of view, virtual MGW is just like a physical one.

Figure 27. Virtual MGWs shared among two MSSs

IP and ATM resources are then in a pool, not controlled by a specific MSS,and they are shared by all virtual MGWs inside one physical MGW.

TDM resources are exclusively and statically controlled by a specific MSS,and they are dedicated to a particular virtual MGW.

MGW

MGW

RNC RNC RNC RNC

MSS

MGW

RNC RNC RNC RNC

MSS

MGW

MGW

RNC RNC RNC RNC

MSS

Virtual MGW

MSSMSS



Principles that need to be taken into account:

. There is a one-to-one relationship between the signalling unit inMSS (SIGU/CCSU) and the signalling unit in MGW (ISU).

. One ISU can be controlled by a maximum of 5 SIGU/CCSUs. ThevMGWs of a particular ISU can be controlled by the same MSS ordifferent MSS. Even thought the MGW’s IP address is the same, theport number is assigned on vMGW basis. In order to do this, MSSdifferentiates each VMGW in an ISU (the same IP address) using theIP port number configured for each VMGW on the MGW. Thus eventhe same signalling unit in MSS can see multiple (v)MGWs in thesame ISU/IP address.

. One SIGU/CCSU can handle a maximum of 16 virtual MGWs.

. One VMGW can have a limited amount of circuit groups (10).

. One E1/T1 can not be split over multiple circuit groups (CGR).

Dimensioning rules are:

. In practice one ISU can handle 3000 simultaneous calls, or 90 000Busy Hour Call Attempt (BHCA), whichever limit is met first.

. In line with 2300 simultaneous calls per SIGU of MSS (MEGACOcontexts).

Note that MGW connection capacity licensing introduced in U3C may limitthe virtual ISU capacity.

The rules of thumb for dimensioning are:

. Number of VMGWs is equal to the number of ISU signalling units inone physical MGW.

. In theory one ISU can control 5 virtual MGWs. Thus 50 VMGWs canbe defined per physical MGW element with the maximum number ofworking ISUs (10+1).




Figure 28. Virtual MGWs and signalling units

Each signalling unit (SIGU) in MSSs is assigned two logical IP addresses:

. IP address 1 corresponds to Primary MSS address for MGW.

. IP address 2 corresponds to Secondary MSS address for MGW.

Both addresses specified to a particular VMGW must always be located inthe same SIGU of MSS. However, different VMGWs of one MGW elementcan be connected to various MSS elements.

The following requirements must be met:

. Primary and secondary MSC Server addresses are known.

. IP address/domain name (for H.248 traffic) of each VMGW is known.

. A circuit group of each VMGW is created.

. The E.164 address of MGW is known.

MBB1 MBB2

MGW1

ISU-0

el0 el1

ISU-1 BU-6 BU-7ISU-2 ISU-3 BU-4 BU-5

SIGU-0 SIGU-1 SIGU-2 SIGU-3 IBU-1

WMGW1 WMGW2 WMGW3 WMGW4 WMGW5 WMGW6 WMGW7 WMGW8

SIGU-0 SIGU-1 SIGU-2 SIGU-3

el0 el1 el0 el1 el0 el1 el0 el1 el0 el1 el0 el1 el0 el1



Virtual MGW and MEGACO example configuration in MGW and MSS

This example assumes that MSS controls MGW. In MGW there are 10working ISUs, and thus the physical MGW is divided into ten virtualMGWs, all under the control of the same MSS: VMGW11, VMGW12,VMGW13, up to VMGW19. There is a one-to-one relationship betweenISU and SIGU. Only one VMGW exists per ISU.

Figure 29. One-to-one relation between ISU and SIGU for VMGW definitions

Table 4. Virtual MGW and MEGACO configuration in MGW, 1

VirtualMGWname

ISUunitID

Own IPaddress(IPaddressof ISU)

Owndomainname

Own IPport

InternalCGRnumber

Analysistreenumberfor AAL2

Transport type

Codingtype

String Numeric

Mnemonic

Numeric Numeric Numeric Numeric Numeric Numeric

1...16chars

0...n #.#.#.#/#::#

1...64 chars 8009...8013

1...1023 2...9999 0...1 0

- - - - - - - - -

VMGW11 0 10.100.2.11

- - 500 2 0 -

MGW data

1 2 30 4 5 6 7 8 9

MSS data

SIGU

SPC: 200, NA0

VMGW12

12

1

VMGW13

13

2

VMGW14

14

3

VMGW11

11

0

VMGW15

15

4

VMGW16

16

5

VMGW17

17

6

VMGW18

18

7

VMGW19

19

8

VMGW20

20

9

SPC: 100, NA0

VMGWname

BCU-ID

ISU




Table 4. Virtual MGW and MEGACO configuration in MGW, 1 (cont.)

VirtualMGWname

ISUunitID

Own IPaddress(IPaddressof ISU)

Owndomainname

Own IPport

InternalCGRnumber

Analysistreenumberfor AAL2

Transport type

Codingtype

VMGW12 1 10.100.2.12

- - 501 2 0 -

VMGW13 2 10.100.2.13

- - 502 2 0 -

VMGW14 3 10.100.2.14

- - 503 2 0 0

VMGW15 4 10.100.2.15

- - 504 2 0 -

VMGW16 5 10.100.2.16

- - 505 2 0 -

VMGW17 6 10.100.2.17

- - 506 2 0 -

VMGW18 7 10.100.2.18

- - 507 2 0 -

VMGW19 8 10.100.2.19

- - 508 2 0 -

Table 5. Virtual MGW and MEGACO configuration in MGW, 2

VirtualMGWname

Primary MSS IPaddress (IPaddress of SIGU)

Primary MSSdomain name

Secondary MSSserver number

Secondary MSS IPaddress

String Mnemonic Numeric Numeric Mnemonic

1...16chars

#.#.#.#/#::# 1...64 chars 1...5 #.#.#.#/#::#

- - - - -

VMGW11 10.100.2.55 - - 10.100.3.55

VMGW12 10.100.2.56 - - 10.100.3.56

VMGW13 10.100.2.57 - - 10.100.3.57

VMGW14 10.100.2.58 - - 10.100.3.58

VMGW15 10.100.2.59 - - 10.100.3.59

VMGW16 10.100.2.60 - - 10.100.3.60

VMGW17 10.100.2.61 - - 10.100.3.61



Table 5. Virtual MGW and MEGACO configuration in MGW, 2 (cont.)

VirtualMGWname

Primary MSS IPaddress (IPaddress of SIGU)

Primary MSSdomain name

Secondary MSSserver number

Secondary MSS IPaddress

VMGW18 10.100.2.62 - - 10.100.3.62

VMGW19 10.100.2.63 - - 10.100.3.63

In the MSS configuration only one MSS address is defined for eachVMGW. This is because the VMGW initiates the registration to MSCServer. In the registration MSS receives both IP addresses of the VMGW.

Table 6. Virtual MGW and MEGACO configuration in MSS, 1

MGWdomainname

MGW IPaddress (IPaddress ofISU)

Portnumber

MGW name MGW type Generalroutenumber

IWF route

String Numeric/hex Numeric String Mnemonic Numeric Numeric

64 chars #.#.#.# (IPv4)#:#:#:#:#:#:#:# (IPv6)

0...65535 16 chars IWF 0...4095 1...4095

- - - - - - -

- 10.100.2.11 8009 VMGW11 Gen - -

- 10.100.2.12 8009 VMGW12 Gen - -

- 10.100.2.13 8009 VMGW13 Gen - -

- 10.100.2.14 8009 VMGW14 Gen - -

- 10.100.2.15 8009 VMGW15 Gen - -

- 10.100.2.16 8009 VMGW16 Gen - -

- 10.100.2.17 8009 VMGW17 Gen - -

- 10.100.2.17 8009 VMGW17 Gen - -

- 10.100.2.18 8009 VMGW18 Gen - -

- 10.100.2.19 8009 VMGW19 Gen - -




Table 7. Virtual MGW and MEGACO configuration in MSS, 2

MGWdomainname

CTRL type (IPaddress ofSIGU)

CTRL unitindex

CTRL unitaddress

E164address

Local BCU-ID

String Mnemonic Numeric Numeric/hex Numeric Numeric

64 chars CCSU/SIGU/GSU - #.#.#.# (IPv4) #:#:#:#:#:#:#:#(IPv6)

- 0...4294967295

- - - - - -

- SIGU 0 10.100.2.55 35860123456 011

- SIGU 1 10.100.2.56 35860123456 012

- SIGU 2 10.100.2.57 35860123456 013

- SIGU 3 10.100.2.58 35860123456 014

- SIGU 4 10.100.2.59 35860123456 015

- SIGU 5 10.100.2.60 35860123456 016

- SIGU 6 10.100.2.61 35860123456 017

- SIGU 7 10.100.2.62 35860123456 018

- SIGU 8 10.100.2.63 35861023456 019

Transmission method for IP can be IP over ATM or IP over Ethernet. Userplane traffic from MGW can be directed through the IP network interfaceunit (IP-NIU) as IP over Ethernet (IP backbone). Control plane traffic maybe routed via ESA or NIS/NIP.

Separation of user plane and control plane

The IP-based logical interfaces of MGW can be mapped both on the IP-NIU interfaces (if present) and on the ESA24 LAN switching unit (SWU).There are two main options for the logical interface mapping:

1. Control plane (SIGTRAN and H.248 signalling) is routed through theESA24 LAN switching unit and user plane traffic is routed to the IP-NIU. This configuration is shown in Figure IP backbone with Gigabit/Ethernet/Fast Ethernet plus ESA24 Control Plane below. This is thebest option when there is IP connectivity between MSS and MGW.

2. IP over ATM: Only NIP1/NIS1 dimensioning is affected in this case.



a. The control plane is routed to NIS1 (ATM over STM-1/OC-3) orNIP1 (ATM over TDM, IMA). A2SU is ignored.

b. IP packets are forwarded to OMU. NIP/NIS may be usedstarting from U3B.

c. OMU sends packets to the correct ISU via ESA24. Only L2switching is done in Ethernet level.

Figure 30. IP backbone with Gigabit Ethernet/Fast Ethernet plus ESA24(control plane)

For more information on MGW dimensioning, see Dimensioning ofMultimedia Gateway, available on request from Nokia.

1G/100M

100Mb

Edge-router

100Mb

MGW

UserPlane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

IPFGE

NetAct

MSC Server

ESA24

O&M




6.5 Comparison between late and early RABassignment in Iu/3G

Nokia MSS configuration includes an incoming parameter set on the Iucircuit group. The operator can define separately for regular, emergency,and service (group) calls whether early or late RAB assignment is in use.

The advantages for late RAB assignment are:

. codec negotiation is possible throughout the whole system

. radio bearer is reserved only if B party is found and there are noproblems on core network (no waste of radio bearer)

The advantages for early RAB assignment are:

. LBCU ID of the incoming side is present when reserving theoutgoing side (important in multi-MSS call cases)

. faster call setup

Note that even though in late RAB assignment the LBCU ID of the selectedMGW on the incoming side is not known, it is still possible to optimise theMGW selection based on the incoming UPD.



7 Planning of services and features

7.1 Selecting signalling protocol for call control

The operator needs to select whether to use SIP/ISUP or BICC signallingprotocol for call control signalling. In a particular network a combination ofsignalling may be used. In a particular network a combination of signallingmay be used. Here are the basic rules:

. In practice, BICC is used between MSC Servers only. SIP is usedbetween various domains, such as IMS, CS Core, fixed softswitches, corporate networks, and so on.

. SIP for telephony does not require the presence of SS7 signallingnetwork. BICC does, unless it is conveyed over SIGTRAN. SIP usesUDP or TCP which do not guarantee similar kind of pre-knowledgeas provided by the SS7 signalling links. Introduction of SCTPtransport for SIP changes this.

. SIP for telephony requires the presence of a resolver (either a DNSserver or local resolver file) which is able to convert the case-sensitive Fully Qualified Domain Name (FQDN) to an IP address.BICC uses pre-configured signalling links of the SS7 signallingnetwork.

. SIP for telephony can be used to establish user plane connectionsover the IP network. BICC can be used to establish connections overboth IP and ATM networks.

. SIP for telephony uses Session Description Protocol (SDP)negotiation in which codecs are listed in priority order. BICC usestunnelled IP Bearer Control Protocol (IPBCP) with only a singleframing protocol media type as well as dynamic RTP payload type.

. SIP for telephony does not use Nb UP framing protocol defined by3GPP. BICC uses it to verify that an IP connection on the user planeexists before the call is alerted to the called party.



Planning of services and features

. BICC is an approved and existing Nc interface protocol whereas SIPfor telephony is currently being standardised by 3GPP.

. Before 3GPP Release 7 implementation, Nb user plane with BICCrequires extensive bandwidth compared to a SIP-based "Nb" whenG.711 is used.

. SIP profile C tunnels ISUP messages. It is also referred to as SIP-I.In practice, SIP-I can support any ISUP as a tunnelled protocol,whereas it is very likely that BICC and the corresponding ISUP haveto be modified according to need.

. SIP for telephony uses only forward type of bearer establishment byits nature. Backward and delayed establishment methods may beimplemented (such as SDP-less INVITE) but they are not commonlyused.

7.2 Planning CDS network configuration

Nokia Circuit Switched Data Server (CDS) offers a possibility to centraliseInter-working Functions (IWF). User plane is connected via TDM trunks.Control plane uses IP-based NPI protocol. The following figures and thelist below illustrate the possible configurations.

. Figure CDS usage with integrated MSS: IWF may reside in theintegrated MSC Server (MSS). Calls that have user plane via MSSuse the IWF of the MSS. If user plane is connected from RAN toMGW, MGW utilises CDS.

. Figure CDS usage with Standalone MSS: If standalone MSS isused, MGW uses the IWF from CDS in all non-transparent datacalls.

. Figure CDS shared by MGWs: CDS is shared by two (or more)MGWs.

. Figure CDS shared by MGWs with additional redundancy: Toachieve more resiliency, CDS may be distributed. To get the benefitsof the statistical concentration, CDS may be shared by multipleMGWs.



Figure 31. CDS usage with integrated MSS

CP

UP

MSC Server

MGW

GSM

IP/ATMbackbone

WCDMA

CDS

RNC

A

A

H.248/Mecago

Iu-cs

MGW site area

IWF




Figure 32. CDS usage with Standalone MSS

CP

UP

MSC Server

MGW

GSM

IP/ATMbackbone

WCDMA

CDS

RNC

A

H.248/Mecago

Iu-cs

MGW site area



Figure 33. CDS shared by MGWs

CP

UP

MSC Server

MGW1

IP/ATMbackbone

CDS

H.248/Mecago

MGW site area

GDM/WCDMAradioaccess

MGW2





Figure 34. CDS shared by MGWs with additional redundancy

CDS provides the following capacity (fully equipped cabinets):

. Base cabinet: 448 data calls

. Base cabinet + 1 IWF extra cabinet: 896 data calls

. Base cabinet + 2 IWF extra cabinets: 1344 data calls

. Base cabinet + 3 IWF extra cabinets: 1792 data calls

All TDM resources to CDS are network element-level circuits, that is, theyare not tied to any specific virtual MGW (vMGW).

CP

UP

MSC Server

MGW1

IP/ATMbackbone

CDS1

H.248/Mecago


MGW2


H.248/Mecago

CDS2



7.3 Video calls requiring protocol/codec conversion

Video calls between two mobiles do not require a separate video gateway(VGW). For a video call requiring protocol/codec conversion a separatevideo gateway (VGW) is required. The VGW is connected either usingPBX signalling (30B+D) or ISUP. If the PBX signalling is used, the TDMsare either connected to integrated MSC Server (MSS), or use semi-permanent connections from MGW to integrated MSS. If ISUP is used, theconnection is made according to the figure below (Radvision VGW):

Figure 35. VGW using ISUP

With Dilithium VGW, the ISUP connection goes directly to the VGW.

VGW may be connected to NetActTM via a firewall if the VGW does notsupport virtual LAN (VLAN).

See also Video Gateway Integration in M-release product documentationlibrary.

7.4 Planning IN services

Nokia MSC/MSS provides CAMEL phases 1 to 4 and Core INAP CS1. Thetriggering of INAP and CAMEL Application Part (CAP) may be based onNokia MAP extension SSET, OICK/TICK and a trigger in MSC/MSS. Inaddition, CAP can be triggered based on standard CAMEL SubscriptionInformation (CSI).

For Intelligent Network (IN) services the operator should specify thedesired service logic. If the service is required to work while out-boundroaming, CAMEL should be used. It is possible to use INAP in HPLMN anda certain CAP version in non-HPLMN.

ISUP/TDM

TDM(user plane)

TCP/IP

VGWMSC/MSSi/MGW

IntelSIU520




The IN services have an impact on the dimensioning of MSC/MSSsignalling link to Service Control Point (SCP).

For more information, see IN services in CS Core System Overview.

7.5 Planning TFO/TrFO

The Tandem Free Operation (TFO) and Transcoder Free Operation (TrFO)features can be used to provide maximal speech quality by avoidingspeech transcodings decreasing the speech quality. For more informationabout the features, see TrFO in MGW and 2G TFO in MGW, in CS CoreSystem Overview.

TrFO uses out-band signalling to negotiate optimal speech codec betweenfar ends. TrFO works with BICC and SIP signallings, and requires MSCServer System to operate. Out-of-band signalling conveys the AMR modeto the other end. To avoid transcoding the AMR mode should be the samein both ends. TrFO cannot be used on PSTN or on a 64k ATM/IPconnection. In these cases transcoding at the edge is used.

Tandem Free Operation (TFO) is an in-band negotiation of the speechcodec between transcoders. In TFO one or two least significant bits ofeach speech G.711/64kbit/s sample convey the mobile 3GPP codec. If theTrFO fails or the G.711 codec is used, TFO may be used. AMR TFOrequires support from MGW. Standard TFO does not provide anybandwidth savings but in the Nokia solution payload optimisation can beachieved. In the UPDR you define the speech codec and if the other enduses the same codec, less payload is used between MGWs.

TrFO has an impact on user plane and MGW dimensioning.

When TrFO is introduced, new Speech Transmission Optimisation Methodparameter is to be defined on the UPD. The new parameter replaces theold “TrFO” parameter.

. CN: STO-CN functionality; codec negotiation is used towards thepeer core network elements to optimise the codec selection.

. DC: STO-DC functionality; default codec is used towards the peercore network elements.

This parameter value is only relevant in the speech calls and in the userplane destinations (UPD) that are defined towards the peer core networkelements, not in the user equipment (UE) codec selection in the UPDs thatare defined towards the RNCs.



7.6 Planning Voice Mail System (VMS)

The operator needs to decide whether all users have a common voice mailaccess number, or whether each user has a separate one. The latter caserequires a lot of free telephone numbers. In addition, the operator mayprovide a short code for VMS access, such as 123. While roaming outCAMEL may be used to provide short code access to VMS, and to providea calling/redirecting number for the VMS.

Generally, the VMS devices support TDM access only. Thus you needTDMs from MSC, integrated MSS or MGW to VMS.

7.7 Planning Selective Ring Back Tone (SRBT)

For network planning the key question in large PLMNs is whether anyexternal SRBT server can serve a subscriber (case A), or whether aparticular server is needed for a particular subscriber (case B). This issueneeds to be checked from the external SRBT server provider.

In case A or in small networks the server may be located at core sites andMGW have direct connections to the servers. In case B the localconnectivity does not provide great benefits, thus the server could beconnected to the transit layer.

Nokia supports the SRBT feature with a CAMEL-based solution and withan internal service logic. If using the internal service logic solution, theMSC Server (MSS) provides the server address in the form of prefix+MSISDN-B. Thus the users should be split into servers based on theMSISDN ranges. For ported-in subscribers specific servers should beused, for example a certain server for a particular donor network(MSISDNs). If the CAMEL-based solution is used in case B, the SCPservice logic should use MSISDN of the served party as part of theserver’s routing address.

For better feature interaction, the VMSC connected solution with Nokiainternal service logic is recommended. If the served party is roaming inanother PLMN, the triggering criteria in either HLR or GMSC may beutilised to start the service in the GMSC/GMSC Server.




If the SCP -based solution is used, the SRBT affects the dimensioning ofthe CAP signalling. If the GMSC/GMSC Server solution is used, there maybe two HLR enquiries per incoming call. The selective ringback tonerequires a speech path between MGW and the external SRBT server. Fordimensioning, you need to estimate MT BHCA per served SRBT user, andthe average duration of the alerting phase.

7.8 Planning charging

The first step is to define the pricing model for different call cases. It needsto be decided, for example, whether the operator charges for bothoriginating and terminating calls or for originating calls only. It is alsoimportant to decide which Charging Data Records (CDRs) are used forcharging as it is possible to generate the same CDRs in different roles ornodes. For example, for a short message it is possible to generate aSMMO CDR in the VMSC and IWMSC. Also, for a terminated call it ispossible to generate a ROAM CDR in the GMSC or a MTC CDR in theVMSC. Generation parameters make it possible to generate CDRsseparately. CDRs can be generated, for example, for all calls or forchargeable calls only. Generation parameters can be used to eliminateunnecessary CDRs.

CDR content

The next step is to define the pricing of the calls. Network operators mayhave different principles in forming call prices. The final call price is usuallybased on the following charging information:

. Conversation duration

. Time of day

. Subscriber category

. Destination of the call

. Services used, for example video call.

MSS/MSC/HLR does not provide the final call price for billing purposes. Itgenerates charging information that is used in the post-processing systemto calculate the final call prices. Three main approaches exist:



1. The operator configures the detailed billing rates to MSC/MSS,including pulse rate.

2. The operator configures the main tariff zones, which depend on, forexample, the origin of the call or the dialled number. The main tariffclass is stored into CDRs and the post-processing system sets therate accordingly. One way of doing this is as follows:. In the extended digit pre-analysis, various call attributes are

analysed and Original Dialling Class (ODC) is set in the result.The ODC is a numeric value with no other meaning.

. In the charging attribute analysis, ODC is taken as an inputattribute. Depending on the ODC value, different ChargingOrigin value is set in the result.

. In the charging analysis, each charging origin value leads to adistinct main zone, and the main zone is written to the CDR.

3. The operator creates no tariff configuration at all. All rating isperformed in the post-processing system.

Based on the pricing plan, you can define the content of the CDRs. Youmust plan the charging functions in both MSS/MSC/HLR and the post-processing system before commissioning a new customer form. PlanningCDR data consists of the following steps:

1. Define the type of charging data needed for the billing processes(you must know the different call cases and their effect on the CDRdata).

2. Plan and define the CDR structure for each CDR type according tothe billing requirements in the whole network. The correct structuresof CDRs are initially defined at the commissioning stage, accordingto your requirements. Nokia Siemens sends you a proposal of thecharging format before commissioning of charging. This proposal isbased on the features that you have ordered. Therefore, you maynot receive all the possible CDR types.

3. Modify the post-processing system software to handle and processthe CDR data and to produce the final billing data.




Note

When you are designing the generating principles and contents ofCDRs, remember that charging data easily increases to large amounts,which has an effect on the required storing and transfer capacity. This iswhy generating and collecting unnecessary charging data is notrecommended.

In addition, note that you cannot select all the possible CDR types withall the possible fields because the capacity limits may be exceeded.

See also Charging in M-release product documentation library.

Store and transfer charging data

You can define in which device the data is stored. The storing device canbe:

. Virtual Data Storing Device (VDS), used with FTAM/FTP and WDU(Winchester Disk).

. Removable media: an MO-disk (FDU).

If you have several CHU pairs in your MSS/MSC, use a VDS device as theprimary storing device and CTUs/FDUs that are connected to each CHUpair as a spare device. The configuration in each CHU should be identical.

CDRs must be transferred from the MSS/MSC/HLR to the post-processingsystem. Normal charging files stored on the CHU/STU disks aretransferred to the post-processing system as a file transfer over X.25, overLAN connection with the OSI/FTAM file transfer method, or over LANconnection with FTP. If you have the Hot Billing feature, CDRs of specifiedmobile subscribers can be sent immediately after their creation to the post-processing system without storing them on a storing device beforehand.Transfer of these CDRs is carried out via the X.25 or LAN, or over an IPnetwork. Hot billing CDRs should also be included among the normalcharging data for backup purposes. For more information, see Hot billingin Charging in M-release product documentation library.

If possible, it is better to use transfer of hot CDRs via an IP network as theprimary method, due to its greater transfer capacity. It also offersacknowledgement of receipt by the post-processing system.



Transfer using COTS with immediate confirmation also offersacknowledgment of received hot CDRs. When using a COTS link, thesystem will automatically change the transfer path from COTS to VPP(Virtual PAD printers) (HBLOFI) in the event of a communication failure.

The following figure illustrates the possible connection alternatives to theBilling Centre (BC). The selected alternative has an impact ondimensioning the selected link, for example IP transmission. The numberof produced CDRs also has an impact on MSS performance.




Figure 36. Storing and transferring CDRs to the billing centre

MSC/VLR

CHU

WDU CTU

BDCU

FTAM/COTS

BC

RAM

VPP

BDCU

HLR

WDU

CTU

X.25 OSI/LANTCP/IP TCP/IPTCP/IP UDP/IP

FTPGTP’FTP GTP’

FDU

FDU

RAM STU



Immediate CDR Transfer for All Subscribers

Feature 1491 Immediate CDR Transfer for All Subscribers makes itpossible to transfer all CDRs (not just the ones generated for Hot Billingsubscribers) immediately to the post-processing system. Immediate CDRtransfer is based on the standard GTP' protocol, which provides a methodfor fast and reliable data transfer between the MSC and the post-processing system. With GTP', CDRs can be immediately sent to the post-processing system. When using this feature it is not possible to storeCDRs on disks at the same time. If there is no connection to any post-processing system, the CDRs are stored on a hard disk or a magneto-optical disk. Immediate CDR transfer makes it possible to have an up-to-date account balance in near real time. It should be noted that this featuredoes not offer prepaid service.

7.9 Planning Supercharger

Supercharger functionality reduces the location update signalling betweenHLR and VLR/SGSN. The subscriber’s data also remains in the sourceVLR/SGSN when moving to a new (target) one. If the subscriber returns toa previously visited VLR/SGSN, subscription data is not necessarily resentto that particular VLR/SGSN. The target VLR/SGSN indicates to the HLRhow old the subscription data is, thus the HLR may send an update if thesubscription has changed between the visits. The network elements alsosend appropriate indications of supercharger support.

Supercharger can be seen as an alternative for multipoint A/Iu interface. Ifmultipoint Iu/A is used, supercharger provides very little if any benefits.

Supercharger has an impact on MAP link dimensioning and VLR databasesize.

7.10 Planning semipermanent cross-connectionconfigurations

MSS system release 2 (MSS SR2) requires semipermanent connectionsfrom the MGW to an integrated MSC Server. The PBX is connected to theMGW via a TDM trunk. From the MGW we connect the TDM to MSS. TheMSS terminates the HDLC framing with a PAU computer unit.




The following figure presents the semipermanent connections betweenexternal termination points in MGW (in the PBX case both externaltermination points are TDMs). Note that only TDM-TDM connection issupported at the moment.

Figure 37. Semipermanent cross-connection between termination points

An alternative is to have small MSC(s) to adapt to the PBX.

7.11 Planning Channel Associated Signalling (CAS)

Currently MGW does not support Channel Associated Signalling, such asR1, R2 and MF. In the MSC Server System it is required that the TDM/PCM is connected to integrated MSS. Another alternative is to have smallMSC(s) to adapt to the CAS.

7.12 Planning Signalling Point Codes (SPC)

Planning Signalling Point Codes (SPC) regionally

If the MSC Server controls multiple MGWs in different regions, it may benecessary to use separate (regional) signalling point codes towardsPSTN.

NIWU

IP

ATM

Termination point

TDM

NIS

IP-NIU

PCM/TSL Internal ATMtermination

point

Permanent VirtualConnections



Note

ISUP is terminated to MSC Server’s SPC, the MGW’s SPC is not visibleto PSTN.

If you start to build alternative routes between the MGW and MSS, it isrecommended that the BSCs and RNCs talk to one regional MSS SPC(only in associative mode) and the other network elements (NE) that arecapable of quasi-associative signalling mode (and thus understand thatMSS is reached via STPs) talk to another regional MSS SPC. This isrecommended because there is no defined behaviour for clusters thatshow one point code outside (for example to BSCs) but have a complexinternal STP structure.

Let us assume that D00 is the point code of the MSS which belongs toregion 1:

. POIs and MSCs in region 1 talk to D00.

. BSCs and RNCs in region 1 talk to D01.

. BSCs and RNCs in region 2 talk to A01.

. POIs and MSCs in region 2 region talk to A00.

MSS knows the IWF type additional own signalling point codes A00, A01,D01. The emulated own signalling point code is set by DPC (its region andNE type) according to the expectations of this partner NE with MMLcommand NRB:

<network>,<dpc>:AOPC=<ownSPC>;

7.13 Planning Multipoint A/Iu

For information on planning and configuring Multipoint A/Iu, see CS Core

Multipoint Configuration Guidelines.

7.14 Planning synchronisation and timing

The core network elements need synchronisation for the followingpurposes:




. To maintain synchronisation for external interfaces (PCMs, SDH).

. To keep the system clock accurate. The system clock should beprecise for CDR time stamp, alarm and message monitoringpurposes.

Note that the calls are charged based on duration, not on time stamps. Thetimestamps are relevant for itemised customer billing only.

NetActTM can be used as Network Time Protocol (NTP) server. NetActTM iscapable of providing the time to HLR/MSC/MSS using MML commands.The MGWs can use SNTP (Simple Network Time Protocol) to obtain timefrom NetActTM or Network Element Management Unit (NEMU). The SNTPconveys Greenwich time stamp on top of UDP. The NTP protocol alsoadjusts clock tick rate. The NTP as a protocol is not supported.

The standalone MSS does not necessarily need synchronisation if it hasno TDM. However, since the MGW needs synchronisation it makes senseto connect GPS to standalone MSS as well.

Traditionally, the synchronisation has been received from the national PTor a higher hierarchy long-distance network. Today the primarysynchronisation is usually taken from an external GPS clock module that isconnected to network elements. In a large network the back-up plan couldbe to take a secondary synchronisation via another site that is connectedto other GPS clock (using SDH or PCM that comes from that site).Alternatively, secondary synchronisation could be taken from an adjacentnetwork via PCM/SDH.

The figure below illustrates an imaginary synchronisation plan. Every nodehas back-up synchronisation except the HLRs. In the figure the MSSsneed to have an IPCH cabinet if the synchronisation is taken from PCM/TDM. For simplicity, some elements have been left out. Nokia Siemens'recommendation is to take RNC synchronisation from MGW. If the SDH isdown, the RNC is not of much use either. The same applies to BSC.However, if the GPS clock is on the same site, a direct connection is fine.



Figure 38. Example synchronisation plan

MSC/MSS/HLR

The MSS/HLR has two independent CLSUs, which adapt to the frequencyof the external synchronisation source. The basic configuration includestwo external synchronisation inputs (120 ohm balanced/75 ohmunbalanced). The two external synchronisation inputs comply with theG.703 standard for 2048 kHz synchronisation interface.

The synchronisation inputs for I Series (applicable for MSS/HLR) are:

. FS1 - FS2: External synchronisation clock sources.

. 2M1 - 2M4: 2.048 MHz PCM Clock sources.

‘Priority’ parameter for the clock sources is defined by the MML.

BSC01

MSS02MSS01

MGW03MGW02MGW01

E1/2MHz

GPS/2MHz

PSTN

RNC01

HLR01 HLR02

GPS1 GPS2

GPS/2MHz

E1/2MHz

SDHE1/2MHz

Primary

Secondary

SDH




CDS

CS Data Server (CDS) supports two external inputs (such as GPS) andfour PCM line inputs. If PCM-external PCM clock inputs are in use,synchronisation method of the CDS is "SLAVE". In the PCM case the clockis cabled from the ET4 unit to CLSU.

MGW

Synchronisation reference inputs for MGW are:

. EXT: External synchronisation clock reference.

. ET: External synchronisation reference from PCM ExchangeTerminal.

. SET: External synchronisation reference from SDH ExchangeTerminal.

In addition to MSC/MSS, the MGW also supports 1544kHz and 64kHz+8kHz modes. The cable needs to be extracted from a particular interfaceunit, for example NIWU-0.

To provide the correct time for MGW the Network Time Protocol (NTP)should be used. The MGW is capable of obtaining the time from the non-real time (NRT) server. Note that MSC/MSS is not capable of being thetime server. The correct time in the MGW is needed only for alarms,reports and message monitoring purposes.

Site routers

The routers need clock only for alarm and monitorings. Network TimeProtocol (NTP) may be used to provide the timing to routers.

7.15 Planning Mobile Number Portability/ServiceRouting Register (SRRi)

This is a short introduction to what must be considered when planning anetwork where the Service Routing Register (SRRi) and/or ETSI MobileNumber Portability (MNP) is implemented.

The actual design of the MNP is not in the scope of this description.However, the implications that MNP has on detailed circuit switched (CS)core network planning are described. For more information on the MNP,see Mobile Number Portability in M-release product documentation library.



For information on SRRi resilience, see Disaster recovery level resilience

in CDS, SRRi and DNS in CS Core Network Resilience.

Dimensioning SRRi signalling network

Integrating SRRis in the network changes the signalling topology, and itcan be difficult to predict its effect on signalling capacities. It is thereforerecommended to perform signalling dimensioning before the integration toensure that there is enough capacity in all link sets.

A new network can be dimensioned with the NetActTM TransmissionPlanner planning tool using the interswitch (ISW) module for modelling theinter-MSC voice traffic and the signalling module for dimensioning theinter-MSC signalling. Firstly, the interswitch network must be dimensionedbased on the estimated subscriber forecasts and subscriber behaviour.Secondly, the signalling network can be modelled and the capacitiescalculated. In most cases the SRRis are integrated in a real existingnetwork. This makes it possible to base the dimensioning on voice trafficand signalling traffic measurements from the real network. A suggestionfor the dimensioning procedure involves:

1. Modelling the existing voice network (interswitch module).

2. Modelling the existing signalling network (signalling module).

3. Modelling the new signalling network topology including SRRis.

4. Calculating the effect MNP has on signalling capacities.

Modelling the existing voice network

The signalling calculations in the signalling module of the NetActTM

Transmission Planner are based on the end-to-end traffic matrix from theinterswitch module. Thus, it is necessary to build a model of the voicenetwork before calculating the signalling capacities. The ISW model canbe based on the usual input concerning, for example, subscriberdistribution, subscriber behaviour, network element locations, routinginformation, and coverage areas. The modelling result can then becompared to circuit group measurements from the real network. If themodelled capacities do not match, some parameters can be changedalong with adjustments in routing, and after that traffic can be generatedagain.

The following steps are repeated:




1. Generating traffic.

2. Comparing results with circuit group measurements.

3. Adjusting ISW parameters and/or routing.

It is recommended to fix the subscriber gravity coordinates based either onRNC locations or on other information from the operator. The parametersthat primarily should be adjusted in the process are traffic per subscriber(individually for each MSC) and traffic distribution within each networkelement.

As routing of calls in the real network can be quite complex, it is impossibleto incorporate all details in the model. The tool produces automatic routingbased on logic and mathematical procedures, and this automatic routingneeds to be adjusted further according to the real routing in the network. Insome cases the real routing must be estimated according to the circuitgroup measurements.

Modelling the existing signalling network

This step is not obligatory but only recommended for obtaining moreaccurate dimensioning results. By first modelling the current signallingnetwork it allows you to adjust signalling parameters to match theparameters in the real network. This requires that you have signalling linkmeasurements from all network elements during busy hour so you cancompare the modelled results to the actual measurements. As whenmodelling the voice network the following procedure is repeated untilsatisfactory results are obtained:

1. Generating traffic.

2. Comparing results with circuit group measurements.

3. Adjusting ISW parameters and/or routing.

It is recommended not to spend time adjusting the signalling routing, as theactual routing can be very different from the automatic routing done by thetool. Adjusting the routing is very time-consuming.

Modelling the signalling network topology including SRRis

In the previous step the signalling parameters were fixed. Now thetopology can be changed to the new topology with SRRis as centralisedsignalling transfer points (use the STP node as SRRi). The basic idea is togenerate signalling traffic and analyse the results.

Load distribution



After automatic routing it is necessary to adjust the routing to set theprimary and secondary routes as desired. The following aspects can betaken into account when determining which SRRi each MSC/MSS/HLRshould use as the primary one:

. geographical locations of elements

. the size of each MSC/MSS/HLR

. the MSCs, MSSs and HLRs planned to be integrated in the future.

The goal is to obtain an equal load distribution on the two SRRis. It is ofcourse not critical if the load is not absolutely even but it minimises the riskof overloading one SRRi.

Capacities in general and in secondary routes

As the number of connections from each MSC/MSS/HLR is stronglylimited with the new topology, a very low number of link sets now has tocarry the traffic that a high number of link sets carried in the old signallingtopology. However, the utilisation is also much better. So it should alwaysmean that a number of links (maybe even up to 50%) are saved in eachMSC/MSS/HLR. As the number of links in a link set is limited to 16 it isrecommended to use high-capacity signalling links from the beginning.However, this is only possible for DX 200 i-series hardware. The signallingtraffic in secondary signalling routes is all towards the MSC/MSS/HLR.The signalling is from all the MSCs/MSSs/HLRs that use the other SRRi asthe primary one.

Use of SIGTRAN/M3UA for MAP signaling removes the limit of 16 x 64kbit/s.

Dimensioning of inter-SRRi links

The links between the SRRis are only used in case of link set failurebetween an SRRi and another network element. If the network should beable to handle one link set failure without overloading the system, thenumber of links between the SRRis should be the same as the maximumnumber of links between one SRRi and another network element.

Calculating MNP effect on signalling capacities

There are two things that significantly change the signalling capacity whenmobile number portability (MNP) is in use:




1. The number of SRRi enquiries from each MSC/MSS due to mobile-to-mobile calls.

2. The number of SRRi enquiries from each SMS GW-MSC due tomobile-terminated SMSs.

In addition to these, a number of other factors can also influence thecapacities depending on the features used in the network. Some examplesof the features are: SMS screening in SMSC based on IMSI, IN servicesusing Any Time Interrogation (ANI), Call Completion to Busy Subscriber(CCBS) feature, Location Based Services and UnstructuredSupplementary Services Data (USSD) features.

The introduction of feature 1081 ETSI Mobile Number Portability in MSCdoes not change the number of HLR enquiries significantly as the numberof real enquiries is still based on the number of own subscribers,subscriber behaviour and call distribution within the network element. Theonly significant change in the call-related signalling capacity is theincreased number of SRRi enquiries due to routing enquiries. The capacityshould be evaluated separately in both directions between the MSC/MSSand the SRRi. In the primary route there is traffic in both directions butmost of the traffic is from the MSC/MSS to the SRRi.

Planning of NE configuration for MNP implementation

The following describes some issues that must be considered when doingdetailed planning in a network where mobile number portability (MNP) is orwill be in use. The implementation requirements for MNP are different fromcountry to country and it is therefore important to read and to understandthe country specifications. These specifications directly influence thedetailed planning. Note also that special settings are necessary to preventrouting loops between operators.

Configuring HLR

MNP causes only minor changes in the configuration of an HLR. Thesignalling definitions are a bit different because the SRRis now act assignalling transfer points (STP) towards the MSCs/MSSs. According to thedimensioning results the HLRs should be divided so that some HLRs useSRRi-1 as the primary STP and the other HLRs use SRRi-2 as the primarySTP.

Configuring MSC/MSS



The biggest change that MNP causes in the configuration of MSC/MSS isin the signalling definitions and digit analysis. The MSCs/MSSs are dividedso that some of them use SRRi-1 and others SRRi-2 as the primary STP.Feature 1081 ETSI Mobile Number Portability in MSC should be active inthe MSC/MSS software in order to utilise the MNP-specific settings. Thecountry-specific MNP specifications should always be followed. This canrequire specific changes to the actual MSC/MSS and/or SRRi software.

Configuring SRRi

The configuration of the SRRi consists mainly of signalling definitions andmobile number portability (or other number translations) specific settings.

The main MNP-specific settings are:

. Calling party address analysis.

. Called party address analysis.

. Database entries.

. Operation code settings and the resulting actions settings.

The basic SRRi configurations are:

. Setting the number of SRRU pairs in the SRRi.

. Setting the alarm limit for discarded messages due to SRRioverload.

. Defining the service key for INAP-based queries.

. Defining the cause code to be used when calls are released withINAP ReleaseCall operation.

On message transfer part (MTP) definitions it can be stated that signallinglinks and signalling routes should be defined to every network elementdirectly connected to the SRRi. The signalling route set should include theother SRRi as a secondary route. Signalling routes should be defined foreach point of interconnection (POI) and other network elements. The otherSRRi should be defined as the secondary route. On signalling connectioncontrol part (SCCP) definitions it should be noted, for example, that as theSRRi is a centralised transfer point for global title (GT) translation, theSRRi should contain analyses for all allocated GT addresses in thenetwork along with international and other national networks.






8 Planning of convergence solutions

8.1 Planning Indirect Access services (IDA)

In IDA-incumbent network the operator connects to MSS/MGW usingISUP. An INDU computer unit pair is used in MSS. The INDU pair replacesone CHU pair. The subscription check/caller validation is done using aninternal database. The INAP CS2 may be used for external services.

For more information, see Indirect Access in CS Core Voice Convergence.

8.2 Planning Unlicensed Mobile Access (UMA)

Unlicensed Mobile Access is used to provide WLAN or Bluetooth accessat home, especially where there is no GSM/UMTS coverage. In Nokia’sUMA solution, Kineto’s UMA Network Controller (UNC) is used. UNCprovides a BSC-like interface for MGW and MSS. Nokia offers two UMAsolutions:

. UMA solution for MSC Server. This solution uses IP-based A+interface.

. UMA solution for GSM. In this solution Nokia MGW providesstandard A interface connectivity for MSC.

For an overview of the solutions, see Unlicensed Mobile Access (UMA), inCS Core Voice Convergence. For a more detailed description, seeUnlicensed Mobile Access, Solution Description, available in NOLS.

AMR FR codec is used towards the UNC. The user plane packets arerouted via Security Gateway (SEGW).



Planning of convergence solutions

The UMA should be taken into account when dimensioning MGW. ForMSC Server (MSS) the impact is the same as in GSM calls.

The UMA concept does not require public IP addresses for the terminal.The private IP addresses (of user plane) can be translated with NetworkAddress Translator (NAT) to public, if necessary. The majority of the callsare to/from CS terminal, thus the IP addressing is not visible outside thePLMN. Terminals should be allocated an IPv4 address since currently fewuser equipment are expected to support IPv6.

Traffic from the Security Gateway (SEGW) should be controlled by afirewall or a router with Access Control List in order to prevent attacksagainst the core network.

The Authentication, Authorisation and Accounting Server (AAA) may beduplicated for resiliency purposes.

For handovers neighbouring cell definitions are needed. For moreinformation on handovers, see chapter GSM Base Station Subsystem(BSS) in Unlicensed Mobile Access, Solution Description

In the UMA registration procedure, the UNC has two roles: default andserving UNC. The default UNC definitions may be configured. For moredetails on UMA discovery and registration, see Unlicensed Mobile Access,Solution Description, available in NOLS.

Location of emergency calls

UNC can be configured to broadcast the terminals to prefer GSM inemergency calls. Then the MS will use the GSM emergency call routingcapabilities. If UMA is used, there are the following options for emergencycalls:



1. Use the regular UMA cell global identification CGI and report thisCGI to the MSC as the cell where the call originated. The UMA CGIis assigned through the UMA Cell Assignment Table. The location ofthe emergency call is then the same as the GSM Cells that mappedto the UMA CGI.

2. Use the Emergency Service CGI provided by the AAA. In thisconfiguration, the Emergency Service CGI substitutes for the regularUMA CGI for emergency calls. The Emergency Service CGI is set bythe AAA server and it is usually set to the overhead GSM CGI in theUMA register message from the MS. This method supportsemergency service location resolution at the GSM cell granularitywithout requiring the one to one mapping of GSM CGI to UMA CGI.The MSC will complete the Emergency Service call routing using theCGI reported for the call and uses that CGI for any location reportingfunction.

3. In the case where the operator allows emergency call handling overthe UMAN when there is no GSM coverage, the UNC GSM-to-UMAmapping table can be constructed to select a UMA-CGI thatrepresents the location of the user adequately enough for thepurposes of routing the 112 call to the correct emergency center. Thehandset will provide the last seen GSM Location Area during UMAregistration, which can then be used to select an appropriate UMA-CGI from the mapping table to be used for the UMA session. ThisUMA-CGI must also be programmed into the Emergency CallRouting table in the MSC to ensure that any 112 call using this UMA-CGI is routed to the correct emergency center. Should the GSMlocation not be recognised within the GSM to UMA mapping table,the UNC will select a (programmable) default entry that can be usedto route the call to a default emergency center. In this case, the 112call will still be handled, however it may not be received at thecorrect emergency center for the users location. In some cases thisis preferrable to not handling the call, in others this method may beused to block the 112 call depending on both national and operator-specific policies.

For more detailed information about the emergency call establishment withUMA, see Unlicensed Mobile Access, Solution Description, available inNOLS.

The following figure illustrates the Nokia UMA solution for MSC Server:




Figure 39. UMA solution for MSC Server

In UMA solution for MSC Server, direct connections are recommendedinstead of routing BSSAP+ via MGW. A modified version of BSSAPsignalling (BSSAP +) is used. BSSAP+ is conveyed on to SIGTRAN(SCTP), that is, SCTP associations are created from MSS to UNC. Aseparate user plane destination reference (UPDR) is created for UNC, in asimilar manner as for a 3G RNC.

The following figure illustrates the Nokia UMA solution for GSM. In thissolution no UPDR is needed for TDM connections.

D’/Gr’MAP

WLANBroadbandAccess

Carrier IPNetwork

LBR

INC

BSSAPSIGTRAN

Wm

Up-CS

2G SGSN

NokiaMGW

CoreNetwork

HLR

FW

IPH.248

AAA

OSS

A+

Gb

SEGWUNC/GANC

NokiaMSS

UNC= UMA Network Controller

GANC= Generic Access Network Controller

UMA-enabledMS



Figure 40. UMA solution for GSM

For an overview of the solutions, see Unlicensed Mobile Access (UMA), inCS Core Voice Convergence. See also QoS in converged networks inQuality of Service in CS Core Network.

For a more detailed description of Nokia UMA solution, see UnlicensedMobile Access, Solution Description, available in NOLS. Site connectivityprinciples for UMA are being documented and will be available in UMAsystem documentation.

8.3 Planning SIP services

For SIP services, the following main cases exist and they are explained inmore detail below:

D’/Gr’MAP

WLAN

BroadbandAccess

Carrier IPNetwork

LBR

INC

Wm

2G SGSN

NokiaMGW

CoreNetwork

HLR

FW

AAA

OSS

A

Gb

MSC

SEGW

UNC= UMA Network Controller

GANC= Generic Access Network Controller

Up-CS

UNC/GANCUMA-enabledMS




1. IMS interworking. For example, emergency calls are routed from theIP Multimedia Subsystem (IMS) to MSC Server (MSS). MSSreceives an Invite and routes the call based on the destinationaddress. No NVS functionality is required. See IMS interworking

below.

2. MSS with Nokia VoIP Server (NVS) functionality with ISC (SIP)interface. MSS is an application server. See MSC Server/Nokia VoIP

Server (NVS) with ISC (SIP) interface below.

3. MSC Server with SIP access. In this case the subscriber makes adirect SIP registration to MSS. Also in this case NVS functionality isrequired in MSS product. See MSS with SIP access below.

With cases 2 and 3 the following applies:

. The subscriber must have a pseudo IMSI in the HLR. This does notcause any requirements for HLR (MAP) and SCP (CAP/INAP). Thisis achieved with the introduction of an additional external database,which has to provide Light Directory Access Protocol database(LDAP) interface toward MSS. The database contains SIPsubscription-related information according to a Nokia-defined LDAPschema such as IMSI that is required by NVS to execute the neededprocedures toward other network elements (NE).

. The same MSISDN is used in both domains. MT calls and SMSsshould be routed via CS domain.

. Within IMS registration CPS loads the IMS user profile from IMR.

These different cases are identified in the MSS by different IP addressesand the port number of the SCPU computer unit.

Session Border Controller versus Domain Name Server

It is recommended that Session Border Controller (SBC) protects the first(front) network element. In other words, in the cases 1 and 2 above, anSBC should protect the IMS. In such cases the IMS selects the NVS andSCPU using DNS. In case 3 the NVS should be protected by SBC.

The registration is based on a domain name that the terminal provides inREGISTER message (for example nvs.operator.com). In IMS 3rd partyregistration the Application Server address is obtained from the IPMultimedia Register (IMR). There are two main possibilities for loadsharing:



1. DNS is used to resolve the domain name. IMS gets the correct IPaddress and the port number from the DNS. At re-registration NVS iscapable of selecting internally the correct SCPU if the signal arrivesto a different SCPU unit. If the operator has multiple NVSs, the re-registration may arrive at a different network element. That is seenas an inter/VLR location update.

2. SBC may be used for load sharing. SBC is capable of distributingsubscribers for one NVS, or between SCPUs of multiple NVSelements. The SBC distributes further invocations to the correctSCPU.

Note

In the MSS, the IMS/CPS port number is in the MSS configuration, onper MSS basis.

See also NbUp framing and 5ms/20ms packetisation on UPD plane foruser plane details.

VLR

The NVS shares the same VLR as is used for 2G/3G access. This meansthat the capacity is shared. If the VLR fails, the SBC is capable of selectinganother working VLR.

IMS interworking

This scenario is used mainly when an IMS subscriber makes a call to CSdomain, for example an emergency call (to Public Safety Answering Point,PSAP).

The IMS makes a Directory Name Server (DNS) query for the FullyQualified Domain Name (FQDN) and gets the SCPU IP address and theport number.

In the MSS the call is basic routing based on the called address.




CPS Connection Processing ServerIMR IP Multimedia Register

NVS Nokia VoIP Server

Figure 41. IMS interworking

MSC Server/Nokia VoIP Server with ISC interface

MSS/NVS provides mobile-oriented telephony services to VoIP clients.This scenario requires 3rd party registration functionality for IP MultimediaSubsystem (IMS).

In this case the subscriber is registered in both domains (IMS and MSS/NVS). MSS runs the services, for example IN services. The IMS runs theauthentication procedures. A SIP user has filter criteria stored in the userprofile in IP Multimedia Register (IMR). The filter criteria indicate theApplication Servers that should be contacted by Connection ProcessingServer (CPS). If the network consists of multiple NVS elements, the filter

IP, ATMor TDM

S

SS

S

MGW

CPS GCS

MSC Serverdomain

WLAN

H.248

AWCDMARAN

BSC

RNC

GSMBSS

Iu-PS

SIP BICC/SIP

SIGTRAN H.248

SIGTRAN

C7(ISUP)

Iu-CS

IMR

WAN

S

Mg/Mj

MSS/NVS/GCS

ATM

IP

TDM

GMSC

TransitSwitch

PSTNSwitch

PSAP

DSLAMIP Multi-access

MGW

PacketCore

S



criteria should be configured so that NVSs are evenly loaded. That is,divide different subscribers to different NVS elements. Within ISCregistration (3rd party registration) MSS loads the GSM/UMTS user profilefrom HLR and updates the location of SIP user (VLR address) to HLR.

AppSe IP Telephony Application Server

CPS Connection Processing ServerIMR IP Multimedia RegisterNVS Nokia VoIP Server

Figure 42. MSC/NVS with ISC interface

In this main case it is essential to control the SIP proxy mode. Thepresence or absence of SIP route header in IMS/CPS determines whether:

. the incoming call is a new call (no route header), or

. the subscriber’s services are executed (route header present).

IP, ATMor TDM

S

SS

S

MGW

CPS

GCS

MSC Serverdomain

WLAN

H.248

A

PacketCore

WCDMARAN

BSC

RNC

GSMBSS

Iu-PS

SIP BICC/SIP

SIGTRAN H.248

SIGTRAN

C7(ISUP)

Iu-CS

WAN

S

MSS/NVS/GCS

ATM

IP

TDM

GMSC

TransitSwitch

PSTNSwitch

LDAP

HLR

MAPover IP

(SIGTRAN)ISC

MAP over IP(SIGTRAN)orTDM basedMAP

IP Multi-access

DSLAMS

MGW

IMR

AppSe

AppSe




This is the proxy mode. The proxy mode is selected by assigning properOUSIGN record (for example OMXS6) on the outgoing route and attachCGR with ASI=SI3MX or ASI=SI2MX on this route.

MSS with SIP access

SIP access is used to provide an entry to Voice over IP (VoIP) services.Different from the MSC Server/Nokia VoIP Server case, here the MSSruns the authentication procedures.

Figure 43. MSS with SIP access

For more information, see Nokia solution for consumer VoIP

communication in CS Core Voice Convergence. See also QoS in

converged networks in Quality of Service in CS Core Network.

ATM

S

WLAN

DSLAM

MSC Serverdomain

GCS

SIGTRAN

SIG-TRANH.248

H.248

MGW MGW

ATM, IPor TDM

MAP overIP(SIGTRAN)

HLR

BICC

IP

TDM

lu-CS

lu-CS

WCDMA RAN

GSM BSS

A

BSC

RNC

LDAP

MAP over IP(SIGTRAN)

orTDM based MAP

C7 (ISUP)

MSCServer/SIP-Re

IP

C7(ISUP)

C7(ISUP)

GMSC

TRANSITSwitch

PSTNSwitch

S

S SS

Firewall

FirewallPACKETCORE



8.4 Planning Session Border Controller (SBC)

The SBC is used to protect network from IP threats and to hide networkstructure from the outside world, including the internal IP addressing. SBCis also valuable in load sharing.

Currently SBC should be used for lawful interception/OLCM since thevideo/multimedia call is not supported in Nokia VoIP Server/MGW. The LIof speech and SMS work also in NVS/MGW. The video/multimediacapabilities will be supported in the NVS in the near future.

8.5 Planning Light Directory Access Protocol (LDAP)

If the operator acquires the Light Directory Access Protocol database(LDAP) product from Nokia, the LDAP is a Sunone Directory product. TheNVS is the LDAP client. In a simple mode, the SCPU units of NVS have asingle TCP connection to the LDAP server, one connection from eachSCPU. Operator may also configure secondary LDAP servers for eachSCPU client. MSS is connected directly from every SCPU to the multilayersite switch/Ethernet router.

The LDAP is a centralised directory and its content is recommeded to bemirrored.

LDAP uses the same PRFILE DiffServ code point value as the othercontrol plane protocols. In MSS SR2 the operator may also set DiffServcode points based on the port number, independent of the protocol.

Intra-operator calls (calling party domain name equals to the called partydomain name): For the NVS use, the LDAP must contain SIP URIs of allsubscribers of the particular PLMN. If the called party URI is not found, thecall fails.

For the inter-operator calls (the domain names of the calling and calledparty are different) the LDAP must contain default routing numberstowards the target operator network.

LDAP also contains user name and password for the HTTP-digestauthentication purposes (SIP access case). Also other information isstored in the schema needed by the NVS to simulate GSM/3G behaviour.




For more information, see LDAP Server for NVS, in M-release productdocumentation.

Nokia delivers the schemas as part of feature FN01670. See Feature1670: SIP Subscriber Database, in M-release feature documentation.



9 CS core network dimensioning

To dimension circuit switched (CS) core network you need to produce adimensioning plan describing the selected network architecture and thenumber of network elements needed for the rollout of the CS core network.To dimension CS core network, you model the traffic in the network andselect the appropriate equipment.

Preconditions for CS core network dimensioning

Before dimensioning, you need to assess the CS core network to produceeffective dimensioning principles. You can perform the assessment for acompletely new network, or for an expansion network taking into accountthe existing CS core network infrastructure.

For assessment, you need information on the following:

. Equipment technology, quantity and location.

. Available/spare capacity.

. Network element interfaces.

. Services provided and new product rollout schedule.

. Subscriber base forecasts.

. Numbering plan.

. Topology.

. Geographical information.

. Transmission network.

. Charging data used.

. Traffic measurements.



CS core network dimensioning

You need to define the scope of the assessment in terms of geographicalareas and services to be considered. Additionally, you need to conduct atleast a preliminary financial analysis. Several studies need to beconducted to define the demand for the services included at short, mediumand long term.

The result you get of the CS core network assessment phase includes, forexample, the following information:

. subscriber penetration forecast

. services to be supported by the network

. market segmentation and location

. numbering principles

. routing principles

. recommendation for technology decisions

. network hierarchy and topology alternatives.

When you start the dimensioning of CS core network, you must haveinformation available on the following:

. The services to the provided and their geographical distribution.

. Available network element interfaces.

. The number of different type of subscribers.

. Geographical node boundaries.

. The erlang amounts and acceptable blocking for POTS, ISDN andRAN.

. Growth estimates, of both capacity growth and geographicalextension.

. Site availability and types (such as equipment premises, indoorcabinets, outdoor cabinets and/or customer premises) andenvironmental conditions.

. Reliability requirements.

. The transmission available.



CS core network dimensioning phases

Create a traffic model of the network and select the equipment to supportit. You should take into account the existing equipment specifications,business plans, availability and types of sites, grade of servicerequirements and charging cases. In addition, you need to consider thefollowing issues:

. You need to produce network diagrams showing different networkelements and parameters for the selected alternatives.

. You need to define routing, protection and synchronisationprinciples. You must evaluate suitable routing, protection andsynchronisation alternatives, and compute the capacities requiredfor the transmission for the chosen routing principles. You shouldpay particular attention to the signalling network’s resilience to linkfailure and its adequate capacity.

. You need to dimension the network for an optimal size, and define asuitable growth path for achieving and implementing it.

. You need to take cost-related matters into consideration to selectcost-effective solutions. To achieve the best possible results, youshould perform the cost optimisation for the CS core, access andtransport networks in parallel.

Results of CS core network dimensioning

The results from CS core network dimensioning serve as the basis for thedetailed network plan and consist mainly of a roll-out plan preparedaccording to the network diagram. The network topology and hierarchy arechosen, and the network element equipment are defined in terms of type,capacity, and interface capacity requirements for transmission andsignalling. Also the principles of synchronisation and management may beprovided. The results of dimensioning are achieved from:

. Selection of the network architecture which creates an optimalsolution of alternative technologies and methods to build thenetwork. The result is a plan delineating roughly the equipment typesper station, the services provided and the capacity per equipmenttype.

. Signalling network diagram involves identifying the signalling nodesand links with their respective capacities and routing principles.Results from Intelligent Network (IN) planning may also be included.Note that the use of the overlay solution in the IN services has aneffect on network dimensioning: in that case IN services arecentralised to certain 3G MSCs, MSSs or service nodes




. Voice and signalling traffic matrixes form the results from the end toend traffic modelling of the network and the basis for the trafficrouting.

. Routing principles

. Protection planning, including both equipment and route protection.

. Synchronisation and management principles, including the basicideas of the synchronisation and management networks.

. Requirements for the transport network, including information oncapacity and protection requirements. This information is used in thetransport network planning, which, in turn, is done in parallel with theaccess network planning.

. List of equipment types delineating the types of required networkelement, their interfaces and features. Based on this information, it ispossible to make a more detailed equipment list

. Roll-out plan meant for a network that is built in several phases dueto capacity increases or geographical extensions. The plan isdesigned by taking the target network in the end of the estimatedroll-out period as a starting point, and then moving backwards todefine a consistent growth path, ensuring that the investments madein the first years are not wasted in the later phases.

9.1 Dimensioning of MSC Server System

For MSC Server System dimensioning, you need to:

1. Estimate how many subscribers there are in each BSC/RNC duringthe busiest hour of that BSC/RNC. Note that certain BSCs may bebusier during office hours, some during evening hours (for examplein a residential area). This difference is mainly relevant for MGWdimensioning of that BSC/RNC connection.

2. Estimate the call request rates per user at busy hour (for example 1call per user, one SMS), and average call duration (for example 90seconds). The share between MO calls and MT calls needs to beestimated, for example 60% MO, 40% MT.

3. Estimate the distribution of the calls by destination and origin. Forexample, calls to/from BSC01 (see the figure Logical Control Planeconnection example below) are distributed as follows:. BSC01 (intra BSC) 7%. BSC02 5%. RNC01 2%



. RNC02 1%

. BSC03 2%

. RNC03 1%

. BSC04 1%

. PSTN via MGW01 31%

. PSTN via MGW02 25%

. PSTN via MGW03 via MGW02 15%

. PSTN via MGW04 via MGW02 7%

. VMS01 2%

. VMS02 1%After these steps you know the BHCA for each MSS and MGW aswell the user plane bandwidth for each direction. For the ISUP,BICC, SIP, BSSAP/RANAP and MAP signallings you now have anestimate for each network element. The MAP signalling is calculatedas bits/s/user.In large networks you may have to take into account intra-networkroaming, for example, 90% of certain MSS/VLR subscribers belongto HLRx and 10% to a distant HLRy. In the example this does notmatter since both HLRs are behind the same Signalling TransferPoint (STP).As you may have noticed, this example network is far from idealsince the same call is connected via 3 MGWs.

4. Estimate the impact of services.. The ratio of pre-pay and other IN services users must be

estimated. For example, 60% prepay, and 10% VPN. 5% in-bound roamers of which 10% is prepay. Check above for thesize of CAP messages and related overheads of SIGTRAN.As a result, you know the CAP/INAP bandwidth requirement.In large networks, you may have to consider the intra-networkroaming if you have regional SCPs serving subscribers of anarea.

. Selective Ringback tone.

. Voice Mail (VMS) usage.

. Percentage of data calls requiring CDS.

. Percentage of multimedia/video calls.

. MNP/SRRi.

5. Calculate the bandwith and BHCA for each element based on theestimates above. After this you should be able to dimension MSSsand MGWs and their units.




Figure 44. Logical Control Plane connection example

9.2 Dimensioning MSC Server

Dimensioning an individual MSS

MSC Server (MSS) can be dimensioned with the help of DimensioningGuidelines for MSC Server (available on request from Nokia Siemens).The following clarifications may be useful to note:

. IP and ATM user plane resources are not tied to any virtual MediaGateway MGW (vMGW). TDM resources may be tied to a certainvMGW. Thus, in the TDM case it is possible that two vMGWs need tobe controlled even if the incoming and outgoing sides are in thesame physical MGW. If so, an additional 0.5 call is calculated on topof the 1.0 call. It is recommended to configure the TDM resources ina physical MGW level pool to avoid extra load.

MGW04 RNC03

BSC04

Site 1 Site 2

Site 3

HLR01

MGW01

BSC01

MGW02

RNC01

SMSC01

BSC02

SCP01

MSS01

MAP/SS7

CAP/SS7

MAP/SS7

MAP+CAP/SIGTRAN

MAP+CAP/SIGTRAN

AAL2+AAL5/ATM


AAL2+AAL5/ATM


RANAP/ATM

BSSAP/7BSSAP, RANAPBICC, ISUP, IWF

control/IP

MGW03

RNC02 BSC03

MSS02

AAL2+AAL5/ATM

MAP+CAP/SIGTRAN

AAL2+AAL5/ATM

HLR02 STP01



(v)MGW weight selection

See MGW selection in User Plane Routing in the M-release productdocumentation for basic information.

Some aspects of Flex Iu and Flex A are also taken into account here.

Make sure that:

. Each MSS has equal load (or balanced/scaled to its capability).MSS’s Busy Hour Call Attempt (BHCA) depends on the size of thepool and the location areas (LACs), and the rate of incoming callsfrom PSTN. The sum of subscribers (in LACs) should be relative tothe VLR size. If all MSCs/MSSs do not support Flex Iu, define defaultMSSs per LAC so that the load is distributed evenly.

. You have the proper number of PCM lines to each PSTN area.

If both MGWs in the example have a connection to both PSTNs(thick black dotted line in figure Example Flex A/Iu network below),the number of PCM lines needs calculation with more granularity. In3G/UMTS we can save that effort by making the Iu interfacemeshed. On the other hand, having both MGWs connected to bothPSTNs makes the network more resilient. Even further, if the Iu is notmeshed, some more calls are received in the “wrong” MGW sincethe majority of the calls are local. Note that if both MSSs controlPSTN connections, both Signalling point Codes (SPCs) are visibleto the PSTN.

If the Iu is meshed (thick red lines in the figure below), we can usethe same for both RNCs (UPD1 = UPD2).

. The MGW load is balanced. If we have set the number of PCM linesto PSTN, the weight is another factor. Note that for PSTN-originatedtraffic the vMGW is defined by the TDM line.

Each route may contain up to 8 circuit groups. Thus each PSTN andBSC TDM connection can easily be split into 8 vMGWs (each CGRbelongs to a certain vMGW).

For simplicity, we assume here that all MGWs have equal capacity. If thatis not the case, scale the weight. For example, if MGW02 has 50% of thecapacity of others, multiply MGW02’s weight by 50% (0.5). It is advised notto go on MGW unit dimensioning yet. You should first distribute the loadequally to all MGWs (including scaling), and eventually double check ifeach MGW can take that load. There may be differences since someMGWs may have to perform more transcoding, whereas some MGWs maybe used more as transit MGWs for user plane.




The figure below shows an example case:

Figure 45. Example Flex A/Iu network

The following example gives an idea how to break traffic to smallercomponent for calculations. In the example we assume the following (seethe figure below):

. All MGWs have equal capacity.

. To demonstrate the meaning of weights we added a third MGW(MGW03).

. We also assume that average user makes 1 BHCA. The numberassigned to each LAC shows the registered users in that LAC.

. Meshed Iu -> UPD1 gets all 3G traffic. There is no need to allocateMSRN per LAC.

RNC01

MSS02

MGW02

MSS01

MGW01

RNC02

UPD2

No UPD

BSC02

BSC01

UPD1

No UPD

No UPD

No UPDUPD12

140 E1PSTN2

PSTN1140 E1

LAC1, LAC2,LAC3, LAC4

LAC1, LAC3, LAC4,LAC5, LAC6

LAC1: 100k

LAC2: 50k

LAC3: 30k

LAC4: 40k

LAC5: 50k

LAC6: 20k



. PSTN1 and PSTN2 have connections to MGW1 and MGW2 only,correspondingly.

. 10% calls MS-MS intra network -> 90% to/from PSTNs (PSTN ratio).

. 60% of calls are MO (MO ratio).

. 40% calls are MT (MT ratio).

. 1 BHCA per subscriber -> total is 290 kBHCA.

. Average call duration 90s -> 90/3600 = 25 mErl/subscriber.

. PSTN1 and PSTN2 each get 50% of PSTN calls.

. In all MGWs the MSS01 controls odd number vMGWs, and MSS02even numbers.

. In MGW01 we have 8 vMGWs. BSC01 route is split to 4 CGRs andvMGWs evenly (vMGW11 – vMGW14) and PSTN1 route is alsoevenly split to 4 vMGWs (vMGW15 – vMGW18). W1 is the weight onUPD12 and UPD1. The weight could be different per vMGW but forsimplicity we use the same value. In this example the only casewhen weights have an impact is calls from PSTN2 to RNC01 andRNC02.

. In MGW02 we have 6 vMGWs. W2 is the weight on UPD12 andUPD1. BSC02 CGRs are split into vMGW22 and vMGW24 evenly(MSS02 controls LAC6). If we want to go further, vMGW weightscould be balanced on RNC-originated calls (on UPD1), especially ifPSTN and BSC-originated calls cause unbalanced load.

Other:

Note that UPDs are on MSS basis. For example, UPD1 needs to beconfigured both in MSS01 and MSS02.




Figure 46. vMGW connections example

You can calculate and simulate weight settings on an Excel sheet. Fine-tuning of the UPD12 weights would balance vMGW loads even more.Since the MGW01 has more TDMs it is beneficial to add weight inMGW02. However, too much weight in MGW02 adds calls that go via bothMGWs. MGW03 load is not calculated. Note that the BHCA is not evenclose to the limit.

Here is an example of the weight settings:

Table 8. Impact of weights on vMGW BHCA

vMGW UPD1weight

UPD12weight

Traffic (BHCA)

vMGW11 20 40 21458

vMGW12 20 40 21458

vMGW13 20 40 21458

vMGW14 20 40 21458

MGW03

PSTN1

MSS01

MSS02RNC01

RNC02

UPD1

UPD1 MSS01

MSS02

UPD12

BSC02

MGW02VMGW21

VMGW22

VMGW23

VMGW24

VMGW25

VMGW26

UPD12

BSC01

MGW01VMGW11

VMGW12

VMGW13

VMGW14

VMGW15

VMGW16

VMGW17

VMGW18

PSTN2



Table 8. Impact of weights on vMGW BHCA (cont.)

vMGW UPD1weight

UPD12weight

Traffic (BHCA)

vMGW15 60 40 21108

vMGW16 60 40 21108

vMGW17 60 40 21108

vMGW18 60 40 21108

vMGW21 110 70 17349

vMGW22 70 70 20416

vMGW23 110 70 17349

vMGW24 70 70 20416

vMGW25 110 70 17349

vMGW26 110 70 17349

Total 900 740

(v)MGW weight selection conclusion

First distribute trunks and subscribers evenly to MGWs and vMGWs. Fine-tune weights if the load is not balanced. Even this simple network is quitelaborious to calculate exactly. In large networks you may break thenetwork to sites, and then calculate the sites separately.

9.3 Dimensioning of MGW

MGW can be dimensioned with the help of Dimensioning of MultimediaGateway (available on request from Nokia Siemens).

In circuit switched (CS) core dimensioning, the major difference between3GPP MSC Server network and MSC architecture is the introduction of thepacket-based Nb and Nc interfaces. Also, the user plane handling is nowtotally separate from the control plane handling. From network planningpoint of view this means more possibilities for building the networkarchitecture and placing the elements.

The number of MGWs required in the network is determined based mainlyon the following:




. Network topology:

The need for local switching at remote sites determines the minimumnumber of MGWs needed in the network.

. MGW’s capacity:

Multiple MGWs might be required in a single site due to the capacityrequirements for the MGW.

MGW’s capacity is affected by:

. The number of different types of ports the MGW can support.

The MGW can support TDM, ATM and IP interfaces simultaneously.Each type can support a maximum number of port. It should benoted that some port configurations are alternative to each other, forinstance the IP network interface units occupy the same space assome of the ATM interface units, so the introduction of IP networkinterface units reduces the maximum number of ATM ports that canbe supported.

. The internal processing capacity of the AAL2 switching units andDSP units.

The need for internal processing capacity is affected by the need fordifferent functionalities such as echo cancelling, CS data callhandling, Transcoder functionality (including Tandem FreeOperation, TFO/Transcoder Free Operation, TrFO). This limits themaximum number of simultaneous calls the MGW can support. Thisis highly dependent on the traffic mix and the backbone technologyused.

In order to be able to dimension the Nb interface between MGWs, youneed to have information on the following:

. Geographical location of the MGWs.

Knowing the location of the MGWs is the basis for deciding whichequipment (routers, switches) are needed at the site, and whichshould be the physical connectivity between the MGWs.

. Number of subscribers and traffic profiles, or volume of traffic eachMGW should support.



Once the location of the MGWs and the traffic amounts are known, atraffic matrix should be created, indicating the amount of trafficbetween any two MGWs in the network. This information is used toestimate the required link bandwidth between the sites and theMGWs.

. Layer 1 transmission.

The overhead added to the user plane depends on what kind ofLayer 1 transmission is to be used.

. Network element level redundancy principles.

The MGWs may be shared between multiple MSC Servers (MSS),or vice versa the MSS may be connected to multiple MGWs toprovide redundancy. This affects the physical transmission planningand also the amount of spare capacity in the network elements.

When estimating the required link bandwidth, the used physicaltransmission should be known to be able to calculate the overhead causedby Layer 1 framing.

The following gives an overview of MGW dimensioning. For details, seeDimensioning of Multimedia Gateway. All the message sizes andfrequencies are found above and in Dimensioning Guidelines for MSCServer (both documents are available on request from Nokia Siemens).

Defining the number of ISU signalling units

ISU units are used for H.248/MEGACO, AAL2, and RANAP/BSSAPsignalling. In addition, the ISUP/BICC/MAP and INAP/CAP signallingsusing SIGTRAN maybe conveyed via ISU. Check the message sizes fromabove or from Dimensioning Guidelines for MSC Server and calculate thenumber of ISU units according to Dimensioning of Multimedia Gateway.

Dimensioning ATM interface units (NIS1, NIP1, A2SU)

. ATM over STM-1 uses NIS1 unit.

. ATM over TDM (IMA) uses NIP1 card.

Dimensioning of Multimedia Gateway describes user plane dimensioningfor these units. In addition, take the signalling into account. If you use ATMtowards RNC in Iu-interface, take the RANAP into account for NIS1.Otherwise, RANAP has an impact on NIP1. In the NIP1 case, take theoverhead of IMA into account as in ATM over TDM (IMA). For thesignallings it is enough to take the required cells per second (cps) intoaccount.




If you have ATM backbone, BICC may be conveyed over ATM. BICCaffects either NIS1 or NIP1.

Signalling using AAL5 does not have an impact on A2SU at all. Thesignals are sent to/from ISU directly from/to NIS1 or NIP1. In the IMA casecalculate cells per second, one E1 corresponds 4490/4500 cps. For SDHthe VC-x level tells the available bit rate. From the ATM unit dimensioningpoint of view the signalling and user plane are measured in bit rate basis/cps only.

If you convey IP over ATM, take the overhead into account as described inIP over ATM (IPoATM). A typical use case is an ATM backbone operatorwho needs to convey H.248 from the MSS site to MGW site. Another caseis an operator with TDM backbone who needs to convey H.248 betweenMSS and MGW. MGWmay also be used for RNC O&M traffic from STM-1/VC to NetActTM Ethernet. In this case the routing is done in the OMU.

Dimensioning TDM interface units (NIWU, IWS1)

. NIWU serves the traditional TDM, that is, when E1/T1/J1 isconnected to MGW.

. IWS1 is used when connecting TDM over STM-1. The STM-1 mayuse either VC-4 (63E1/84T1), 3 x VC-3 (each 21E4/28T1). Inaddition, either a VC-12 (E1) or VC-11 (T1) connection is providedper STM-1.

The dimensioning can be done according to Dimensioning of MultimediaGateway. Note the restriction of IWS1: the restriction depends on theMGW SW release.

The number of signalling links also affects the dimensioning. For moredetails, see Dimensioning of Multimedia Gateway.

Dimensioning IP interface units (IP NIU)

Only user plane impacts IP NIU. The dimensioning can be done accordingto Dimensioning of Multimedia Gateway.

Dimensioning other units

For dimensioning of Transcoding units (TCU) and Voice AnnouncementUnit (VANU), see Dimensioning of Multimedia Gateway.

Dimensioning Switching Fabric Unit (SFU) and Multiplexing Unit (MXU) donot need to be considered here.



For details on dimensioning MSS and MGW, see Dimensioning Guidelinesfor MSC Server and Dimensioning of Multimedia Gateway, available onrequest from Nokia Siemens.

9.4 Dimensioning IP network

Over-dimensioning in IP network

Once you know the maximum bandwidth used for the backbone and thesignalling links, you need to do some over-dimensioning, that is, thenormal busy hour traffic does not populate 100% of IP links. Here aresome basic rules:

. For bigger links less over-dimensioning can be done than forbroader links. This is due to the statistical nature of IP traffic.

. For 100M or greater bit pipe 70% - 80% of the capacity can be used.

. If you use multiple load balanced routes the failure of one route istaken into account. For example, if you have 2 routes of equal load,only a maximum of 40% of the capacity may be used (if the otherroute/link fails, the load is 80%).

IP queueing

In addition to over-dimensioning, queueing is recommended.

Low Latency Queueing (LLQ) brings strict priority queueing to Class-Based Weighted Fair Queueing as shown below. Strict priority queueingallows delay-sensitive data such as voice to be sent first, giving delay-sensitive data preferential treatment over other traffic.




Figure 47. Low Latency Queueing with priority queue

The ability to provide both a priority queue and scheduled queues isessential if a network is to support the low latency and jitter required tosupport voice over IP.

The voice traffic is policed to ensure that it does not starve the otherqueues. In the example queue configuration above, voice traffic is allowedto use only 70% of the link capacity. In congestion situations, 30% of thebandwidth is always available for signalling and other applications.

Subsequent queues are then applied a portion of the scheduler, either anabsolute amount or a percentage of the remaining bandwidth. Within eachof these queues, multiple WRED drop profiles can also be applied forfurther differentiation.

When a queue has reached its configured queue limit, additional arrivingpackets are dropped. In order to optimise throughput for TCP trafficcongestion avoidance is done via Weighted Random Early Detect(WRED).

.......EF.......EF

FIFO

............AF

FIFO

............AF

............AF

WRED

............AF

............BE

WRED

............BE

WFQ

10%

50%

40%

Priority max 70%Voice

SignalingRouting

StreamingInteractive

Best Effort



Random Early Detection randomly drops packets when queues start togrow, thus slowing down some TCP connections. Weighted REDcombines RED with the class structure defined in DSCP or MPLS Exp toprovide preferential traffic handling of higher priority packets. WRED canselectively discard lower priority traffic when the interface begins to getcongested and to provide differentiated performance characteristics fordifferent classes of service.

9.5 Estimating the needed bandwidth

The first step is to calculate the result net bandwidth used of varioussignallings and user plane. The next step is to take the bandwidth intoaccount for each unit and interface. Next, for the backbone andtransmission, you need to reserve spare capacity.

For more details, see Dimensioning Guidelines for MSC Server, availableon request from Nokia Siemens.

Dimensioning of Multimedia Gateway (also available on request fromNokia Siemens) shows the dimensioning for each unit of the MGW. Notethat there is a separate document for each MGW release.

IP bandwidth usage example for signalling at Mc-interface

The bandwidth used for all signalling over IP depends on the networkarchitecture and the subscriber traffic profile. The following presentsexamples of Mc interface with Nokia’s official traffic profile.

The signalling data transferred between MSS and MGW (Mc) may include

. H.248,

. BSSAP/RANAP by SIGTRAN,

. ISUP by SIGTRAN if MGW has interface to PSTN,

. MAP by SIGTRAN,

. CAP by SIGTRAN (not included in the example calculations).

The following calculations also apply to other interfaces.

NIP/CDS

The control plane signalling from MSS to CDS can be ignored indimensioning.




H.248/MEGACO

Media Gateway Control protocol (MEGACO)/ H.248 protocol is used formedia gateway control between MSS and MGW. For different calls(backbone type IP/AAL2, MS or UE call, SIP or BICC, with or withouthandover), the message number and sequences are different. Typically,the average number of messages per H.248 context in one direction is 10-13, and the average message length is 120-160 bytes without countingIPv4 (20 bytes), SCTP (28 bytes) and Ethernet overhead (38 bytes).

According to H.248 message flow (over SCTP) measurement and anestimation, assuming that there is "1 H.248 context per call", on theaverage 1000k BHCA uses IPv4 bandwidth for H.248 (over SCTP)message as explained in the table below.

Table 9. H.248 message bandwidth

H.248 Excluding Ethernetoverhead

Including Ethernetoverhead

IP bandwidth 5.0 - 6.7 Mbit/s 6.3 - 8.3 Mbit/s

MAP, ISUP, BSSAP/RANAP over SIGTRAN

SIGTRAN’s overhead of each layer is as follows:

. The length of M3UA: 24 bytes

. The length of SCTP: 28 bytes

. IPv4 (without optional fields): 20 bytes

. IPv6: 40 bytes

. Ethernet overhead length: 38 bytes

Deriving SIGTRAN message length from known TDM message length

The length of any SS7 message using SIGTRAN can be derived from theconventional SS7 message length that is well known. The length of themessage using SIGTRAN would be:

. = X - 12 + 24 + 28 + 20 = X + 60 (bytes) (without Ethernet overhead)

where X (bytes) is the length of an SS7 message using TDM.



If Ethernet overhead should be taken into consideration, the length of themessage using SIGTRAN is:

. = X - 12 + 24 + 28 + 20 + 38 = X + 98 (bytes) (with Ethernetoverhead)

To get the used IP bandwidth for SS7 signalling over SIGTRAN, use theformula “X + 60” (without Ethernet overhead, where X byte is the length ofan SS7 message over TDM), or “X + 98” (with Ethernet overhead). To geteach SS7 message length over SIGTRAN, the same way of calculatingSS7 over TDM can be applied.

Rough estimation of required IP bandwidth for MAP, ISUP, BSSAP/RANAPand BICC

The IP bandwidth usage for different signallings listed below are only forreference. For a live network, the operator needs to calculate signallingbandwidth according to the network structure and its own traffic profile.

Note that the estimation was based on the following assumptions:

. Full duplex IPv4 network is used.

. Nokia official traffic profile, introduced either in DX200 StandaloneMSS/VLR/SSP Design Capacities or DX200 Integrated MSS/VLR/SSP Design Capacities, is used.

BSSAP/RANAP by SIGTRAN

The known facts for BSSAP over TDM are:

. BSSAP transmitted by SS7 needs bandwidth of 9000 bits - 16 000bits per busy hour per subscribers depending on traffic profiles persub (for example BH, SMS, LU, HO) and use of authentication, IMEIchecking, ciphering as well.

Or:

. Average number of BSSAP messages per Busy Hour per sub is 25-33 at one direction, average message length is 45 - 60 bytes,depending on the traffic model and how the operator usesauthentication, IMEI checking, ciphering, and TMSI reallocation.

When transmitting BSSAP by IP (SIGTRAN), more bandwidth is used dueto SIGTRAN overheads.




If we assume that 1000k GSM subscribers with traffic profile described asstated in the Nokia official capacity statement, on the average, 1000ksubscriber uses IP bandwidth for BSSAP message:

Table 10. BSSAP message IP bandwidth

BSSAP (1000ksub)

By TDM By SIGTRANexcludingEthernetoverhead

By SIGTRANincluding Ethernetoverhead

Bandwidth 2.5 Mbps*)- 4.5 Mbps 5.8 Mbps**)- 8.8Mbps

8.0 Mbps***)- 11.6Mbps

*) 2.5 Mbps = 1000k sub. x 9000 bit/sub/BH/3600 s

**) 5.8 Mbps = 2.5 Mbps + 1000k sub x (25 msg/sub/BH x 60 byte(overhead)/msg) x 8 bit/Byte/3600 s

***) 8.0 Mbps = 2.5 Mbps + 1000k sub x (25 msg/sub/BH x 98 byte(overhead)/msg) x 8 bit/Byte/3600 s

The bandwidth for RANAP message is estimated based on the simpleassumption as presented below:

1. Average RANAP message length is 70 bytes. This means thattransferring by ATM cells, one message takes 2 cells (53 byte/cell).

2. By typical traffic model, [8,9] average message number per sub perBH in one direction is 35.

Table 11. RANAP message estimation

RANAP (1000ksub)

By ATM (cps) By SIGTRANexcludingEthernetoverhead

By SIGTRANincludingEthernetoverhead

Rough estimation(average)

19.4 kcps*) 10.1 Mbps**) 13.1 Mbps***)

*) 19.4 cps = 1000k sub. x 35 msg/sub/BH x 2 cells/msg/3600 s

**) 10.1 Mbps = [1000k sub. x 35 msg/sub/BH x (70 byte + 60byte)/msg x8bits/byte]/3600 s



***) 13.1 Mbps = [1000k sub. x 35 msg/sub/BH x (70 byte + 98 byte)/msg x8bits/byte)]/3600 s

ISUP by SIGTRAN

ISUP message transmitted by TDM link needs bandwidth per call 40 byte x6/2 = 120 bytes. In the case of SIGTRAN, it uses IPv4 bandwidth (40 + 60)x 6/2 = 300 bytes per call excluding Ethernet overhead. Or (40 + 98) x 6/2= 414 bytes per call including Ethernet overhead.

Table 12. ISUP message estimation

ISUP By TDM ExcludingEthernetoverhead

Including Ethernetoverhead (38 bytes)

Per call 120 bytes 300 bytes 414 bytes

500K BHCA 0.133 Mbps*) 0.333 Mbps**) 0.46 Mbps***)

*) 0.133 Mbps = 500k calls/BH x 120 bytes/call x 8 bit/byte/3600 s

**) 0.333 Mbps = 500k calls/BH x 300 bytes/call x 8 bit/byte/3600 s

***) 0.46 Mbps = 500k calls/BH x 414 bytes/call x 8 bit/byte/3600 s

BICC by SIGTRAN

BICC is based on ISUPv3. It supports different kind of bearers bydeploying application transport mechanism (APM). The message IAM andAPM contain all necessary information for bearer establishment, forexample, action indicator (forward/backward), a bearer networkconnection identifier (BNC-ID), reference used to associate the bearer witha call), bearer interworking function (BIWF) address (MGW address),Codec(s) and tunnelling-related information. Approximately 150 bytespayloads are introduced in an initial address message (IAM) or applicationtransport mechanism (APM).

The simplified rule for calculating BICC message (by SIGTRAN) length percall is (40 + 98) x 6 + (150 + 98) x 2)/2 = 662 bytes (including Ethernetoverhead).

MAP by SIGTRAN

Known facts about MAP over TDM links:




. With average traffic model, 11 000 bits per subscriber need to betransferred during a busy hour from MSC to other NEs (HLR,neighbour MSC/VLR for handover, GMSC).

. 11 messages per busy hour at one direction are transferred, withaverage MAP message length 121 bytes.

The table below shows the average estimation results, which are based onM12 MSCi (600k) testing report (Nokia official traffic profile is used). In therough estimation, it is assumed that the average MAP message number is11 per busy hour per subscriber and the message length is 121 bytes byTDM links. The results and estimates are scaled to 1M subscribers.

Table 13. MAP estimation results

MAP (1000k) By TDM ExcludingEthernetoverhead


By testing report 3.3 Mbps 5.2 Mbps 6.2 Mbps

By rough estimation 3.0 Mbps 4.5 Mbps 5.3 Mbps

The rough estimation is based on the well-known MAP signallingscenarios, message length and Nokia official traffic profile.

CAP/INAP by SIGTRAN

It is assumed here that SCP also packs all operations to a separate SCCPmessage. This means 36 octets per message extra with TDM/SS7. Thecontent of the messages varies greatly, depending on the case. Thereforetruncation is a good choice.

Also, future CAMEL releases will increase the message sizes (X) includingSCCP, TCAP and CAP. For INAP you can assume the same messagesizes.

From MSC/MSS to SCP, the value of X is:

1. IDP 220

2. ACR 60

3. ERB(Disconnect) 60

4. SRR 70

From SCP to MSC/MSS, the value of X is:



5. AC 60

6. CUE 40

7. RRB 80

8. FCI 90

9. CTR 50

10. ETC 50

11. PA 50

12. PC 80

13. DFC/DFCwA 40

14. SCI 100

The total IP bandwidth requirement at Mc interface

If no MAP/CAP need to be transferred at Mc interface

MAP and CAP do not need to be transferred through Mc interface if:

. HLR and SCP support the same SIGTRAN implementation as MSSdoes, MAP/CAP can be handled directly between MSS and HLR/SCP through SIGTRAN associations in the IP network.

Or:

. HLR and SCP do not support the same SIGTRAN implementationbut conventional TDM links, and integrated MSS is used, orstandalone MSS has optional IPCH to support TDM links too. Thedirect TDM links between MSS and HLR/SCP can be used.

It is obvious that H.248 and BSSAP/RANAP always have to be transferredat Mc interface. If the MGW has a direct PCM connection to PSTN, theISUP signalling is handled through MGW.

Assuming that 50% of traffic is Mobile-PSTN calls, 500k BHCA would usea certain amount of IP bandwidth for ISUP signalling between MGW andMSS on top of the total need of H.248 and BSSAP/RANAP. In this case,total IP bandwidth needed between MSS (1000k sub.) and MGW (1000kBHCA) is shown below:




1. If there is 100% BSCs (1000k sub.) traffic in the connection:

Table 14. Total IP bandwidth needed between MSS and MGW, 1

BSSAP+H.248+500kBHCA PSTN calls

Excluding Ethernetoverhead


IP bandwidth 11.2 Mbps - 15.8 Mbps 14.7 Mbps - 20.5 Mbps

2. If there is 100% RNCs (1000k sub.) traffic in the connection:


RANAP+H248 +500k BHCAPSTN calls



IP bandwidth 15.5 Mbps - 17.2 Mbps 19.7 Mbps - 21.8 Mbps

3. If there is 50% RNCs (500k sub.) and 50% BSC (500k sub.) traffic inthe connection:


RANAP+BSSAP+H.248 + 500kISUP calls

ExcludingEthernet overhead


IP bandwidth 13.3 Mbit/s - 16.5Mbps

17.2 Mbit/s - 121.2 Mbps

If MGW has to be used as a signalling gateway for MAP between MSSand HLR



If HLR does not support the same SIGTRAN implementation, and MSSdoes not support TDM links, MAP between MSS and HLR has to behandled through MGW. The IP bandwidth at Mc interface has to includethe MAP requirement.

Adding average MAP signalling requirement to Mc interface, the averageIP bandwidth use between MSS (1000k) and MGW (1000k) is estimatedas presented below:

1. If 50% BSC (500k sub.) and 50% RNC (500k sub.) traffic in theconnection:


H.248+RANAP+BSSAP MAP+500k ISUP calls



Average use 17.8 Mbps - 21.7 Mbps 22.5 Mbps - 27.3 Mbps

The bandwidth usage for CAP signalling depends on IN services types,the way of implementation, and the use of those services in the network.Once getting each CAP message length (X + 60 or X + 98) by SIGTRAN,the same way of calculating TDM CAP links can be used to estimate the IPbandwidth.

If CAP message is added and the needed message is maximised, themaximum used bandwidth probably goes up to 20 Mbit/s.

Nokia standalone MSS (1000k) has three duplicated LAN switches forSIGTRAN, equipped separately in three cabinets. Each has uplinkcapacity up to 100 Mbit/s, which is enough for MSS signalling needs.

User data

User data is carried over AAL2/ATM on the Iu-CS interface and over RTP/UDP/IP or AAL2/ATM on the Nb interface. The protocol stacks for userdata transport over Iu-CS and Nb interfaces are depicted in the tablesbelow.

Table 18. Protocol stack for user data transport over Iu-CS interface

Codec

Iu-UP




Table 18. Protocol stack for user data transport over Iu-CS interface (cont.)

AAL2

ATM

Phy

Table 19. Protocol stack for user data transport over Nb interface

Codec

Nb-UP

AAL2 RTP

UDP

ATM IP

Phy

Codecs

The MGW supports AMR, GSM EFR, GSM FR, and G.711 A-law and �-law codecs.

The AMR codec can operate in eight different modes, each modeproducing a different bit rate. For example purposes we assume belowAMR mode 7 (12.2), which corresponds to GSM EFR mode. Thisproduces the best voice quality, and consequently the highest bit rate. Thenumber of bits in each AMR mode 7 frame according to 3GPP TS 26.101is 244 bits, or 31 bytes (30.5 to be exact). A frame is produced every 20ms, yielding a bit rate of 12.2 kbit/s.

AMR specifies silence suppression, which is assumed to reduce theeffective bandwidth of AMR 12.2 to about 7.5 kbit/s for one connection.This is based on the following assumptions:

. Voice/silence ratio is 60/40.

. SID is sent every 8 frames (0.16 s).

. SID frame is 39 bits long.



In one second, with 60% activity, 1000ms x 0.6/20ms = 30 speechsamples are generated. Three SIDs are generated. Thus the resultingbandwidth (in one direction) is 30 samples x 31 bytes + 3 samples x 5bytes = 7 560 bit/s.

G.711 A-law and �-law produce a constant bit rate of 64 kbit/s, no silencesuppression (SID) is used.

Nb-UP/Iu-UP framing

The Nb-UP protocol, specified in 3GPP TS 29.415, is used to convey databetween MGWs over the Nb interface. The Nb-UP protocol can be eitherin support mode or in transparent mode. In Nokia MSS, the use of Nb-UPcan be configured in the user plane analysis for the IP backbone. For ATMbackbone Nb-Up framing is always used.

The transparent mode is intended to be used when the bearer does notneed any services from the Nb-UP protocol except transfer of data. Intransparent mode, no Nb-UP frames are generated.

The support mode is intended to be used when the bearer requires somefunctionalities of the Nb-UP protocol besides transfer of data. So far, theonly support mode defined is the support mode for predefined SDU size.For example, an AMR codec might use this support mode because itrequires some procedure control function, for example initialisation andrate change.

The Nb-UP framing is identical to the Iu-UP framing defined in 3GPP TS25.415. In the support mode, the Nb-UP overhead is 3 or 4 bytes,depending on whether CRC is used or not. In the transparent mode, Nb-UP header is absent, and thus overhead is 0 bytes.

Real-Time Protocol (RTP)

RTP is a simple protocol used to encapsulate (typically) voice andcomressed video codec information for end-to-end delivery. The purposeof RTP is to offer a remedy for the delays and packet losses inherent in IPbased networks. RTP uses UDP for transport.

The services provided by RTP, and its companion protocol Real-TimeControl Protocol (RTCP), include

. payload type identification

. sequence numbering




. time stamping

. delivery monitoring.

An RTP packet consists of a fixed RTP header, a possibly empty list ofcontributing sources, and the payload data. Up to 5 speech frames can bepacked into a single RTP packet. In the MGW, RTCP packets aregenerated every 5 seconds, and therefore their effect on the bandwidthrequirement is negligible.

The Contributing Source (CSRC) identifiers are present in the header if thepayload consists of a mix of traffic from various contributing sources. Anexample could be, for example, audio conferencing streams, which aremultiplexed in am RTP mixer, which would then include the SSRCidentifiers contributing to this stream in the CSRC field. In Nokia'simplementation (FN21106) the CSRC is always empty. Thus the resultingRTP overhead is 12 bytes.

IP bandwidth requirement example for user plane

The user plane can use either 20ms packetisation interval (GSM andG.711 codecs) or 5ms packetisation interval (G.711 codec). The resultingpacket size for different codecs is:

. AMR 4.75 12 bytes (codec + Nb-Up*)) + 20 bytes (RTP + UDP) + 20bytes IPv4

. AMR 4.75 12 bytes 35 bytes (codec + Nb-Up*)) + 20 bytes (RTP +UDP) + 40 bytes IPv6

. AMR 12.2 31 bytes (codec + Nb-Up*)) + 20 bytes (RTP + UDP) + 20bytes IPv4

. AMR 12.2 12 bytes 31 bytes (codec + Nb-Up*)) + 20 bytes (RTP +UDP) + 40 bytes IPv6

. EFR 35 bytes (EFR + Nb-Up*)) + 20 bytes (RTP + UDP) + 20 bytesIPv4

. EFR 35 bytes (EFR + Nb-Up*)) + 20 bytes (RTP + UDP) + 40 bytesIPv6

. FR 37 bytes (EFR + Nb-Up*)) + 20 bytes (RTP + UDP) + 20 bytesIPv4

. FR 37 bytes (EFR + Nb-Up*)) + 20 bytes (RTP + UDP) + 40 bytesIPv6

. G.711/5ms 44 bytes (G.711 + Nb-Up*)) + 20 bytes (RTP + UDP) + 20bytes IPv4



. G.711/5ms 44 bytes (G.711 + Nb-Up*)) + 20 bytes (RTP + UDP) + 40bytes IPv6

. G.711/20ms 160 bytes (G.711 + Nb-Up*)) + 20 bytes (RTP + UDP) +20 bytes IPv4

. G.711/20ms 160 bytes (G.711 + Nb-Up*)) + 20 bytes (RTP + UDP) +40 bytes IPv6

*) = Nb-Up is added in Mc interface (CS-MGW <-> CS-MGW) but not in Mbinterface towards IMS. In the Mb interface 4 octets are saved per frame/packet. See NbUp framing and 5ms/20ms packetisation on UPD for moredetails.

The small size and large number of the voice packets leads to a trafficprofile that is different from traditional IP networks. The packet processingcapacity of the networking equipment has to be dimensioned for the smallpacket size.

IP bandwidth requirement example for user plane router forwardingcapacity

When calculating the router's forwarding capacity, you should always usethe information about the number of simultaneous calls routed through therouter. For example, with 6000 simultaneous RTP streams (meaning forexample 3000 simultaneous calls with 2 participants), the forwardingcapacity requirements are (packets per second):

. AMR with 20ms packetisation interval 6000 x 50 = 300 kpps

. EFR with 20ms packetisation interval 6000 x 50 = 300 kpps

. G.711 with 20ms packetisation interval 6000 x 50 = 300 kpps

. G.711 with 5ms packetisation interval 6000 x 200 = 1200 kpps

And the bandwidth usages for the example with 6000 simultaneous RTPstreams using IPv4 are:

. EFR with 20ms packetisation interval (IPv4) 300 kpps x 75 bytes x 8bits = 180 Mbit/s

. FR with 20ms packetisation interval (IPv4) 300 kpps x 77 bytes x 8bits = 185 Mbit/s

. G.711 with 20ms packetisation interval (IPv4) 300 kpps x 160 bytesx 8 bits = 384 Mbit/s

. G.711 with 5ms packetisation interval (IPv4) 1200 kpps x 84 bytes x8 bits = 970 Mbit/s




Note

The example does not contain link layer overheads. These have to becalculated separately for PPP, ATM, Ethernet or any other protocolused.

IP bandwidth requirement example for user plane backbone transmissioncapacity

For the backbone the calculation is the same as for forwarding capacity,except:

. The Ethernet header 38 octets is replaced by PPP (8 octets).

. The transmission pipe is always 2-directional.

Voice Activity Detection (VAD )

In practice, voice activity level is not 100%, as in a typical MS/UE call bothparticipants usually speak less than half of the time on the average, andtherefore the actual bandwidth use is less than in the example above, assilence suppression turns off the transmitter when there is no voice input.For the other codecs but G.711 60% activity can be used for dimensioning.

The resilience of the backbone should be considered in dimensioning. Asvoice traffic is generally carried using the highest priority group (EF PHB),load-balanced links should not be loaded with more than 50% of voicetraffic, as the failure of one link would lead to an overload situation on theremaining link. The UDP-based voice traffic cannot be scaled down insuch an overload situation. Instead all voice connections will suffer andlower priority traffic will be starved to the extent allowed by the schedulerused in the routers. See also Over-dimensioning in IP network.

The small size and large number of the voice packets leads to a trafficprofile that is different from traditional IP networks. The packet processingcapacity of the networking equipment has to be dimensioned for the smallpacket size.

ATM bandwidth requirement example for user plane

AAL2

AAL2 specifies bandwidth-effective transmission of variable length ofpackets over a single ATM VC. Up to 248 AAL2 connections can bemultiplexed on a single VC.



The AAL2 adaptation layer consists of two parts: Common Part SublayerCPS [I.363.2] and Service Specific Convergence Sublayer SSCS [I.366.1].The CPS specifies a format for CPS-PDU, which consists of a CPS-PDUstart field and CPS-Packet.

The CPS-Packet has a three-byte CPS-Packet Header followed by 1-45octets payload. The start field (STF) is one-octet long, followed by CPS-PDU payload. The CPS-PDU payload may carry zero, one or morecomplete or partial CPS-Packets. The CPS-Packet may overlap one ortwo ATM cells, and the boundary can be anywhere, including the CPS-Packet Header. Thus, AAL2 userplane message format is:

Table 20. AAL2 userplane message format

5 1 3 31+4 9 (bytes)

AMR 12.2 kbit/s

ATM Header STF AAL2 (AMR+IuUP) Next AAL2 PDU

Note

Note that if G.711 codec is being used then Nb_UP is not present in theprotocol stack.

Note that the used L2 /L1 technology adds overhead to the bit ratespresented below.

Thus, the bandwidth with ATM/AAL2 for different codecs are:

. G.711: 64kbit/s x 53 octets per ATM cell /45 payload octets per cell =75.4kbit/s.

. AMR 12.2: 8bit/byte x 50/s x [31 (frame) + 4 (NbUp) + 3 (AAL2) ] + 8x 50 x [5 (ATM header) + 1 (STF) ] x [31 + 4 + 3] / 47 (payload percell, 48 – 1 STF) = 17.14 kbit/s (without VAD). With VAD 11kbit/s.(17.14k x 60% + 40% x 0.296kbit/s SID frames).

. AMR 4.75: 8.57kbit/s (without VAD). 5.26bit/s with VAD.

. EFR: Basic rate is 35 bytes/frame x 8bit/byte x 50 frame/s = 14kbits.-> 18.94kbit/s without VAD. With VAD 11.5kbit/s.

. FR: 19.85kbit/s without VAD. With VAD 12.0kbit/s.




The required bandwith depends on the allowed AAL2 multiplexing delayand the number of channels per VC. 2 ms delay is recommended. Asmaller delay requires drastically more bandwidth and a bigger delay doesnot save much bandwidth, and the delay is critical.

Next values are bandwidths that need to be reserved for AAL2 AMR12.2speech order to ensure delay requirements. Values provided by AAL2CAC are presented in the following table.

Table 21. Values provided by AAL2 CAC

Number of AAL2 channels/path Bandwidth/delay 2 ms [Mbit/s]

50 1.7 (34 kbit/s/channel)

100 2.57

150 3.36

200 4.2

248 4.98 (20 kbit/s/channel)

N CID bandwidths with different path sizes are presented in the followingtable.

Table 22. N CID bandwidths with different path sizes

Number of AAL2 paths Bandwidth/delay 2 ms [Mbit/s]

50 channels/paths x 60 paths = 3000channels

102


72


67


50


60



Table 23. Conclusion: If the average size of RNC is at least 2000 Cs-channels,the minimum size of paths is 220 channels.

Channel/AAL2 paths Number of channels/A2SU

Bandwidth/A2SU [Mbit/s]

220 2640 110

248 2976 123

IP bandwidth requirement of SIP

Session Initiation Protocol (SIP) conveys information in text (ASCII)format. Thus the message sizes are big. For example, the INVITEmessage to setup a call has the following sizes, excluding the lower layers(UDP/TCP, IP, Ethernet):

. INVITE of Profile A 800-1100 bytes

. INVITE of Profile B 500-700 bytes

. INVITE of Profile C 800-1100 bytes

An average SIP message size is expected to be 500-550 bytes, 8.5-9.0kbytes/call.

Both UDP and TCP headers are 20 octets. The UDP is used unless thepacket fits to a single IP packet (MTU-200, if MTU is known, otherwise1300 bytes). If TCP is used, the dialogue is common for all calls betweenthe particular pair of sender and recipient IP addresses. In other words, theTCP session establishment messages (SYN, FIN) can be ignored whendimensioning. For each data packet TCP sends acknowledgement whichadds a minor overhead.

The IP and UDP/TCP overhead is about 10% with the given messagesize.

Nokia VoIP Server (NVS) - LDAP

In 1000k the MSS requirement is LDAP 500 reads/s. The protocol stack isEthernet 38 (octets), IPv4/IPv6 20/40, TCP 20, LDAP. MSS sends aSearch request in which the LDAP content is about 75 octets.

LDAP database returns a Search entry in which the LDAP content is 380octets (plus headers) and a Search result with LDAP 3 octets (plusheaders).




NVS registration

SIP is used in MSC Server (MSS) in the following cases: In IMS (Profile A)when MSS is a Nokia VoIP Server (NVS), in IMS interworking (Profile B),and for tunneling ISUP messages with MiME encoding (Profile C/SIP-I).The SIP messages should be routed directly to the correct signalling unitof the MSS, that is, the MGW is not involved.

The UE sends the registration interval. After each interval, the registrationmust be repeated, otherwise the user is deregistered. MSS default is 1h ifthe terminal does not provide a timer.

MSS receives about 700 octets (excluding Ethernet header) and respondswith some 500 octets (excluding Ethernet header).

If the authentication is on, the sequence is duplicated.

Network Element Management Unit (NEMU) bandwidth requirements

The following list describes the bandwidth requirements per application:

. NEMU client - NEMU server: 0.5 Mbit/s for one Application launchersession.

. Feature 1127 Fast Subscriber Management: 2 Mbit/s for aconnection between an FSM server and FSM client.

. Feature 1138 NE Backup Server: for a connection between the localbackup server and the remote backup server

HLR (1.2M) 2 Mbit/s

HC HLR (2.4M) 4 Mbit/s

EHC HLR (3.75M) 8 Mbit/s.

. Feature 1539 Multivendor HLR redundancy: 2 Mbit/s for aconnection between an MVR server and a Customer Care andBilling System (CCBS).

. Feature 1601 N+X HLR Redundancy:

The bandwidth requirement between the N+X server and a live HLRdepends on the traffic profile as described in the table below:



Table 24. N+X bandwidth requirements by HLR capacities

HLR type Trafficprofile*)

BW real timecopy phase**)

BW initialisationphase 40 min***)

BW initialisationphase 40 min***)

1.6M HLR 2 250 000 2 8.5 5

HC HLR 4 500 000 4 16.5 9.5

EHC HLR 7 031 250 6 25.5 14.5

*) Traffic Profile (average transactions in HLR during busy hour)

**) Bandwidth (BW) requirement Mbit/s

***) The given BW initialisation phase requirement is the total demand forbandwidth during the given N+X HLR Redundancy initialisation phase (40min or 90 min).

Note that the final bandwidth requirements are always calculatedaccording to the specific network where NEMU is to be implemented.Factors such as number and capacity of HLRs and RHLRs, and averageHLR traffic profile during a busy hour all affect the BW requirements.

9.6 IP over ATM

IP over ATM (IPoA) is needed if the backbone is ATM and some IPprotocol such as H.248 needs to be conveyed between core sites. In thefirst case, the STM-1s connected to MGWs and ATM cells are conveyedon SDH (STM-1/OC-3). In another case, ATM cells may be furtherconveyed over TDM (IMA). The Nokia implementation of IP over ATM usesthe following protocol stack:

Table 25. IP over ATM protocol stack

UDP/TCP/SCTP

IP

AAL5

ATM

SDH/TDM

For the sake of dimensioning, the ATM/AAL5 overhead needs to beconsidered. The payload is IP packets excluding the Ethernet/MAC layer.




Example

Let us take H.248 as an example:

MEGACO messages are 120 - 160 octets on the average, let us assume140 as an average message size. IP overhead is 20 (IPv4) or 40 octets(IPv6), let us assume IPv4. SCTP overhead is 28 octets. Ethernetoverhead is not conveyed. With IPv4 the average packet size would be140 + 20 + 28 = 188 octets.

AAL5 breaks this 140 octet packet into ATM cells in the following way:

For each (IP) packet it adds 1 UUI, 1 CLI, 1 L and 4 CRC octets = 5 octets.In order to make it full ATM cells a filler (PAD) 0-47 octets is added. 140/48= 2.9 cells, this means that 3 cells are needed, and the PAD is 3 x 48 – 140octets = 4 octets.

However, since the packet size varies it is better to calculate an averagePAD size which would be half of the maximum: 47/2 = 24 octets. Thus, theaverage IPoATM overhead would be in this example:

AAL5 overhead + ATM cell headers (3 cells) + average filler/IP packetsize:

(5 + 3 x 5 + 24)/188 = 23% on top of IP overhead.

The following table shows the overhead ratio as a function of an averageIP packet size:

Table 26. Overhead ratio of an average IP packet

IP packet size Overhead ratio

72 54,17

120 36,67

168 29,17

216 25,00

264 22,35

312 20,51

360 19,17

408 18,14

456 17,32

504 16,67



Table 26. Overhead ratio of an average IP packet (cont.)

IP packet size Overhead ratio

552 16,12

600 15,67

9.7 ATM over TDM (IMA)

If the operator does not have an ATM network, Iu-interface between MGWand RNC needs to be conveyed over TDM trunks. The technology iscalled Inverse Multiplexing over ATM (IMA). At the maximum, one IMAgroup can contain 8 E1s. The capacity of one E1 is 4500 cps (ATM cellsper second) when not part of IMA group, and 4490 when the E1 is part ofan IMA group.

Thus the payload bit rate per E1 is about 4500 cell/s x 48 bytes/cell x 8bits/byte = 1.728Mbit/s per E1.

In the Iu case the RANAP and the user plane are calculated as payload. Insome cases H.248 is conveyed as IP over ATM over TDM.

9.8 Connection rate based CAC by BICC CICconfiguration

A connection rate based Call Access Control (CAC) can be established byBICC Call Identification Code (CIC) configuration. This feature is based onITU-T and 3GPP specifications. Call Identification Code (CIC) in BICCcompared to the Circuit Identification Code (CIC) in ISUP does not havesimilar relationship to the actual user plane resource (that is, the actualcircuit). Technically, the BICC CIC is only the limitation of how manysimultaneous calls can be established between two specific signallingpoints. However in Nokia system, more flexible configuration can be basedon individual CIC ranges within circuit groups.




Figure 48. BICC CIC controlling the number of calls between two MGWs

On MSS level BICC CICs control how many calls one MSS sets up overone particular BICC Circuit Group (CGR) towards another MSS. By routeand circuit group configuration the BICC CICs can be used to manage thenumber of simultaneous calls between MGWs controlled by different MSCServers.

BICC

CIC range:122-100 ... 122-240

MSC Server_1NA0, 3F8h


MGW_1 MGW_2

BSC

Route:BICCROU1, 360 +UPDR=MSS2UPR

Circuit group 3:BICC1, 10

Alternativerouting toTDM can takeplace if themaximumnumber ofBICC CICshave beenconsumed.

The maximumnumber ofsimulatenouscalls betweenMGWscontrolled bydifferent MSSscan be definedby BICC CICsallocated tocertain circuitgroups betweenMGWs.

MSC

SSP

VLR

MSCSSP

VLR

RNC

IP transport

TDM transport

BSC

RNC

BICC CICs’allocated CGRsdeterminethe numberof calls forIP transportbetween theservice areas.



Figure 49. BICC CIC controlling the number of calls between two MSC Serverservice areas, BICC CIC control is per MSC service area, that is, peruser plane destination (group of MGWs)

There can be be dedicated CIC ranges for different user plane transports,CICs per circuit groups, and normal routing control can be applied. Thismeans that it is possible to use one route to lead calls to the samedestination through different circuit groups by linking several circuit groups(maximum 8) with different connections to the same route.

BICC

CIC range:122-100 ... 122-240



MGW_1

IPBB

MGW_3

MGW_2 MGW_4

BSC





MSCSSP

VLR

MSCSSP

VLR

TDMBB

BSC

IP transport

TDM transport

BICC CICs’allocated CGRsdeterminethe numberof calls forIP transportbetween theservice areas.




Figure 50. BICC CIC controlling the number of calls between two MSC Serverservice areas, BICC CIC control is per MGW

It is also possible to make Selective Circuit Reservation (SCR) that allowsthe operator to have more extensive control over how the circuits arereserved and used under heavy traffic. You can set a limit to how manycircuits may be reserved on the circuit groups of a route, after whichdifferent criteria are followed on how calls are directed to another circuitgroup or how they are rejected. This alllows specific control for example foremergency calls etc. Normally (when SCR is not in use), the circuits arereserved in the order the calls arrive. All calls are directed to the primarycircuit group until no free circuits are left on that circuit group. After this,calls are directed to the next alternate circuit group, and so on. All calls aretreated equally. When no free circuits are left on any of the alternate circuitgroups, calls are rejected or directed to an alternate route if there is one.Selective circuit reservation makes it possible to alter the normal searchmethod.

BICC

CIC range:122-100 ... 122-240



MGW_1

IPBB

MGW_3

MGW_2 MGW_4

CGR1

CGR11

BSC

CGR12CGR2

CGR13

CGR3





MSCSSP

VLR

MSCSSP

VLR

TDMBB

BSC

IP transport

TDM transport



Figure 51. Selective circuit reservation

Whenever the connection rate limit is exceeded, new call attempts arerejected. Whenever a call is rejected, preferrably an alternative routing/re-hunting for other User Plane transport like for TDM should take place.

Note

User plane related configuration may become too complicated if highergranularities are needed for IP CAC based on BICC CIC ranges (forexample, if certain limit need to be defined for calls between differentMGWs, CGR configuration may become too complex to manage).

Additionally, if IP is used between MGWs controlled by same MSC Server,BICC CIC based IP CAC cannot be used. This requires furthermechanisms such as the planned IP CAC enhancements in theforthcoming releases.

DESTINATION

SUBDESTINATIONALT=0

ROUTE 1

SUBDESTINATIONALT=1

SUBDESTINATIONALT=2

ROUTE 2 ROUTE 3

PRIMARYCIRCUITGROUP

2ndALTERNATIVE

CIRCUITGROUP

1stALTERNATIVE

CIRCUITGROUP

- rejection % of direct traffic- rejection % of alternative traffic

- rejection % of direct traffic- rejection % of alternative traffic




9.9 Detailed planning of CS core network

In the detailed planning phase the skeleton plan created during thenetwork dimensioning is truly fleshed out. With detailed circuit switched(CS) core network planning you generate the source data for implementingthe CS core network and define the network element configurationparameters. The detailed CS core planning starts from the predefined setof planning assumptions, which are defined in the dimensioning phase.The detailed CS core planning produces the source data required forintegrating the core network elements.

You need to do the following:

. Check the network diagrams obtained in the network dimensioningphase for any changes and complete them with the data created bythe tasks described below.

. Create names for destinations and subdestinations, circuit groups,and so on, based on the naming and numbering conventionsadopted, fix the routing types and create the routing source data foreach network element.

. Define a standardised approach in programming the digit analysisand produce the source data for digit analysis for each networkelement.

. Define signalling points in the network, signalling links and link sets,signalling routes and route sets, based on the naming andnumbering conventions, and generate the related source data foreach network element.

. Define the numbering plans, which include mobile subscriberinternational ISDN number (MSISDN) ranges, mobile stationroaming number (MSRN) ranges, handover number ranges, voicemail access numbers, and network element numbering andaddressing (for example, global titles, signalling point codes and IPaddresses).

. Define the number groups used by each network element, bypromoting the allocation of geographically determined number groupin order to facilitate the operation of the network.

. Define the charging zones and cases for the network, determine thecollection and transfer of charging records, and generate thecorresponding source data for each network element.

. Define the parameters for the logical and physical connections of thenetwork elements to DCN networks in order to implement the DCNplanning at the network element level.



. Plan the general synchronisation in detail at each network elementlevel: define physical connection and priority settings in eachnetwork element, and generate the source data for thesynchronisation.

. Define the network topology, including information on how MSCs,MSSs and MGWs are interconnected (for example, hierarchy of theelements and use of transit MSCs or GCSs).

. A location area refers to the part of the MSC or MSS area where amobile station can move freely without location updating. Considerthe use of location areas also when planning the core network sites.

A table listing the source data requirements is created for each networkelement. The 3G MSC’s source data requirements are presented as anexample in the following table:

Table 27. MSC source data requirements

PCM usage ET creation (MSC/HLR)

PCM number

signalling controlling unit

signalling userpart

synchronisation usage and priority

SS7 signalling link sets

signalling route sets

STP access, global title analysis

global title results

global title data record

SCCP subsystems

optimum routing analysis

routing circuit groups

routes

destinations

subdestinations

special routes

semipermanent connections

routing and charging attribute subanalysis

routing attribute final result




Table 27. MSC source data requirements (cont.)

digit analysis origin analysis

preanalysis + extended preanalysis

analysis trees

emergency and service numbers

IMSI analysis

call forwarding analysis

service centre analysis

charging charging day classes

charge groups

charging zones

charging attribute subanalysis

charging analysis final result

hot billing

connections special circuit groups

announcement parameters

external announcements

end of selection analysis

data link connection

end of selection attribute subanalysis

end of selection attribute final analysis

outgoing call barring analysis

private networks digit analysis for private numbering plan

private branch

exchange routing

supplementary services for private branchexchange

cellular network RNC definition

BS definition

LAC definition

network location areas

MSC-specific number range

network and MSC-specific number



Table 27. MSC source data requirements (cont.)

parameters PLMN parameters

VLR parameters

signalling link parameters

signalling route set parameters

SCCP parameters

CCS7 level 3 parameters

PLMN parameters (HLR)

HLR parameters






10 Network management system planning

Data Communication Network (DCN) is a communication network thatprovides a means for connecting network management system andnetwork elements together. The DCN planning service provides theconnectivity between the OSS (NetActTM) sites and core network sites(that is, packet switched and circuit switched sites) for operation andmaintenance purposes. The DCN can also be built either on OSI Layersstack or on TCP/IP protocol layers stack, but the new Nokia networkelements are supported with TCP/IP protocol stacks for managementpurposes.

Operation and maintenance (O&M)

NetActTM

Nokia NetActTM network management system for 3G supports both aregional and a centralised O&M organisation. Centralised O&M operationsallow full management of the network via a single screen. The applicationsin the centralised management centre include nation-wide monitoring ofnetwork faults and performance together with traffic monitoring as shownin the following figure:



Network management system planning

Figure 52. Nokia NetActTM centralised solution

Decentralised O&M operations support different regional managementcentres, and perform all activities related to monitoring and developing thenetwork in individual regions, as depicted in the following figure:

VLAN3

RNC RNCRNC ATMm

Backbone

GSM RAN

Operator office& Internet

RAN

VLAN2

NetAct (servers, EMs, Traffica, etc.)

VLAN1

FW

WAN connections (ATM, analog X.25, digital X.25)

Packet Core

VLAN4

GGSN

DNS

SGSN



Figure 53. Nokia NetActTM decentralised solution

For detailed information, see Nokia NetActTM product documentation.

Network Management Unit (NEMU)

The MGW network element contains an integrated network elementmanagement unit (MGW NEMU) that offers an interface towards NokiaNetAct. MGW NEMU is a mandatory part of MGW deliveries. It offers post-processing functions for statistics and trace, and mediates all alarms andnotifications sent from MGW to NetAct and vice versa.

The role of MSC/MSS/HLR NEMU is completely different. This optionalNEMU offers value-added services mostly to HLR but also to MSS andSRRi. MSC/MSS/HLR NEMU is a separate network element and it doesnot have a mediator role. Instead, MSC/MSS/HLR elements have a directinterface from NE to NetAct.

MGW NEMU can be used without NetActTM for the following purposes:

Regional cluster

NetAct Site 2

Global cluster

NetAct Site 1

Regional cluster

NetAct Site 3

3G network 2G network

WAN(IP)VPN





. Configuration management:

MMI Window

. Network monitoring:

Fault Management GUI

O&M support for 3rd Party device

Diagnostics and State Handling GUIs

. Performance management:

NE Measurement explorer (GUI)

Measurement Management GUI

NE Threshold Management

. Network administration:

HW and SW management

. Trace

MGW NEMU can be used with NetActTM for the following purposes:

. Network monitoring:

via alarm system

. Performance management

. Network administration:

HW and SW management

Security management

. Trace

In MSC/MSS/HLR, NetActTM can be used for the following purposes:

. Fault management:

In DX alarms

. Configuration management:

In DX MMLs

. Account management – not used



. Performance management:

In DX measurements and reports, Trace

. Security management – not used

Additionally, NEMU enables the following applications:

. Network Element Backup Server (NEBS)

. N+X HLR redundancy

. Multi-vendor HLR redundancy

. HLR/SRRi Workstation

. Fast Subscriber Management

. Redundant HLR Signalling Activation

For MSC/MSS/HLR NEMU connectivity TCP/IP or X.25 are supported. IfIP is selected, it is recommended to use a separate O&M VPN, andfirewalls should be used to a separate O&M from the Internet. NEMUsupports IPv4 only. See Site Connectivity Guidelines for CS Core Networkfor more details. As a rule of thumb, each network element requires600kbit/s IP bandwidth.

NEMU feature's functionality is based on two network topologies: oneserver per multiple network elements, where one NEMU server can servemany network elements, and one server per single network element,where one server is dedicated to one network element. Below is a list ofthe main NEMU applications and the topologies they require.

Server per multiple NEs Server per single NE

NE Backup Server X

HLR/SRR Workstation X

Fast SubscriberManagement

X

Redundant HLR signallingactivation

X

N+X HLR redundancy X

Multivendor HLRredundancy

X

For more information on NEMU dimensioning and planning, contact NokiaSiemens. The features used affect dimensioning.




10.1 Planning O&M network for CS core network

Detailed O&M network planning

The detailed O&M network planning in the core network is based on theresults produced in the pre-planning phase. The deliverables for detailedDCN network planning in the core network are:

. Detailed DCN network topology plan (including all physicalconnections, cabling and port numbers in each site for all networkelements with their names and addresses).

. Detailed inter-site connectivity plan (including WAN connections androuting strategy).

. Detailed intra-site connectivity plan (including VLAN configurations).

. Naming convention (domain name configurations).

. IP addressing plan (including a subnetting plan based on siteinformation and number of NEs in each site and IP addressingassignment).

. Capacity requirements (O&M traffic capacities, PM FM, AM, SMS,charging).

. Security requirements (describing physical security, element levelsecurity and application level security with access listconfigurations).

. Data sheets of each network element for O&M purposes (MSCi,HLRi, MGW, RNC, BTS, SGSN, GGSN, Cisco routers andswitches).

The aim of the planning phase is to create an IP network for carrying theO&M traffic from the different core network elements and platforms to themanagement system (OSS site). For this purpose, the IP DCN networkuses the same operator backbone network, which is also used for carryingthe signalling and user traffic. This is shown in the following figure:



Figure 54. Core network and different platforms using the same IP backbonenetwork

DCN planning phase for operation and maintenance network takes intoaccount the existing network platform and the network development path,estimated future changes in service and capacity demand as well as anytechnical and geographical constraints, and provides high-qualityinterconnections.

The service consists of three main modules:

. analysing and assessing operator’s DCN service requirements

. pre-planning or network dimensioning

. detailed planning of the management interconnection.

Regional cluster

NetAct Site 2

Global cluster

NetAct Site 1

Regional cluster

NetAct Site 3


WAN(IP)VPN





The benefit of using IP-based DCN is that it decreases the overall cost ofbuilding the O&M network and the network also becomes morehomogenous. Another benefit for using the IP DCN is that it becomes easyto install and monitor the network. The Nokia Siemens DCN planningservice ensures that the new service requirements and technologies,together with the existing networks, form an integrated platform for theoperator’s business.

O&M service analysis and network assessment

The DCN or O&M service analysis for the core network is performedtogether with backbone planning, which identifies the entire O&Mconnections in both the circuit switched (CS) and packet switched (PS)domains such as the NetActTM, BC, CEIR, SMSC, AdC and Trafficaconnections. The service analysis also gives an indication of the trafficdemands and also the forecast demand when the service usage grows.

While the network assessments facilitate an analysis of the O&M serviceand LAN & WAN interconnectivity solutions with the management systemsfor the existing or planned network environment, the existing networkinfrastructure (or previous network plans) may set requirements andlimitations to the network solution to be planned. Analysing the existingnetwork helps overcome planning problems. The network assessmentmay require investigation of the current network, such as analysing thetraffic in the network for different type of services.

The network assessment generates the dimensioning inputs and givesinformation about the available resources and restrictions. The resultsachieved from the network assessment are used for DCN dimensioning.

The network assessment is similar in core, transmission and RAN O&Mnetworks. It is beneficial if these assessments are coordinated and done inpart jointly to reach an all-over confined design.

Dimensioning for O&M network

The pre-planning or network dimensioning is carried out based on thenetwork assessment and the inputs from the operator, and a DCN MasterPlan is produced as a result.

The O&M network dimensioning in the core network is mainly dependenton the backbone network planning. The deliverables from the DCNnetwork dimensioning in the core network are:



. High-level DCN network architecture, including network topologyand the number of network elements.

. Inter-site connectivity plan (WAN connections backbone planning).

. Intra-site connectivity plan (LAN connections).

. Naming conventions.

. IP addressing plan.

. NTP planning.

. Capacity requirements.

. Security requirements.






11 Using KPIs for network planning andperformance monitoring

Using Key Performance Indicators (KPI) for network planning andperformance monitoring gives the operator information on network qualityin terms of number of, for example, dropped and failed calls, circuitcongestion, type of call and connection. The operator may select the KPIsfor monitoring the performance and capacity of the network continuously.

OSS NetActTM KPI browser provides an overall performance measure ofthe network. However, it does not provide details of a particular call, clearcode, circuit group, and so on. To get a more detailed picture on thesystem, other tools (such as Traffica and trace) should be used.

In the MGW Network Element Management Unit (NEMU) the operatormay use the NE Threshold Management to monitor the media gateway.The operator can define their own customised KPI formulas. KPIs areeither an individual counter or a combination of several counters which arecollected in the network.

Example Ethernet interface measurement

The individual counters of the Ethernet interface measurement (561/231H)of the MGW measure Ethernet traffic on the interfaces. It providesinformation about collisions, error packets, amount of transmitted andreceived packets and bytes (octets). By adding up properly selectedcounters the operator can monitor the used bandwidth in the Ethernetinterface and forecast the expansion required.

Performance monitoring documentation of network elements

The main sources of counter information is the performance monitoringdocumentation in network element product documentation libraries.



Using KPIs for network planning and performance monitoring

The MGW measurements and their descriptions are available in MGWproduct documentation. See MGW Performance Management Overviewand MGW Measurement and Trace Management and MGW counterdescriptions.

The MSC Server (MSS) measurements are described in M-releaseproduct documentation. See NSS Statistics, Advanced Guide. The detailsof each measurement can be found at NSS Statistics, Reports (Part 1, 2and 3). Note that only the XML format is further developed.

However, the documents cannot be updated immediately after eachcounter improvement action. The purpose of the Reference InformationService (RISE) is to bring the latest counter information immediatelyavailable to the customers.

RISE can be found under Nokia Online Services → Documentation →Reference Information.

For more detailed information, see OSS/NetActTM product documentationand NSS Reporting Suite and MGW Reporting Suite.



Documents

CS CoreNet Planning