Core Network Design Guide V2.0

8/11/2019 Core Network Design Guide V2.0

1/95

___________________________________________________________________________________________Issue :One Date : 20 Nov. 06

Author : Page 1

Core Network DesignGuideline.

Prepared by Motorola Core Network Services Group


2/95

Motorola Core Network Services REF. :

Title : Core Network Design Guideline V2.0

_______________________________________________________________________________________________


Completion of the following Table is the agreement and authorization to implement the contents

of this document.

Name Department Title Signature Date

Revision History

Date Issue Author Reason Descript ion Of Change

Nov 05 S RameshV 1.0 First DraftNov 06 S Ramesh UMTS change incorporated, M2UA, M3UA

Incl. addtl. Case StudyV 2.0 Second Draft

Author : Page 2


3/95



_______________________________________________________________________________________________


.............................................................................................................................................. 2NAME................................................................................................................................ 2DEPARTMENT

............................................................................................................................................... 2TITLE

.................................................................................................................................... 2SIGNATURE

............................................................................................................................................... 2DATE

1. .............................................................................................................................. 5SETTING

1.1. ........................................................................................................................... 5AUDIENCE1.1.1. ....................................................................................................................... 5Primary

1.2. ............................................................................................................................ 5CONTENT ............................................................................................................. 51.2.1 Initial Version

.......................................................................................................... 51.2.2 Second Version1.3. ................................................................................................................................ 5ROLES

2. ................................. 6INTRODUCTION TO CORE NETWORK DESIGN AND PLANNING

2.1. ........................................................................................................... 6NEED FOR PLANNING2.2. ........................................................................................ 6STAGES WHEN PLANNING NEEDED2.3. .............................................. 8MOTOROLA NETWORK PLANNING SUPPORT INFRASTRUCTURE

2.3.1. ........................................................................................ 8Design & Planning Support2.3.2. ................................................................................................. 8Engineering Services

3. .................................................................................................... 11CAPACITY CONCEPTS

3.1. ........................................................................................................ 11CAPACITY CONCEPTS3.1.1. ....................................................................................................................... 11BHCA3.1.2. ......................................................................................................... 11Call Hold Time3.1.3. ......................................................................................................... 12Minutes of Use3.1.4. ..................................................................................................................... 12Erlangs3.1.5. ...................................................................................................... 13Grade of Service3.1.6. .............................................................................................................. 13CPU Usage3.1.7. ..................................................................................................... 13Memory Capacity3.1.8. ................................................................................................. 14Messaging Capacity3.1.9. ..................................................................................................... 14Channel Capacity3.1.10. ................................................................................................. 14Physical Capacity3.1.11. ..................................................................................................... 14Wireless Traffic

3.2. ................................................................................................... 15EMERGING NEW CONCEPTS3.2.1. Call control signalling over Packet transport technologies....................................... 163.2.2. Evolution of transport technologies for signalling.................................................... 193.2.3. Bearer over Packet transport technologies.............................................................. 24

3.3. .................................................................................. 28ELEMENTS OF NETWORK TOPOLOGY3.4. ...................................................................................... 29TRAFFIC FLOW CHARACTERISTICS3.5. ......................................................................................... 30BASIS OF BUILDING CALL MODEL

3.5.1. ...................................................................................... 31Building basic traffic model3.5.2. ................................................................. 31Traffic distribution pattern for each MSC3.5.3. ..................................................................................... 32Network wide Traffic matrix3.5.4. ....................................................................... 33Traffic routing and Network topology3.5.5. ..................................................................................... 35Signalling network planning

Author : Page 3


4/95



_______________________________________________________________________________________________


3.5.6. .................................................................................................... 35Link dimensioning

................................................................................................ 364. NETWORK TOPOLOGIES

4.1. ........................................................................................................ 36TYPICAL TOPOLOGIES4.1.1. ..................................................................................................... 37Bearer topologies4.1.2. .................................................................................................... 39Signalling network

4.2. ....................................................................................................... 40NETWORK EVOLUTION4.3. ....................................................................................................... 43MSSARCHITECTURES

4.3.1. ............................................................................. 43MSS card and chasis modularity4.3.2. .......................................................................... 43MSS with multiple mediagateways4.3.3. ............................................................................ 45MSS with Remote mediagateway

5. .......................................................................... 47ENGINEERING NETWORK ELEMENTS

5.1. ......................................................................................................... 47TRAFFIC CALL MODEL5.2. ................................................................................................. 49INTERFACE DIMENSIONING

5.3. ................................................................................................. 64STP/SGWDIMENSIONING5.4. ................................................................................................ 65HARDWARE DIMENSIONING5.5. ...................................................................................................... 72SPARE REQUIREMENTS5.6. ................................................................................................ 72SOFTWARE DIMENSIONING

6. ................................................................................................................. 73CASE STUDIES

6.1. ................................................................................................................ 73CASE STUDY #16.2. ............................................................................................................... 82CASE STUDY #2

Author : Page 4


5/95



_______________________________________________________________________________________________


1. SETTING

1.1. AUDIENCE

1.1.1. PRIMARY

Regional engineering teams who will be required to Design the Core Networks Solutionfor the purpose of Bidding and raising Proposals catering to customer specific needs

1.2. CONTENT

INITIAL VERSION1.2.1 First draft version of Core network designing guidelines. It includesguidelines that can be applied on excel sheet used to dimension the core network.SECOND VERSION1.2.2 - Detailed description of Design guidelines. Includes processes and

deliverables. The most detailed document around the service in question. Multiple-pagedocument in black and white a technical paper. Covers UMTS core dimensioningdetails with MSC server and Media Gateway architecture.

1.3. ROLES

Development Champion: Initial content creation according to template below. Final technicalapproval on finished document.Services Product Manager: Edit and contribute as required to fulfill content requirements fordefined audience. This includes editing for the Development Champion and final approval onfinished proof.

Author : Page 5


6/95



_______________________________________________________________________________________________


2. INTRODUCTION TO CORE NETWORK DESIGN AND PLANNING

2.1. NEED FOR PLANNING

Core network Design and Planning is a complex process particularly if the size of the networksbecome large. This is so as all the networked elements are almost fully meshed logically andthere is an end-to-end dependency causing any change in the core network at a single elementimpact many other elements as well. Thus core network is always to be regarded as a wholewhich is dynamically changing. A core planning could theoretically be done without a previousaccess network planning. This is often the case as core and access planning is de-coupled formany operators. In this case core planing is done based on the expected subscriber figures andthe forecasted traffic for the MSC area in consideration. The purpose and the basic idea of thisdocument is to show how to sequentially proceed with traffic payload planning.

Core network has well defined capacity of service requests it can handle. These service attemptsmay be in the form of Voice calls, SMS, Data calls or other type of service requirement that issupported by the system. There are many network elements involved in a typical call scenarioand each network element has a definite call handling capacity. Again the call handling capacityof each network element is dependent on a number of factors such as caller behaviour, software

features, hardware capability etc. In addition to planning the capacity of the network elementitself that is involved in handling a particular type of call, there are links (signalling and trafficbearing) that carry traffic between these network elements based on the type and nature of thecall that needs to be planned to efficiently deliver a minimum assured Quality of Service to theend customer.

All of these concepts are defined and explained in detail later in this chapter.

2.2. STAGES WHEN PLANNING NEEDED

Core Network Solution system is a huge investment incurred by the Service providing operatorand contributes significantly to his CAPEX costs. Service providers profitability therefore dependson using this high cost capital infrastructure to its optimal capacity. In addition to the installedbase of equipment capacity, operators need to keep pace with growing number of subscribersand features. This growth plan and seamless integration with the existing infrastructure is a keycomponent in Operators infrastructure investment related decision making process.

Core Network Planning & Designing exercise can be broadly distributed over the following stages,

Bidding stage

Detailed Engineering stage Observation stage Forecasting stage

Bidding: This stage of planning is before the equipment is ordered and built. During this stagetraffic is assumed and a basic dimensioning exercise is conducted on the basis of assumedsubscriber count and their behaviour. This is the design stage and does not involve a detailedcapacity planning. Bidding process could be for a number of reasons such as capacity

Author : Page 6


7/95



_______________________________________________________________________________________________


augmentation, new area to be serviced by an established operator or greenfield application. Inthe first two instances viz., capacity augmentation and new service area the approximation in

very close to the real traffic whereas in case of greenfield application this designed networkneeds to be constantly monitored after deployment (observation stage) to amend the provisionedcapacity. Typical flow of different stages of Core network implementation is as shown below,

Core NetworkDesign

DetailedEngineering

Site Surve

DPQ

Dial Plan

Routing

Equipment Layout

SystemEngineering(Central/Regional)

Dial Plan

Provisionin

(Core Network DesignGuideline)

LOI

Site

Interaction with Mot

Site Plan

Interaction with

Supporting customer

Supporting for any new

Accounts Specification, Testing &

Installation &Commissioning

Ph sical Installation

Commissionin

Database loading

Acceptance Testing

Customerinputs

PostCommercial

Cutover

Performance

O timisation

Growth Plannin

O & M

(Core Network PlanningGuideline)

Detailed Engineering: During this stage, the designed system on the basis of assumed trafficparameters, is further refined to a higher level of granularity and the equipment is provisionedand installed.

Observation and Measurement stage: During this stage, the operator collects data from thesystem to measure actual traffic and load on the system and its key components.

Forecasting: In the forecasting stage, historical data gathered from monitoring the system isprojected into the future to determine - when components in the system must be augmented tosustain the growth in traffic. This stage is also called as the Detailed planning stage whereindetailed exercise is conducted to estimate and evaluate the traffic flow patterns within thenetwork. On the basis of this study alteration of provisioned network topology,alteration/augmentation of provisioned network element resources, alteration of engineered linkand bearer capacities is taken up.

Author : Page 7


8/95



_______________________________________________________________________________________________


2.3. MOTOROLA NETWORK PLANNING SUPPORT INFRASTRUCTURE

2.3.1. DESIGN &PLANNING SUPPORT

Motorola has a well established guideline to estimate the capacity of new and existing productlines. Important points in this process are identified by M-Gates. Based on inputs from Motorolaproduct support, prediction on the capacity and performance of new design software and/orhardware is made. At M-Gate 11, Network services group works with the regional services andlocal installation team to collect the data from actual deployments where the equipment issubjected to real customer traffic models. Problems/bugs discovered are fedback in theappropriate stages of Design process for proper redressal and corrective action is invoked beforethe product is destined for M-Gate 3 release process where it is declared fit for volumeintroduction into the market as shown in the flow chart below,

Design

EngineeredCapacity

(prediction on the basisof lab tests)

Design software/hardware tools

Verification atCustomer premises

Fix ProductBugs

Fix ToolBugs

Mgate 3Product Release

Capacity published,Computing methodology,

Results prediction

Release ofService Tools

2.3.2. ENGINEERING SERVICES

In addition to capacity engineering services, Motorola addresses any other service requirementsthat may arise from the customer, such as,

Author : Page 8


9/95



_______________________________________________________________________________________________


2.3.2.1. Network load balancing - Balancing the traffic such as data, voice,signalling among all the network elements deployed in the customer

network so as to maximise utilisation of all the invested capitalequipments such as serving MSC, gateway MSC, IN Platform, SMSC,STP, GGSN, SGSN, PDSN etc

2.3.2.2. Network capacity optimisation / augmentationAnalysis oftraffic and callflow patterns requiring in depth study of the observed statistics inconsonance with the database. This study typically results in exposingproblems pertaining to routing and dial plan deficiencies as well assuggesting new network architecture that optimises the flow of traffic soas to augment revenue and minimise utilisation ratio of the deployednetwork elements.

2.3.2.3. Capacity predictions and validation Predict any adverse capacity

impacts due to introduction of new features and/or services that theOperator might contemplate to provide. These predictions help operatorin avoiding any misadventures and lose competitive customer base.Complex algorithms are used to internally calculate the resourceutilisation due to different call model and suggest preemptive actions.Upon introduction of the new service or software release, the capacity isvalidated

2.3.2.4. Software tool requirements Based on the deployed network elements

Motorola can help the Operator in identifying any specific need fordevelopment of new tools that might be useful to the customer includingrequirement for services to integrate a new network element to extend aspecific type of service etc.

The Motorola support structure for supporting Customer on capacity, services and feature issuesis as below,

Author : Page 9


10/95



_______________________________________________________________________________________________


Customer

Field Support Motorola on site Sales/ Marketing

Product Development,Testing, Product

Services etc

Regional EngineeringServices Team

ProductDevelopmentFRs, REQs

RegionalEngineering

ServicesTeam

ServicesDevelopmentSFRs, REQs

Services PdM mt

Author : Page 10


11/95



_______________________________________________________________________________________________


3. CAPACITY CONCEPTS

3.1. CAPACITY CONCEPTS

While evaluating the capacity criteria for core network elements, some of the fundamentalconcepts and their relationship with each other are important to understand. Concepts such as,

BHCA Call Hold Time Minutes of Use Erlangs Grade Of Service CPU Occupancy Memory capacity

Messaging capacity Channel capacity Physical capacity

3.1.1. BHCA

BHCA or Busy Hour Call Attempts by definition is a measure of number of call attempts that the

network element handles during a busy hour. Typically BHCA relates to the time consistent busyhour ie., call attempts averaged over a period of time. Normally network is engineered to thisbusy hour call attempt rate of call arrivals.

It has to be noted that from the processor point of view call attempts are not only incoming (ororiginating calls) call attempts, but calls that are attempted to be terminated are also consideredas call attempts. They are called as the O leg and T leg of the call and accordingly registered as

2 separate attempts for a single mobile to mobile call.

Call attempts as an indicator is important due to the fact that control processor of the switch (orany network element) gets actively involved primarily during this phase of the call set up processand hence the internal resource gets utilisated that puts a cap on the engineering limits of thatnode.

3.1.2. CALL HOLD TIME

Call holding time (CHT) by definition is a measure of period during which the conversation phasehappens between the calling and the called subscriber. Holding time is therefore a measure ofamount of usage of the equipment that gets held due to this conversation. Accordingly thesubscriber is charged for this duration.

By definition there is a definite amount of time that lapses during the call setup phase, when theequipment is blocked for handling that call and therefore included in the holding time. Astechnology improved, the processing speed of handling an instance of call has reduceddramatically causing significance of this delta time to become less important for all practicalpurposes.

Author : Page 11


12/95



_______________________________________________________________________________________________


3.1.3. MINUTES OF USE

Minute of Use is another unit typically used in specifying the call quantity. In simple terms 1

MOU is equal to 60 call seconds.

3.1.4. ERLANGS

Named after A. K. Erlang, founder of the theory of telephone traffic, an Erlang is an internationaldimensionless unit of traffic intensity defined as a product of call arrival rate and call holding time(A = BHCA x CHT). One Erlang is equal to 60 call minutes, which could be a single 60- minutecall, 60 one-minute calls, or any combination of calls and minutes adding up to 60. Erlangtherefore is a measure of the quantity of call that is handled by a network element.

Alternate definitions of Erlangs that merit consideration are as below, Erlang is an average number of simultaneous occupations for a defined time interval Average occupancy of a trunk over a defined time interval

Expressed mathematically, following applies

A= y . sA = Traffic in Erlangy = Call intensity (calls/time unit)s = Mean holding time

T = Length of the time periodtv= Length of occupation no.v

N = Total no.of occupations

p = No. of simultaneous occupations in the groupt p= Total time with exactly p occupationsN = Max.no of occupations = no. of trunks

A= 1

t vv = 1

A= 1

n

p.t pp= 0

To convert BHCA to Erlangs following equation may be used,

Erlangs = (ACHT) * (BHCA) where ACHT = Average Call Holding Time3600

For the purposes of calculating erlangs for trunks, standard erlang conversion tables areavailable. These tables are called Erlang B table and applies to the lost-call-cleared callingscenario. The Erlang B traffic model is the simplest and assumes that all blocked requests for

Author : Page 12


13/95



_______________________________________________________________________________________________


service leave the system forever. The Erlang B table provides the number of trunks (channelsand radios) needed versus offered traffic (in Erlangs) for different blocking probabilities.

The Erlang C formula and tables are applicable to a lost-call-delayed calling scenario anddetermine the blocking probability, average delay time, and average queue length. It assumesthat all callers will wait indefinitely to get through.

3.1.5. GRADE OF SERVICE

Grade of Service by definition is the number of calls that is allowed to fail due to equipmentcongestion for every 100 call attempts and therefore expressed as percentage. Hence 1% gradeof service would indicate 1 call allowed to fail over 100 call attempts due to equipmentcongestion. There are many GoS criteria that is applied across different network elementsinvolved in a call. Network GoS is the overall - end to end - grade of service that would involvethe entire call chain that is applicable for that call instance. Trunk GoS pertains to the number ofcalls that can fail over that particular trunk group due to lack of free available trunk circuit tohandle a call.Congestion has a direct correlation with the engineered capacity of the system. Trade-offhappens between the cost of procuring the equipment and Grade of Service. Very high grade ofservice (implying very few calls rejected) causes the equipment costs to go up due to excesscapacity that needs to be engineered for a particular solution. On the other hand reducing theequipment costs by under engineering capacity causes revenue loss due to call rejection. Overtime it has become an industry practice to engineer the network equipment for a 1% or 2%grade of service (as specified by the operator).

3.1.6. CPUUSAGE

One of the most important parameters in the context of softswitch that needs constantmonitoring is the CPU usage. This is due to the architecture that is employed in MSS as well asmost of the core network element that is based on server technology such as HLS, INS etc. CPUusage can be defined as the amount of time available in the processor of a system node forexecution of tasks, including processing of calls and noncall tasks such as programming, audits,log processing, statistics handling and delta provisioning etc. In case of MSS since theprocessors run in active backup configuration (such as ccSwitch, Advlr, Adhlr) adequate care hasto be taken to ensure that CPU usage does not exceed 50 % - wherein 40 % of Cpocc is

attributed to the call processing and the remaining 10 % is used for p2p (peer 2 peer) sync.

3.1.7. MEMORY CAPACITY

Memory capacity imposes a limiting factor on number of calls that can be handled by a single

CPU card. This is so as enough on board memory should be kept available to ensure enoughspace exists for new call originations as well as all the existing calls this is in addition to thememory occupied by software load itself. In MSS most of the call processing occurs in CPU cardwhich has a limited memory. Call contexts are maintained for each and every call handled bythat CPU card and they are held as compact data structures. Due to the finite limitation imposedby onboard memory, there is a capacity limitation that occurs when the number of calls

simultaneously handled by that CPU card increases. As the hardware keeps upgrading, the callhandling capacities improves (within the limits imposed by CPU Occupancy) and the latestcapacity possible may be referenced from the latest release of MSS Configurator.

Author : Page 13


14/95



_______________________________________________________________________________________________


3.1.8. MESSAGING CAPACITY

Messaging capacity refers to the limitation imposed on account of the number of messages that

are exchanged between components within a system. The number of messages per call dependson the call scenario and the number of features invoked etc.

3.1.9. CHANNEL CAPACITY

Channel capacity refers to the number of network channels available in a switching component.As the softswitch technologies employ Server and Media Gateway combinations, all the networkchannels are created in the Media Gateway. Typically this is implemented as ATM backplaneswitching and this capacity refers to the limitations imposed by such an arrangement.

3.1.10. PHYSICAL CAPACITY

Physical capacity refers to the number of terminations a component or a group of componentssupports, such as the total number of ports in a SS7 Message Handler card etc

3.1.11. WIRELESS TRAFFIC

Shown below is a typical wireless network involving different components and telephone traffic ina wireless system varies according to the time of day, day of the week, month of the year, and

holidays. This traffic variation passes from very low levels to peaks of usage. Operators muststudy this behavior in order to offer quality services at a reasonable price. Figure below showstraffic capacity units applicable to each system element. For example, some elements real-timecapacity is characterized by busy hour call attempts (BHCA) at the recommended engineeringlimit, calculated from measured values of CP occupancy.

Author : Page 14


15/95


16/95



_______________________________________________________________________________________________


There are two aspects that emerge as benefits to Operator due to packetisation viz.,Packetisation of Signalling and Packetisation of Bearer such as voice, video etc. Both are

examined below and implications analysed as under.

3.2.1. CALL CONTROL SIGNALLING OVER PACKET TRANSPORT TECHNOLOGIES

Traditionally signalling in Telecom networks has been carried by circuits which were used astransport layer to transport SS7 signalling. SS7 stack has been originally conceptualised andevolved around this transport technology. Most of the call control signalling happening aroundnetwork elements were evolved using this technology and application layers such as ISUP, MAP,CAP, IS41, WINCAP etc were adopted to be carried by SS7 transport layer viz., the MTP layers.

Application layer signalling responsible for call control such as ISUP in its current form thereforeare tightly integrated and associated with the underlying bearer transport mechanism throughMTP layers. With the emergence of new technologies such as IP/ATM, however, there emergeda need to disengage strict dependence between the bearer control and call control leading toemergence of two solutions which are vying with each other for filling in this gap BICC BearerIndependent Call Control and SIP T Session Initiation Protocol for Telephones.

3.2.1.1.Bearer Independent Call Control

This solution is built around upgrading existing call control protocol (ISUP) to itssuccessor, BICC, with the aim of enabling other transport technologies, such as IPor ATM. BICC re-uses most of ISUP, changing only those parts related to theunderlying bearer. This scenario is particularly applicable with disaggregatednetworks of the type of covered under Rel 04 onwards wherein the Call control

entity is different and physically seperated from Media handling entity such as aMedia gateway. Consider the scenario when a mobile to mobile call traversesthrough two mediagateways (ie., through Nb interface) and call control happensthrough Nc interface. Nb interface could be implemented using ATM/IP to derive

the advantages of packetisation.

Transcoder is the network function in charge of processing voice traffic andconvert it between representation formats, i.e. codecs. Cellular networks havetraditionally employed specific codecs that compress speech and utilize efficientlythe expensive bandwidth in the radio interface. With the introduction of voice-over-packet transport, compressed voice can also be transmitted across corenetwork, yielding significant bandwidth savings. The main drawback of codecs isthe voice quality degradation caused by transcoding. Therefore, it has becomecritical for cellular networks to incorporate signaling procedures to control whichcodecs are available and when/where transcoding must be applied.

Thus, the call control protocol must offer signaling procedures to negotiate andselect the voice codec, and change or renegotiate it under certain circumstances

(inter-system handover, call forward, etc). The main functions that the protocolhas to support are Codec Negotiation, Codec Modification, Mid-call CodecNegotiation.When the Codec negotiation procedure finds a codec common to mobiles andnetwork nodes involved, transcoding can be avoided and the call is said to be in

Transcoder Free Operation (TrFO). Even if codec negotiation does not result in aTrFO call, it is required when the network supports multiple codecs and it provides

Author : Page 16


17/95


18/95



_______________________________________________________________________________________________


Bearer control is thus employed by the MGs to exchange the bearer instanceparticulars. For IP transport, ITU reused the IETF Session Description Protocol (SDP),

though imposing some constraints on the protocol. The Bearer Control Protocolmessages can be tunneled over the Mc and Nc interfaces, (encapsulated insideMegaco and BICC messages respectively) or exchanged directly between MGs viaalternative signaling means. 3GPP mandated bearer control tunneling for IP bearers,preventing MGs from sending SDP information directly to each other.The bearer control for IP bearers defined by the ITU as IP Bearer Control Protocol(IPBCP), is just a simplified SDP, where most options have been pruned and a newattribute to signal the IPBCP message type (Request, Accepted, Confused orRejected) is defined. The main limitation imposed to SDP is that only 1 RTP payloadtype is allowed in the format list, so that codec negotiation must take place prior toexchange of SDP. The main purpose of the IPBCP messages is to allow MGs toexchange IP addresses and port numbers for both ends of the media stream, as wellas media properties of the selected codec.

As regards to BICC itself, it is very similar to ISUP except that the bearer part of thesignalling has been removed and the CIC field (Circuit Identity Code) has beenreused for the Call Instance Code (CIC) in BICC. The function is very similar: thiscode identifies the signaling relationship between peer BICC entities for a certain call,and all the PDUs for the call should be tagged with the same code. BICC reused theexisting ISUP Application Transport Mechanism (APM) to transport bearer-related

information between call control instances. This mechanism comprises theApplication Transport Parameter (APP), which BICC actually tailored as a containerfor bearer information, and the Application Transport Message (APM). The APMmessage is only generated when there is no other BICC message that the APP canpiggyback onto. Among the new information elements defined by BICC inside APP,we find the Action Indicator, the Backbone Network Connection (BNC) Characteristics

and the Codec list.

3.2.1.2.Session Initiation Protocol for Telephones (SIP-T)

This solution is based on the IETF architectural framework Session InitiationProtocol (SIP) for Telephones. The SIP-T recommendation describes how to use SIPto provide telephony over IP networks, and interwork with legacy ISUP networks. Inparticular, it identifies the basic mechanisms required: encapsulation of ISUP

messages into SIP payload, translation of ISUP information into the SIP header andafew new SIP extensions required to adequately emulate ISUP. An important pointabout SIP-T is that it is focused on enabling plain telephony calls, disregardingadditional services. That is the main reason why SIP-T dictates that MSCs must buildand encapsulate the whole ISUP message inside the SIP payload. The MSCs need toread the service information in the ISUP message to be able to support

supplementary services and other legacy network features.Regarding signaling transport, SIP can run on top of several different protocols, likeSCTP or TCP, or TLS (encrypted transport) over those. Obviously, SIP signalingtransport, SCTP or TCP over IP, cannot route messages based on telephony number(E.164 numbers). For call delivery MSS has to translate a received E.164 MobileStation Roaming Number (obtained using MAP Send Routing Info) into thedestination MSC IP address.

Author : Page 18


19/95



_______________________________________________________________________________________________


Bearer control uses Session Description Protocol, exchanged as SIP payload. SDPdefines a format to formally describe the bearer details for a variety of technologies.

It has to be actually carried by another protocol, say Megaco on the Mc interface andSIP on the Nc interface and the only dynamic procedure considered for SDP is bearernegotiation.

On the issue of signalling therefore the implementation of BICC or SIP-T will probably bedetermined by the preferences of Telecom Operators. BICC is backed by GSM/UMTS operators,while 3GPP2 CDMA standard body seems to support SIP-T. However, there is a technicalparameter that favors BICC over SIP-T. BICC has a comprehensive set of detailed specifications,some of them applied to cellular networks. SIP-T specifications are not complete or detailed.Thus, BICC maturity ensures the inter-operability with other vendors.

3.2.2. EVOLUTION OF TRANSPORT TECHNOLOGIES FOR SIGNALLING

With the evolution of high capacity networks, the existing capacity constraints on signallingbandwidth were imposing severe restraints in growth potential of network elements. In order toenhance the bandwidth capability of signalling carriers, many methods have been tested and arein existence. Some of them are the traditional DS0 or Low Speed Links (LSL), 2M High SpeedLinks (HSL) and the new age IP based signalling transport or SIGTRAN. As is well establishedthe bandwidth capacity of LSL is DS0 bandwidth which is 64000 bits/sec or 64 Kbps. In case ofHSL, the entire 2 M bandwidth capacity (or 1.5 M in case of T1) is considered as a singlesignalling link so as to exploit a much higher signalling payload capacity with 2 basic types of HSLviz., HDLC HSL and ATM based HSL defined by standards. IP based transport mechanisms aredefined by SIGTRAN protocol workgroup and adopted by 3GPP R4. This protocol suite is madeup of a new transport layer the Stream Control Transmission Protocol or SCTP and a set ofUser Adaptation layers which mimic the services of the lower layers of SS7 and ISDN. SCTPaddresses many of TCP shortcomings and offers key advantages such as Multi-homing, Multi-

streaming facility & SCTP timers are more adapted to SS7 MTP transmission delay timers. Inorder to carry signalling over SCTP/IP user adaptation layers for different transport layers had tobe defined viz., M3UA, M2UA, M2PA, SUA, IUA etc.

Author : Page 19


20/95



_______________________________________________________________________________________________


IP

SCTP

M3UA

M2UA M2PA

M3UA

SUAIUA

ISUP

SCCP

TCAP

MTP3

ISDN

3.2.2.1.M2UA or MTP2 User Adaptation

The only SS7 MTP 2 user is MTP3. All MTP 3 primitives are backhauled to the MGC

for interpretation. One of the key advantages of M2UA is that the SGW does notrequire a separate PC. Signalling Gateway signifies that the entity performs thegateway function to transform TDM based signalling to IP based signalling. Thisfunction is typically implemented in MGW & Remote MGW to take advantage ofextracting signalling information communicated from RAN through TDMMessaging timeslot and convert into IP packets without the need for RAN toaddress Media Gateway by the way of point code. Using M2UA obviates this needand RAN can address CS directly for all signalling information and media gatewayroutes the same through its M2UA link to Control switch.

TDMSignallin

IPSignallin

SGWFunctio

CS RANMGW

Typical Usage of M2UA

Author : Page 20


21/95



_______________________________________________________________________________________________


3.2.2.2. M2PA or MTP2 Peer to Peer Adaptation

M2PA is the peer to peer equivalent of M2UA. Rather than provide a link between

remotely located MTP2 and MTP3 instances, it replaces an MTP2 link beneathMTP3. The user of M2PA is MTP3 at both ends of the connection (with M2UA,

one user is MTP3 and the other is SGWs Inter-working function). Typical M2PAarchitecture is shown as below,

Signalling Gateway

MTP3

MTP2

MTP1 IP

SCTP

M2PA

Signalling Gateway

MTP3

MTP2

MTP1

M2PA

IP

SCTP

SS7 SS7

M2PA Architecture

This architecture is most applicable for an SGW to SGW connection used to bridgetwo SS7 network islands. MTP3 is present on each SGW to provide routing andmanagementof the MTP2/M2PA links. Because of the presence of MTP3, eachSGW would require its own pointcode.

The significant difference in function from M2UA is that M2PA actually provides an

MTP2 like service itself. M2UA merely provides an interface to a remote MTP2service. This means that M2PA is responsible for Link activation/deactivation (in

response to requests from MTP3), Maintaining link status information, Maintainingsequence numbers and retransmit buffers for retrieval by MTP3, Maintaining localand remote processor outage status etc.

Author : Page 21


22/95



_______________________________________________________________________________________________


3.2.2.3. M3UA or MTP3 User Adaptation

M3UA provides adaptation between SCTP and applications that use the services of

MTP3 across an IP interface. SS7 User applications such as ISUP, MAP, TUP etc.Typical usage of this adaptation layer is for PSTN connectivity in instances when

POI can support IP signalling or Apertio HLR, MSC to SGW/STP etc. Thearchitecture of M3UA is shown as below,

Signalling Gateway

MTP2

MTP1 IP

SCTP

M3U

MGC

ISUP

M3U

IP

SCTP

SS7

MTP3

NIF

M3UA Architecture

The MTP3 in the SGW is unaware that the ISUP user is located remotely.Similarly ISUP layer at the MTC will not be aware of the transport layer used tocarry the signalling interactions. This architecture is most appropriate in instanceswherein there is a high enough density of SS7 links that normal SS7 link capacityis insufficient to cater to the entire signalling requirement, SS7 links are physicallyaccessible at a single point

Author : Page 22


23/95



_______________________________________________________________________________________________


3.2.2.4. SUA or SCCP User Adaptation

SUA provides a means by which an application part (such as TCAP) is sent over to

an IP SCP through a SGW. The network architectures associated with SUA allowsfor multiple IP SCPs to be reached via a single SGW. The IP SCP do not have

local MTP3 instances and so do not require their own SS7 point codes.The functionality of SUA could be provided by MTP2 or MTP2 UA. However SUAprovides the mapping between SCCP addresses and IP addresses (at the SGW). Without such a function, SCCP would have to be present at each IP SCP and theexternal SS7 network would require knowledge of each such SCCP instance. SUAcan abstract the presence of each IP SCP, providing one SCCP address to cover allnodes. The services of individual databases are addressed via Subsystem Number(SSN). SUA provides a service similar to SCCP GTT to map

Signalling Gateway

MTP2

MTP1 IP

SCTP

SUA

IP SCP

TCAP

SUA

IP

SCTP

SS7

MTP3

NIF

SCC

SUA Architecture

these SSNs into SCCP Connection IDs (which are used to route the Applicationpart messages to the appropriate IP SCP). SUA is also flexible enough to support

Author : Page 23


24/95



_______________________________________________________________________________________________


Application parts running between two network nodes wholly within the IPnetwork. This is particularly relevant to emerging networks where there may be

no need for an underlying traditional SS7 network. In this case the IP SCP stackwould be the same on both (IP based) nodes. SUA will further allow ServiceDatabases in the SS7 network to be accessed from the IP network. In this casethe architecture would be the same as shown in the figure above.

3.2.2.5. IUA and V5UA

Similar to the previous user adaptations, ISDN user adaptations work to adapt theISDN layers to the IP transport

3.2.3. BEARER OVER PACKET TRANSPORT TECHNOLOGIES

As in case of signalling carried over packet technologies, bearer support over packet technologyis emerging as the new trend in Core Network domain due to incorporation of QoS criteria

meeting the stringent needs of Voice and Real time services requirement being built intoprotocols. Various options such as G.711 PCM over IP, G726 over IP, EVRC/FR/EFR Bypass,Accelerated A1p/A2p, TFO/TrFO are available with varying degree of advantages anddevelopment effort to incorporate them in the product portfolio. G.711 PCM over IP justpacketises the PCM samples and sends it over the IP does not involve voice payloadcompression and result in higher bandwidth requirement due to header used in instanceswhen there is no dearth of IP bandwidth. G726 over IPsame as before except the payload iscompressed voice using dominant format used in enterprise networks today - R-MGW would usestandard TDM-based RAN interfaces to set up calls and route G.711 bearer, after which MGWcompresses the voice internally from G.711 to G.726-32, and places on IP backbone network.EVRC/FR/EFR bypass are applicable in CDMA(EVRC) and existing GSM (FR/EFR) networkswherein the encoded speech is sent as it is to MSC and MSC-RAN signaling messagescommunicate to setup this vocoder bypass (Motorola CDMA solutions call it Supercell TRAU). As

transcoding is minimised, this results in best quality of speech. The RANs at each end (mobile-to-mobile call) look for inband, robbed-bit signaling to communicate call setup capabilities and mid-

call changes used in instances when IP network bandwidth gain combined with low bit rateprovides significant economical benefits. Accelerated A1p/A2p is the same as previous optionexcept the RAN has pushed up the use of packet interfaces into the 2005 timeframe. Thus theLBR voice and PCM for a given call are sent in independent RTP streams to/from the MGW. Amechanism is provided to toggle between using the PCM and the LBR streams. TRAU iseliminated from use in the RAN-TRAU interface. The inband, robbed-bit signaling to communicate

call setup capabilities and mid-call changes is replaced with proprietary A and A1 messages andthe MSS control takes over more control of call setup and mid-call modifications. This is desirablewhen the IP network used for VoIP is so incredibly expensive that LBR produces significanteconomical benefits. Compared to others, the voice quality is best because the number oftranscoders in minimized. This option is NOT currently available on the MSS; the ability wouldhave to be added for AudioCodes, Sonus and Motorola MGWs. TFO/TrFOsolution would use

full negotiation methods to select transcoding type and location for inter-system calls. This isdesirable when the IP network used for VoIP is so incredibly expensive that LBR producessignificant economical benefits. The R-MGW would use IP RAN interfaces to set up calls androute LBR for M-M, PCM (transcoded in the CORE) bearer for M-L and L-M on RTP/UDP/IPstreams. The MGW is instructed to use the appropriate voice format after end-to-endnegotiations determine where and how vocoding occurs.

Author : Page 24


25/95



_______________________________________________________________________________________________


Header compression is not prevalent today in Media Gateways suppliers, but will more than likelybe deployed in a later phase. Since voice payload compression is farther along, they are more

readily available. It is interesting to compare the fixed bandwidth (64,000 bps) per voice calltoday in the TDM network to the bandwidth required to carry VoIP in an IP network. The keything to consider is that the IP bandwidth per call depends on the packetization rate of the IPendpoints, with a typical current practice today of setting this to 5-20 milliseconds.

Figure below depicts the relationship between bandwidth, packetization rate (PR) and VoiceActivity Detection (VAD). The bandwidth for a TDM system is the benchmark and is shown asstraight black line at 64 Kbps (TDM systems do not vary due to VAD or PR. Generally, for a VoIPsystem, the higher the PR, the lower the VoIP bandwidth. The more time an IP endpoint takes togather multiple PCM-TDM voice samples before putting into an IP message, the lower thepercentage overhead impact due to RTP/UDP/IP addressing, and the lower the over allbandwidth. At the far end of typical practice (5-20ms) the effect reaches asymptotic limits sinethere is always a fixed amount of IP addressing that requires its own contribution to bandwidth.

VoIP for 64Kbps PCM Inpu t DSP

20

40

60

80

100

120

140

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Packetization Rate (ms)

VoIP

BandwidthPerCall(Kbps)

TDM (baseline)

w/o VAD/CNI

20% VAD/CNI

40% VAD/CNI

60% VAD/CNI

80% VAD/CNI

Bandwidth per Call when Using G.711 voice formatting over IP

A few observations from above fig G.711 over IP: Without VAD, putting 64Kbps payload with IP addressing overhead can never beat

traditional TDM,

Even if experiencing 20% VAD (means speech averages idleness 20% of time and theability to NOT send packets during those moment of quiet reduces the bandwidthproportionally), the VoIP solution cannot beat TDMs 64,000 fixed bandwidthrequirement.

Author : Page 25


26/95



_______________________________________________________________________________________________


There would need to be VAD at 40-80% (statistically unlikely) to offer a hope that PCMover IP beats TDM in lower bandwidth, and even then, it may require a favorable PR of 8

ms or higher.

Figure below shows a similar comparison, only replacing PCM voice format in the payload with acompressed voice. Although the figure shows G.729 in the title, it generally represents acompressed voice payload of 8Kbps, such as EVRC or GSM-FR, etc. That is, the results of thiscomparison can be applied to various LBR voice formats.

VoIP for 8Kbps Compressed Voice Input DSP

20

30

40

50

60

70

80

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20


VoIP

BandwidthPerCall(Kbp

s)

TDM (baseline)

w/o VAD/CNI

20% VAD/CNI

40% VAD/CNI

60% VAD/CNI

80% VAD/CNI

Bandwidth per Call when Using G.729 voice formatting over IP

A few observations from Figure above showing compressed voice over IP: VAD offers little extra savings due to the relative efficiency of the compressed voice

(G.729) versus PCM (G.711); being able to clip voice idleness is not as important ifpayload is compressed than if at full rate, like PCM.

The savings using compressed VoIP is almost immediate within the PR range.

The degree of savings is much more pronounced than PCM over IP, even when VAD isnone or little (20%).

Another way to think of the bandwidth savings of LBR VoIP to PCM TDM is to measure thenumber of calls per unit of bandwidth. This is particularly useful when the physical facilitlieswould be common, such as channelized (circuit) vs non-channelized (packet) E1/T1. A usefulcommon unit of bandwidth is the benchmark TDM DS0 slot of 64Kbps.

Figure below shows the extra gain in calls per DS0. Notice the gains in number of calls per DS0can range from 1.0 to 3.0 depending mostly on PR.

Author : Page 26


27/95



_______________________________________________________________________________________________


Total Calls per Fixed Transmission Varies by Packetization and VAD Rates Using

Compressed 8Kbps as input to VoIP

0.500

1.000

1.500

2.000

2.500

3.000

3.500

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20


Callsper

Every64KbpsofBandwidth

TDM (baseline)

w/o VAD/CNI

20% VAD/CNI

40% VAD/CNI

60% VAD/CNI

80% VAD/CNI

Number of Calls per DS0 for LBR VoIP by Packetization Rate and by VAD

Author : Page 27


28/95



_______________________________________________________________________________________________


3.3. ELEMENTS OF NETWORK TOPOLOGYAs below, various network elements are involved in a typical MSS-G and MSS-C networktopology. Network elements that are typically associated with a wireless architecture are BTS,BSC together they form the part of Radio Access Network or RAN. The Core networkcomprises of Media Gateway where the bearer trunks from the BSC is terminated and signallingtrunk which is terminated in MSS chasis itself.

The Motorola End-to-End Architecture

CDMA-One/CDMA-

IP Backbone

TDM Backbone

IP

SS7

IOS 4.x

RA Core

SIP, MAP+/IP,IOS/A on IP

ANSI-41 HLR,

AuC, SCP

ANSI-41,IS771,GSM MAP,CAMEL

TDM / ATM

IP

ISUPMSC/

PSTN Swit ch

TDM

TDM/ATM/IP

ControlSwitch

MediaGateway

ALL-IPIP

RANIP

RAN

Motorola GSM/UMTS

BSC

MSS-CMSS-GMSS-U

Future

Control Switch

Media Gateway

Typically PSTN, Other operators are connected to the operator network through Points ofInterconnect or POI in Gateway MSC which is configured to perform the IN/HLR/AuC interactionsfor Mobile termination scenarios. In case of large networks multiple serving MSCs areinterconnected through bearer trunks if inter MSC roaming scenario is applicable, otherwise theyare directly connected to the GMSC (signalling and bearer trunks) to cater to Land to Mobile callscenario and vice versa. Inter MSC trunks may be provided in the above case if there is

substantial mobile to mobile traffic between the regions served by these MSCs, else the callsmay be allowed to transit through GMSC. In smaller markets the serving MSC itself functions asthe gateway MSC where POIs are terminated in which case, VLR has to be provisioned.

In case of a typical GSM network HLR is an external network entity and signalling link is extendedfrom MSS directly to HLR or through an STP in case of a large network. HLR is an SCP type of

Author : Page 28


29/95



_______________________________________________________________________________________________


SS7 network element that typically supports authentication. In instances when Mobile numberportability, has to be supported, many markets incorporate the function of Signalling Relay

Function in HLR itself.

Value added services such as Short Message Service, Multimedia messaging service, Voice Mail

service etc are typically provided by standalone servers that are connected to the MSS. Ininstances when SMS, MMS servers are provisioned as a standalone network elements, onlysignalling links, based on SMS/MMS BHCA, need to be extended from the MSS. On the otherhand in case of Voice Mails systems, both signalling(based on busy hour Voice mail retrieval rate)and bearer trunks (based on erlang) have to be provisioned.

Prepaid solution and other intelligent network solutions are provisioned through an external INplatform which is WINCAP capable in case of CDMA and CAMEL compliant in case of GSM. All theIN solutions need only signalling interaction with the serving MSS and signalling links arecalculated on the basis of number of services the operator wishes to host.

3.4. TRAFFIC FLOW CHARACTERISTICS

To characterise the calls handled by MSC, typically H diagram is used to graphically represent thecombination of incoming and outgoing traffic where Mobile traffic is shown on the left and Landtraffic on the right. The Hdiagram shows the possible terminations of a call, whether a calloriginates from a mobile or from a land trunk. Intra-switch traffic occurs when the call follows themobile-to-mobile flow. The flow of traffic originated by mobiles runs mainly from the outgoingtrunks to the land trunks, and has a small amount of inefficiency when a block in the exchange or

M-L

MM

INTRA(mobile to mobile)

TANDEM(Call forward,

Voice mail etc)

MobileOrigination

Mobile

Termination

Incoming traffic(From PSTN,

Gateway etc)

Outgoing traffic(To PSTN,Gateway,

Intra MSC etc)

Failed mobile originations(Setup failures, Invalid attempts etc)

Failed mobile terminations(Page timeout, Invalid mobiles etc)

Mobile

Trunk

s

LandTrunk

s

LL

Author : Page 29


30/95



_______________________________________________________________________________________________


on the outgoing route occurs. Out of this a portion of the flow terminating in mobiles representsthe traffic between mobile units (ie., mobile to mobile traffic). Similarly, the incoming traffic

generated from the land trunks terminate largely in the mobiles; a portion of the traffic is tandemand a portion is ineffective. Another additional component of the tandem calls is represented bythe traffic in the tandem trunks in MSS, for example, calls transferred back to the network itself.Other tandem trunks are added to permit an adaptation of the signaling supported by theexchange and the signaling characteristics of the operators network.

3.5. BASIS OF BUILDING CALL MODEL

Core Network Design involves arriving at the traffic flow pattern within various network elementsthat it is comprised of. Network designing activity involves the determination of the trafficvolumes between the various core sites of a network and involves all elements where traffic can

be originated or terminated. From core networks point of view, typically, those elements are theMSC itself, the voice mail centre VMSC, Points of Interconnection towards PSTN or PLMN.Between those elements a logical fully meshed traffic relation exists which can be expressed inend-to-end matrices. Those matrices exist for each call type, i.e. mobile originating traffic,

mobile terminating traffic, mobile to mobile traffic and forwarded traffic etc. Typical flow chartinvolving such a design process is shown as below,

Core Network Design Flowchart

Inputs

Call Model # of Subs

Determine trafficdistribution pattern

for all MSCs

Network widetraffic planning forall types of calls

Traffic routing and

Network topology

Signalling networkplanning

Link dimensioning

Those matrices need to be calculated separately and superimposed later to do dimensioning.Transit MSCs or Gateway MSCs are not considered here as they do traffic routing only. Routingand interfaces dimensioning are not considered at this stage and are treated in subsequent steps.Normally traffic planning is related to payload traffic as this represents the major traffic in a

Author : Page 30


31/95



_______________________________________________________________________________________________


network. Signalling planning will be done in later steps, which is based on the output of trafficplanning.

3.5.1. BUILDING BASIC TRAFFIC MODEL

The basic input to traffic planning are the subscriber figures and the traffic call model. It may sohappen that there is no homogeneous traffic model across different MSC in the network. Thisdoes not only apply to the traffic per subscriber but also to the proportional traffic share for the

various types of call such as mobile to mobile, land to mobile, mobile to land etc., thus trafficplanning needs to be done for each individual MSC.

3.5.2. TRAFFIC DISTRIBUTION PATTERN FOR EACH MSC

At this point it is necessary to obtain information about the traffic distribution for each MSC, such

as what percentage of traffic is routed locally, type of traffic routed at different nodes, how manyPOIs are provisioned for National and International calls etc. Traffic dissemination in each nodeis computed at this stage and a separate traffic distribution for the MSC under considerationmight appear as shown in the figure below. If such information pertaining to traffic

discriminatioin is not available (e.g. in rough offer cases), it will be necessary to makeassumptions about the traffic flows in the network and document them. It is important to knowthat any parameters changed after assumption have a direct impact on the designing exerciseoutput, hence it is important to record the assumption to establish the reference frame. Basedon extrapolation of different call scenarios (m2m, m2p, p2m, p2p etc) applicable for the MSCunder consideration, the following detail may be arrived at,

ToFrom

MSC 1 MSC 2 POI 1 POI 2 VMS 1 BSC 1 BSC 2

MSC 1 75 12 31 42 10 30 40

MSC 2

POI 1

POI 2

VMS 1

BSC 1

BSC 2

Traffic dissemination per MSC

Author : Page 31


32/95



_______________________________________________________________________________________________


POI 1

POI 2

MSS 2

VMS 1

MSS 1

BSC 1BSC 2

3.5.3. NETWORK WIDE TRAFFIC MATRIX

Based on above traffic planning results for the individual MSCs it will be possible to extrapolateall the traffic matrices that describes the end-to-end dependencies between all involved nodes.Thus we obtain the entire traffic distribution picture between all the nodes involved in the coredesigning process. All network elements that act as traffic sink or source are part of the matrix.Typically those elements are MSCs, PSTN, PLMN, VMSC etc. Other elements as pure transitMSCs TMSC may not to be considered here as they fulfil routing functions only. For a smallnetwork consisting of 2 MSCs and 2 POI elements, the logical traffic flow may be calculated asfollows. Note that some arrows are bi-directional, implying traffic summed up both ways etc.

ToFrom

MSC 1 MSC 2 POI 1 POI 2 VMS 1 BSC 1 BSC 2

MSC 1 75 12 31 42 10 30 40

MSC 2 6 10 25 41 8

POI 1 32 42 5

POI 2 76 34 7

VMS 1

BSC 1 32

BSC 2 45

Please note that the above shown values are just dummy values and are not backed up withdetailed calculation

Author : Page 32


33/95


34/95



_______________________________________________________________________________________________


needed bandwidths between the different network elements. The traffic in the end-to-end matrixneeds to be considered on each link along which the specific traffic is routed. This leads to a

revised table which then represents the aggregated traffic on the links and reflects the networkstructure. If further elements such as Gateway MSCs or Transit/tandem MSCs are to be used inthe network, they have to be added to the matrix and have to appear as well. Retaining theexample from the traffic planning, the possible routing results could look as follows.

Network Topology

POI 1 POI 2

GMSS2

GMSS1

MSS 1 MSS 2

VMS 1

BSS 1 BSS 2

The assumed topology above is adopted to highlight concepts of load sharing and redundancy.MSS 1 can for instance send the outgoing traffic via the Gateway MSS 1 or the Gateway MSS 2.In this case it is necessary to define a load split between all possible paths. In this example, a

50% load split for both Gateways shall be assumed. This does not apply for the MMC trafficwhich shall be routed via the direct route between MSS 1 and MSS 2. This leads to the following

table. Note that traffic between two nodes are transferred via the same link no matter the factwhich node sends or receives the traffic. Thus the traffic between two nodes can be summed upas follows,

Author : Page 34


35/95


36/95



_______________________________________________________________________________________________


75737271696866646259

73727170686765636158

72717069676664626057

71706967666563615956

70696866656462605855

69686765646361595754

68676664636260585653

67666563626159575552

66656362616058565452

65646261605957555351

64636160595856545250

63616059585755545249

61605958575654535148

7775747371706866646175

74

73

72

71

70

69

68

67

66

65

64

63

62

61

0.10.090.080.070.060.050.040.030.020.01

76747372706967656360

Dimensioning needs to be done path-wise. As an output one obtains either the number of trafficchannel with a bandwidth of 64kbps (for E1 TDM systems) or 56 kbps (as in T1 TDM systems).After all traffic components have been calculated and their bandwidths determined, it is finallypossible to determine the number of E1/T1 links between the sites. Therefore one has tocompare the bandwidth demand between the sites with the required capacity of a specific nodeconnection.

4. NETWORK TOPOLOGIES

4.1. TYPICAL TOPOLOGIES

Network topology broadly combines two distinct topologies viz., the bearer topology and thesignalling topology. Network Topology mainly refers to the way bearer traffic flows in thenetwork as it determines the scale of economies underlying the overall network architecture.Nevertheless signalling topology is also important in view of fault alleviation, disastermanagement, redundancy requirements that is demanded by newly emerging networks.

Author : Page 36


37/95



_______________________________________________________________________________________________


4.1.1. BEARER TOPOLOGIES

In large networks or in cities where more than one MSC will be needed to cater to the traffic

requirement of the market, the issue of networking the MSCs, pros and cons of the same needto be considered. Typical topologies that are used in the Telecom network domains are Startopology, Mesh topology, Pyramid, Double Pyramid topology and Hybrid structures. Representedfiguratively these topologies would appear as below,

MSC

MSC MSC

MSC

Tandem

Star Topology

MSC

MSC MSC

MSC

Mesh Topology

MSC

MSC MSC

MSC

GMSC

Pyramid Topology

MSC

MSC MSC

MSC

GMSC Tandem

Double Pyramid Topology

Star topology is rarely used in telecom domains due to its inability to be fault resilient which iscritical decision altering factor to determine the topology. Any failure in any link will isolate thenode and therefore is not a good solution. Mesh topology on the other hand evolves through aring architecture where all the nodes are interconnected in a ring format without any cross links.The issue with the ring architecture is that the traffic in any node increases due to transit traffic.One of the basic thumb rule that need to be observed in Core Network Design is to congregateas much traffic as possible from all possible call originating sources, but this traffic need to bequickly disseminated out of the core network as soon as the routing design permits. This is so asto reduce the wastage of valuable call processing capability of various nodes in the network aswell as to preserve the bandwidth of the intereconnecting transmission network, resulting in

optimal utilisation of the network element resources. In order for this to be realised,theoretically, if we can realise a very large capacity of switch, then that will provide the mostoptimal solution. Mesh topology is fault resilient and any failure of transmission link does notisolate a particular node as alternative routes are available to reach the destination. It may not

be possible to realise a Mesh architecture in all market deployments, but most of thedeployments almost always tend to migrate towards mesh architecture as the network grows.One of the practical evolutions from mesh architecture is the Pyramid and Double Pyramidarchitectures. In Pyramid architecture, the Gateway MSC is at the top of the pyramid and is

Author : Page 37


38/95



_______________________________________________________________________________________________


responsible for interconnecting this PLMN with other PLMN as well as PSTN networks. There area lot of advantages of this configuration that accrues due to optimal routing and least wastage of

trunk / switching resources. Double Pyramid architecture improvises by addition of Tandem MSC.Tandem MSC does not have gateway functionality and hence the processing capacity of TandemMSC is very high and can cater to higher capacity networks. All the outgoing traffic from thePLMN is routed through Tandem whereas all Incoming traffic from external networks is routedthrough Gateway MSC. The disadvantage of this design is that it becomes prohibitive in cost andis justifiable only in high capacity networks. Many an instance these perfect architectures are notrealised due to limitations of trunking resource availability/connectivity and a hybrid of thesetopologies is implemented with a stub connection to one or more nodes etc.

Providing network solutions catering to a number of cities within a region is a common remit ofoperators. Networking issues and transmission design to cater to this multi city environmentrequires adequate planning and preparation.

City A Link l, Traffic = 2yeab/

Traffic = 2yeac/

om

n

City B

City CCity D

Shown above is a typical instance of four cities interlinked with each other. Based on degree ofaffinity, mobiles from any of the city above viz., A, B, C, D can call among themselves

constituting Inter City Mobile to Mobile traffic scenario that flows in link l, m, n, o, p, q. Trafficbetween any two nodes is calculated and as an example in link l ie., between City A and City B itis 2yeab/where y is intercity m2m traffic, e is Erl/subs, a is City A mobile population and b isCity B mobile population, is sum of all subscribers. This traffic is shown figuratively as directlyflowing between A and B, but it may not be so due to Transmission facility availability and mayhave to be routed via available trunks through other cities. Typically this rerouted traffic is not

recommended to flow through switching nodes in the rerouted path as it serves no purpose tounnecessarily load the intermediate switch. Depending on alternate route availability, there maybe more than one path to reach the destination (in case of no direct trunking facility available)and during those instances a route matrix is constructed with the cost of alternate routes. Basedon the cost structure, a weighted average determines the percentage distribution of trafficthrough these alternate paths.

Author : Page 38


39/95



_______________________________________________________________________________________________


4.1.2. SIGNALLING NETWORK

One of the important components of any Telecom Network is the Signalling component. Almost

all of modern day telecom networks are built around common channel signalling wherein thesignalling path is kept distinctly different from the bearer path to capitalise on bandwidthadvantages obtained by delinking signalling from the bearer path. This requires therefore toconstruct an overlay network capable of handling signalling and the fundamental networkelement in this layer is Signalling Transfer Point this plane of Network is also termed as theControl Plane (vis a vis the User Plane which signifies the Bearer path). In addition to routingsignalling between MSCs and PLMNs, STP is used to provide connectivity to databases such asHLR, EIR, AUC, IN etc. From a network perspective following are the reasons for implementingSTP,

Helps in load balancing signalling traffic load among distributed databases Ability to provide resilient and failsafe signalling route to destination

Allows minor application NE to connect to all available databases in the network as wellas itself being made available to all NEs within that domain (eg., Missed Call Alertsystem), thereby easing introduction of new services

STPs act as the signalling gateways to the interface to the other domains be it TDM toIP or PLMN to PSTN or PLMN to Other PLMNs etc.

STP in its functional capacity as border gateway network element implements GlobalTitle Translation functionality obviating the need to have extensive routing database tobe managed in internal NEs.

Minimises the need to have Public Point Codes within a PLMN network STP can also add value by accounting for SCCP transactions which are used by some

operators to settle inter network accounts eg., SMS accounting for home subscribersroaming in other PLMNs

STP functionality has enhanced due to advances in transport layer technologies as detailed earlierand can work as Signalling Gateway. Signalling Gateway works as the Border Network Element

between TDM based SS7 signalling network and IP based signalling network.An STP/SGW is always duplicated in a network due to its critical functionality, and failure of anyone STP does not affect the healthy functioning of the network. Topologically therefore for thesignalling network, Star Topology is used due to the availability of redundant nodes. Typical STPconfiguration is shown as below,

Author : Page 39


40/95



_______________________________________________________________________________________________


STP/SGW

STP/SGW

MSC MSC MSC

HLRHLR

inIN

SMSC LBS

MCAOTA

EIR

BSC BSC BSC

IP/MPLS

Star Topology of typical

Signalling Network

4.2. NETWORK EVOLUTION

With the onset of Next Generation Networks or NGN, standards body have become active indefining the network architecture as well as links interconnecting different NEs within this newarchitecture. Notably 2 standards organisation viz., 3GPP and 3GPP2 have been defining this forthe UMTS market and CDMA market respectively. As shown in the figure below, networkarchitecture evolved with the release of new specifications from R96 to R99 with the inclusion ofLocation based service offerings (R98) and IN services, UTRAN (in R99) etc.

Author : Page 40


41/95



_______________________________________________________________________________________________


VLRMSC VLR

BSC

HLR

A i/f

B i/f

C i/f

D i/f

MSC

E i/f

EIR

F i/f

MSCVLR

G i/f

AuC

H i/f

Gs i/f

SGSNGr i/f

GMLC

Lg i/f

Ls i/f

Lh i/f

Lb i/f

R96, R97

CAP i/f

CAMEL

UTRAN

IuCSi/f

CBC

IuBC i/f

R99

SMLC

IuPS i/f

Network Entities and Interfaces evolution in 3GPP

There has been more dramatic changes in the architecture subsequent to R99 with the onset ofNGN that started with Rel 04. Rel 04 captured the concept of MSC legacy platform bifurcated infunctionality - physically as well as logically into the Call Control part which is the MSC server (orMGCF) and the Bearer Handling part which is the Media Gateways (or MGW). Server basedsoftware oriented telecom systems came into existence and traditional legacy HLRs, IN platformshave evolved into Server based HLR and Server based IN platforms. Onward from Rel 04, Rel 05brought in another radically new concept to the Telecom domain viz., IMS or the IP MultimediaCore Network subsystem. IMS is expected to herald the onset of feature rich service offerings byTelecom operators as warranted by evolution from 2G to 3G networks. Elementary IMSfunctionality was further refined and clear roles defined for different elements constituting thisdomain as the release progressed from Rel 05 to Rel 06.

Shown below, an extract from the Network architecture specification 23.002 480 of Rel04standards that highlights the Core Network elements and their interfaces. As can be seen newinterfaces Mc, Nc, Nb pertaining to MSC - MGW, Inter MSC interface and Inter MGW bearer

interfaces respectively have been defined. MSC MGW interface or Mc interface typically usesMGCP or MEGACO protocol for MSC server to control the functioning of MGW. MSC MSCinterface earlier used standard ISUP to carry MAP traffic, had to be revised with Nc interface tocarry BICC signalling. Similarly MGW MGW interface, Nb, though shown as a direct interactionbetween the two entities, in reality is implemented through Mc Nc interface as discussedearlier.

Author : Page 41


42/95



_______________________________________________________________________________________________


BSS

BSC

RNS

RNC

CN

Node B Node B

IuPS

Iur

Iub

USIM

ME

MS

Cu

Uu

MSC serverSGSN

Gs

GGSNGMSC

server

GnHLR

Gr

GcC

D

Nc

H

EIR

F Gf

GiPSTN

IuCS

VLRB

Gp

VLR

G

BTSBTS

Um

RNCAbis

SIM

SIM-ME i/f or

MSC server

B

PSTN

cell

CS-MGWCS-MGW

CS-

MGW

AuC

Nb

McMc

Nb

PSTNPSTN

Nc

Mc

AGb

E

NGN Architecture Rel 04 heralding split between Call controland Media handling functions

Author : Page 42


43/95



_______________________________________________________________________________________________


4.3. MSSARCHITECTURES

4.3.1. MSSCARD AND CHASIS MODULARITYMSS has a flexible architecture that allows innovative configurations which provide cost-effectivesolutions to the operators. Personnel involved in core network architecture will understand thatone of the primary reasons for escalating costs of core network is the inability to scale the size ofMSC based on demand. Fundamental design issues crop up when all the traffic cannot behandled by one MSC and needs multiple MSCs.

Documents

Core Network Design Guide V2.0