39034649 network planning

CScore1.1 CS Core System Documentation, Version 1.1

CS Core Network Planning

dn0534754 Issue 3 en

# Nokia Corporation Nokia Proprietary and Confidential

1 (158)


The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia's customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which may not be covered by the document. Nokia's liability for any errors in the document is limited to the documentary correction of errors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this document or the information in it. This document and the product it describes are considered protected by copyright according to the applicable laws. NOKIA logo is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only. Copyright Nokia Corporation 2006. All rights reserved.

2 (158)



Contents

ContentsContents 3 1 2 3 4 5 5.1 5.2 6 6.1 6.2 6.3 6.4 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 8 8.1 8.2 8.3 8.4 8.5 9 9.1 Changes in CS Core Network Planning 5 CS core network planning overview 7 Nokia network planning services 11 Resilience in network planning 15 Inter and intrasite connectivity 17 Backbone alternatives 17 Network topology 23 Planning of control and user plane analyses 31 Minimising hops on user plane 40 SS7 Signalling Transport over IP (SIGTRAN) 46 Signalling Management Cluster 50 Planning virtual MGW configuration 51 Planning of services and features 61 Selecting signalling protocol for call control 61 Planning CDS network configuration 62 Video calls requiring protocol/codec conversion 66 Planning IN services 66 Planning TFO/TrFO 67 Planning Voice Mail System (VMS) 68 Planning Selective Ring Back Tone (SRBT) 68 Planning charging 69 Planning Supercharger 73 Planning semipermanent cross-connection configurations 73 Planning Channel Associated Signalling (CAS) 74 Planning Signalling Point Codes (SPC) 74 Planning Multipoint Iu/Flex Iu 75 Planning Multipoint A/Flex A 78 Transmission planning for Multipoint Iu/A 78 Planning synchronisation and timing 79 Planning Mobile Number Portability/Service Routing Register (SRRi) Planning of convergence solutions 89 Planning Indirect Access services (IDA) 89 Planning Unlicensed Mobile Access (UMA) 89 Planning SIP services 93 Planning Session Border Controller (SBC) 98 Planning Light Directory Access Protocol (LDAP) CS core network dimensioning 101 Dimensioning of MSC Server System 104

82

98



3 (158)


9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 10 10.1 11

Dimensioning MSC Server 106 Dimensioning of MGW 111 Dimensioning IP network 115 Estimating the needed bandwidth 117 IP over ATM 135 ATM over TDM (IMA) 137 Connection rate based CAC by BICC CIC configuration Detailed planning of CS core network 142 Network management system planning 147 Planning O&M network for CS core network 152

138

Using KPIs for network planning and performance monitoring 157

4 (158)



Changes in CS Core Network Planning

1Change

Changes in CS Core Network PlanningThe following changes have been made since the last documentation release. The changes are detailed in the table below.

Table 1.

Changes in CS Core Network Planning SeeFigure CS core network architecture in CS core planning overview. Selecting signalling protocol for call control in Planning of services and features.

In the Nc interface ISUP is required if the user plane between MGWs is TDM. BICC is required if the user plane is ATM, and SIP or BICC if the user plane is IP. MGW includes the WCDMA transcoding functionality which can be used also for GSM, and the Ater interface can be terminated in MGW. The resilience information has been replaced by an overview of resilience in network planning. A separate description on Nokia CS Core resilience solution has been included in CS Core System Documentation. When planning user plane analysis configuration for UMA solution for MSC Server (A+ interface), note that the user plane destination reference (UPDR) is defined into the UMA Network Controller (UNC) data. For the UMA solution for GSM (A interface) the UPDR is not relevant. Information about the in-built logic of Nokia VoIP Server's call control to define a call mediation node (CMN) depending on the call case has been added. When planning the Virtual MGW selection for SIP calls, it is important to ensure equal load sharing between VMGWs.

Resilience in network planning CS core network resilience PDF: CS Core Network Resilience

Example Planning user plane analysis configuration in the MSS1 in Planning of control and user plane analyses.

CMN determination phase in Example Planning subanalyses/phases in Planning of control and user plane analyses. VMGW selection for SIP calls in Minimising hops on the user plane.



5 (158)


Table 1. Change

Changes in CS Core Network Planning (cont.) SeePlanning Unlicensed Mobile Access (UMA) in Planning of convergence solutions.

Nokia has two Unlicensed Mobile Access (UMA) solutions: UMA solution for GSM and UMA solution for MSC Server. Information about the resilience of AAA server, handovers, UMA registration and the location of emergency calls has been added, with references to relevant UMA documentation that is provided separately. Information about the use of Session Border Controller versus Domain Name Server has been included. The Session Border Controller (SBC) should protect the first front network element. The registration is based on a domain name. Nokia VoIP Server shares the same VLR as is used for 2G/3G access. If the VLR fails, the SBC is capable of selecting another working VLR. In case of MSC Server/Nokia VoIP Server with ISC interface, it is essential to control the SIP proxy mode. An overview of planning Session Border Controller (SBC) has been included. Information about the LDAP configuration for NVS has been added. A connection rate based Call Access Control (CAC) can be established by BICC Call Identification Code (CIC) configuration. The latest information about the available MGW and MSS measurements can be found in the respective product documentation libraries. Information about the main sources of network element performance counter information has been added.

Planning SIP services in Planning of convergence solutions.

Planning SIP Services/MSC Server/Nokia VoIP Server with ISC interface in Planning of convergence solutions Planning Session Border Controller (SBC) in Planning of convergence solutions Planning Light Directory Access Protocol (LDAP) in Planning of convergence solutions Connection rate based CAC by BICC CIC configuration in CS core network dimensioning

Performance monitoring documentation of network elements in Using KPIs for network planning and performance monitoring

6 (158)



CS core network planning overview

2

CS core network planning overviewThe purpose of this document is to provide a general guideline for CS core network planning issues, with the focus on MSC Server System -specific topics. MSC Server System brings many new aspects into core network planning when compared to MSC. In the circuit switched core network, the biggest changes result from the introduction of a new network element, the Multimedia Gateway (MGW), and the new radio network interface, Iu-CS interface, introduced by the 3G network. Furthermore, the separation of control and user planes is introduced: the MSC Server (MSS) handles the control plane while the user plane is switched in the MGW. IP Multimedia Subsystem (IMS) implements the functionality specified in 3GPP, and additionally, offers service execution, creation and deployment environment 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 covered here from the core network point of view. Good network quality is a combination of infrastructure, planning and deployment quality. It is also important to achieve the targeted Quality of Service (QoS) levels from the start, and this can be done by paying special attention to the network planning phase. For more information on QoS, see Quality of Service in CS Core Network.

CS Core Network Planning introduces some issues that must be taken into account when planning and dimensioning CS core networks. However, very detailed instructions cannot be given because network planning has to be carried out case by case.Circuit switched core network planning

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



7 (158)


The purpose of the CS core network planning is to plan the CS core and database network elements required for the functionality of the network. The aim is to take into account, for example, the available switching equipment 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 core network architecture. The figure below illustrates the architecture of Nokia CS core network:

SCP(CAP, INAP, MAP)

(MAP)

HLR(MAP)

D (MAP) (ISUP)

PSTN/ISDN

(CAP, INAP) Nc (SIP BICC CS2 ISUP)

BSC

A/Ater

Gs

MSS

MSS/GCSMj/Mg/ISC Mc Mn (H.248) (SIP) Mb

IMRCx

SGSN

Mc (H.248)

CPS

SGSNIu

MGWNb

MGW

RNC(BSSAP+) VoIP IP/ ATM/TDM backbone

Nb Gi(Gm)

IP/ATM backbone

UNC BSC

GGSN

Gi

DSLAM

External IP networks

In the Nc interface:

8 (158)



CS core network planning overview

.

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.Nokia CS core network architecture

.

.

Figure 1.

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 the traffic is switched through the MSC, and the MGW is used only for connecting the Iu-CS to the MSC. In addition, CS core Network Planning gives information on what must be taken into account in respect of capacity and dimensioning when planning the intelligent network services, and network management system (Nokia NetActTM). It is assumed that you are familiar with the basic concepts and network elements related to networks.

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

For information on the connectivity of MSC Server System network elements (MSS, MGW and CDS) to the backbone network, as well as planning core sites and remote media gateway sites, potentially co-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 core network 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 network planning process. Some of the targets have a significant effect on the overall network design, and must be known in the early stages of network planning (for example, the number of core sites and how they back up each other, and the use of independent alternative routes in the transport network). For details of the Nokia CS core resilience solution, see CS core network resilience in CS Core Network Resilience. For information on planning the migration of MSC Server System to an 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 of new threats. The security solutions used in the core network are explained in more detail in Security in CS core network in CS Core System Overview.

.

.

.

.



9 (158)


.

For Quality of Service (QoS), see QoS in CS core network in Quality of Service in CS Core Network. For more information on radio network and cellular transmission planning, 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 core network are shown in figure Nokia CS core network architecture above. See also Overview of the CS core network interfaces in CS Core System Overview. For more information on the CS core elements and functionalities, see CS core network architecture also in CS Core System Overview. For descriptions of the core network elements and their functionalities, see network element product documentation. The major difference between 3GPP MSC Server CS core network and MSC architecture is the introduction of packet-based Nb and Nc interfaces. The effects of these are described in Dimensioning of MGW.

10 (158)



Nokia network planning services

3

Nokia network planning servicesNokia offers a wide range of support services and solutions for helping you plan the network. The services include the entire process of planning, building and operating a network and developing, managing and optimising network services. The 3G network planning modules and services are shown in the figure below. Each of these modules is further divided into submodules (network assessment, dimensioning and detailed planning) according to the planning process:

IP backbone planningMSC Server system planning Assessment Dimensioning Transition planning Migration Replacement CS Core evolution consulting NSS to Rel-4 R99 to Rel-4 CS Core performance management Detailed planning MSC Server system optimization

Vision Strategy

Solution Design

Implementation

Operation

Figure 2.

Nokia network planning modules and services

NoteNote that Multimedia Core Network Planning, IP/ATM Planning, and IN Planning are covered in Circuit Switched and Packet Switched Core Network Planning services.



11 (158)


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 the process there are uniform measures for evaluating the success of the project operators get a better understanding of the content of the network planning project and more visibility to the incurred costs.

.

.

.

.

Nokia offers two paths for the 3G network planning service. The first path is for operators that prefer a complete service for the network planning activities. This means that Nokia has the full responsibility of the network planning tasks. The second path is for operators that have their own planning personnel but need some expertise support. This freedom of choice offers the operator clear benefits in getting the network ready on time and their own personnel educated during the planning and implementing phases. While Nokia MSC Server System can merge the core network to a single IP network, the migration needs to be well-planned to avoid any unnecessary service breaks. Nokia planning services are quantified to fit the operator's needs and to ensure a smooth evolution path.

12 (158)



Nokia network planning services

Network Evolution ConsultancyNetwork Planning Services Network Performance Services

Network Planning Project Management Pre-planning Network Planning for Replacement Rollout Network Planning Consultancy

Planning

Pre-launch Optimisation

Network Optimisation Quality Benchmarking and Performance Analysis

Mobile Services Optimisation

Process Development

Network Evolution Consulting

Figure 3.

Nokia network planning and performance services for MSC Server System

Network Evolution Service combines Nokias knowledge of mobile network technology evolution with a current state analysis of the 2G network. The outcome of the service specifies the foundation for the operator network evolution, the cornerstones and main decisions of how the network will evolve. This includes support on, for example, backbone type, pace of modernisation, high level architecture etc. Planning and operating a network can be seen as a continuum and mobile networks are developed in cyclical steps. Optimising a



13 (158)


network consists of a follow-up of how the planned services are actually provided so as to ensure an efficient use of the network resources. It also provides a follow up of the business plan, subscriber and services penetration forecast in order to plan the eventual upgrading of the network when necessary. The CS core network has to support all required end-user services and to provide enough flexibility to support future needs in terms of capacity, topology, hierarchy and services. The CS core network rollout planning is usually carried out as a modular project. Each of the following modules can also be carried out separately, if the preconditions are met:

Network assessment

Feasibility study

Dimensioning principles

Network dimensioning

Business plan

Master plan

Detailed network planning

Source data

Implementation

Operation

Figure 4.

The structure of CS core network rollout planning project

14 (158)



Resilience in network planning

4

Resilience in network planningNetwork resilience targets must be taken into account in the network planning process. Some of the targets have a significant effect on the overall network design, and they must be known in the early stages of network planning (for example, the number of core sites and how they back up each other, and the use of independent alternative routes in the transport network).Network pre-planning and dimensioning

Solution principles and a rough network structure are determined in the early stages of network planning. The main inputs in this phase are related to 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 of products are used; planned future network development; possible existing transmission infrastructure (SDH/PDH/WDM, own or leased, 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 and technically optimised network plan. The plan indicates the selected network architecture and the amount of equipment needed during the roll-out of the network.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 on more accurate traffic estimates, and more detailed availability targets (for services and/or network elements).



15 (158)


Network planning tools

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

NetAct Radio Planner offers effective support for all phases of the radio network planning process. NetAct WCDMA Planner is designed to provide comprehensive radio planning functionality for the new 3rd Generation mobile networks. NetAct Transmission Planner helps to plan transport networks, such as IP, ATM, and SDH. NetAct Link Planner is an efficient and flexible solution for microwave link and transmission network planning. NetAct Quality Planner is an intelligent software package for field measurement analysis.

.

.

.

.

Nokia services

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

16 (158)



Inter and intrasite connectivity

55.1

Inter and intrasite connectivityBackbone alternativesNokia MSC Server System provides many alternatives for creating backbone connectivity between sites. The backbone connectivity can be based on:.

IP ATM TDM interfaces a combination of the above.

.

.

.

When selecting a suitable backbone solution, there are many things to consider:.

Strategy and long range plan. Interface requirements (for example Iu is still over AAL2). Requirements set by other solutions using the same backbone elements. Resiliency requirements. QoS requirements. See Quality of Service in the packet backbone in IP Connectivity in Core Networks and QoS in CS core network in Quality of Service in CS Core Network. See also QoS requirements for IP backbone, in Site Connectivity Guidelines for CS Core Network Multi-vendor capabilities. Network element (NE) capacity impact.

.

.

.

.

.

.

CS core can use either IP, ATM or TDM backbone. The connection to IP backbone is arranged via multilayer site switches / IP routers. MSS control plane (for example H.248) is connected to the site routers regardless of the backbone type. The ATM functionality is built-in into MGW, ATM switches can be used in



17 (158)


large networks to simplify the configuration. Existing TDM connectivity can be used for circuit switched (CS) voice and data even in MSC Server System. PS core always uses IP (or IP over ATM) transport. The following figure illustrates the alternatives:

Nokia GGSN IP router PS and CS core use IP transport Nokia SGSN SDH/SONET as common transport for all options IP router

Nokia GGSN

Nokia SGSN MGW ATM switch

CS core with ATM transport option

MGW

ATM switch

CS core with TDM transport optionDXC/ADM DXC/ADM

Figure 5.

Backbone alternatives

Requirements for the backbone

ATM backbone shall support two distinct delay variation values, one for control plane and another for user plane. CS core uses Constant Bit Rate (CBR) for user plane. That is configured in MGW. PS core uses Undefined Bit Rate (UBR) for user plane. IP backbone must support Virtual Private Networks (VPN). For backbone planning see Backbone connectivity solution in IP connectivity in Core Networks. See also QoS requirements for IP backbone, in Site Connectivity Guidelines for CS Core NetworkPure IP backbone

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

18 (158)




Iu-interface will also move to IP, which removes some of the benefit for AAL2. IP backbone provides simplification in flexibility, configuration and management 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 with DiffServ. MPLS is a router functionality. Site router is capable of mapping DiffServ classes code points into MPLS exp bits.

Core site 1SGSN GGSN ... MGW Signalling carried over IP . DNS Core site 2

No connection setup signaling in the backbone. MPLS may be used.

MSC ServerPhysical transmission layer based on SDH/SONET. Core site n

IP backboneIP router Core site 3

User data over RTP/UDP/IP.

Figure 6.

IP backbone

ATM backbone

As stated for the IP backbone, an ATM backbone may already exist and ATM may also be the operators long-haul strategy. ATM can be used with STM-1 or with IMA groups (n* E1/T1). ATM in Nokia MGW provides somewhat higher capacities due to internal packet size handling and IP stack termination issues. AAL2 nodal function enables efficient use of MSS and MGW resources by enabling a more optimised MGW selection. Iur over AAL2 brings synergies through use of nodal function (no full virtual channel connection (VCC) mesh end-to-end required, only point to point).



19 (158)


Core site 1SGSN GGSN ... MGW User data AAL2/ATM. DNS Core site 2

PNNI signalling for dynamic SPVC setup. MPLS over ATM VCs can be used.

MSC Server ATM PVC mesh and/or SPVCsCore site 3 Physical transmission layer based on SDH/SONET.

ATM switch

Signalling carried on IP over ATM, or over IP to ATM switch.

Core site n

Figure 7.

ATM backbone

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

Use ATM nodal function of MGW. MGW performs the AAL2 switching. Use ATM switch functionality in MGW. MGW connects ATM cells based on virtual channels and paths.

.

With SDH/SONET the following applies: Since MGW includes ATM switch (and AAL2 switch) capability, it is possible to build ATM backbone without external ATM switches. Within one MSS all MGWs shall be interconnected. In this option, between MSS areas, dedicated MGWs can be used, or MGWs can be fully meshed. The target is to minimise MGWs per call while keeping (ATM network) signalling manageable. Nokia MGW supports ATM over SDH, and TDM over SDH. The following figure illustrates the ATM with SDH/SONET option:

20 (158)




MSS1

MSS2

GSM BSS/ UMTS RANPSTN MGW

MGW

MGW

SDH/ SONETMGW MGW MGW

Figure 8.

ATM with SDH/SONET

ATM locally, IP long distance

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



21 (158)


MSC Server

MSC Server

A MGW MGW MGW MGW

A BSC

GSM

BSC

GSM

Iu

Iu MGW

WCDMAPSTN/ PLMN

RNC

IP/MPLS

MGW

RNC

WCDMAPSTN/ PLMN

Site 1

Site 2

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 area transport 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 network using TDM backbone is a feasible option. Some MSC Server System (MSS) benefits cannot be capitalised on (for example transmission savings, Transcoder-free operation (TrFO)), but using the existing transmission might be beneficial in some migration scenarios. An example could be replacing old MSCs or expanding MSC port capacity. Note that MEGACO/H.248 and O&M traffic require IP connectivity between MGW and MSS. Also SIGTRAN and IWF control may require IP transport. IP over ATM is the solution for that (inter-site). Within a site, site connectivity solution includes IP routers. Nokia MGW supports ATM over SDH, as well as TDM over SDH. The following figure illustrates this solution:

22 (158)




GSM network

MSS network

ADM SDH/ Sonet ADM

ADM SDH/ Sonet

MSC

MSC

MSC

ADM

MSC

MSS

Figure 10.

TDM backbone

5.2

Network topologyThe first step to estimate is the number of subscribers, and the ratio they use the circuit switched (CS) services. Also the geographical distribution of subscribers is taken into account. Already in the initial planning phase the final target network topology should be taken into account.Logical network topology

The logical topology shows how the sites and network elements are connected. That is, the connections to other network elements from each elements point of view. For each site and network element the capacity needs to be considered. In other words, check that the network element can handle the required number of subscribers and their service attempts. The logical topology should be split into control plane and user plane topology. The following figure shows an example of logical control plane connections:



23 (158)


Site 3HLR01 MAP/ SS7 HLR02 SCP01 CAP/ SS7 STP01 MAP+CAP/ SIGTRAN MSS01 MAP/ SS7 SMSC01 MGW04 BSSAP, RANAP BICC, ISUP, IWF control/IP MAP+CAP/SIGTRAN MSS02 BSSAP, RANAP BICC, ISUP, IWF control/IP MGW03 AAL2+AAL5/ATM RANAP/ ATM RNC03

BSSAP/7 BSC04

MAP+CAP/ SIGTRAN

BSSAP, RANAP BICC, ISUP, IWF control/IP AAL2+ AAL5/ATM

MGW01

AAL2+AAL5/ATM

MGW02

AAL2+AAL5/ATM

BSC01

BSC02

RNC01

RNC02

BSC03

Site 1

Site 2

Figure 11.

Logical Control Plane connection example

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

24 (158)




Site 1 HLR01 SCP01 SMSC01 MGW04Fax/data /TDM Voice/ATM

Site 3 RNC03

Voice/TDM

HLR02

STP01

BSC04 Site 2

MSS01Voice/ATM Fax/data/TDM

MSS02Fax/data/TDM

Voice/ATM

MGW01

Voice/ATM

MGW02

MGW03Voice/ATM Voice/ATM Voice/TDM

BSC01

BSC02

RNC01

RNC02

BSC03

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 be private IP addresses. If the MSC Server (MSS) network is connected to an external IP network using SIP or BICC, that particular MSS and MGW taking care of inter-connection need to have public IP addresses. All other MSSs and MGWs may have internal IP addresses in this case. One sub-option is to have IPv6 addresses for the inter-connection, and use IPv4 addresses in intra-network signalling. This is a good option since IPv6 addresses suffice and IPv4 addressing saves resources. In this option the units are allocated to both IPv4 and IPv6 addresses. In the user plane analysis you define the BNC characteristics (IPv4/IPv6) that are informed to an adjacent element in the SIP signalling. When the interface unit sends packets, it selects the address from the same subnet where its own address for this call is, that is, IPv6 or IPv4 according to the BNC characteristics of the UPD.



25 (158)


NoteNokia CS Core documentation includes instructions for configuring IPv6, but Nokia does not currently support or recommend the use of IPv6 for commercial CS Core traffic in live networks. Interworking with site IP infrastructure will be finalised and verified in a later MSS System release.

For more information on LAN topology, see the description for LAN building 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 Core Network. 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 port connectivity for control plane, charging, O&M and provisioning, and user plane (user plane only if IP backbone). The IP addresses of the computer units are shown in the figure, and how each SWU is connected to site routers. These example figures illustrate how the final plan should look like in a site.

26 (158)




IP backboneSTU0-ETH1

HLR01

MGW01CAMA-ESA24SW0 ETH1 ETH2

STU0-ETH2 STU1-ETH1 STU1-ETH2 ETH1 HLRU2-SWU0 ETH2 ETH1 HLRU2-SWU1 ETH2 ETH1 HLRU6-SWU0 ETH2

ISU1

CCSU1 .. CCSU32

..ISU10 CAMA-ESA24SW0 ETH1 ETH2

CDS01

ETH1 HLRU6-SWU1 ETH2

GSU1

IPCC-LANU0-ETH1 IPCC-LANU0-ETH2 IPCC-LANU1-ETH1 IPCC-LANU1-ETH2

MSS01IPCG0-LANU2-SW1-ETH1 IPCG0-LANU2-SW1-ETH2 IPCG0-LANU3-SW1-ETH1 IPCG0-LANU3-SW1-ETH2 IPCG1-LANU4-SW1-ETH1 IPCG1-LANU4-SW1-ETH2 IPCG1-LANU5-SW1-ETH1 IPCG1-LANU5-SW1-ETH2 IPCG2-LANU6-SW1-ETH1 IPCG2-LANU6-SW1-ETH2

..GSU2

SIGU1 .. SIGU42

CP1 VLAN - 10.100.2.0/24 CP2 VLAN - 10.100.3.0/24

IPCG2-LANU7-SW1-ETH1 IPCG2-LANU7-SW1-ETH2

CP VLAN consists of 3 subnets. Addressing is not shown in the figure.Figure 13. Site Timbuktu control plane- physical



27 (158)


MSS01

CHU0-0 CHU0-1

ETH1 IPCF-LANU0-SW1 ETH2 Charging Mediation Device

CHU1-0 CHU1-1

IP backboneCHU2-0 ETH1 IPCF-LANU1-SW1 ETH2 CHU2-1 CHU3-0 Cha VLAN - 10.100.12.0/24 CHU3-1

Separate SWU is an optional feature.Figure 14. Site Timbuktu charging physical

28 (158)




MGW01CAMA-ESA24- ETH1 SW0 ETH2 CAMA-ESA24- ETH1 SW1 ETH2 CMM0-ETH1 CMM0-ETH2 CMM1-ETH1 CMM1-ETH2 ETH1 HLRU0-SWU0 ETH2 ETH1 HLRU0-SWU1 ETH2 IPCC-LANU0ETH2 ETH1 HLRU8-SWU0 ETH2 ETH1 HLRU8-SWU1 ETH2

HLR01

CDS01

. .IPCC-LANU1ETH2

MSS01 NEMUIPCF-LANU0-SW2-ETH1 IPCF-LANU0-SW2-ETH2

OMU0 OMU1

P23 . . P23

IPCF-LANU1-SW2-ETH1 IPCF-LANU1-SW2-ETH2

BDCU1 ..

Note: In HLR HLRU0-1, 4-0, 8-0 and 8-1 would have similar connectivity than HLRU0-0

IP backbone Regional OMCCP1 VLAN - 10.100.14.0/24

Provisioning

Figure 15.

Site Timbuktu O&M physical



29 (158)


IP backbone

MGW - L3SW link: 10.100.9.0/29

IPGEP0-0

IP interface (IPGEP) IP Address: 10.100.9.1

IPGEP0-1

MGW01

CDS01 2 E1IWS1

4 STM1 PSTNSDH mux BSC01

Figure 16.

Site Timbuktu user plane physical

30 (158)



Planning of control and user plane analyses

6

Planning of control and user plane analysesControl plane analysis in MSS

Control plane routing in MSC Server (MSS) is fairly similar to the traditional MSC. For the basics, see Basic Routing Functions. To understand the link between 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. Similar alternative routing applies and dual seizure/glare may occur. SIP and BICC with IP backbone are different in this regard. With SIP signalling the only limitations are user plane bandwidth and the number of internal processes in MSS. Thus there is no alternative routing or dual seizure. In other words, each destination has only one alternative (subdestination).User plane analysis in MSS

User plane analysis is a new analysis introduced in MSC Server System. It consists of several subanalyses which can be chained and linked to different kinds of results. Additional information can be found from User Plane Routing in Mrelease product documentation library. Even in MSS system, user plane analysis is not needed for TDM resources. MSC does not use UP analysis. The structure of one analysis is depicted in the following figure:



31 (158)


Parameter

subanalysis

Default result

Result_subanalysis Parameter subanalysis Default result

Result_subanalysis

Parameter

subanalysis

Default result

Result_subanalysis

Parameter

subanalysis

Default result Final result

Figure 17.

User plane analysis structure

User plane analysis has input attributes to be analysed, similar to extended preanalysis and attribute analysis. Each attribute can be analysed in one or more subanalyses, and the subanalyses can be chained. Attribute is a call-related variable. The value of the attribute is the value of the variable. In one subanalysis, there can only be one attribute, but the handling of the different values of this attribute may differ. For example, the analysis may continue from the next subanalysis with one value of attribute, but with some other value the analysis goes to the final result. UNKANA/UNKRES is met when the attribute does not exist in this particular call, or a phase of the call. You do not need UNKANA/UNKRES if the handling is the same as in the default case (DEFRES/DEFANA). The result goes to default branch if none of the explicitly defined values match. The figure below shows the flow of output/input attributes. For example, the preceding UPD determination sets PUPD, which is used as an input attribute in three other phases.

32 (158)




1. Preceding UPD determination

2. Succeeding BNC characteristics determination

3. CMN determination

5. Succeeding action indicator determination 4. Succeeding UPD determination 6. Inter-connecting BNC characteristics determination

Figure 18.

User plane analysis phases

The following describes the relationship between the six phases of user plane 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 the outgoing side. 6. Interconnecting bearer network connection identifier (BNC-ID) characteristics: Indicating what type of bearer is used between two MGWs controlled by one MSS. User plane analysis phase analysis results:



33 (158)


.

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, only the necessary attributes are analysed. Parallel to this, despite the multiple subanalyses only a few of them need to be used in the call scenario. You are recommended to create a number of final results and a subanalysis and in this way establish a tool set which can be used in different configuration setups. Example 1. Planning user plane analysis configuration in MSS1 The figure below shows an example user plane analysis configuration in MSS1. In this example there are two backbones: ATM and IP backbone.

route1 -> (s)UPDR1 CGR1 -> (P)UPDR1 MSS1 route4 -> (s)UPDR4 CGR4 -> (P)UPDR4 AAL2, UPDR1 CGR1, Route1 ATM BB MSS2

No UPDR CGR2, Route2 BSC1

MGW1 VMGW11 VMGW12

MGW3 VMGW31 VMGW32

No UPDR CGR3, Route2 RNC1 AAL2, UPDR3 no CGR4, no Route

MGW2 VMGW21 VMGW22 IP BB IP, UPDR4 CGR4, Route4

Figure 19.

Example network for user plane analysis

34 (158)




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

VMGWxx: For each (V)MGW you may assign a BCU-ID parameter with JG MML group. It is recommended that all Virtual MGWs in a physical 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 circuit group data in incoming calls. CGR2: No UPDR since this is TDM. A interface channels are reserved independent of UP analyses. Also the MT side circuit is reserved independent of incoming side A interface trunk. CGR3: No UPDR. RNC CGR4: Does not exist. UPDR4 is read from RNC data. Route1: CGR1, UPDR1. For outgoing calls, the Succeeding UPDR is read from the route data. If MGW1 and MGW2 both have ISUP connection to PSTN it is possible to optimise the MGW usage. If you set different BCUID values on the routes, MSS compares (v)MGW BCU-ID. For these destination numbers there should be two alternative routes (RouteX and RouteY). MSS prefers the matching values. 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 is defined into UMA Network Controller (UNC) data. For UMA solution for GSM (A interface) the UPDR is not relevant.

.

.

.

.

.

.

.

.

.

.

.

.

It is recommended to create the minimum number of UPDs, that is, when there is a real difference between UPDs. And also to add all VMGWs to all UPDs that are supported. Example 2. Planning subanalyses/phases Preceeding UPD determination



35 (158)


This phase is executed in the beginning of the call, right after the setup message is received by MSS. The purpose of this phase is to enable ATM and IP backbones concurrently and/or allow different speech codecs and/or allow a different IP version addressing on user plane. In this example the following settings are needed:.

If UPDR=1 => UPD:=1. Call is coming from MSS2 with ATM backbone. 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 is required in user plane (UP) analysis. Design the analyses so that DEFANA/ DEFRES goes to the appropriate handling (CONTINUE without any parameter setting in this case). When calls come from IMS using SIP, the calling users IP address type (IPv4 or IPv6) should be checked. Each IP version should have a separate PUPD so that the address is allocated using the same IP version. MSS uses the INVITEs SPD headers IP address (type) for the Preceeding BNC characteristics (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. 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 mediation node, CMN. CMN is meant for a big network that is not fully meshed and an intermediate MSS conveys the BICC/SIP signalling to destination MSS. Gateway or redirecting MSS shall never be a CMN. If MSS is a CMN (that is, sees control plane only), On-line Call Monitoring (OLCM) may have an impact here. In case of a monitored call, CMN may have to be INACTIVE. For more information, see User Plane Routing in M-release product documentation library.

36 (158)




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

Call forwarding: when the forwarded to number leads to PSTN, for example. Announcements: CMN mode changes to INACTIVE for the announcement period and it changes back to ACTIVE after the announcement. The CMN mode change is not supported during midcall.

.

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. For example, 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 best choice if the originating MGW has E.164 analyses for the target MGW address. A fully meshed network benefits from using this option. 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 to that address. With Transcoder-free Operation (TrFO) and codec negotiation the establishment method is 'delayed forward tunneling' with this FORW setting. BACK (backward) is a good choice when the target MGW has analyses for the source MGW address. IAM contains the source MGW address, and target MGW sends ERQ to source MGW. DFORW may also be used with AAL2. Here terminationID is reserved when MSS receives acknowledgement from the next MSS.

.



37 (158)


If SIP signalling is used, FORW is the only option. Interconnecting BNC characteristics determination This phase is executed if the (same) MSS controls the both MGWs of the call. The purpose of the phase is to define whether IP or ATM is used between the two MGWs. If the virtual MGWs belong to the same physical MGW, MSS uses AAL2 hardcoded. The value depends on the backbone (BB) between MGWs. If the MGWs are on different sites you must use the BB available. 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 same MSS, and some have ATM and some IP connectivity in between them. In such a case you need to analyse all combinations of the preceeding UPD (to check the source MGW) and succeeding UPD (to check the target MGW). The combination indicates which inter-connection hop is needed. To ease the configuration, use the default result (for example ATM), and analyse/list the exception cases requiring the other value (for example IP) only. Special cases Emergency call may use special user plane routing. Inter-MSS handover does not require special attention. Even if the (S)UDP has other than G.711 default codec, the source MSS sets G.711 for speech calls. With PRFILE parameter COMP_ROUTES_USED_IN_HO 029:0013 you can set Transmission Medium Requirement (TMR) to UDI (64kbit/s). In that case there will be no speech codec.NbUp framing and 5 ms/20 ms packetisation on UPD

When you define a User Plane Destination (UPD) with User Plane Topology Data Handling (JF) MML, you also define packet interval and user plane framing. The following table summarises the configuration.

Note5 ms is the standard value in Nb (CS-MGW CS-MGW) interface with NbUp framing, whereas IMS uses 20 ms packet interval without framing. TRUNK and DCODEC are parameters on an UPD. Nokia supports also 20 ms packet interval in the NbUp interface.

38 (158)




Table 2. Input values Signalling Call type

NbUp framing and 5 ms/20 ms packetisation on UPD Result

TRUNK

DCODEC

Packet interval (ms)

Framing (NbUp)No Yes Yes Yes No Yes Yes Yes No No Yes

Comments

BICC BICC BICC BICC SIP-T SIP-T SIP-T SIP-T Other SIP BICC-SIP-T BICC/SIP-T

Speech Speech Speech Speech Speech Speech Speech Speech Any Data Data

Y N Y N Y N Y N Any Y N

G.711 G.711 ` G.711 ` G.711 G.711 G.711 ` G.711 ` G.711 Any Any Any

20 5 20 20 20 5 20 20 20 20 20

NoteSet TRUNK to N when TrFO is used.

See also Selecting signalling protocol for call control.



39 (158)


6.1

Minimising hops on user planeOptimising MGW selection based on BCU-ID

When BICC call control signalling is used, MGW selection can also be optimised 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 user plane traffic by the peer MSS. In Nokia implementation it can be configured to 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 attribute. Depending on the call case and the BICC bearer establishment method used, it can be used to optimise the preceding or succeeding user plane destination (UPD) selection. This way it 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 the succeeding MSS. No MGW is selected for the call before sending an IAM message towards the succeeding MSS. The succeeding MSS selects an MGW and sends the BCU-ID and the necessary bearer information for the bearer establishment back in the APM message. The BCU-ID identifies the selected MGW and is used in user plane analysis for determining the succeeding UPD.

40 (158)




5. MSS A selects MGW2 from the UPD.

2. MSS B selects MGW1.

1. IAM MSS A 3. APM (bcu-id of MGW1) MSS B

RNC

MGW 2 4. BCU-ID of MSSB is used in user plane analysis to determine succeeding UPD in MSSA. MGW 3

MGW 1

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 plane analysis, but does not select an MGW for the call. An IAM message is sent to MSS B without any BCU-ID. In case codec negotiation is used, the supported codec list in the IAM is composed based on the minimum set of codecs supported by the MGWs belonging to the succeeding UPD. MSS B selects MGW1 for the call. It sends back the BCU-ID of the selected MGW and the necessary bearer information for bearer establishment in a backward APM message.

2.



41 (158)


3.

MSS A re-determines the succeeding UPD by re-executing the user plane analysis. Re-execution of the user plane analysis can result either in the same or in a different succeeding UPD which was determined in the first step. MSS A selects an MGW from the succeeding UPD. Note that MGW selection inside the UPD can be further optimised using the BIWF address. See Optimising MGW selection based on BIWF address below. Note also that if the succeeding UPD is changed, codec negotiation is used and no MGW supporting the selected codec is available in the new UPD, the call is released.

4.

Similar optimisation is possible when other bearer establishment methods are used. In case of backward establishment or forward establishment with nondelayed MGW selection, the preceding UPD selection in the succeeding MSS can be optimised by using the BCU-ID in the user plane analysis. For related topics, see User Plane Routing in M-release product documentation library.Port expander for integrated MSS

In some networks GSM BSCs may have TDMs connected to both integrated MSS and MGW. In such a case you should minimise TDM usage between MGW and MSS. Also in this case the optimisation is based on BCU-ID..

MO call: MSS has a PRFILE parameter defining the BCU-ID for the PCMs connected to that particular MSS. For the MGW circuits MSS contains the BCU-ID in the MGW topology database. In the control plane analyses you define a BCU-ID on the outgoing route. The trunks going out to PSTN (in the figure below) have distinct routes depending on whether the circuit is in MSS or MGW. The BCU-ID on the route is considered as a property. A matching BCU-ID is preferred. If no match is found on any alternative (subdestination), any route is accepted. This way the MO call using BSCMSS trunks prefers MSS-PSTN trunks, and MO call using BSC-MGW trunks prefers MGW-PSTN trunks. Alternatively, or in addition, in the outgoing circuit reservation MSS can favour either MSS (TYPE=CCS) or MGW trunks (TYPE=ECCS), depending on whether the incoming trunk is connected to MSS or MGW, correspondingly. Note that in this solution all MGWs have a common handling, that is, they all have the same value for ECCS. When a BSC is connected to both MSS and MGW, a new hunting method can be applied to MO calls. MSS can be configured to hunt circuits from a circuit group which has the most free circuits. This ensures that MT calls will succeed even if the CGRs have a different number of time slots.

42 (158)




MSS default: BCU-ID1 MSS01 Route1: BCU-ID1 PSTN

BSC01

MGW01

Route2: BCU-ID2

BCU-ID2

Figure 21..

Port expander

MT call: Works like the MO call. In the A-interface circuit hunting MSS prefers matching BCU-IDs automatically, that is, the preceding BCU-ID is matched. Note that the hunting method introduced for MO calls above does not apply to MT calls.

Optimising MGW selection for MT call using MSRN/LAC

Mobile Station Roaming Number (MSRN) allocation on Location Area code (LAC) basis is beneficial only if an MSC (not MSC Server) is connected to PSTN or if TDM backbone is used within PLMN. This is a special case in which transit MSC (TMSC) (not MSS) is connected to PSTN. TMSC makes the HLR enquiry for a roaming number (MSRN). The visited MSS is configured to allocate MSRN per Location Area Code (LAC). Thus TMSC receives MSRN based on location of the called party. The different MSRN ranges lead to different route and thus directly to the correct MGW.



43 (158)


PSTNT/GMSC01

MSRN1 -> Route1:

VMSS02LAC1: MSRNrange1

BSC01MSRN2 -> Route2:

MGW01LAC2: MSRNrange2

BSC02 MGW02

Figure 22.

MT call optimisation based on MSRM range

Optimising MGW selection based on BIWF address

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

MSSA RANAP RNC

BIWF address of MGWV1 H.248 H.248

MSS B RANAP RNC

Virtual MGWV1

Virtual MGWV2 Physical MGWP12

Figure 23.

MGW selection based on BIWF address

44 (158)




When BICC call control signalling is used between MSSs or in intra-MSS call cases, the BIWF addresses of the virtual MGWs can be used in the MGW selection process to select virtual MGWs from the same physical MGW for the call. This kind of optimisation benefits from the resource usage's point of view. In Nokia MGW implementation no external bearer connection is required between the virtual MGWs belonging to the same physical MGW. In call cases between MSSs with BICC call control signalling the steps in the selection process are the following: 1. BIWF address is received from the preceding node in the IAM or from the succeeding node in the APM, depending on the BICC bearer establishment method used. In case of backward establishment or forward establishment with nondelayed MGW selection, MSS A first selects an MGW for the call. In this case MSS B receives the BIWF address of the selected MGW in the IAM. 2. In case of forward establishment with delayed MGW selection, MSS B first selects an MGW for the call. In this case MSS A receives the BIWF address of the selected MGW in the APM. The received BIWF address is analysed by MSS during the MGW selection procedure. MSS recognises that a virtual MGW with the same BIWF address is included in the previously determined UPD towards the other node. Since the BIWF addresses of the MGWs are the same, this means that the used virtual MGWs are physically located in the same network element. MSS selects the Virtual MGW from the same physical MGW for the call.

3.

4.

If there are more virtual MGWs in the UPD which belong to the same physical MGW, MSS selects from those MGWs that are based on the defined load sharing value. The BCU-ID-based MGW selection optimisation can be especially useful when CMN nodes are involved in the call between the MSSs that control user plane resources. In this case determining an optimal preceding or succeeding UPD towards the peer MSS can be problematic because the CMN node can hide the identity of the peer MSS that controls user plane resources. The BCU-ID can be used to overcome the problem. It can identify the MGW that was selected for the call by the peer MSS. This information can be used in user plane analysis to select an optimal UPD that provides connectivity towards the MGW selected by the peer MSS. For more information, see User Plane Routing in M-release product documentation library.



45 (158)


VMGW selection for SIP calls

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

TDM borrowing saves TCUs trancoding capacity. TDM resources are always tied to a certain Virtual MGW (VMGW). TDM borrowing is a useful functionality when MSS has reserved the H.248 context (for example RANAP early assignment, handover, etc.). and the outgoing TDM circuit is hunted thereafter. If the TDM circuit belongs to a different VMGW but the same physical MGW, TDM borrowing allows to control the TDM using the existing H.248 context. In MSS the PRFILE parameter IC_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 can be transferred over IP. If the operator has already invested in an IP network in order to be able to carry voice over IP (VoIP), the efficiency of the network is further enhanced by also transferring all signalling traffic over IP. If SIGTRAN messages (ISUP/CAP/MAP/INAP over IP) are routed via MGW, the following is relevant: it is possible to have only one SIGTRAN association set between MGW and MSS per (physical) MGW. To balance the load, it is recommended to create the association set in the MSS side into a BSU unit for the MGW connection. (H.248/MEGACO uses SCTP but it does not use an association set.) For SIGTRAN links you need to plan the SCTP associations. The following figure shows the associations in a logical level. You should keep in mind which MSS computer units control the MGWs. On one hand, multiple virtual MGWs are recommended to balance the load. On the other hand, if possible, 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.

46 (158)




MSS01SIGU-0 SIGU-1 SIGU-2 SIGU-3 HLRU-0 HLRU-1 HLRU-2 HLRU-3

HLR01

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

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 are different possibilities for this implementation: 1. 2. 3. 4. Primary (usually SIGTRAN) and secondary (usually TDM SS7) transport networks. Separating some signalling messages to SIGTRAN and others to TDM SS7. Separating SCCP traffic from non-SCCP traffic. Separating traffic based on an SCCP field. GT analysis also provides additional means for separating traffic. The separation can be based on any SCCP field that can be analysed:



47 (158)


.

. . .

Digits. The most usable of these is the division between the destination GT addresses (digits). This allows, for example, the separation 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 of a 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 the same SPC value in SIGTRAN and TDM networks unless you use separate signalling networks (NA0 and NA1). It should also be noted that if separate signalling networks are used for SIGTRAN and TDM SS7 (for example NA0 and NA1), it is not possible to configure the TDM links to be redundant to SIGTRAN links, as it is not possible to create a Signalling Route Set to an adjacent SPC in signalling network X using a transfer SPC in signalling network Y. If you decide to select additional point codes, Nokia recommends the use of IWF type of Additional Point Code whenever possible. The IWF method allows the use of two Signalling Link Sets between a network element pair. The IWF method can only be used with Routing Indicator set to GT, since SCCP also carries the point code in the data part. DPC+SSN cannot be used as routing indicator. Therefore, for example, separating ISUP/TUP messages from MAP/ CAP/INAP messages is possible. This is done by defining 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/INAP are routed in TDM SS7 links, or vice versa.

48 (158)




Signaling link: OPC = SP Aa DPC = SP Ba

NE1DPC=SP Ba OPC=SP A SP Aa User Part DPC=SP B OPC=SP A SP A SP Ba SP B DPC=SP B OPC=SP A DPC=SP B OPC=SP Aa User Part

NE2

Signaling link: OPC = SP A DPC = SP B

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 of additional 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 be understood as a logical link between Aa and Ba, and neither SP A nor SP B 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, TDM SS7, 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 Signalling Link Set point of view the SPCs can belong to separate network elements.



49 (158)


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

6.3

Signalling Management ClusterManagement Cluster is needed if BSC or RNC does not support the sending of control plane and user plane signals to different addresses (signalling point codes, SPC). In MSC Server System this is essential since the user plane goes to MGW and the control plane to MSS. Both MSS and MGW support the Management Cluster feature (Feature 31352 Additional Signalling Point Codes). BSC/RNC is connected to Gateway node (B) which checks the signals from Switch A (BSC/ RNC) to Application Node C. With the NPC MML command you define those MTP/M3UA user parts that are for own handling and those that are to be forwarded to the application node. The main input is the SIO that consists of network part (NA0, NA1, IN0, IN1) and user part. For example, for NA0 (SIOs 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 node for family 452H, but SIO=83/SCCP (NA0) are forwarded to MSS (MSG SERV is T/TER in the MML). Note that both BSSAP and RANAP run on top of SCCP, whereas ALCAP is seen as AAL2 in the MML.

50 (158)




Switch B OPC=SP A DPC=SP BMTP

SP B Switch A OPC=SP A DPC=SP CUser Part/ MTP

SP A

OPC=SP A DPC=SP C

OPC=SP A DPC=SP C

SP C

User Part

OPC=SP A DPC=SP C Switch C

Figure 26.

Signalling Management Cluster

For more information, see Feature 31352: Additional Signalling Point Codes, in M-release feature documentation. See also Configuring Management Cluster Point Code in Migration to MSC Server System.

6.4

Planning virtual MGW configurationThe virtual Media Gateway (VMGW) concept provides better load sharing and resiliency. It also enables multiple MSC Servers (MSS) to control the same 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 different MSSs. If the physical MGW consists of multiple ISU computer units, it should be divided into several virtual MGWs, each of them controlled by a different MSS, from which resources are allocated and released using H.248/MEGACO protocol. Each VMGW from the same physical MGW does not have to be controlled by a different MSS. If the VMGWs are on different ISUs, they can be controlled by the same MSS. The advantage of having a virtual MGW is that



51 (158)


several MSSs can control the same physical MGW when split into several virtual MGWs. It is recommended to use this feature in order to spread the call control equally through all the signalling units. From MSS point of view, virtual MGW is just like a physical one.MSS MSS

MGW

MGW

MSSRNC RNC RNC RNC RNC RNC RNC RNC

MGW

MGW

MGW

RNC

RNC

RNC

RNC

MSS

MSS

Virtual MGW

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. Dimensioning rules are:

52 (158)




.

In practice one ISU can handle 3000 simultaneous calls, or 90 000 Busy Hour Call Attempt (BHCA), whichever limit is met first. In theory only 1500 simultaneous calls per ISU. In line with 2000 simultaneous calls per SIGU of MSS.

.

.

Note that MGW connection capacity licensing introduced in U3C may limit the virtual ISU capacity. The rules of thumb for dimensioning are:.

Number of VMGWs is equal to the number of ISU signalling units in one physical MGW. In theory one ISU can control 5 virtual MGWs. Thus 50 VMGWs can be defined per physical MGW element with the maximum number of working ISUs (10+1).

.

MGW1

WMGW1 ISU-0el0 el1

WMGW2 ISU-1el0 el1

WMGW3 ISU-2el0 el1

WMGW4 ISU-3el0 el1

WMGW5 BU-4el0 el1

WMGW6 BU-5el0 el1

WMGW7 BU-6el0 el1

WMGW8 BU-7el0 el1

SIGU-0

SIGU-1

SIGU-2

SIGU-3

SIGU-0

SIGU-1 IBU-1

SIGU-2

SIGU-3

MBB1

MBB2

Figure 28.

Virtual MGWs and signalling units

There is a one-to-one relationship between the signalling unit in MSS (SIGU/ CCSU) and the signalling unit in MGW (ISU). One ISU can be controlled by a maximum of 5 SIGU/CCSUs with the condition that they are located under different MSSs. One SIGU/CCSU can handle a maximum of 16 virtual MGWs.



53 (158)


It is possible to have multiple MSSs controlling the same ISU (different VMGWs in the same ISU). In order to do this, MSS differentiates each VMGW in an ISU (the same IP address) using the IP port number configured for each VMGW on the MGW. Thus even the same signalling unit in MSS can see multiple (v)MGWs in the same ISU/IP address. 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 in the same SIGU of MSS. However, different VMGWs of one MGW element can 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.

.

.

.

Virtual MGW and MEGACO example configuration in MGW and MSS

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

54 (158)




MGW data VMGW name BCU-ID

SPC: 100, NA0VMGW VMGW 11 12 11 12 VMGW 13 13 VMGW 14 14 VMGW 15 15 VMGW 16 16 VMGW 17 17 VMGW 18 18 VMGW 19 19 VMGW 20 20

ISU

0

1

2

3

4

5

6

7

8

9

MSS data SIGU

SPC: 200, NA0

0

1

2

3

4

5

6

7

8

9

Figure 29.

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

Table 3. Virtual MGW name ISU unit ID Own IP address (IP address of ISU)Mnemonic #.#.#.#/ #::# 10.100.2.11 10.100.2.12

Virtual MGW and MEGACO configuration in MGW, 1 Own IP port Internal CGR number Analysis tree number for AAL2 Transport type Coding type

Own domain name

String

Numeric 0...n

Numeric

Numeric

Numeric

Numeric

Numeric

Numeric 0

1...16 chars VMGW11 VMGW12

1...64 chars

8009...8013 -

1...1023

2...9999

0...1

0

-

500

2

0

-

1

-

-

501

2

0

-



55 (158)


Table 3. Virtual MGW name ISU unit ID Own IP address (IP address of ISU)10.100.2.13 10.100.2.14 10.100.2.15 10.100.2.16 10.100.2.17 10.100.2.18 10.100.2.19

Virtual MGW and MEGACO configuration in MGW, 1 (cont.) Own IP port Internal CGR number Analysis tree number for AAL2 Transport type Coding type

Own domain name

VMGW13 VMGW14 VMGW15 VMGW16 VMGW17 VMGW18 VMGW19

2

-

-

502

2

0

-

3

-

-

503

2

0

0

4

-

-

504

2

0

-

5

-

-

505

2

0

-

6

-

-

506

2

0

-

7

-

-

507

2

0

-

8

-

-

508

2

0

-

Table 4. Virtual MGW nameString 1...16 chars VMGW11

Virtual MGW and MEGACO configuration in MGW, 2 Primary MSS domain name Secondary MSS server number Secondary MSS IP address

Primary MSS IP address (IP address of SIGU)Mnemonic #.#.#.#/#::#

Numeric 1...64 chars

Numeric 1...5

Mnemonic #.#.#.#/#::#

10.100.2.55

-

-

10.100.3.55

56 (158)




Table 4. Virtual MGW nameVMGW12 VMGW13 VMGW14 VMGW15 VMGW16 VMGW17 VMGW18 VMGW19

Virtual MGW and MEGACO configuration in MGW, 2 (cont.) Primary MSS domain name Secondary MSS server number Secondary MSS IP address

Primary MSS IP address (IP address of SIGU)10.100.2.56

-

-

10.100.3.56

10.100.2.57

-

-

10.100.3.57

10.100.2.58

-

-

10.100.3.58

10.100.2.59

-

-

10.100.3.59

10.100.2.60

-

-

10.100.3.60

10.100.2.61

-

-

10.100.3.61

10.100.2.62

-

-

10.100.3.62

10.100.2.63

-

-

10.100.3.63

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

Table 5. MGW domain name MGW IP address (IP address of ISU)Numeric/hex #.#.#.# (IPv4) #:#:#: #:#:#:#:# (IPv6)

Virtual MGW and MEGACO configuration in MSS, 1 Port number MGW name MGW type General route number IWF route

String 64 chars

Numeric 0...65535

String 16 chars

Mnemonic IWF

Numeric 0...4095

Numeric 1...4095



57 (158)


Table 5. MGW domain name MGW IP address (IP address of ISU)10.100.2.11 10.100.2.12 10.100.2.13 10.100.2.14 10.100.2.15 10.100.2.16 10.100.2.17 10.100.2.17 10.100.2.18 10.100.2.19

Virtual MGW and MEGACO configuration in MSS, 1 (cont.) Port number MGW name MGW type General route number IWF route

-

8009 8009 8009 8009 8009 8009 8009 8009 8009 8009

VMGW11 VMGW12 VMGW13 VMGW14 VMGW15 VMGW16 VMGW17 VMGW17 VMGW18 VMGW19

Gen Gen Gen Gen Gen Gen Gen Gen Gen Gen

-

-

Table 6. MGW domain nameString 64 chars

Virtual MGW and MEGACO configuration in MSS, 2 CTRL unit index CTRL unit address E164 address Local BCU-ID

CTRL type (IP address of SIGU)Mnemonic CCSU/SIGU/ GSU

Numeric -

Numeric/hex #.#.#.# (IPv4) #: #:#:#:#:#:#:# (IPv6) 10.100.2.55

Numeric -

Numeric 0...4294967295

-

SIGU

0

35860123456 35860123456

011

-

SIGU

1

10.100.2.56

012

58 (158)




Table 6. MGW domain name-

Virtual MGW and MEGACO configuration in MSS, 2 (cont.) CTRL unit index CTRL unit address E164 address Local BCU-ID

CTRL type (IP address of SIGU)SIGU

2

10.100.2.57

35860123456 35860123456 35860123456 35860123456 35860123456 35860123456 35861023456

013

-

SIGU

3

10.100.2.58

014

-

SIGU

4

10.100.2.59

015

-

SIGU

5

10.100.2.60

016

-

SIGU

6

10.100.2.61

017

-

SIGU

7

10.100.2.62

018

-

SIGU

8

10.100.2.63

019

Transmission method for IP can be IP over ATM or IP over Ethernet. User plane traffic from MGW can be directed through the IP network interface unit (IP-NIU) as IP over Ethernet (IP backbone). Control plane traffic may be 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 the ESA24 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 the best option when there is IP connectivity between MSS and MGW. IP over ATM: Only NIP1/NIS1 dimensioning is affected in this case.

2.



59 (158)


a. b. c.

The control plane is routed to NIS1 (ATM over STM-1/OC-3) or NIP1 (ATM over TDM, IMA). A2SU is ignored. IP packets are forwarded to OMU. NIP/NIS may be used starting from U3B. OMU sends packets to the correct ISU via ESA24. Only L2 switching is done in Ethernet level.Edge-router

IPFGE

1G/100M

MSC Server ISU 100Mb TCU ESA24

OMU/ NEMU

100Mb

NetAct

MGWLAN 1 LAN 2 LAN 3 UserPlane H.248/Sigtran O&M

Figure 30.

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

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

60 (158)



Planning of services and features

77.1

Planning of services and featuresSelecting signalling protocol for call controlThe operator needs to select whether to use SIP/ISUP or BICC for call control signalling. In a particular network a combination of signalling may be used. Here are the basic rules:.

TDM trunks on the user plane require ISUP. BICC or SIP does not work on TDM user plane. ISUP works only 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. SIP profile A is used within IMS domain only (3GPP). SIP profile B is IETF SIP without ISUP tunneling. SIP profile B is used for IMS-MSS interworking. SIP profile C tunnels ISUP messages. Also referred to as SIP-I. MSS-MSS SIP is referred to as SIP-T. SIP-T is similar to SIP-I but in case of MSC Server (MSS), Nb-UP may be used. See NbUp framing and 2ms/ 20ms packetisation on UPD. Nokia VoIP Server (NVS) supports both 3GPP SIP (profile A) and IETF SIP (profile B). BICC signalling provides better capacity and bandwitdh point of view than SIP. Since BICC uses CICs, the number of calls between two entities can be controlled in a similar way to ISUP.

.

.

.

.

.

.

.

.

.



61 (158)


7.2

Planning CDS network configurationNokia Circuit Switched Data Server (CDS) offers a possibility to centralise Interworking Functions (IWF). User plane is connected via TDM trunks. Control plane uses IP-based NPI protocol. The following figures and the list below illustrate the possible configurations..

Figure CDS usage with integrated MSS: IWF may reside in the integrated MSC Server (MSS). Calls that have user plane via MSS use the IWF of the MSS. If user plane is connected from RAN to MGW, MGW utilises CDS. Figure CDS usage with Standalone MSS: If standalone MSS is used, MGW uses the IWF from CDS in all non-transparent data calls. Figure CDS shared by MGWs: CDS is shared by two (or more) MGWs. Figure CDS shared by MGWs with additional redundancy: To achieve more resiliency, CDS may be distributed. To get the benefits of the statistical concentration, CDS may be shared by multiple MGWs.MSC Server A IWF

.

.

.

GSM

A H.248/ Mecago RNC Iu-cs MGW IP/ATM backbone

WCDMA

CP UP

CDS MGW site area

Figure 31.

CDS usage with integrated MSS

62 (158)




MSC Server

GSM

A H.248/ Mecago RNC Iu-cs MGW IP/ATM backbone

WCDMA

CP UP

CDS MGW site area

Figure 32.

CDS usage with Standalone MSS



63 (158)


MSC Server

H.248/ Mecago MGW2 GDM/WCDMA radio access IP/ATM backbone GDM/WCDMA radio access

MGW1

CP UP

CDS MGW site area

Figure 33.

CDS shared by MGWs

64 (158)




MSC Server

H.248/ Mecago

H.248/ Mecago

MGW2 GDM/WCDMA radio access IP/ATM backbone GDM/WCDMA radio access

MGW1

CDS1

CP UP

CDS2

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, they are not tied to any specific virtual MGW (vMGW).



65 (158)


7.3

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

ISUP/TDM

Intel SIU520

TCP/IP

MSC/MSSi/ MGW

TDM(user plane)

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 not support virtual LAN (VLAN). See also Video Gateway Integration in M-release product documentation library.

7.4

Planning IN servicesNokia MSC/MSS provides CAMEL phases 1 to 4 and Core INAP CS1. The triggering of INAP and CAMEL Application Part (CAP) may be based on Nokia MAP extension SSET, OICK/TICK and a trigger in MSC/MSS. In addition, CAP can be triggered based on standard CAMEL Subscription Information (CSI). For Intelligent Network (IN) services the operator should specify the desired service logic. If the service is required to work while out-bound roaming, CAMEL should be use

39034649 network planning

Documents