Core Network Design Guide V2.0

___________________________________________________________________________________________
Issue :One Date : 20 Nov. 06

Author : Page 1

Core Network Design
Guideline.

Prepared by Motorola Core Network Services Group

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 Description Of Change
Nov 05 S Ramesh V 1.0
First Draft
Nov 06 S Ramesh UMTS change incorporated, M2UA, M3UA
Incl. addtl. Case Study
V 2.0
Second Draft

Author : Page 2



_______________________________________________________________________________________________

___________________________________________________________________________________________

.............................................................................................................................................. 2 NAME
................................................................................................................................ 2 DEPARTMENT
............................................................................................................................................... 2 TITLE
.................................................................................................................................... 2 SIGNATURE
............................................................................................................................................... 2 DATE
1. .............................................................................................................................. 5 SETTING
1.1. ........................................................................................................................... 5 AUDIENCE
1.1.1. ....................................................................................................................... 5 Primary
1.2. ............................................................................................................................ 5 CONTENT
............................................................................................................. 5 1.2.1 Initial Version
.......................................................................................................... 5 1.2.2 Second Version
1.3. ................................................................................................................................ 5 ROLES
2. ................................. 6 INTRODUCTION TO CORE NETWORK DESIGN AND PLANNING
2.1. ........................................................................................................... 6 NEED FOR PLANNING
2.2. ........................................................................................ 6 STAGES WHEN PLANNING NEEDED
2.3. .............................................. 8 MOTOROLA NETWORK PLANNING SUPPORT INFRASTRUCTURE
2.3.1. ........................................................................................ 8 Design & Planning Support
2.3.2. ................................................................................................. 8 Engineering Services
3. .................................................................................................... 11 CAPACITY CONCEPTS
3.1. ........................................................................................................ 11 CAPACITY CONCEPTS
3.1.1. ....................................................................................................................... 11 BHCA
3.1.2. ......................................................................................................... 11 Call Hold Time
3.1.3. ......................................................................................................... 12 Minutes of Use
3.1.4. ..................................................................................................................... 12 Erlangs
3.1.5. ...................................................................................................... 13 Grade of Service
3.1.6. .............................................................................................................. 13 CPU Usage
3.1.7. ..................................................................................................... 13 Memory Capacity
3.1.8. ................................................................................................. 14 Messaging Capacity
3.1.9. ..................................................................................................... 14 Channel Capacity
3.1.10. ................................................................................................. 14 Physical Capacity
3.1.11. ..................................................................................................... 14 Wireless Traffic
3.2. ................................................................................................... 15 EMERGING NEW CONCEPTS
3.2.1. Call control signalling over Packet transport technologies....................................... 16
3.2.2. Evolution of transport technologies for signalling.................................................... 19
3.2.3. Bearer over Packet transport technologies .............................................................. 24
3.3. .................................................................................. 28 ELEMENTS OF NETWORK TOPOLOGY
3.4. ...................................................................................... 29 TRAFFIC FLOW CHARACTERISTICS
3.5. ......................................................................................... 30 BASIS OF BUILDING CALL MODEL
3.5.1. ...................................................................................... 31 Building basic traffic model
3.5.2. ................................................................. 31 Traffic distribution pattern for each MSC
3.5.3. ..................................................................................... 32 Network wide Traffic matrix
3.5.4. ....................................................................... 33 Traffic routing and Network topology
3.5.5. ..................................................................................... 35 Signalling network planning

Author : Page 3



_______________________________________________________________________________________________

___________________________________________________________________________________________
3.5.6. .................................................................................................... 35 Link dimensioning
................................................................................................ 36 4. NETWORK TOPOLOGIES
4.1. ........................................................................................................ 36 TYPICAL TOPOLOGIES
4.1.1. ..................................................................................................... 37 Bearer topologies
4.1.2. .................................................................................................... 39 Signalling network
4.2. ....................................................................................................... 40 NETWORK EVOLUTION
4.3. ....................................................................................................... 43 MSS ARCHITECTURES
4.3.1. ............................................................................. 43 MSS card and chasis modularity
4.3.2. .......................................................................... 43 MSS with multiple mediagateways
4.3.3. ............................................................................ 45 MSS with Remote mediagateway
5. .......................................................................... 47 ENGINEERING NETWORK ELEMENTS
5.1. ......................................................................................................... 47 TRAFFIC CALL MODEL
5.2. ................................................................................................. 49 INTERFACE DIMENSIONING
5.3. ................................................................................................. 64 STP/SGW DIMENSIONING
5.4. ................................................................................................ 65 HARDWARE DIMENSIONING
5.5. ...................................................................................................... 72 SPARE REQUIREMENTS
5.6. ................................................................................................ 72 SOFTWARE DIMENSIONING
6. ................................................................................................................. 73 CASE STUDIES
6.1. ................................................................................................................ 73 CASE STUDY #1
6.2. ............................................................................................................... 82 CASE STUDY #2

Author : Page 4



_______________________________________________________________________________________________

___________________________________________________________________________________________

1. SETTING
1.1. AUDIENCE
1.1.1. PRIMARY
Regional engineering teams who will be required to Design the Core Networks Solution
for the purpose of Bidding and raising Proposals catering to customer specific needs
1.2. CONTENT
INITIAL VERSION 1.2.1 First draft version of Core network designing guidelines. It includes
guidelines that can be applied on excel sheet used to dimension the core network.
SECOND VERSION 1.2.2 - Detailed description of Design guidelines. Includes processes and
deliverables. The most detailed document around the service in question. Multiple-page
document in black and white a technical paper. Covers UMTS core dimensioning
details with MSC server and Media Gateway architecture.
1.3. ROLES
Development Champion: Initial content creation according to template below. Final technical
approval on finished document.
Services Product Manager: Edit and contribute as required to fulfill content requirements for
defined audience. This includes editing for the Development Champion and final approval on
finished proof.

Author : Page 5



_______________________________________________________________________________________________

___________________________________________________________________________________________

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 networks
become large. This is so as all the networked elements are almost fully meshed logically and
there is an end-to-end dependency causing any change in the core network at a single element
impact many other elements as well. Thus core network is always to be regarded as a whole
which is dynamically changing. A core planning could theoretically be done without a previous
access network planning. This is often the case as core and access planning is de-coupled for
many operators. In this case core planing is done based on the expected subscriber figures and
the forecasted traffic for the MSC area in consideration. The purpose and the basic idea of this
document 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 attempts
may be in the form of Voice calls, SMS, Data calls or other type of service requirement that is
supported by the system. There are many network elements involved in a typical call scenario
and each network element has a definite call handling capacity. Again the call handling capacity
of 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 element
itself that is involved in handling a particular type of call, there are links (signalling and traffic
bearing) that carry traffic between these network elements based on the type and nature of the
call that needs to be planned to efficiently deliver a minimum assured Quality of Service to the
end 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 operator
and contributes significantly to his CAPEX costs. Service providers profitability therefore depends
on using this high cost capital infrastructure to its optimal capacity. In addition to the installed
base of equipment capacity, operators need to keep pace with growing number of subscribers
and features. This growth plan and seamless integration with the existing infrastructure is a key
component 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 stage
traffic is assumed and a basic dimensioning exercise is conducted on the basis of assumed
subscriber count and their behaviour. This is the design stage and does not involve a detailed
capacity planning. Bidding process could be for a number of reasons such as capacity

Author : Page 6



_______________________________________________________________________________________________

___________________________________________________________________________________________
augmentation, new area to be serviced by an established operator or greenfield application. In
the 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 network
needs to be constantly monitored after deployment (observation stage) to amend the provisioned
capacity. Typical flow of different stages of Core network implementation is as shown below,

Core Network
Design

Detailed
Engineering
Site Survey
DPQ
Dial Plan
Routing
Equipment Layout
System
Engineering
(Central/Regional)
Dial Plan
Provisioning
(Core Network Design
Guideline)
LOI
Site
Interaction with Mot
Site Plan
Interaction with
Supporting customer
Supporting for any new
Accounts
Specification, Testing &
Installation &
Commissioning
Physical Installation
Commissioning
Database loading
Acceptance Testing
Customer
inputs
Post
Commercial
Cutover
Performance
Optimisation
Growth Planning
O &M
(Core Network Planning
Guideline)

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

Observation and Measurement stage: During this stage, the operator collects data from the
system 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 is
projected into the future to determine - when components in the system must be augmented to
sustain the growth in traffic. This stage is also called as the Detailed planning stage wherein
detailed exercise is conducted to estimate and evaluate the traffic flow patterns within the
network. On the basis of this study alteration of provisioned network topology,
alteration/augmentation of provisioned network element resources, alteration of engineered link
and bearer capacities is taken up.

Author : Page 7



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 product
lines. Important points in this process are identified by M-Gates. Based on inputs from Motorola
product support, prediction on the capacity and performance of new design software and/or
hardware is made. At M-Gate 11, Network services group works with the regional services and
local installation team to collect the data from actual deployments where the equipment is
subjected to real customer traffic models. Problems/bugs discovered are fedback in the
appropriate stages of Design process for proper redressal and corrective action is invoked before
the product is destined for M-Gate 3 release process where it is declared fit for volume
introduction into the market as shown in the flow chart below,

Design
Engineered
Capacity
(prediction on the basis
of lab tests)
Design software/
hardware tools
Verification at
Customer premises
Fix Product
Bugs
Fix Tool
Bugs
Mgate 3
Product Release
Capacity published,
Computing methodology,
Results prediction
Release of
Service Tools

2.3.2. ENGINEERING SERVICES
In addition to capacity engineering services, Motorola addresses any other service requirements
that may arise from the customer, such as,

Author : Page 8



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 capital
equipments such as serving MSC, gateway MSC, IN Platform, SMSC,
STP, GGSN, SGSN, PDSN etc
2.3.2.2. Network capacity optimisation / augmentation Analysis of traffic and call
flow patterns requiring in depth study of the observed statistics in
consonance with the database. This study typically results in exposing
problems pertaining to routing and dial plan deficiencies as well as
suggesting new network architecture that optimises the flow of traffic so
as to augment revenue and minimise utilisation ratio of the deployed
network elements.
2.3.2.3. Capacity predictions and validation Predict any adverse capacity
impacts due to introduction of new features and/or services that the
Operator might contemplate to provide. These predictions help operator
in avoiding any misadventures and lose competitive customer base.
Complex algorithms are used to internally calculate the resource
utilisation due to different call model and suggest preemptive actions.
Upon introduction of the new service or software release, the capacity is
validated
2.3.2.4. Software tool requirements Based on the deployed network elements
Motorola can help the Operator in identifying any specific need for
development of new tools that might be useful to the customer including
requirement for services to integrate a new network element to extend a
specific type of service etc.

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

Author : Page 9



_______________________________________________________________________________________________

___________________________________________________________________________________________

Customer
Field Support Motorola on site Sales/ Marketing
Product Development,
Testing, Product
Services etc
Regional Engineering
Services Team
Product
Development
FRs, REQs
Regional
Engineering
ServicesTeam
Services
Development
SFRs, REQs
Services Pd
Mgmt

Author : Page 10



_______________________________________________________________________________________________

___________________________________________________________________________________________

3. CAPACITY CONCEPTS
3.1. CAPACITY CONCEPTS
While evaluating the capacity criteria for core network elements, some of the fundamental
concepts 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 busy
hour ie., call attempts averaged over a period of time. Normally network is engineered to this
busy 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 (or
originating calls) call attempts, but calls that are attempted to be terminated are also considered
as 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 (or
any network element) gets actively involved primarily during this phase of the call set up process
and hence the internal resource gets utilisated that puts a cap on the engineering limits of that
node.
3.1.2. CALL HOLD TIME
Call holding time (CHT) by definition is a measure of period during which the conversation phase
happens between the calling and the called subscriber. Holding time is therefore a measure of
amount of usage of the equipment that gets held due to this conversation. Accordingly the
subscriber is charged for this duration.

By definition there is a definite amount of time that lapses during the call setup phase, when the
equipment is blocked for handling that call and therefore included in the holding time. As
technology improved, the processing speed of handling an instance of call has reduced
dramatically causing significance of this delta time to become less important for all practical
purposes.

Author : Page 11



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 international
dimensionless 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- minute
call, 60 one-minute calls, or any combination of calls and minutes adding up to 60. Erlang
therefore 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
.
s

A =Traffic in Erlang
y =Call intensity (calls/time unit)
s =Mean holding time
T =Length of the time period
t
v
=Length of occupation no.v
N =Total no.of occupations
p =No. of simultaneous occupations in the group
t
p
=Total time with exactly p occupations
N =Max.no of occupations =no. of trunks
A =
1

t
v
v =1
A =
1

n
p. t
p
p =0

To convert BHCA to Erlangs following equation may be used,

Erlangs = (ACHT) * (BHCA) where ACHT = Average Call Holding Time
3600

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

Author : Page 12



_______________________________________________________________________________________________

___________________________________________________________________________________________
service leave the system forever. The Erlang B table provides the number of trunks (channels
and 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 and
determine the blocking probability, average delay time, and average queue length. It assumes
that 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 equipment
congestion for every 100 call attempts and therefore expressed as percentage. Hence 1% grade
of service would indicate 1 call allowed to fail over 100 call attempts due to equipment
congestion. There are many GoS criteria that is applied across different network elements
involved in a call. Network GoS is the overall - end to end - grade of service that would involve
the entire call chain that is applicable for that call instance. Trunk GoS pertains to the number of
calls that can fail over that particular trunk group due to lack of free available trunk circuit to
handle a call.
Congestion has a direct correlation with the engineered capacity of the system. Trade-off
happens between the cost of procuring the equipment and Grade of Service. Very high grade of
service (implying very few calls rejected) causes the equipment costs to go up due to excess
capacity that needs to be engineered for a particular solution. On the other hand reducing the
equipment costs by under engineering capacity causes revenue loss due to call rejection. Over
time 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. CPU USAGE
One of the most important parameters in the context of softswitch that needs constant
monitoring is the CPU usage. This is due to the architecture that is employed in MSS as well as
most of the core network element that is based on server technology such as HLS, INS etc. CPU
usage can be defined as the amount of time available in the processor of a system node for
execution 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 the
processors run in active backup configuration (such as ccSwitch, Advlr, Adhlr) adequate care has
to 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 enough
space exists for new call originations as well as all the existing calls this is in addition to the
memory occupied by software load itself. In MSS most of the call processing occurs in CPU card
which has a limited memory. Call contexts are maintained for each and every call handled by
that CPU card and they are held as compact data structures. Due to the finite limitation imposed
by 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 call
handling capacities improves (within the limits imposed by CPU Occupancy) and the latest
capacity possible may be referenced from the latest release of MSS Configurator.

Author : Page 13



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 depends
on 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 network
channels are created in the Media Gateway. Typically this is implemented as ATM backplane
switching 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 components
supports, 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 in
a 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 must
study this behavior in order to offer quality services at a reasonable price. Figure below shows
traffic capacity units applicable to each system element. For example, some elements real-time
capacity is characterized by busy hour call attempts (BHCA) at the recommended engineering
limit, calculated from measured values of CP occupancy.

Author : Page 14



_______________________________________________________________________________________________

___________________________________________________________________________________________

Mobiles
Radios, Voice and
Control Channels
Cell
BSC
Media Gateways
MSC
Erlang per subscriber
Call Attempts per subs
Erlangs per voice channel
BHCA at engineering limit
CP occupancy
CP occupancy
CP occupancy
Erlangs
CP occupancy

The study of telephone traffic involves an attempt to quantify these traffic variations and help
operating company engineers estimate the amount and types of equipment needed for a system.
The best way to gather reliable information is to observe the traffic presented by one exchange
during preestablished periods of time. After a number of observations, or samples, average data
from this traffic is calculated. This establishes rules and trends for the application and forecasting
of an optimized telephone system.

3.2. EMERGI NG NEW CONCEPTS
With the evolution of telecom networks from the traditional Circuit oriented approach to low cost,
highly adaptable packet based solutions such as IP, ATM etc., new concepts and standards are
being evolved to cater to this evolving reality. Voice traffic traditionally carried over dedicated
circuits due to strict Quality of Service requirements are yielding to packet based carrier primarily
due to following reasons
Highly adaptable and Low cost packet based equipment
Tremendous advances in technologies such as variable and low bit rate compression
techniques surrounding packetisation
Packet-based networks do not allocate transmission resources statically augmenting
benefits accrued due to compression technologies
Evolution of standards surrounding IP domain
Very wide acceptance of IP technologies with internet providing a catalyst for it
ubiquity

Author : Page 15



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 SI GNALLING OVER PACKET TRANSPORT TECHNOLOGIES
Traditionally signalling in Telecom networks has been carried by circuits which were used as
transport layer to transport SS7 signalling. SS7 stack has been originally conceptualised and
evolved around this transport technology. Most of the call control signalling happening around
network 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 therefore
are tightly integrated and associated with the underlying bearer transport mechanism through
MTP layers. With the emergence of new technologies such as IP/ATM, however, there emerged
a need to disengage strict dependence between the bearer control and call control leading to
emergence of two solutions which are vying with each other for filling in this gap BICC Bearer
Independent 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 its
successor, BICC, with the aim of enabling other transport technologies, such as IP
or ATM. BICC re-uses most of ISUP, changing only those parts related to the
underlying bearer. This scenario is particularly applicable with disaggregated
networks 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 a
Media gateway. Consider the scenario when a mobile to mobile call traverses
through two mediagateways (ie., through Nb interface) and call control happens
through 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 and
convert it between representation formats, i.e. codecs. Cellular networks have
traditionally employed specific codecs that compress speech and utilize efficiently
the expensive bandwidth in the radio interface. With the introduction of voice-
over-packet transport, compressed voice can also be transmitted across core
network, yielding significant bandwidth savings. The main drawback of codecs is
the voice quality degradation caused by transcoding. Therefore, it has become
critical for cellular networks to incorporate signaling procedures to control which
codecs are available and when/where transcoding must be applied.

Thus, the call control protocol must offer signaling procedures to negotiate and
select the voice codec, and change or renegotiate it under certain circumstances
(inter-system handover, call forward, etc). The main functions that the protocol
has to support are Codec Negotiation, Codec Modification, Mid-call Codec
Negotiation.
When the Codec negotiation procedure finds a codec common to mobiles and
network 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 a
TrFO call, it is required when the network supports multiple codecs and it provides

Author : Page 16



_______________________________________________________________________________________________

___________________________________________________________________________________________
other advantages such as inserting the transcoder at the most appropriate
location (e.g. Remote Transcoder Operation (RTO) when it is placed at the CN
edge).

Gateway
MSC Srv
BSC
MSC
Server
MG MG
Nc
Nb
Mc Mc
BSC
BSC
A
Signaling Interface
User Traffic
I t f
PLMN/
PSTN
Nb
Nc
As shown in the architecture above, the call control protocol (without media or
bearer dependency), BICC, is exchanged in Nc interface. The Bearer control
(such as bearer identification, codec negotiation etc) signalling is exchanged
between Media Gateways but that negotiation does not happen over Nb interface,
instead it happens over Mc -> Nc -> Mc interface through a special tunneling
mechanism as shown in the conceptual figure below. It is referred to as a
tunnel, because the BICC protocol does not inspect, check or understand the
information it passes and the advantage it offers is that a separate signaling
transport between MGs does not have to be configured; the same BICC signaling
transport is used instead.

Megaco

Author : Page 17



_______________________________________________________________________________________________

___________________________________________________________________________________________
Bearer control is thus employed by the MGs to exchange the bearer instance
particulars. For IP transport, ITU reused the IETF Session Description Protocol (SDP),
though imposing some constraints on the protocol. The Bearer Control Protocol
messages can be tunneled over the Mc and Nc interfaces, (encapsulated inside
Megaco and BICC messages respectively) or exchanged directly between MGs via
alternative 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 new
attribute to signal the IPBCP message type (Request, Accepted, Confused or
Rejected) is defined. The main limitation imposed to SDP is that only 1 RTP payload
type is allowed in the format list, so that codec negotiation must take place prior to
exchange of SDP. The main purpose of the IPBCP messages is to allow MGs to
exchange IP addresses and port numbers for both ends of the media stream, as well
as media properties of the selected codec.
As regards to BICC itself, it is very similar to ISUP except that the bearer part of the
signalling has been removed and the CIC field (Circuit Identity Code) has been
reused for the Call Instance Code (CIC) in BICC. The function is very similar: this
code 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 the
existing ISUP Application Transport Mechanism (APM) to transport bearer-related
information between call control instances. This mechanism comprises the
Application Transport Parameter (APP), which BICC actually tailored as a container
for bearer information, and the Application Transport Message (APM). The APM
message is only generated when there is no other BICC message that the APP can
piggyback 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 Initiation
Protocol (SIP) for Telephones. The SIP-T recommendation describes how to use SIP
to provide telephony over IP networks, and interwork with legacy ISUP networks. In
particular, it identifies the basic mechanisms required: encapsulation of ISUP
messages into SIP payload, translation of ISUP information into the SIP header and a
few new SIP extensions required to adequately emulate ISUP. An important point
about SIP-T is that it is focused on enabling plain telephony calls, disregarding
additional services. That is the main reason why SIP-T dictates that MSCs must build
and encapsulate the whole ISUP message inside the SIP payload. The MSCs need to
read 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, like
SCTP or TCP, or TLS (encrypted transport) over those. Obviously, SIP signaling
transport, 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 Mobile
Station Roaming Number (obtained using MAP Send Routing Info) into the
destination MSC IP address.

Author : Page 18



_______________________________________________________________________________________________

___________________________________________________________________________________________
Bearer control uses Session Description Protocol, exchanged as SIP payload. SDP
defines 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 and
SIP on the Nc interface and the only dynamic procedure considered for SDP is bearer
negotiation.

On the issue of signalling therefore the implementation of BICC or SIP-T will probably be
determined 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 technical
parameter 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. EVOLUTI ON OF TRANSPORT TECHNOLOGIES FOR SI GNALLING
With the evolution of high capacity networks, the existing capacity constraints on signalling
bandwidth were imposing severe restraints in growth potential of network elements. In order to
enhance the bandwidth capability of signalling carriers, many methods have been tested and are
in existence. Some of them are the traditional DS0 or Low Speed Links (LSL), 2M High Speed
Links (HSL) and the new age IP based signalling transport or SIGTRAN. As is well established
the bandwidth capacity of LSL is DS0 bandwidth which is 64000 bits/sec or 64 Kbps. In case of
HSL, the entire 2 M bandwidth capacity (or 1.5 M in case of T1) is considered as a single
signalling link so as to exploit a much higher signalling payload capacity with 2 basic types of HSL
viz., HDLC HSL and ATM based HSL defined by standards. IP based transport mechanisms are
defined by SIGTRAN protocol workgroup and adopted by 3GPP R4. This protocol suite is made
up of a new transport layer the Stream Control Transmission Protocol or SCTP and a set of
User Adaptation layers which mimic the services of the lower layers of SS7 and ISDN. SCTP
addresses 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. In
order to carry signalling over SCTP/IP user adaptation layers for different transport layers had to
be defined viz., M3UA, M2UA, M2PA, SUA, IUA etc.

Author : Page 19



_______________________________________________________________________________________________

___________________________________________________________________________________________

IP
SCTP
M3UA
M2UA M2PA
M3UA
SUA
IUA
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 not
require a separate PC. Signalling Gateway signifies that the entity performs the
gateway function to transform TDM based signalling to IP based signalling. This
function is typically implemented in MGW & Remote MGW to take advantage of
extracting signalling information communicated from RAN through TDM
Messaging timeslot and convert into IP packets without the need for RAN to
address Media Gateway by the way of point code. Using M2UA obviates this need
and RAN can address CS directly for all signalling information and media gateway
routes the same through its M2UA link to Control switch.

TDM
Signallin
IP
Signallin
SGW
Functio
CS RAN
MGW
Typical Usage of M2UA

Author : Page 20



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 beneath
MTP3. 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 M2PA
architecture 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 bridge
two SS7 network islands. MTP3 is present on each SGW to provide routing and
managementof the MTP2/M2PA links. Because of the presence of MTP3, each
SGW 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 MTP2
service. This means that M2PA is responsible for Link activation/deactivation (in
response to requests from MTP3), Maintaining link status information, Maintaining
sequence numbers and retransmit buffers for retrieval by MTP3, Maintaining local
and remote processor outage status etc.

Author : Page 21



_______________________________________________________________________________________________

___________________________________________________________________________________________
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. The
architecture 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 to
carry the signalling interactions. This architecture is most appropriate in instances
wherein there is a high enough density of SS7 links that normal SS7 link capacity
is insufficient to cater to the entire signalling requirement, SS7 links are physically
accessible at a single point

Author : Page 22



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 allows
for 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 SUA
provides 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 the
external SS7 network would require knowledge of each such SCCP instance. SUA
can abstract the presence of each IP SCP, providing one SCCP address to cover all
nodes. 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 Application
part messages to the appropriate IP SCP). SUA is also flexible enough to support

Author : Page 23



_______________________________________________________________________________________________

___________________________________________________________________________________________
Application parts running between two network nodes wholly within the IP
network. 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 stack
would be the same on both (IP based) nodes. SUA will further allow Service
Databases in the SS7 network to be accessed from the IP network. In this case
the 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 the
ISDN 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 technology
is 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 into
protocols. 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 and
development effort to incorporate them in the product portfolio. G.711 PCM over IP just
packetises the PCM samples and sends it over the IP does not involve voice payload
compression and result in higher bandwidth requirement due to header used in instances
when there is no dearth of IP bandwidth. G726 over IP same as before except the payload is
compressed voice using dominant format used in enterprise networks today - R-MGW would use
standard TDM-based RAN interfaces to set up calls and route G.711 bearer, after which MGW
compresses 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) networks
wherein the encoded speech is sent as it is to MSC and MSC-RAN signaling messages
communicate 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 rate
provides significant economical benefits. Accelerated A1p/ A2p is the same as previous option
except the RAN has pushed up the use of packet interfaces into the 2005 timeframe. Thus the
LBR voice and PCM for a given call are sent in independent RTP streams to/from the MGW. A
mechanism is provided to toggle between using the PCM and the LBR streams. TRAU is
eliminated 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 and
the MSS control takes over more control of call setup and mid-call modifications. This is desirable
when the IP network used for VoIP is so incredibly expensive that LBR produces significant
economical benefits. Compared to others, the voice quality is best because the number of
transcoders in minimized. This option is NOT currently available on the MSS; the ability would
have to be added for AudioCodes, Sonus and Motorola MGWs. TFO/ TrFO solution would use
full negotiation methods to select transcoding type and location for inter-system calls. This is
desirable when the IP network used for VoIP is so incredibly expensive that LBR produces
significant economical benefits. The R-MGW would use IP RAN interfaces to set up calls and
route LBR for M-M, PCM (transcoded in the CORE) bearer for M-L and L-M on RTP/UDP/IP
streams. The MGW is instructed to use the appropriate voice format after end-to-end
negotiations determine where and how vocoding occurs.

Author : Page 24



_______________________________________________________________________________________________

___________________________________________________________________________________________
Header compression is not prevalent today in Media Gateways suppliers, but will more than likely
be 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 call
today in the TDM network to the bandwidth required to carry VoIP in an IP network. The key
thing to consider is that the IP bandwidth per call depends on the packetization rate of the IP
endpoints, with a typical current practice today of setting this to 5-20 milliseconds.

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

VoIP for 64Kbps PCM Input 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)
V
o
I
P

B
a
n
d
w
i
d
t
h

P
e
r

C
a
l
l

(
K
b
p
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.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 the
ability to NOT send packets during those moment of quiet reduces the bandwidth
proportionally), the VoIP solution cannot beat TDMs 64,000 fixed bandwidth
requirement.

Author : Page 25



_______________________________________________________________________________________________

___________________________________________________________________________________________
There would need to be VAD at 40-80% (statistically unlikely) to offer a hope that PCM
over 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 a
compressed voice. Although the figure shows G.729 in the title, it generally represents a
compressed voice payload of 8Kbps, such as EVRC or GSM-FR, etc. That is, the results of this
comparison 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
V
o
I
P

B
a
n
d
w
i
d
t
h

P
e
r

C
a
l
l

(
K
b
p
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 if
payload 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 is
none or little (20%).

Another way to think of the bandwidth savings of LBR VoIP to PCM TDM is to measure the
number of calls per unit of bandwidth. This is particularly useful when the physical facilitlies
would be common, such as channelized (circuit) vs non-channelized (packet) E1/T1. A useful
common 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 DS0
can range from 1.0 to 3.0 depending mostly on PR.

Author : Page 26



_______________________________________________________________________________________________

___________________________________________________________________________________________

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
C
a
l
l
s

p
e
r

E
v
e
r
y

6
4

K
b
p
s

o
f

B
a
n
d
w
i
d
t
h
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



_______________________________________________________________________________________________

___________________________________________________________________________________________

3.3. ELEMENTS OF NETWORK TOPOLOGY
As below, various network elements are involved in a typical MSS-G and MSS-C network
topology. 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 network
comprises of Media Gateway where the bearer trunks from the BSC is terminated and signalling
trunk 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
ISUP
MSC/
PSTN Switch
TDM
TDM/ATM/IP
Control
Switch
Media
Gateway

ALL-IP
IP
RAN
IP
RAN
Motorola GSM/UMTS
BSC
MSS-C
MSS-G
MSS-U
Future
Control Switch
Media Gateway

Typically PSTN, Other operators are connected to the operator network through Points of
Interconnect or POI in Gateway MSC which is configured to perform the IN/HLR/AuC interactions
for Mobile termination scenarios. In case of large networks multiple serving MSCs are
interconnected through bearer trunks if inter MSC roaming scenario is applicable, otherwise they
are directly connected to the GMSC (signalling and bearer trunks) to cater to Land to Mobile call
scenario 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 calls
may be allowed to transit through GMSC. In smaller markets the serving MSC itself functions as
the 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 extended
from MSS directly to HLR or through an STP in case of a large network. HLR is an SCP type of

Author : Page 28



_______________________________________________________________________________________________

___________________________________________________________________________________________
SS7 network element that typically supports authentication. In instances when Mobile number
portability, 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. In
instances when SMS, MMS servers are provisioned as a standalone network elements, only
signalling links, based on SMS/MMS BHCA, need to be extended from the MSS. On the other
hand 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 IN
platform which is WINCAP capable in case of CDMA and CAMEL compliant in case of GSM. All the
IN solutions need only signalling interaction with the serving MSS and signalling links are
calculated 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 the
combination of incoming and outgoing traffic where Mobile traffic is shown on the left and Land
traffic on the right. The Hdiagram shows the possible terminations of a call, whether a call
originates from a mobile or from a land trunk. Intra-switch traffic occurs when the call follows the
mobile-to-mobile flow. The flow of traffic originated by mobiles runs mainly from the outgoing
trunks to the land trunks, and has a small amount of inefficiency when a block in the exchange or

M
M-L
M
M
INTRA
(mobile to mobile)
TANDEM
(Call forward,
Voice mail etc)
Mobile
Origination
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)
M
o
b
i
l
e

T
r
u
n
k
s
L
a
n
d

T
r
u
n
k
s
L
L

Author : Page 29



_______________________________________________________________________________________________

___________________________________________________________________________________________
on the outgoing route occurs. Out of this a portion of the flow terminating in mobiles represents
the 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 tandem
and a portion is ineffective. Another additional component of the tandem calls is represented by
the 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 the
exchange 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 elements
that it is comprised of. Network designing activity involves the determination of the traffic
volumes 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 the
MSC 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 in
end-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 chart
involving such a design process is shown as below,

Core Network Design Flowchart

Inputs
Call Model
#of Subs
Determine traffic
distribution pattern
for all MSCs
Network wide
traffic planning for
all types of calls
Traffic routing and
Network topology
Signalling network
planning
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. Routing
and 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



_______________________________________________________________________________________________

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

3.5.1. BUILDING BASIC TRAFFIC MODEL
The basic input to traffic planning are the subscriber figures and the traffic call model. It may so
happen that there is no homogeneous traffic model across different MSC in the network. This
does 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 traffic
planning 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 many
POIs are provisioned for National and International calls etc. Traffic dissemination in each node
is computed at this stage and a separate traffic distribution for the MSC under consideration
might 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 make
assumptions about the traffic flows in the network and document them. It is important to know
that any parameters changed after assumption have a direct impact on the designing exercise
output, hence it is important to record the assumption to establish the reference frame. Based
on extrapolation of different call scenarios (m2m, m2p, p2m, p2p etc) applicable for the MSC
under consideration, the following detail may be arrived at,

To
From
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



_______________________________________________________________________________________________

___________________________________________________________________________________________

POI 1
POI 2
MSS 2
VMS 1
MSS 1
BSC 1
BSC 2

3.5.3. NETWORK WIDE TRAFFIC MATRIX
Based on above traffic planning results for the individual MSCs it will be possible to extrapolate
all 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 core
designing 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 transit
MSCs TMSC may not to be considered here as they fulfil routing functions only. For a small
network consisting of 2 MSCs and 2 POI elements, the logical traffic flow may be calculated as
follows. Note that some arrows are bi-directional, implying traffic summed up both ways etc.

To
From
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 with
detailed calculation

Author : Page 32



_______________________________________________________________________________________________

___________________________________________________________________________________________
The above matrix is the result of this planning step and is the base for the subsequent traffic
routing exercise. The individual traffic shares for MOC, MTC etc can be recognised in this table:
traffic between MSCs must be MMC traffic, traffic from PSTN to MSC must be MTC etc.

End to End Traffic Flow

POI 1
POI 2
MSS 2
VMS 1
MSS 1
BSC 1
BSC 2

3.5.4. TRAFFIC ROUTING AND NETWORK TOPOLOGY
Traffic Matrix once arrived, the volume of traffic between different nodes becomes evident. Next
is the routing process to decide on the route to be taken for these traffic relationships. During
this step decision on network element structure as well as transmission bandwidth needed
between them is evaluated. The logical fully meshed end-to-end traffic matrix is to be mapped
on the physical network structure and decision on which specific paths are available for each
specific end-to-end traffic relationship are considered. Traffic might either be routed directly or
using other nodes as relay points. Aspects like load sharing and redundancy are to be regarded
here as they directly influence the traffic on individual trunks. Different traffic portions belonging
to different end-to-end connections will share the same trunks and will compete there for
resources. Therefore they need to be treated together for dimensioning. This is also very
important as different traffic portions sharing the same lines will lead to a higher traffic
multiplexing gain on the trunks. These aggregated values can then be used to determine the

Author : Page 33



_______________________________________________________________________________________________

___________________________________________________________________________________________
needed bandwidths between the different network elements. The traffic in the end-to-end matrix
needs 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 network
structure. If further elements such as Gateway MSCs or Transit/tandem MSCs are to be used in
the network, they have to be added to the matrix and have to appear as well. Retaining the
example from the traffic planning, the possible routing results could look as follows.

Network Topology

POI 1 POI 2
GMSS
2
GMSS
1
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 traffic
which 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 fact
which node sends or receives the traffic. Thus the traffic between two nodes can be summed up
as follows,

Author : Page 34



_______________________________________________________________________________________________

___________________________________________________________________________________________

To
From
MSC 1 MSC 2 POI 1 POI 2 VMS 1 BSC 1 BSC 2 GMSS 1 GMSS 2
MSC 1 18 62 85 95.5 95.5
MSC 2 75 75
POI 1 67.5 67.5
POI 2 100 100
VMS 1 15 15
BSC 1
BSC 2
GMSS 1
GMSS 2

MSC1 sends the entire traffic towards the Gateways, except the m2m traffic. Thus the traffic per
Gateway must be equal to 50% of the rest, which is 32 Erlang to POI1, 42 Erlang to POI2, 10
Erlang to VMS, 32 Erlang from POI1, 76 Erlang from POI2. Thus the traffic is
50%*(32+42+10+32+76) = 95.5 Erlang. In this matrix it is no longer possible to identify the
individual traffic shares. This matrix shows now the traffic per connection and is the input for the
link dimensioning. If there are several services in the network, this matrix needs to be
individually determined for each service.
3.5.5. SIGNALLING NETWORK PLANNING
After the arriving at the network wide traffic matrix, it is now necessary to consider signalling
traffic. This is necessary as this traffic shares resources with the payload and hence needed to
be accorded high priority. Also signalling planning involves planning the SS7 network elements
such as STP, SCP, HLR, IN, SMSC etc. Due consideration has to be accorded to all the different
types of signalling traffic that flows in a signalling link and typically it is a very detailed exercise
involving processing of a numerous inputs. However there are rules of thumb available that is
fairly accurate which may be used as not all the inputs are not available at the design stage.
These traffic types are also described by their own traffic matrices following the same pattern as
above. Signalling bandwidth demand needs to be added to the previously determined payload
bandwidth if the same media is to be used for carrying signalling as well as payload traffic.
Normally the signalling demand is derived from indicators such as traffic per link or number of
trunks per signalling link etc.
3.5.6. LINK DIMENSIONING
Link dimensioning pertains to provisioning enough bandwidth to carry the traffic per route as
determined in the preceding step. The bandwidth dimensioning can be done using Erlang's
theories. Standard Erlang B tables are used for this purpose when it involves lost-call-scenario
which is normal in PSTN/PLMN networks. A further input for the dimensioning is the maximum
allowable blocking probability P, which normally should be a very low value (0,1% or 0,01%) as a
high quality network operation is desired as shown below,

Author : Page 35



_______________________________________________________________________________________________

___________________________________________________________________________________________
75 73 72 71 69 68 66 64 62 59
73 72 71 70 68 67 65 63 61 58
72 71 70 69 67 66 64 62 60 57
71 70 69 67 66 65 63 61 59 56
70 69 68 66 65 64 62 60 58 55
69 68 67 65 64 63 61 59 57 54
68 67 66 64 63 62 60 58 56 53
67 66 65 63 62 61 59 57 55 52
66 65 63 62 61 60 58 56 54 52
65 64 62 61 60 59 57 55 53 51
64 63 61 60 59 58 56 54 52 50
63 61 60 59 58 57 55 54 52 49
61 60 59 58 57 56 54 53 51 48

77 75 74 73 71 70 68 66 64 61 75
74
73
72
71
70
69
68
67
66
65
64
63
62
61
0.1 0.09 0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01

76 74 73 72 70 69 67 65 63 60
Dimensioning needs to be done path-wise. As an output one obtains either the number of traffic
channel 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 finally
possible to determine the number of E1/T1 links between the sites. Therefore one has to
compare the bandwidth demand between the sites with the required capacity of a specific node
connection.
4. NETWORK TOPOLOGIES
4.1. TYPICAL TOPOLOGIES
Network topology broadly combines two distinct topologies viz., the bearer topology and the
signalling topology. Network Topology mainly refers to the way bearer traffic flows in the
network as it determines the scale of economies underlying the overall network architecture.
Nevertheless signalling topology is also important in view of fault alleviation, disaster
management, redundancy requirements that is demanded by newly emerging networks.

Author : Page 36



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 need
to be considered. Typical topologies that are used in the Telecom network domains are Star
topology, Mesh topology, Pyramid, Double Pyramid topology and Hybrid structures. Represented
figuratively 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
MS
C
GMSC Tandem
Double Pyramid Topology

Star topology is rarely used in telecom domains due to its inability to be fault resilient which is
critical decision altering factor to determine the topology. Any failure in any link will isolate the
node and therefore is not a good solution. Mesh topology on the other hand evolves through a
ring 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 congregate
as much traffic as possible from all possible call originating sources, but this traffic need to be
quickly disseminated out of the core network as soon as the routing design permits. This is so as
to reduce the wastage of valuable call processing capability of various nodes in the network as
well 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 most
optimal solution. Mesh topology is fault resilient and any failure of transmission link does not
isolate 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 the
deployments 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 Pyramid
architectures. In Pyramid architecture, the Gateway MSC is at the top of the pyramid and is

Author : Page 37



_______________________________________________________________________________________________

___________________________________________________________________________________________
responsible for interconnecting this PLMN with other PLMN as well as PSTN networks. There are
a 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 Tandem
MSC is very high and can cater to higher capacity networks. All the outgoing traffic from the
PLMN is routed through Tandem whereas all Incoming traffic from external networks is routed
through Gateway MSC. The disadvantage of this design is that it becomes prohibitive in cost and
is justifiable only in high capacity networks. Many an instance these perfect architectures are not
realised due to limitations of trunking resource availability/connectivity and a hybrid of these
topologies 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 of
operators. Networking issues and transmission design to cater to this multi city environment
requires adequate planning and preparation.
City A Link l, Traffic = 2yeab/
Traffic = 2yeac/
o
p
q
m
n
City B
City C City D

Shown above is a typical instance of four cities interlinked with each other. Based on degree of
affinity, 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. Traffic
between any two nodes is calculated and as an example in link l ie., between City A and City B it
is 2yeab/ where y is intercity m2m traffic, e is Erl/subs, a is City A mobile population and b is
City B mobile population, is sum of all subscribers. This traffic is shown figuratively as directly
flowing between A and B, but it may not be so due to Transmission facility availability and may
have 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 to
unnecessarily load the intermediate switch. Depending on alternate route availability, there may
be 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. Based
on the cost structure, a weighted average determines the percentage distribution of traffic
through these alternate paths.

Author : Page 38



_______________________________________________________________________________________________

___________________________________________________________________________________________
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 the
signalling path is kept distinctly different from the bearer path to capitalise on bandwidth
advantages obtained by delinking signalling from the bearer path. This requires therefore to
construct an overlay network capable of handling signalling and the fundamental network
element in this layer is Signalling Transfer Point this plane of Network is also termed as the
Control Plane (vis a vis the User Plane which signifies the Bearer path). In addition to routing
signalling between MSCs and PLMNs, STP is used to provide connectivity to databases such as
HLR, EIR, AUC, IN etc. From a network perspective following are the reasons for implementing
STP,
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 well
as itself being made available to all NEs within that domain (eg., Missed Call Alert
system), thereby easing introduction of new services
STPs act as the signalling gateways to the interface to the other domains be it TDM to
IP or PLMN to PSTN or PLMN to Other PLMNs etc.
STP in its functional capacity as border gateway network element implements Global
Title Translation functionality obviating the need to have extensive routing database to
be 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 subscribers
roaming in other PLMNs
STP functionality has enhanced due to advances in transport layer technologies as detailed earlier
and 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 any
one STP does not affect the healthy functioning of the network. Topologically therefore for the
signalling network, Star Topology is used due to the availability of redundant nodes. Typical STP
configuration is shown as below,

Author : Page 39



_______________________________________________________________________________________________

___________________________________________________________________________________________
STP/
SGW
STP/
SGW

MSC MSC MSC
HLR
HLR
in
IN
SMSC LBS
MCA OTA
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 in
defining the network architecture as well as links interconnecting different NEs within this new
architecture. Notably 2 standards organisation viz., 3GPP and 3GPP2 have been defining this for
the UMTS market and CDMA market respectively. As shown in the figure below, network
architecture evolved with the release of new specifications from R96 to R99 with the inclusion of
Location based service offerings (R98) and IN services, UTRAN (in R99) etc.

Author : Page 40



_______________________________________________________________________________________________

___________________________________________________________________________________________
VLR
MSC VLR

BSC

HLR

A i/f
B i/f
C i/f
D i/f
MSC
E i/f

EIR

F i/f
MSC
VLR
G i/f

AuC
H i/f
Gs i/f

SGSN

Gr i/f

GMLC

Lg i/f
Ls i/f
Lh i/f
Lb i/f
R98
R96, R97
CAP i/f

CAMEL

UTRAN

IuCS
i/f

CBC

IuBC i/f
R99

SMLC

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

Shown below, an extract from the Network architecture specification 23.002 480 of Rel04
standards that highlights the Core Network elements and their interfaces. As can be seen new
interfaces 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 uses
MGCP or MEGACO protocol for MSC server to control the functioning of MGW. MSC MSC
interface earlier used standard ISUP to carry MAP traffic, had to be revised with Nc interface to
carry BICC signalling. Similarly MGW MGW interface, Nb, though shown as a direct interaction
between the two entities, in reality is implemented through Mc Nc interface as discussed
earlier.

Author : Page 41



_______________________________________________________________________________________________

___________________________________________________________________________________________

BSS
BSC
RNS
RNC
CN
Node B Node B
IuPS
Iur
Iub
USIM
ME
MS
Cu
Uu
MSC server
SGSN
Gs
GGSN GMSC
server
Gn
HLR
Gr
Gc
C
D
Nc
H
EIR
F Gf
Gi
PSTN
IuCS
VLR
B
Gp
VLR
G
BTS BTS
Um
RNC
Abis
SIM
SIM-ME i/f or
MSC server
B
PSTN
cell
CS-MGW CS-MGW
CS-
MGW
AuC
Nb
Mc
Mc
Nb
PSTN PSTN
Nc
Mc
A
Gb
E

NGN Architecture Rel 04 heralding split between Call control
and Media handling functions

Author : Page 42



_______________________________________________________________________________________________

___________________________________________________________________________________________
4.3. MSS ARCHITECTURES
4.3.1. MSS CARD AND CHASIS MODULARITY
MSS has a flexible architecture that allows innovative configurations which provide cost-effective
solutions to the operators. Personnel involved in core network architecture will understand that
one of the primary reasons for escalating costs of core network is the inability to scale the size of
MSC based on demand. Fundamental design issues crop up when all the traffic cannot be
handled by one MSC and needs multiple MSCs. The resources consumed for handling inter-MSC
calls becomes prohibitively high when the number of MSCs increases. MSS has one of the best
scalable architecture available in the market today. MSS capacity can be augmented by simple
addition of CPU cards running the desired process till all the slots available in a chasis are
exhausted. If the MSS capacity has to be augmented beyond a chasis, additional control chasis
shelf which can accommodate additional cards can be engineered - modularly expanding the
capacity of the system. Currently MSS supports upto 2 control chasis stacked together.
4.3.2. MSS WITH MULTIPLE MEDIAGATEWAYS
MSS handles the bearer traffic through media gateways and any media gateway that supports
MGCP can interwork with MSS seamlessly. Motorolas prefered mediagateways are Motorola
Mediagateway, Audiocode Mediagateway, Sonus Mediagateway. These mediagateways may be

located locally as shown above or remotely as below,

When multiple media gateways are involved, provision has to be made to address traffic flow
between the media gateways. There are 2 methods viz., Local trunks configured between these
two MGW, or using GigE RTP voice streams to transport bearer from one MGW to MSS followed
by MSS to the other MGW. Providing local trunks reduces the bandwidth availability on the MGW
and calls for additional resources such as E1/T1 interface cards, transmission availability etc.

Author : Page 43



_______________________________________________________________________________________________

___________________________________________________________________________________________
Also if the number of MGW exceeds 2, then a matrix of local trunks need to be provisioned for,
all of which results in sub-optimal utilisation of available switching/MGW/transmission resources
as highlighted below.
Mesh Configuration of Local Trunks

MSS 1
MGW
3
MGW
1
MGW
2
Mesh Configuration of
Local Trunks
MGCP Control & Management only
TDM for Bearer

On the other hand GigE solution is more acceptable when the number of MGW exceeds 2, as
these MGWs can interwork in a star configuration as against mesh configuration in the previous
case. Also in this case any future additions of MGW can happen seamlessly without affecting the
existing configuration. Decision regarding provisioning one of the two methods would depend on
if these MGWs are located remotely or locally as also the proximity of these MGWs and
availability of IP bandwidth etc.

Author : Page 44



_______________________________________________________________________________________________

___________________________________________________________________________________________

Star Configuration of Local trunks realised through GigE RTP bearer

MSS 1
MGW
3
MGW
1
MGW
2
Star Configuration of
Local Trunks realised
through GigE
MGCP Control & Management only
GigE for Bearer

4.3.3. MSS WITH REMOTE MEDIAGATEWAY
In case of MSS connected to MGW remotely, there are significant bandwidth gain vis a vis the
Legacy solution. In Legacy solution, there are remote concentration units or remote line units
which performs similar functions, but in all those solutions, the bearer traffic has to be brought to
the centrally located MSC, as call control, switching crosspoint and the associated CDR
generation, is performed in this location. Softswitch solution specifically adds value in this
scenario with the use of Remote MGW. In this instance, as against the legacy solution, the
bearer path need not be extended all the way to the MSS since the control and the bearer have
been clearly demarcated and seperated right from the conceptualisation stage. Hence only the
control part or the MGCP signalling bandwidth need to be provisioned for while designing for
Remote MGW. Only in instances when media mixing has to be performed in control chasis, the
bearer needs to be brought to the control chasis and the engineering detail of the IP bandwidth
requirement etc needed for this purpose is documented in MSS System Resource Guide
maintained at http://compass.mot.com/go/136985679 .

While provisioning for Remote MGW, as a rule of thumb, the total size of MGCP or MEGACO
signaling messages in each direction for a typical call scenario is 16KB. Using this information,
the bandwidth requirements for the signaling path between the Control Switch and the MGW are
determined by multiplying the bandwidth requirements per call (16KB) times the call rate.
Because MGWs are typically sized in terms of Erlangs of traffic, the call rate can be specified as:

Call Rate = Erlangs / Average Call Hold Time

Using this value, the bandwidth needed is then:
Signaling BW (kbps) = 16KB per call * (Erlangs / Average CHT)

Author : Page 45



_______________________________________________________________________________________________

___________________________________________________________________________________________

Example of Remote Media Gateway Configuration

Author : Page 46



_______________________________________________________________________________________________

___________________________________________________________________________________________
5. ENGINEERING NETWORK ELEMENTS
In real life situations such detail of traffic discrimination as highlighted previously is hardly
available and basic call models are provided as inputs. Based on the call model, transmission or
link dimensioning exercise is taken up.

Traffic Call Model
Interface
Dimensioning
Hardware
Dimensioning
Software
Requirements
Spare
Requirements
Bill of
Material
Typical Core Network Design Process
5.1. TRAFFIC CALL MODEL
Traffic call models provided by different operators are different from each other and no standard
model is followed universally. Accordingly, there may be more inputs than what might be
required (rarely) or less inputs than what is needed (most often). Considered decisions need to
be adopted in instances when insufficient information is available and standard call models as
adopted by Motorola may be used as reference for the purposes of computation and customer
signoff on the assumptions may be secured.

Author : Page 47



_______________________________________________________________________________________________

___________________________________________________________________________________________

Traffic Ratio
M 2 M
Intra 10%
Inter 10%
M 2 L 40%
L 2 M 40%

GOS
Um/Uu 1.00%
A/IuCS 0.10%
PSTN 1.00%
Other interfaces 1.00%
PLMN 1.00%
Data 1.00%

Traffic Defaults
Avg. Traffic per subs 25 mE
Total Traffic 7500
VLR Capacity 300,000
Avg. HT per subs 90 s
Avg. BHCA per Subs 1
SMS Subs 100%
Msg/day/user 4
BHSM 240000
IN Subs 70%
Avg. Traffic per subs 25 mE
IN Subs Total 210000

Default Utilisation factors
E1 Traffic factor 0.8
ATM Traffic factor 0.8
IP Traffic factor 0.3
Traffic Load per SS7 link 0.2

Author : Page 48



_______________________________________________________________________________________________

___________________________________________________________________________________________
Reference Network Diagram for Capacity Calculations

HLR/
AuC/
MSS 1
MSS 2
VMS 1
BSS 1 BSS 2
POI 1
SCP SMSC SGSN
EIR

5.2. INTERFACE DIMENSIONING
Transmission or link dimensioning involves two aspects viz., the bearer path dimensioning and
signalling link dimensioning. For the bearer path dimensioning there are basically two methods
available and the first one is based on the use of Erlang B tables (needs Grade of Service and
Total traffic in Erlangs as input) while the second one is based on the utilisation ratio of the
trunks provisioned (such as 80% etc). Based on the above default values and the reference
network diagram the dimensioning of all the transmission links follows (replace 30 with 24 at all
instances where E1 basis is to be substituted with T1 calculations).

In case of signalling links as the load distribution of signalling traffic is on the basis of SLS bit
which distributes traffic among all the provisioned links. Hence the signalling links have to be
provisioned as per the formula
Number of signalling links = 2
n
Where n can have value from 1 to 4 (indicating the 4 bits in SLS field). This implies the number
of signalling links have to be either 2 or 4 or 8 or 16 in order to ensure even distribution of traffic
among the links as well as to ensure proper traffic reallocation in case of any link failures etc. All
the indicative formulae furnished hereunder follows MS Excel formats.

Signalling links are of different types viz., LSL or Low Speed Links (64 kbps or 56 kbps as the
case may be), HSL or High Speed Links (2 M or 1.5 M depending on the market) or Sigtran links
(IP FE type links). While engineering signalling link requirement for a particular application, it
is typically estimated as x number of LSLs which is later extrapolated into HSLs or Sigtran
based on the field conditions as required. Conversion methodology employed to calculate the

Author : Page 49



_______________________________________________________________________________________________

___________________________________________________________________________________________
equivalence of LSL, HSL and Sigtran varies based on the vendor. In case of Huawei, following
applies,
HSL interface card capability - 12.6 Erl
With 1:1 redundancy, capability - 6.3 Erl
LSL Erlangs with redundancy - 0.4 Erl (varies on market reqmnt)
16 LSL/ HSL ~ HSL Equivalence in LSL - 6.2/0.4

Similarly in case of Sigtran links,

Sigtran interface card capability - 1280 MSUs/sec (varies with Vendor spec.)
Assumed average MSU size - 100 Octets (varies with signalling application)
LSL capability @ 0.4 Erl/LSL - 64000 *0.4/8 - 3200 Octets/sec
Above expressed in MSUs - 3200/100 - 32 MSUs/LSL
Sigtran equivalence in LSL - 1280/32 - 40 LSL/Sigtran
20 LSL/ Sigtran Considering 1:1 redundancy - 40/2 -
5.2.1.1. MSC to BSS Link This link dimensioning pertains to A interface and
transmission needs for this interface involves consideration to both the
bearer and signalling traffic requirements. As a thumb rule since just one
messaging link is enough to cater to about 900 trunks or 30 E1s, the
bandwidth requirement for signalling is insignificant in comparison to
bearer transmission requirement (ie., one time slot for 30 E1s) hence
separate computation is not shown and is assumed incorporated in the
overall transmission need as calculated below,

IuCS Dimensioning involves providing ATM interface ie., 155 Mbps if BSS
also supports UTRAN ATM interface.

Iu
ATM
= Roundup((Total_UTRAN1_CS_traffic in Mbps)/155 * 0.8)

A Interface typically involves provisioning at least 2 E1s to carry bearer
and signalling traffic with 2 messaging links distributed across each E1 /
T1 etc. In case of Erlang B table method of computation for deriving
transmission need,

A
E1
= Roundup(ErlangB(Total_CS_traffic in Erlangs, Blocking
probability)/30)

In cases involving utilisation factor, such as 0.8,

A
E1
= Roundup(Total_CS_traffic in Erlangs/0.8/30)

Octet Method:

Depending on the type of BSC such as 2/2.5G BSC which carries BSSAP
messages or 3G UTRAN which carries RANAP messages, dimensioning of
interfaces follows as below,

Author : Page 50



_______________________________________________________________________________________________

___________________________________________________________________________________________
LSL/ HSL for BSSAP dimensioning

Average BSSAP message size = 80 octets
Overheads MTP3/MTP2 = 14 octets
(Breakup details of MTP3/MTP2 overhead MTP2 Overhead = 6 Octets,
MTP3 Overhead = 8 Octets)
Total Octets = 94 octets
Average number of msgs/call = 10
Link load = 0.3
= BSSAP BSSAP
BHCA ERL
/Av. CHT

LSL
BSSAP
= Max (Roundup((BSSAP
BHCA
* 94 * 10 * 8)/(3600 * 64 * 0.3 *
1024),0),2)

Similarly for HSL,

HSL
BSSAP
= Max(Roundup(LSL
BSSAP
/16,0),2)

ATM dimensioning to cater to RANAP traffic,

Average RANAP message size = 100 octets
Overheads ATM = 36 octets
Link load = 0.3
= RANAP RANAP
BHCA ERL
/Av. CHT

ATM
RANAP
= (RANAP
BHCA
* 136 * 15 * 8)/(3600 * 0.3 * 1024 * 1024) Mbps

User Plane Traffic Dimensioning:

On the User plane, traffic is carried as 12.2 K encoded voice which is
transcoded in MGW or passed without transcoding as in case of TFO or
TrFO scenarios. This 12.2 K voice requires a bandwidth of 22 kbps due to
ATM overheads.

Erlangs on IuCS interface = RANAP
ERL
ATM Bandwidth reqmnt = Roundup(RANAP
ERL
* 22 /
1024,2) Mbps

5.2.1.2. MSS to HLR Link C interface computation involves evaluation of just
the signalling bandwidth requirement. Exact computation method will
involve computing the transactions per second that will be exchanged
with the HLR for the market of deployment which would in turn need a
number of inputs such as how frequently location updates occur, whether
authentication is supported, how many SRIs can be expected from SMSC,
how often IMEI check is conducted etc. These details may not be

Author : Page 51



_______________________________________________________________________________________________

___________________________________________________________________________________________
available at the design stage and hence typical rule of thumb is used in
this case. Rule of thumb for HLR queries is that for every 20K
subscribers, 0.4 Erl of traffic is generated (Important : please note that
this rule of thumb does not include MNP-SRF, mobile number portability
signalling routing function, when performed by the HLR itself). On the
HLR side there is also a limitation to restrict the number of signalling links
to 8 per E1 with each signalling link engineered to carry 0.4 Erl of traffic
this is applicable to Apertio HLS, whereas other manufacturers may have
other specifics. There are other HLR manufacturers who recommend only
0.2 Erl of traffic per signalling link resulting from 10K subscriber count and
a limitation of just 4 links per E1. Once these limitations are understood,
depending on the HLR being considered for the proposal, the following
empirical formula may be used to adapt to the situation:

C
64K
= Max(Roundup(Number of subs block/Number of links per E1),2)

Number of subs block = Susbcriber count expressed in 10K (in case of
0.2 Erl/link) or 20K (in case of 0.4 Erl/link)
Number of links per E1 = 8 (In case of Apertio) or 4 (Depending on the
manufacturer specification)

Again it is pertinent to design at least 2 signalling links distributed over 2
E1s in case HLR is located in a distant location to secure redundancy
protection over media failures. Depending on the network architecture,
HLR interface may be extended through GMSC or directly from the
Serving MSC itself and this redundancy needs to be kept in mind from the
point where HLR is connected to the current PLMN.

In case of high capacity systems, instead of using 64 kbps signalling link,
there are manufacturers who support 2 Mbps signalling link (represented
as 2M signalling link), but the ground rules remain the same as only the
bandwidth for one signalling link now goes up. Care is again taken to
ensure that at least 2 x 2M link is provided for redundacy purposes.

C
2M
= Max(Roundup(Number of subs block/32),2)

Octet Method:

Bulk of traffic to HLR primarily results on account of call attempts from
subscribers or BHCA attempts.
BHCA Attempts/subs = x attempts/hr
Total subscriber count = n subscribers
Average Octet size per MAP transaction = 300 Octets
Octet messages handled per sec = x * n * 300 / 3600
LSL capacity at 40 % loading (octet/sec) = 8000 * 0.4 = 3200
Number of LSLs required = x*n* 300 / 3600 / 3200

C
LSL
= Max(Roundup(x*n* 300/3600/3200),2)

Author : Page 52



_______________________________________________________________________________________________

___________________________________________________________________________________________
5.2.1.3. Inter MSC E Interface exists between MSC to MSC within the same
PLMN. Traffic that flows in this link includes Inter MSC handover, M2m
calls for call termination (here it is assumed that there is an underlying
mesh network to interconnect serving MSCs within PLMN). There could
be other type of traffic that flows in this interface depending on the
network architecture and a proper evaluation of the traffic in Erlangs need
to be arrived at (as highlighted in the Section 3.4) before the transmission
media requirement is estimated as below. In addition to the bearer traffic
that flows between the MSCs there is also signalling relation that exists
between these MSCs that handle E interface messages as well as ISUP
call termination messages.

Bearer capacity using Erlang B Formula,

E
E1
= Roundup(ErlangB(Inter_MSC_Traffic, GOS)/30)

Bearer capacity using Trunk utilisation factor (say 0.8),

E
E1
= Roundup(Inter_MSC_Traffic/30/0.8)

64K Signalling link requirement for the E link calculation depends on the
fact that at least 2 links are needed and one signalling link catering to
every 1000 trunks generates 0.4 erl traffic (thumb rule). Incorporating
those cases that might need different link loading (ie., other than 0.4
erl/link) the formula as below,

E
64K
= Max(Roundup((E
E1
*30/1000)*(0.4/Load_per_SS7link)),2)

Similarly for 2M signalling link (very rare !!)

E
2M
= Max(Roundup((E
E1
*30/1000/32)*(0.4/Load_per_SS7link)),2)

In addition to the above there are instances when we may have to route
the traffic through IP cloud using Fast Ethernet. In these instances please
note that there is an IP Transmission Efficiency factor which is much
lower, say 0.3, as compared to TDM trunk efficiency factor which is
typically maintained at 0.8. On the other hand there is a compression
efficiency obtained in bearer compression called Efficiency factor which is
missing in traditional TDM method of transmission. Computationally to
calculate the FE requirement,
E
FE
=
Roundup(Inter_MSC_Traffic_in_Mb*EfficientFactor/100/IPEfficiencyfactor)

If ATM is used to carry this traffic then

E
ATM
=
Roundup(Inter_MSC_Traffic_in_Mb*EfficientFactor/155/ATMEfficiencyfact
or)

Author : Page 53



_______________________________________________________________________________________________

___________________________________________________________________________________________

In case of Rel 04 with MSC Server and MGW architecture employing IP
transmission facility control plane for inter MSC traffic employs M3UA
(including MSC <-> GMSC interface) signalling ie., the Nc interface and
the dimensioning shall follow as below,

BHCA attempts on inter MSC link = N
cBHCA
Average MSU size at application layer (BICC) = 150 Octets
M3UA Overhead = 35 Octets
SCTP Overhead = 48 Octets
IP Overhead = 20 Octets
Number of messages on average per call = 7

Bearer capacity required to cater to signalling traffic with 0.3 link load,

N
c
= Roundup((N
cBHCA
* 253 * 8 * 7)/(3600 * 0.3 * 1024 * 1024),0)
Mbps
Similarly user plane traffic signified by N
b
interface when implemented
on IP transport has its advantages and disadvantages due to voice
compression as discussed earlier. When implemented without voice
compression the following is applicable,
Bearer traffic = 64 kbps
IP Overhead on packetisation = 31.2 kbps
Voice Activity Detection factor = 50 %
Bandwidth required per call = (64 + 31.2) * 50% = 47.6 kbps
Inter MSC MGW traffic on IP = x %
MGW Erlangs = MGW
erl

N
b
= Roundup((MGW
erl
* x % * 47.6)/1024) Mbps
5.2.1.4. MSC EIR Link MSS to EIR link is called the F link that carry just the
signalling information to perform the equipment identity check and ensure
that the mobile does not feature in the black list or grey list etc. Apertio
HLS has capability to function additioinally as EIR and capacity calculation
for HLR may be used for this purpose as well.

F
64K
= Max(Roundup(Number of subs block/Number of links per E1,0),2)
5.2.1.5. MSC SGSN Link The interface that exists between MSS and SGSN is
the Gs interface and carries only signalling information needed by SGSN
on the current location details of the mobile as well as page request
message from MSS to SGSN. Assumes accomodating 4 signalling links to
SGSN on one E1 (to be confirmed with the manufacturer of SGSN). Also
minimum of 2 E1 links are needed to provide for failsafe redundancy,

G
S64K
= Max(Roundup(NumberOfSignalLinks/4),2)

Author : Page 54



_______________________________________________________________________________________________

___________________________________________________________________________________________
Where,
NumberOfSignalLinks =
Roundup((3G_Subs+2.5G_Subs_block)/9.6/2,0)*2

and subs_ block is 10K subscribers.
5.2.1.6. MSC SMSC Dimensioning - Value added services such as SMS and MSS
are interconnected using the H interface and only signalling information
is exchanged between the entities that carries the SMS messages. Traffic
contributed by the SMS messages depends on the average length of the
messages which may not be immediately available and hence thumb rules
are followed. The SMS traffic is typically measured as BHSM or Busy Hour
Short Messages and based on the market, an average of about 40K to
48K BHSMs generate about 0.4 Erl of traffic, accordingly the SS7 links are
calculated as below, subject to a minimum condition of 2 E1 links. Also
the number of signalling links per E1 varies from manufacturer to
manufacturer. Also, designer needs to keep in mind if the SMS server is
remotely connected and based on that make a considered decision on the
number of signalling links to be accomodated in an E1 to safegaurd
against media failures. Following assumes 4 signalling links may be
accomodated in 1 E1,

H
64K
= Max(Roundup(NumberOfSignalLinks/4,0),2)

Where the number of signal links is calculated on the 48K BHSM basis as
below,

NumberOfSignalLinks = Roundup(BHSM/48,0)

Where BHSM is expressed in 1000s of SMS

Octet Method:

SMS traffic calculation is typically split into SMS-MO and SMS-MT traffic
because the path followed by SMS on Origination leg is different from path
taken by SMS on Termination leg. Whereas SMS-MO is forwarded by the
received MSC to the target SMSC (may be through STP), SMS MT
results in MAP query to HLR for locating the terminating mobile before
SMS is forwarded to the destined mobile. This results in varying traffic on
various legs of the network as shown in the figure below.

SMS-MO Calculation:

MSC <->SGW/STP

BHSM per subscriber = x BHSM/Sub/hr
Number of subscribers = n Subscribers
Total BHSM of subs/sec = x * n / 3600 BHSM/sec
Av. size of SMS msg = 200 Octets (varies with market)

Author : Page 55



_______________________________________________________________________________________________

___________________________________________________________________________________________
SMS traffic/sec = 200 * x * n / 3600 Octets/sec
Expressed in LSL (@0.4) = 200*x*n / 3600 / 8000 / 0.4 LSL

* AvSMSsize/3600/8000/0.4,0),2) H
LSL
= Max(Roundup(Tot
BHSM

Above traffic calculation holds good for forward and reverse direction on
this leg

SMS-MT Calculation:

SGW <->SMSC

In addition to the traffic calculated above in the forward direction, there is
additional traffic in this leg of the traffic flow due to routing query to HLR.
Part of this traffic is diverted towards HLR by SGW and the remaining part
proceeds to the terminating MSC as shown in the diagram below,

STP STP
MSC
HLR
HLR
SMSC
BSC
SMS-MO
200 Octets
SMS-MO
200 Octets
Routing Query
SMS-MT
150 Octets
SMS-MT
200 Octets
SMS-MT
200 +150 Octets
Routing Query response
SMS-MT
150 Octets

Author : Page 56



_______________________________________________________________________________________________

___________________________________________________________________________________________

As above,

SMS Route query size = 150 Octets
Traffic expressed in LSL = (200+150)*x*n / 3600 / 8000 / 0.4 LSL

SGW <->HLR (for SMS traffic only)

Traffic in the forward and reverse direction of this link remains the same
and is arrived at as below,

SMS Route query size = 150 Octets
Traffic expressed in LSL = 150*x*n / 3600 / 8000 / 0.4 LSL

5.2.1.7. MSC SCP Dimensioning SCP or Service Control Platform is connected
to MSC through an L interface. SCP is typically a database where a
number of service logics are performed and implemented to cater to
intelligent network services. Services such as Prepaid, Closed User Group,
Virtual Private Number, Follow on service, Home zone billing, USSD
services, Voucher redemption and a number of other services could be
implemented and provided by the operator. GSM uses Camel Service
Environment or CSE which functions as SCP and uses CAP (Camel
Application Protocol) whereas CDMA uses WINCAP protocol to interact
with IN Server. IN traffic calculation is very sensitive to the services
hosted and this needs to be kept in mind while actually provisioning the
number of links. As an example for a sample system with 300K subs with
70 % IN subscribers ie., 210000 IN subscribers at 1 BHCA would generate
3.89 Erl of traffic (just for pure MO call scenario). This traffic will increase
as the number of services supported increases as well as subscription to
those services change. INS palettes are available that compartmentalise
different services and the transaction per second(TPS) each of them
entails. Empirical formulas that may be used as below,

L
E1

where,

NumberOfSignalLinks = Roundup((TrafficOfCAPs)/(LoadPerSS7*8000)
TrafficOfCAPs = NumberOfCAPs*NumberOfTCAPs*LengthOfTCAPs (in
bytes)

Elaborating Above:

In case of IN in GSM/UMTS markets, proper estimation of BHCA needs to
be arrived at and usually is higher than BHCA for a voice call. This is due
to the fact that there are additional attempts due to SMS, Data calls and

Author : Page 57



_______________________________________________________________________________________________

___________________________________________________________________________________________
other services hosted by the IN platform. The traffic estimated here is
routed between MSC and IN platform either directly or through STP/SGW.

BHCA for Voice Call = x
SMS-MO + SMS MT = y
Other Data services etc = z
Total BHCA = (x+y+z) - (Typically if x=3, x+y+z =
4.2)
Number of Subs = n
Total BHCA = (x+y+z) * n = Tot
BHCA
Av. No. of Txn per call = 4
Av. Transaction size = 124 octets
* 4 * 124 /3600/8000/0.4 LSLs Traffic expressed in LSL = Tot
BHCA

L
LSL
= Max(Roundup(Tot
BHCA
* 4 * 124 /3600/8000/0.4,0),2)
5.2.1.8. MSC PSTN Dimensioning PSTN interface is the Points of Interconnect
with the system. Traffic that flows in this interface is both the bearer
traffic as well as the signalling traffic. Based on the traffic matrix arrived
at (as highlighted in Section 3.4), in the earlier stage, we will have the
number of Erlangs for which the transmission medium needs to be
provided for.

Bearer capacity using Erlang B Formula,

E
E1
= Roundup(ErlangB(PSTN_Traffic, GOS)/30)

Bearer capacity using Trunk utilisation factor (say 0.8),

E
E1
= Roundup(PSTN_Traffic/30/0.8)

64K Signalling link requirement for this interface depends on the fact that
at least 2 links are needed and one signalling link can cater to every 1000
trunks generating 0.4 erl traffic (thumb rule). Incorporating those cases
that might need different link loading (ie., other than 0.4 erl/link) the
formula as below,

E
64K
= Max(Roundup((E
E1
*30/1000)*(0.4/Load_per_SS7link)),2)

Octet Method:

Calculation on the basis of ISUP octet size, as below:

Total BHCA = x * n = Tot
BHCA
Inter MSC call percent = p %
Av. ISUP txn. size = 150 octets
Number of Txns per call = 5

Author : Page 58



_______________________________________________________________________________________________

___________________________________________________________________________________________
Traffic expressed in LSL = Tot
BHCA
* p % * 150 *5/3600/8000/0.4
LSLs

E
LSL
= Max(Roundup(Tot
BHCA
* p * 150 * 5 / 3600 / 8000 /
0.4,0),2)
5.2.1.9. MSC PLMN Dimensioning PLMN interface dimensioning follows the
same principles as PSTN above. Once the traffic in Erlangs is estimated in
this interface, it is possible to arrive at the trunk capacity as well as the
signalling bandwidth requirements as above.
5.2.1.10.MSC MGW Dimensioning Mc interface is an IP interface that is
responsible for handling H.248 - MGCP/MEGACO messages that are
used to setup end points, add and remove connections. In addition to the
MGCP messages, if implemented to take care of signalling requirement of
Nb interface (information such as IP address, port number, RTP
compression etc is exchanged between the MGWs) which typically is the
case. Typically, the following messages are considered for the purpose of
calculation
Notify Request and Reply
AuditCapabilities and Reply
Add Request and Reply
Modify Request and Reply
Notify Request and Reply
Subtract Request and Reply
Average of 9 messages considered per call.
Average message size = 150 octets
Overheads UDP / IP = 103 Octets
(Breakup details of UDP/IP overhead SCTP Overhead = 48 Octets, IP
Overhead = 20 Octets, M3UA Overhead = 35 Octets)
Total Octets = 253
Link load = 0.3
BHCA for the calls hosted by a particular MGW = MG
BHCA
which can be
calculated as below,

= MG /Av. CHT or MG MG
BHCA ERL ERL
* BHCA per sub/Erl per Sub

IP Bandwidth required,

Mc = Rouondup (MG
BHCA
* 9 * 253 * 8)/(3600 * 0.3 * 1024 * 1024) Mbps

In addition to the above there are other signalling that happens between
MGW and MSC server viz., the M2UA links to carry BSS signalling (for
BSSAP and RANAP) and M2UA signalling to carry any ISUP traffic. Details
as below,

M2UA dimensioning to cater to ISUP traffic,

Author : Page 59



_______________________________________________________________________________________________

___________________________________________________________________________________________
Average ISUP message size = 100 octets
Overheads UDP/IP = 93 octets
Link load = 0.3
= ISUP ISUP
BHCA ERL
/Av. CHT

M2UA
ISUP
= Roundup(ISUP
BHCA
* 193 * 5 * 8)/(3600 * 0.3 * 1024 *
1024) Mbps

M2UA dimensioning to cater to BSSAP traffic,

Average BSSAP message size = 80 octets
Link load = 0.3
= BSSAP BSSAP
BHCA ERL
/Av. CHT

M2UA
BSSAP
= Roundup(BSSAP
BHCA
* 173 * 10 * 8)/(3600 * 0.3 * 1024 *
1024) Mbps

M2UA dimensioning to cater to RANAP traffic,

Average RANAP message size = 100 octets
Link load = 0.3
= RANAP RANAP
BHCA ERL
/Av. CHT

M2UA
RANAP
= Roundup(RANAP
BHCA
* 193 * 15 * 8)/(3600 * 0.3 * 1024 *
1024) Mbps

5.2.1.11.SMSC-HLR Dimensioning This interface caters primarily to route
query performed by SMSC to locate the terminating mobile location.
Details of this calculation is furnished earlier under MSC-SMSC
dimensioning.

Author : Page 60



_______________________________________________________________________________________________

___________________________________________________________________________________________
5.2.1.12.IN HLR Dimensioning This interface comes into existence if the
network has to comply with CAMEL Phase II and above. Functions like
USSD etc if supported by the operator, will require interface provisioning
between these two NEs.

5.2.1.13.SGSN HLR Dimensioning This interface Gr is used by SGSN to
obtain the subscriber details, authenticate, attach, purge etc. Majority of
the messages are Location Update message which are responded to by
the HLR with ISD data. Based on the subscription profile, this size could
vary but on an average 150 octets may be considered for every
transaction, accordingly,
Average Location Update message size = 150 octets
Number of Transactions per LU procedure = 4
Subscriber base of SGSN = N
SGSN
Frequency of LUs/hr = P
SGSN

Gr = (N * P * 150 * 4 * 8) / (3600 * 0.3 * 1024* 1024) Mbps
SGSN SGSN

5.2.1.14.MSC SGSN Dimensioning - Gs interface is used to exchange location
related information between SGSN and MSC/VLR. This interface may be
used to page the mobile through Packet interface enabling mobile to
monitor a single paging channel and conserving the battery life. This
interface is often not implemented.

5.2.1.15.SMSC SGSN Dimensioning Gd interface is established between
these two entities and it enables operators to deliver SMS messages
through Packet interface. MO SMS are sent as per mobile settings which
can be controlled through OTAPA (by the operator) if it will use the packet
channel to send SMS or circuit channel to route them. When a mobile
station is on GRPS mode all SMS are sent through the Gd interface.
Interface dimensioning for this interface will follow the same guideline as
in 5.2.1.6 MSC SMSC Dimensioning. Accordingly,
SGSN STP/SGW - SMSC,
G
d LSL
= Max(Roundup(Tot * AvSMSsize/3600/8000/0.4,0),2)
BHSM

5.2.1.16.MMSC HLR Dimensioning MMSC server interfaces with HLR for
route query as well as to find the SMS service centers of MT mobile (used
to send MMS notification through SMS message in instances when MMS
is not supported by the recipient mobile such as legacy mobiles). Route
query message size and dimensioning follows those detailed in Sec
5.2.1.6.
MMSC STP/SGW HLR dimensioning

MM = Max(Roundup (Tot * 150/3600/8000/0.4,0),2)
5 LSL BHMM

Author : Page 61



_______________________________________________________________________________________________

___________________________________________________________________________________________

5.2.1.17.MSC - MCA Dimensioning Missed Call Alert Server functions to alert
the subscribers of the missed call events due to their absence from RF
coverage area or power down condition. Typically the call is forwarded to
a voice mail system in the event of inability to reach the subscriber and if
the subscriber is not subscribed to voice mail services, then MCA server is
alerted about the call instance by sending IAM message, upon receipt of
which MCA server sends a REL message. This IAM message is used to
decode the originators identity and MCA server SMSs the Called party
about the missed call event. SMS server delivers the SMS as soon as the
called party registers on to the network again.

Average message size of IAM & REL = 100 octets
Total Busy Hr Missed Call Events = Tot
BHMCA

MSC MCA server LSL dimensioning,

MSC - MCA = Max(Roundup(Tot
LSL BHMCA
* 100 /3600 / 8000 / 0.3
, 0), 2 )

In addition to the above, for those subscribers who are subscribed to
Voice mail, the VMServer can outdial the called party and indicate
through CLI the missed call event. Dimensioning for provisioning, as
below,

Total Busy Hr Missed Call Events = Tot
BHMCA
Min Holding time for call to mature = HT
min
secs

Outdial Erlangs = Tot
BHMCA
* HT / 3600 Erl
min

5.2.1.18.Welcome Server Dimensioning Welcome server serves to welcome In
roamers and typically thank out roamers through SMS messages. In
addition, promotional campaign services are hosted for roamers through
this server. Typically probes are put up at DDF locations where signalling
messages are tapped and filtered to detect roamers and appropriate
messages are triggered by the server to be sent through SMS to reach the
roamers. Messages such as LU, CL, ISD, SRI
SM
, SRI
FORWARDSM
, SAI are
tapped and its dimesioning as below,

Average size of (LU +CL +ISD +SAI) * Tot +(SRI
BHLU SM
+
SRI
FORWARDSM
)* Tot
BHSM
= Tot
Avmsg
Total Roamers = Tot
Roam

Welcome Server LSL reqmnt
= Roundup(Tot
Avmsg
* Tot /3600 / 8000 / 0.3 , 0)
Roam

Author : Page 62



_______________________________________________________________________________________________

___________________________________________________________________________________________
5.2.1.19.HLR USSD Dimensioning USSD server is typically a part of IN
system which offers a number of Personalised services as well as the
popular Call back services. USSD messages when sent by prepaid
subscriber are received by Home HLR which in turn initiates dialogue with
USSD server to
SMS in case of call denial (lack of account balance etc)
Initiate Call back through Home MSC or
Initiate procedures for Personalised services

Dimensioning rules applicable for both the cases above presented as
below,

Average Message size of USSD message = 60 Octets
Total Busy Hour USSD requests = Tot
BHUSSD
(Callback +Personalised services)

HLR USSD = Max(Roundup(Tot * 60 / 3600 / 8000 / 0.3,
LSL BHUSSD
0),2)

To initiate Call Back, USSD server initiates call origination to both A party
(USSD Subscriber) and B party, resulting in 2 call legs for every USSD
call attempt.

Total Busy Hour USSD Call Back requests = Tot
BHUSSDCB
Above call back request results in call origination = 2 * Tot
BHUSSDCB
Average message size for call originations = 400 Octets

USSD MSC = Max(Roundup( 2 * Tot
LSL BHUSSDCB
* 400 / 3600 /
8000 / 0.3, 0), 2)

Author : Page 63



_______________________________________________________________________________________________

___________________________________________________________________________________________
5.3. STP/SGW DIMENSIONING
STP typically combines the functionality of Signalling Transfer point with that of Signalling
Gateway function required to interwork with IP transmission path of Control Plane. Based on the
signalling relation between various core network entities, STP is dimensioned. Guidelines for
using/not using STP for control plane signalling need to be taken based on the factors enlisted
earlier and the number of links to be routed between any two signalling network entities is filled
in as below for evaluating the interface needs of STP.

M
S
C

1
M
S
C

2
P
S
T
N
G
M
S
C
H
L
R
S
M
S
C
I
N
S
G
S
N
E
I
R
V
M
S
/
U
M
S
M
M
S
C
O
T
A
P
A
L
I
G
G
S
N
I
M
S
P
o
C
S
D
P
G
M
L
C
W
A
P
I
M
P
C
S
S
M
S
_
C
B
C
MSC 1
MSC 2
PSTN/PLMN
GMSC
HLR
SMSC
IN
SGSN
EIR
VMS/UMS
MMSC
OTAPA
LI
GGSN
IMS
PoC
SDP
GMLC
WAP
IMPCS
SMS_CBC

Many of the fields in the matrix above may have to be blanked out (in addition to those already
blanked out) depending on the signalling relation between the two NE concerned. Please note
there are various factors such as - vendor specific, solution offered, protocol version dependent
etc., that determine if a signalling relation exists or not. Once this table has been arrived at,
then all the entries involving a particular NE (such as green highlighted IN platform) is added up
to extend so many links from STP. This summed up quantity may be downward revised (by say
10%) due to consolidation efficiency.

Having arrived at the number of LSL equivalents that need to be extended to the STP for all the
NEs, following decisions have to be made and implemented,
Determination of NEs connection to STP

Author : Page 64



_______________________________________________________________________________________________

___________________________________________________________________________________________
o Distribution of links to be routed through STP vis a vis direct connection. For
example IP signalling points IPSPs may be load shared by the MSC itself
instead of routing through STP
Distribution of LSL equivalents
o LSL equivalent of a signalling relation may be distributed into LSL, HSL,
Sigtran links in the order of 25%, 25%, 50% depending on the quantity of
links
o As shown earlier,
1 HSL = 16 LSL
1 Sigtran = 20 LSL
Make provision for signalling relation with existing STPs P2P B/D links, say, 2 HSL
from each STP
Based on the above, quantity of LSL, HSL and Sigtran interfaces that need to be hosted by the
STP is calculated and STP is engineered from the vendor.
5.4. HARDWARE DIMENSIONING
Once the interfaces are all dimensioned, then the equipment hardware needs to be dimensioned.
This section will discuss with the hardware planning that highlights principle behind dimensioning
hardware requirements of MSS. MSS is capable of handling GSM, CDMA or UMTS traffic and the
capacity of the switch varies depending on the call model.
5.4.1.1. MSS Configuration
MSS is a large capacity softswitch capable of handling from 800,000 BHCA
(90 s CHT) as per standard call model. MSS can scale to higher capacities
based on changes in call model upto about 1,700,000 BHCA (25s CHT)
with a corresponding change in hardware that can support these ratings.
MSS chasis, also called force chasis is the control switch and comprises of
the following cards that needs to be configured.

S
S
7

M
H

#
1

S
S
7

M
H

#
2

Z
N
Y
X

#

1

Z
N
Y
X

#

2

T
A
M

T
A
M

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

C
P
U

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

In addition to the cards that need configuration, there are other elements
that need to be considered for design purposes. Motorola Soft Switch
Equipment Planning Guide gives a complete description of all the part
numbers that needs ordering and the kit details that constitute the same.
MSS chasis is shown below as an example extract from the above guide
for ready reference. Once the functionality of all the components
comprising of MSS chasis is understood, the need for these components
becomes self evident. For example EMS Server #1 and #2 are always

Author : Page 65



_______________________________________________________________________________________________

___________________________________________________________________________________________
needed as they are configured in redundant mode for any application.
RAID array is needed as a part of the EMS Server. 2 x Cisco ethernet
switch is advisable for any commercial application to interconnect various
elements of the MSS chasis through 10/100BaseT FE ports. Gigabit
Ethernet switches are typically needed if RTP bearer path is to be brought
from the media gateway to the control switch or if the configuration
entails 2 control switches to work together. Terminal server is a part of
the Base kit etc.

Author : Page 66



_______________________________________________________________________________________________

___________________________________________________________________________________________
MSS Chasis

Power Dist Unit
iTouch Terminal Server
Cisco Ethernet Switches
EMS Server #1, #2
RAID Array
DAT Backup Server
Control Chasis (Force Chasis)
Fan & Filter Unit
Media Gateway

Author : Page 67



_______________________________________________________________________________________________

___________________________________________________________________________________________

Author : Page 68
MSS Configurator, maintained at http://compass.mot.com/go/136985679
is a tool available to configure the hardware needs of a particular call
scenario. Shown below is an extract from the configurator that gives an
idea of capacity of MSS components pertaining to different software
releases as well as hardware releases for both GSM and CDMA
technologies.

Control Chassis Card Data
Resource
Type
Part
Number
Limit
MSS-C
2.0
MSS-C
2.5
MSS-C
3.0
MSS-C
4.0
MSS-G
1.0
MSS-G
1.1
MSS-G
2.0
MSC Serving RfBHCA 1,200,000 1,200,000 1,200,000 1,200,000 800,000 800,000 800,000
MSC Gateway RfBHCA 1,200,000 1,700,000 1,700,000 1,700,000 800,000 800,000 800,000
CCSW 1.2 GHz T965AB NwkBHCA 100,000 0 0 0 85,000 85,000 85,000
CCSW 1.2 GHz T965AB RfBHCA 0 0 0 0 67,946 0 0
CCSW 1.2 GHz STLN6193 NwkBHCA 0 100,000 100,000 100,000 0 0 0
CCSW 1.2 GHz STLN6193 RfBHCA 0 79,936 79,936 79,936 0 0 0
SS7 T965AD RfBHCA 400,000 400,000 400,000 400,000 400,000 400,000 400,000
SS7 T965AD Links 64 64 64 64 64 64 64
MRS 1.2 GHz T965AC Sessions 35 0 0 0 35 35 35
MRS 1.2 GHz STLN6194 Sessions 0 35 35 35 0 0 0
IWF T965AR Sessions 0 0 60 60 60 60 60
VLR 1.2 GHz T965AM RfBHCA 1,200,000 0 0 0 1,200,000 1,200,000 1,200,000
VLR 1.2 GHz T965AM Subs 300,000 0 0 0 500,000 500,000 500,000
VLR 1.2 GHz STLN6192 RfBHCA 0 1,200,000 1,200,000 1,200,000 0 0 0
VLR 1.2 GHz STLN6192 Subs 0 300,000 300,000 300,000 0 0 0
HLR 1.2 GHz T965AN RfBHGA 2,000,000 0 0 0 2,000,000 2,000,000 2,000,000
HLR 1.2 GHz T965AN Subs 250,000 0 0 0 150,000 150,000 150,000
HLR 1.2 GHz SGDN4627 RfBHGA 0 2,000,000 2,000,000 2,000,000 0 0 0
HLR 1.2 GHz SGDN4627 Subs 0 250,000 250,000 250,000 0 0 0
CCSW 1.6 GHz STLN6193 NwkBHCA 0 140,000 140,000 140,000 85,000 85,000 85,000
CCSW 1.6 GHz STLN6193 RfBHCA 0 959,233 959,233 959,233 0 0 0
MRS 1.6 GHz STLN6194 Sessions 0 35 35 35 0 0 0
VLR 1.6 GHz STLN6192 RfBHCA 0 1,200,000 1,200,000 1,200,000 0 0 0
VLR 1.6 GHz STLN6192 Subs 0 500,000 500,000 500,000 0 0 0
HLR 1.6 GHz SGDN4627 RfBHGA 0 2,000,000 2,000,000 2,000,000 0 0 0
HLR 1.6 GHz SGDN4627 Subs 250,000 250,000 250,000 250,000 175,000 175,000 175,000
Billing
Process RfBHCA 300,000 300,000 300,000 300,000 300,000 300,000 300,000
Backup
Server T965AG RfBHCA 1 0 0 0 0 0 0
Backup
Server STLN6331 RfBHCA 0 1 1 1 0 0 0
NB: Pls note that HLR and VLR capacities are indicated per pair of CPU
cards



_______________________________________________________________________________________________

___________________________________________________________________________________________
Based on the above, depending on the software release intended to be
deployed, capacities of various cards can be ascertained. Please note that
the capacities highlighted here are basically Lab condition capacities and
do not pertain to the real live call scenario conditions which has to take
into account Network Factor (NwF). Network Factor denote this critical
modifier used in the network call model to account for network events
other than RF call-based activities. Network factor components, such as
the following, accumulate to form a network factor that enables
calculation of total call processing capacity of the MSS, which is referred
to as Network BHCA.

Call Redirection
Call Delivery
Short Message Service (SMS) Message Delivery
Packet and Circuit Data Delivery
Registration / Location Update Factors
Paging Impact Factors
Handoffs
Prepaid Traffic

Typically these factors are factored in depending on the customer call
model.
CCSW calculation Based on the MSS release that is planned for ccswitch
capacity can be calculated as below,

No of Ccsw cards = Even(Roundup((1+NwF)*Calc_BHCA/Rated_BHCA,0))

Where Calc_BHCA is the calculated BHCA that the MSS is expected to
carry and Rated_BHCA is the BHCA capability of the CPU card depending
on the hardware and the software release intended to be deployed with.

ADVLR Calculation Again based on the MSS release as well as the
hardware intended to be used, the VLR can cater to a capacity of 300K
(1.2 GHz) upto 500K (1.6 GHz). Please note at the current release, there
can be only one instance of ADVLR (active + backup) that can be run in a
switch. Expressed as formula the following may be used,

No of ADVLR cards 2

ADHLR Calculation Similar to VLR, the HLR capacities can range
anywhere from 150K (1.2 GHz, 1 GB RAM) to 300K (1.6 GHz, 2 GB RAM)
subs per pair of card. Unlike ADVLR process, ADHLR process is scalable
and the number of cards provisioned to run HLR process can be
augmented in pairs to cater to the market needs. Please also note that
HLR process has to be run in pair ie., an active process should always be
backed up by another standalone process running in a separate CPU card.

Author : Page 69



_______________________________________________________________________________________________

___________________________________________________________________________________________
The backup card cannot run one more instance of active HLR process as
in the case of ccswitch. Expressed as formula the following,

No of ADHLR cards = 2*Roundup(No_of_Subs/CPU_card_cap,0)

Where No_of_subs is the number of subscribers homed in on that MSS
and CPU_card_cap is the HLR capacity of the card.

MRS Calculation Media Resource Server is a process run in the CPU card
to take care of media mixing need as in case of 3 way calling, legal
intercept, announcements (such as for CAMEL/IN working as an
Intelligent Peripheral) etc. A single card with MRS process running in it
can handle 100 call leg instances. Please note that while MRP server is
run in a CPU card, RTP packets of bearer information is mixed and hence
it is not backed up with another instance of MRS process etc. Hence
based on the engineering need only so many cards are configured,
subject to a minimum of 2 cards so as not to loose the functionality of
conferencing or LI of MSS. Expressed as formula,

No of MRS Cards = Max(Roundup(No_of_3wc/35,0),2)

Where No_of_3wc is the number of 3 way conference calls handled by the
card. As the limitation stems from the total number of call legs that can
be handled, in case of 6wc, the number of sessions is limited to 100/6 ~
16 etc.

SS7MH Calculation SS7 Message handler cards are capable of hosting 4
E1 ports resulting in 128 time slots to bring in the signalling traffic. Each
SS7 card consists of a mother card and two daughter cards. Each
daughter card supports physical connectivity for two T1 or E1
connections. However, the software on the daughter cards limits each
card to 32 links per daughter card. Each SS7 card (mother card +
daughter cards) support up to 750 message signaling units (MSUs) per
second at 40% utilization (assuming each MSU is of maximum size of 272
octets). Due to this, out of total flexibility of 128 time slots, only 64 time
slots could be equipped at any point of time to carry the signalling traffic.
Typically all the messaging links are distributed evenly among 2 message
handlers to ensure fault tolerance.

No of SS7MH cards = Max(Roundup(No_of_signalling_lnks/64,0),2)

IPMH Calculation IP Message Handlers need to be scaled if there are
SIP call instances and currently they just perform the function of load
balancing IP messages between the entities within MSS. Since we do not
have SIP at the moment, a minimum of 2 process instances are
provisioned - in active backup configuration.

Author : Page 70



_______________________________________________________________________________________________

___________________________________________________________________________________________
PCMGR Calculation Typically we provide 2 point code manager process
that runs in active standby configuration. This is not a scalable process
and is limited to one instance per MSS.

In most instances we do not need to provision separate cards for IPMH,
PCMGR processes as they can be multiplexed to run on the same card
that hosts MRS or ADVLR process etc.

5.4.1.2. Media Gateway Configuration
Media Gateways are primarily responsible for handling bearer traffic and
providing switching crosspoints for circuit switched voice. In addition
Media gateways also handle Packet traffic as well as conversion between
circuit switched voice call and packetised voice and vice versa. MSS being
the control server, controls the functions performed by media gateway
through the control protocols such as MGCP or MEGACO. MSS provides
support for a number of media gateways including Audio Code media
gateway and Sonus Media Gateway.

Audio Code Mediagateway Audio code mediagateway currently in use is
TP1610 which is a card that can be housed in the MSS control chasis
itself. Audio code is very useful for small market applications which can
handle a number of signalling applications including R2 protocol. The
AudioCodes MGW supports circuit interfaces including DS1 and E1 and is
designed specifically to meet the needs of CDMA and GSM networks. The
MSS supports multiple AudioCodes MGW cards in the control chassis for
scalability. A single AudioCodes TP-1610 card supports 16 T1 or E1 ports
for a maximum capacity of 384 T1 or 496 E1 timeslots.

No of Audiocode MGW = Roundup(No_of_required_E1/16,0)

Sonus Mediagateway - The Sonus GSX9000 MGW is a compact, high-
performance system that significantly reduces space requirements over
legacy circuit switches, lowering operational costs for cooling, power and
other facilities. The Sonus MGW supports high density circuit interfaces
including T1, DS3, E1 and OC3/STM-1/ STM-0 as well as IP, ATM and POS
packet interfaces. The Sonus MGW chassis provides 16 slots, two of which
are reserved for redundant Management Network Servers (MNS). The 14
remaining slots can be populated with any combination of Packet Network
Server (PNS) or Circuit Network Server (CNS) interface modules. Typically
2 PNS and 2 MNS cards are populated with a variable number of CNS
cards. There are a number of varieties of CNS cards available to suit the
requirement and following is a summary,

CNS10 - Maximum of 12 T1 spans (288 chls) can be terminated
CNS20 - Maximum of 8 E1 spans (240 chls) can be terminated
CNS25 - Maximum of 12 E1 spans (372 chls) can be terminated
CNS30 - Maximum of 1 T3 span (672 chls) can be terminated

Author : Page 71



_______________________________________________________________________________________________

___________________________________________________________________________________________
CNS60 - Maximum of 3 T3 spans (2016 chls) can be terminated
CNS71 - Maximum of 1 OC3 span (2016 chls) can be terminated

5.5. SPARE REQUIREMENTS

For every order of MSS equipment, a list of spares is to be maintained as highlighted in System
Equipment Planning Guide which also provides spare requirement calculations for Sonus
Mediagateway. An extract of the same for ready information as below,

New Part Number Description Supplier
STLN4807A
On CS / AD Chassis:
STLN6197A SS7 Card w/o RTM Force
STLN6196A SS7 RTM Card Force
SGDN4628A CPU 700MHz 1GB SPARE Force
STLN6186A Ethernet w/o RTM Card Force
STLN6185A Ethernet RTM Card Force
STLN6188A Alarm w/o RTM Card Force
STLN6187A Alarm RTM Card Force
STLN6189A Power Supply, CS/AD Force
STLN6190A Fan Tray, CS/AD Force
STLN6191A Air Filter, CS/AD Force
Spare for EMS
STLN6166A Linus Server Arrow
Spares for RAID (100977)
SANnet II SCSI, RAID controller w/ 512 MB
cache STLN6172A Dothill
STLN6173A SANnet II SCSI, event managenment unit Dothill
STLN6174A SANnet II SCSI, RAID IO module Dothill
STLN6175A SANnet II SCSI, termination card Dothill
STLN6176A SANnet II, SCSI cable, bus config Dothill
STLN6177A SANnet II, drive bay air mgmt module Dothill
STLN6178A SANnet II, DD, Ultra 160 SCSI, 36GB10k RPM Dothill
STLN6179A SANnet II, DC power and cooling mod Dothill
STLN6180A SANnet II, DC power cord Dothill
STLN6181A Cable, Ultra160, VHDCI-VHDCI, 3 foot Dothill

5.6. SOFTWARE DIMENSIONING

Software modules and the ordering numbers are also highlighted in the System Planning Guide.

Author : Page 72



_______________________________________________________________________________________________

___________________________________________________________________________________________
6. CASE STUDIES
6.1. CASE STUDY # 1
Customer Input:

Customer Inputs

Basic details
Total Subscribers 1000000
BHCA 1000000
Total Erlangs 104000 Erl

Call Mix
Mobile to Mobile 20%
Mobile to Land 40%
Land to Mobile 40%

Value Added Services
IN Subscribers 60%
SMS 100%
SMS BHSM 0.5
VMS 100%
VMS BHCA 0.4
VMS Mean Holding Time 50 s
% of active subs using VMS 20%

Trunking efficiencies
Inter network trunk efficiency 0.8
MSC-POI trunk efficiency 0.8

GMSC to be used for Incoming calls
Tandem to be used for Outgoing calls

Network Planning:

Traffic Distribution Matrix

Based on Call mix proportion of call to be distributed as below,

MSS POI
MSS 20800 41600
POI 41600

Author : Page 73



_______________________________________________________________________________________________

___________________________________________________________________________________________
As we can accommodate maximum of 300000 subscribers per MSS, number of MSS
needed for the total subscriber base = Roundup(1000,000/300,000,0) = 4. With 4 MSS
configuration, to handle the Mobile to Mobile traffice, we need Inter-MSC trunks.

Inter-MSC call matrix to handle M2M calls :

Erlangs per MSC = 20800/4 = 5200
Incoming into MSC = 5200/2 = 2600
Outgoing out of MSC = 5200/2 = 2600

Outgoing to other MSC = 2600/4 = 650
Incoming from other MSC = 2600/4 = 650

Summarised as below,

MSS
1
MSS
2
MSS
3
MSS
4 GMSC TANDEM
MSS 1 1300 650 650 650
MSS 2 650 1300 650 650
MSS 3 650 650 1300 650
MSS 4 650 650 650 1300
GMSC
TANDEM

Consolidating outgoing and incoming traffic on per MSS basis, the following,

MSS
1
MSS
2
MSS
3
MSS
4 GMSC TANDEM
MSS 1 1300 1300 1300 1300
1300 1300 1300 MSS 2
MSS 3 1300 1300
1300 MSS 4
GMSC
TANDEM

Author : Page 74



_______________________________________________________________________________________________

___________________________________________________________________________________________
Accordingly the network diagram at this stage..

MSS 4
5200
MSS 3
5200
MSS 2
5200
MSS 1
5200
m2m
1300
1300
1300
1300
1300
1300
1300
1300
1300
1300

PSTN <-> MSC call matrix to handle L2M and M2L calls :

For calls out of network use Tandem MSC and for incoming calls use GMSC, accordingly
the traffic distribution matrix will be as below,

Incoming L2M calls per MSS = 41600/4 = 10400 Erl,

Therefore,
MSS
1
MSS
2
MSS
3
MSS
4 GMSC TANDEM
MSS 1 1300 650 650 650 0 10400
MSS 2 650 1300 650 650 0 10400
MSS 3 650 650 1300 650 0 10400
MSS 4 650 650 650 1300 0 10400
GMSC 10400 10400 10400 10400
TANDEM 0 0 0 0

Author : Page 75



_______________________________________________________________________________________________

___________________________________________________________________________________________

Consolidating Outgoing and Incoming traffic, the following,

MSS
1
MSS
2
MSS
3
MSS
4 GMSC TANDEM
MSS 1 1300 1300 1300 1300 10400 10400
1300 1300 1300 10400 10400 MSS 2
1300 1300 10400 10400 MSS 3
1300 10400 10400 MSS 4
GMSC
TANDEM

MSS 4
5200 +
20800
MSS 3
5200+
20800
MSS 2
5200 +
20800
MSS 1
5200+
20800
m2m
1300
1300
1300
1300
1300
1300
1300
1300
1300
1300
GMSC TANDEM
10400
10400
10400
10400
10400
10400
10400
10400
VMS Dimensioning :

VMS may be connected to Tandem MSC / GMSC assuming traffic distribution of 90 : 10.

VMS Traffic = Roundup(VMS_BHCA*VMS_CHT/3600,0)
= Roundup(100%*1000,000*0.4*50/3600,0)
= 5556 Erl

Interface Dimensioning :

Author : Page 76



_______________________________________________________________________________________________

___________________________________________________________________________________________
MSS BSC Dimensioning
sing internetworking trunking efficiency of 0.8,
nks to BSC - A
E1
= Roundup(Total_CS_traffic in Erlangs/0.8/30)
ignalling A
64k
= Roundup(1084/30,0)
ased on BSC capability, number of BSCs and the signalling links to these BSCs need to
SS HLR Dimensioning

U

Li
= Roundup((5200+20800)/0.8/30)
= 1084 E1s

S
= 37

B
be decided.

M
LR is distributed among 4 MSSs as 250,000 subs/HLR.
ssuming 20K subs contribute 0.4 Erl traffic query to HLR, number of links
o. of 0.4 Erl Signalling links = Roundup(250000/20000,0)
ut of t above links fr S ndup(13*40/60,0)
3*15/60,0)
ter MSC Dimensioning

H
HLR queries will originate from Other MSSs (20%*3/4)
GMSC (40 %)

A

N
= 13
O he om GM C = Rou
= 9
Links from other MSS = Roundup(1
= 4

In
sing internetworking trunking efficiency of 0.8,
SS1 <-> MSS2 <-> MSS3 <-> MSS4 = 1300 erl
ter MSS link E
E1
= Roundup(Inter_MSC_Traffic/30/0.8)
ignalling traffic pertaining to voice (assuming 30 E1s traffic can be handled by 1
ax(Roundup(E
E1
/30,0),2)
herefore the total signalling links between any 2 adjacent MSS is (incl. HLR queries)

U

M

In
= Roundup(1300/30/0.8)
= 55 E1s

S
signalling link of 0.4 Erl),
E
64K
= M
= Max(Roundup(55/30,0),2)
= 2

T
= Roundup((4/3)*2+2,0)

Author : Page 77



_______________________________________________________________________________________________

___________________________________________________________________________________________

C SMSC Dimensioning
= 5
MS
MS BHSM Traffic = (No_of_Subs_per_MSS*BHSM)
ssuming 0.4 Erl per signalling link for carrying SMS traffic to SMSC,
nks to SMSC - NumberOfSignalLinks = Roundup(BHSM/48)
umber of E1s - H
E1

SC IN Dimensioning

S
= (250,000*0.5)
= 125,000 = 125 K

A

Li
= Roundup(125/48)
= 3 SS7 links

N
= Max(Roundup(3/4),2)
= 2 E1s

M
otal IN subscribers/MSS = 60%*250000
template)
4 Erl/ k
SC GMSC Dimensioning

T
= 150000
Traffic generated = 3.88 Erl (using
Signalling liks @ 0. ln = Roundup(3.88/0.4,0)
= 10 links

M
earer Traffic = 10400 Erl
0400/0.8/30,0)
0)
otal signalling links including GMS HLR = 15 + 9 = 24.
ince the total number of signalling links exceed 16, we may have to employ MSSs
SC Tandem Dimensioning

B
No of E1s = Roundup(1
= 434 E1s
Signalling Traffic = Roundup(434/30,
= 15 Links

T

S
secondary OPC configuration to accommodate this condition.

M
earer traffic same as above = 434 E1s
MS Dimensioning

B
Signalling traffic = 15 links

V
MS may be connected to Tandem MSC and the link engineering as below, V

Author : Page 78



_______________________________________________________________________________________________

___________________________________________________________________________________________
earer Traffic = 5556 Erl
5556/0.8/30,0)
ignalling traffic = Roundup(231/30,0)
B
No of E1s = Roundup(
= 231 E1s

S
= 8 links

Author : Page 79



_______________________________________________________________________________________________

___________________________________________________________________________________________

The Final Network Diagram may now be presented as below,

MSS 4
5200 +
20800
MSS 3
5200+
20800
MSS 2
5200 +
20800
MSS 1
5200+
20800
m2m
GMSC TANDEM
434 E1
24 lnks
VMS
231 E1
8 lnks
434 E1
24 lnks
434 E1
24 lnks
434 E1
24 lnks
434 E1
15 lnks
434 E1
15 lnks
434 E1
15 lnks
434 E1
15 lnks
55 E1
5 lnks
55 E1
5 lnks
55 E1
5 lnks
55 E1
5 lnks
55 E1
5 lnks
55 E1
5 lnks
SMSC
1084 E1
37 lnks
1084 E1
37 lnks
1084 E1
37 lnks
1084 E1
37 lnks
2 E1
3 lnks
2 E1
3 lnks
2 E1
3 lnks IN
2 E1
10 lnks
2 E1
10 lnks
2 E1
10 lnks

MSS Engineering :

All the 4 MSSs will have the same configuration.

Number of CCSW CPU cards 1.6 GHz, 2 GB RAM

Assuming NwF = 0.7 (IN, SMS etc)

No of ccsw cards = Even(Roundup(250000*(1+0.7)/100000,0))

Author : Page 80



_______________________________________________________________________________________________

___________________________________________________________________________________________
Number of CCSW CPU cards = 6
Number of ADVLR CPU cards = 2
Number of ADHLR CPU cards = 2 (Max 300 K subs per card reqd 250 K)
Number of MRS Cards = 2
Number of SS7MH cards = 2 (as below)

Signalling links total = 5*3+37+24+15+3+10
= 104
@64 links per card reqd SS7MH = Roundup(104/64,0)
= 2

Author : Page 81



_______________________________________________________________________________________________

___________________________________________________________________________________________
6.2. CASE STUDY # 2

Input Parameters

Voice BHCA/sub = 3
Total Subscribers = 45.5 Million
Erlang Per Subscriber = 50 mErl
IN Subs = 100 %
BHSM/Sub = 0.5
Signalling link loading = 30 %
M2M % = 60 %
M2P % = 10 %
P2M % = 30 %
Inter MSC BICC traffic = 50 %
HLR signalling reqmnt = 2.5 LSL/ 10,000 subs subject to a minimum of 128 links

Derived Parameters

MHT Mean Holding Time = Erl/BHCA = 0.05 x 3600/3 = 60 s

Above capacity is to be distributed over 21 PLMNs which are contained among 3 Regions. Out of
the required network elements, some are to be engineered at Region level, some at PLMN level,
and some more at Central level and the list furnished as below,

MSC, MGW, GMSC, GMGW PLMN
RAN, UTRAN PLMN
HLR/HSS PLMN
SMSC / SMSC MO gateway Regional
IN Platform/VoMS/USSD Regional
UMS Regional / PLMN
MMS Regional
OTAPA Regional
LI PLMN
SGW/STP PLMN
IP/SRP PLMN
SGSN PLMN
GGSN Regional
WAP Regional
SDP Regional
Central IN Central
EIR Central
GRX Central
GMLC Regional
SMLC PLMN

Author : Page 82



_______________________________________________________________________________________________

___________________________________________________________________________________________
User Plane traffic shall be on IP (within PLMN)
Interfaces to be engineered for STP/SGW for other elements, standard configuration to
be applied.
Control Plane traffic assumed to be distributed as 25 % LSL, 25 % HSL, 50 % Sigtran

TCP/IP
HLR/
AuC/
MSC MSC 2
UMS Central
(Zonal)
MGW MGW 2
PSTN/
PLMN
SMSC
SGSN
EIR
STP
STP
GMSC
UMS Remote
+MCA
IP/MPLS
IN USSD
SDP
BSC RNC
A i/f IuCs i/f
H.248,
M2UA(BSSAP
&RANAP)
Nc i/f
MGW 2
Nbi/f
MMSC
TCP/IP
interface
GMGW
State / LSA
Regional
Network Logical Diagram Network Logical Diagram

Capacities of standard configurations categorised under A, B, C for MSC and GMSC
servers whereas for Mediagateways, categorised under A, B, C, D & E
Capacity required shall be supplied in 3 phases with Phase 1 , Phase 2, Phase 3 having
subscriber ratios in the following proportion,
GSM : UMTS 75 : 25 50 : 50 25 : 75
Various interfaces from each of these MSC servers identified and provisioned in the Bid
requirement, except for some which needs Bidder to calculate. Listed below the
interface requirement,

MSC Server Dimensioning

MSC Server Category Remark
A B C
Subscriber Capacity 400K 200K 100K Expn
VLR Cap 600K 300K 150K

Author : Page 83



_______________________________________________________________________________________________

___________________________________________________________________________________________
BHCA 1.2 Mil 0.6 Mil 0.3 Mil
CCS7 Links - 64 kbps (min) 512 256 128
CCS7 Links - 2 Mbps - to STP/other nodes 24 12 6
Number of Simultaneous calls that could be
handled 40000 25000 15000
50% Inter MSC S
traffic Nc Interfaces, BICC 6 Mbps (min) 3 Mbps (min) 2 Mbps (min)
Mc Interfaces, H.248 10 Mbps (min) 8 Mbps (min) 6 Mbps (min) On IP
100 Mbps IP Signalling ports Optical 5+5 3+3 2+2 Redundancy
ATM Signalling ports for HSL 2+2 2+2 2+2 Redundancy
16+2 port IP Site Router for MPLS VPN 2 2 2

GMSC Server Dimensioning

GMSC Server Category Remark
A B C
BHCA 1.2 Mil 0.9 Mil 0.6 Mil
Erlang 30000 25000 15000
E1 1500 1300 800
STM - 1 25 20 15
STM - 4 5 4 3

Similarly the MGW interfaces to be provisioned as below,

MGW Dimensioning

Traffic Profile Values Remarks
BHCA/Sub 3
Traffic/Sub 0.05
IN Calls 100%
BHSM/Sub 0.5
GSM Sub 75%
WCDMA Sub 25%
Link Loading 30%
Mobile To Mobile 60%
Mobile to PSTN 10%
PSTN to Mobile 30%
Media Gateway on IP (Nb, Mc) 100%
MGW Interfaces

Interface
Interface
Type Unit Cat A Cat B
Cat
Cat C D Cat E Remark
Traffic Capacity Erlang 16000 12000 8000 4000 2000
(i) GSM No. 14000 10000 7000 3500 2000 Simultaneous call
contexts
(ii) UTRAN-
Voice No. 4500 3500 2300 1200 600

Author : Page 84



_______________________________________________________________________________________________

___________________________________________________________________________________________

Author : Page 85
(iii) UTRAN-
Video No. 180 150 100 50 25
E1 No. 660 495 330 165 83
A Interface
STM-1 No. 2 2 2 2 1
lu-CS Interface STM-1 No. 4 3 3 2 2
E1 No. 640 480 320 160 80 MGW-
PSTN,USAL,CMSP STM-1 No. 10 8 6 3 2
E1 No. 64 64 48 32 20
E Interface
STM-1 No. 2 1 1 1 1 MGW-MSC
Mbps 102 77 51 26 24
STM-1 4 4 3 3 2 Nb Interface
GE 1 1 1 1 1
Mc Interface
No.
To be provided by the bidder as per
actual calculations
AVF
No. 20000 15000 10000 5000 2500
Transcoders
lu-CS
No. 5000 3750 2500 1250 625
Transcoders
are to be in a
single pool
Echo Cancellers No. 20000 15000 10000 5000 3000
LSL
No.
actual calculations SS7 links to BSC,
PSTN, GMSC etc
HSL
No.
actual calculations
Number of Annoucement Devices No. 600 400 300 200 100
No.
actual calculations
SIGTRAN Ports
Mbps
actual calculations
IWF Devices No. 100 100 100 100 100

Network Elements supplied as per Bill of Quantity - adhering to geographical and
capacity redundancy as well as disaster relief provisioning as per requirements
Network Elements such as IN, SMSC, HLR need swapping the existing one and replacing
with new one catering to augmented capacity or augmenting the existing one to meet
the existing and new requirement so that multiple makes and models of a particular
network element is avoided for the Region needs or PLMN needs as the case may be.

Based on the above customer requirement, the following interfaces have to be engineered,

MSC - MGW Interfaces
A, Iu Interface
Nc, Nb Interfaces
MSC PSTN Interface
SGW



_______________________________________________________________________________________________

___________________________________________________________________________________________

MSC - MGW Interface Dimensioning Mc (H.248 Component)

This interface between MSC and MGW has to cater to various configuration scenarios based on
the models requested. Following the calculations :
Required IP bandwidth (Ref 5.2.1.10 for details)

Mc = Roundup (MG
BHCA
* 9 * 253 * 8)/(3600 * 0.3 * 1024 * 1024) Mbps

Media Gateway BHCA calculated for various models

MGW Cat A Cat B Cat C Cat D Cat E
Erlang 16000 12000 8000 4000 2000
BHCA 960000 720000 480000 240000 120000

On the basis of above formula the Mc interface for each of MGW shall be as below,

Mc
(Mbps) 15.44 11.58 7.72 3.86 1.93

MSC MGW Interface Dimensioning M2UA (BSSAP Component)

In addition to H.248, M2UA links will be established to handle BSC traffic from 2/2.5G BSSAP
subscribers. Bandwidth requirement for the same is shown as below,


M2UA
BSSAP
= Roundup(BSSAP
BHCA
* 173 * 10 * 8)/(3600 * 0.3 * 1024 * 1024) Mbps

Based on the above formula M2UA bandwidth in Mbps to cater to BSSAP traffic is calculated as
below,

Cat A Cat B Cat C
MSC
Ph 1 Ph 2 Ph 3 Ph 1 Ph 2 Ph 3 Ph 1 Ph 2 Ph 3
BHCA 1200000 600000 300000
BSSAP % 75% 50% 25% 75% 50% 25% 75% 50% 25%
M2UA
BSSAP 11.00 7.33 3.67 5.50 3.67 1.83 2.75 1.83 0.92

MSC MGW Interface Dimensioning M2UA (RANAP Component)

Balance of traffic results from the UMTS subscriber utilising RANAP application layer wherein the
bandwidth requirement calculation shown as below,


Author : Page 86



_______________________________________________________________________________________________

___________________________________________________________________________________________
M2UA
RANAP
= Roundup(RANAP
BHCA
* 193 * 15 * 8)/(3600 * 0.3 * 1024 * 1024) Mbps

Based on the above formula M2UA bandwidth in Mbps to cater to RANAP traffic is calculated as
below,

Cat A Cat B Cat C
MSC
BHCA 1200000 600000 300000
RANAP % 25% 50% 75% 25% 50% 75% 25% 50% 75%
M2UA
RANAP 6.14 12.27 18.41 3.07 6.14 9.20 1.53 3.07 4.60

MSC MGW Interface Dimensioning M2UA (ISUP Component)

M2UA links need to be provisioned additionally to cater to traffic from PSTN. Required IP
bandwidth (Ref 5.2.1.10)

M2UA
ISUP
= Roundup(ISUP
BHCA
* 193 * 5 * 8)/(3600 * 0.3 * 1024 * 1024) Mbps

Based on the formula above and given parameters, calculation shown as below,

MSC Cat A Cat B Cat C
BHCA 1200000 600000 300000
M2P % 10% 10% 10%
P2M % 30% 30% 30%
M2UA
ISUP 3.27 1.64 0.82

A Interface (MSC BSC) Dimensioning BSSAP Traffic

This interface to be implemented using LSL/HSL will follow dimensioning guidelines as specified
under 5.2.1.1 and the number of LSLs required is,

LSL
BSSAP
= Max(Roundup((BSSAP
BHCA
* 94 * 10 * 8)/(3600 * 64 * 0.3 * 1024),0),2)

Required number of LSLs phase wise for different categories of MSC servers are listed
accordingly as below,

Cat A Cat B Cat C
MSC
BHCA 1200000 600000 300000
BSSAP % 75% 50% 25% 75% 50% 25% 75% 50% 25%
LSL
BSSAP
96 64 32 48 32 16 24 16 8

In case the above is required to be implemented using HSLs, then the number of HSLs needed
will follow guidelines listed under 5.2.

Author : Page 87



_______________________________________________________________________________________________

___________________________________________________________________________________________
HSL
BSSAP
= Max(Roundup(LSL
BSSAP
/16,0),2) which translates into,

Cat A Cat B Cat C
MSC
BHCA 1200000 600000 300000
BSSAP % 75% 50% 25% 75% 50% 25% 75% 50% 25%
HSL
BSSAP
6 4 2 3 2 2 2 2 2

Iu Interface (MSC RNC) Dimensioning RANAP Traffic

As in case of BSSAP traffic, refer section 5.2.1.1. for RANAP dimensioning details, listed below for
ref,

ATM
RANAP
= Roundup(RANAP
BHCA
* 136 * 15 * 8)/(3600 * 0.3 * 1024 * 1024) Mbps

Above formula when applied translates into following bandwidth requirement in Mbps

Cat A Cat B Cat C
MSC
BHCA 1200000 600000 300000
RANAP % 25% 50% 75% 25% 50% 75% 25% 50% 75%
ATM
RANAP
4.32 8.65 12.97 2.16 4.32 6.48 1.08 2.16 3.24

MSC PSTN Interface Dimensioning LSL/HSL (ISUP Component)

Based on Points of Interconnect and the traffic, this interface will be dimensioned as below, (Ref
Sec 5.2.1.8 for details)

LSL
ISUP
= Max(Roundup(Tot
BHCA
* p * 150 * 5 / 3600 / 8000 / 0.3,0),2)

and equivalent HSLs given by

HSL
ISUP
= Max(Roundup(LSL
ISUP
/16,0),2)

Number of LSLs/HSLs needed on the basis of above is tabulated as below,

BHCA 1200000 600000 300000
M2P % 10% 10% 10%
P2M % 30% 30% 30%
LSL
ISUP
42 21 11
HSL
ISUP
3 2 2

MSC MSC Interface Dimensioning Nc Interface

Author : Page 88



_______________________________________________________________________________________________

___________________________________________________________________________________________
Proposed BICC traffic, flow in this interface. As highlighted in Sec 5.2.1.3, dimensioning will
follow the formula as below,

N
c
= Roundup((N
cBHCA
* 253 * 8 * 7)/(3600 * 0.3 * 1024 * 1024),0) Mbps

On application of the above formula, Nc bandwidth requirement in Mbps tabulated as below,

BHCA 1200000 600000 300000
Inter MSC BICC % 50% 50% 50%
N
C
7.51 3.75 1.88

MSC MSC Interface Dimensioning Nb Interface

In case of User plane traffic carried via Nb interface, bandwidth dimensioning depends on BICC
negotiation of an appropriate protocol. Since that is indeterminate, maximum bandwidth is
dimensioned, wherein, we assume G.711 compression with a VAD of 50% is applicable. When
expressed as formula, following is the bandwidth applicable (for details ref. sec. 5.2.1.3)

N
b
= Roundup((MGW
erl
* x % * 47.6)/1024) Mbps

Above when applied on different media gateways, results in the following bandwidth requirement
for each of the required configurations (Mbps),

Erlang 16000 12000 8000 4000 2000
Inter MGW Traffic % 50% 50% 50% 50% 50%
Nb (Mbps) 371.88 278.91 185.94 92.97 46.48

SGW/STP Dimensioning

Signalling Gateways are required to be provided in most of the PLMN based on subscriber
population. Since the subscriber population varies widely, the Signalling Gateway dimensioning
had to be split into 6 different categories with the following guideline for SGW implementation.

Subscriber Population Model Number
<1 Million 1
>1 Million and <2 Million 2
>2 Million and <2.5 Million 3
>2.5 Million and <3 Million 4
>3 Million and <4 Million 5
>4 Million 6

Most of the network elements listed earlier would use the services of SGW/STP to interconnect
with the other Network elements. Bulk of this traffic would come from
HLR Queries MAP Routing Queries and Location Updates

Author : Page 89



_______________________________________________________________________________________________

___________________________________________________________________________________________
SMSC traffic Both MO and MT traffic
IN transactions For all the various services proposed to be hosted
ISUP traffic
As against the above there would be a lot of variation in traffic that may flow via SGW which
would be implementation specific details of which are not available at this stage. Hence a
margin factor to the above traffic may be used to make a learned assumption of the traffic to be
handled by the SGW. Details of traffic on account of above items calculated as shown below,

MAP Calculations -

MSC <-> SGW (Refer Section 5.2.1.2)

MAP BHCA m/sgs : 3 call attempts per sec per subs
Avg Octet size : 300 octets per transaction
BH msgs/mil subs : 3000000
Msgs/mil/sec : =3000000/3600 = 833 msgs/sec/million subs
MAP traffic in octets : = 833 * 300 = 250,000 octets/sec/million subs
MSC map lsl/mil. Subs : = 250000/8000 * 30 % = 104 LSLs from MSC
Since this traffic would be routed by SGW towards HLR, traffic towards HLR would be the
same as above henc,
HLR map lsl/mil. Subs : = 104 LSLs towards HLR

SMSC Calculations -

MSC <-> SGW (Refer Section 5.2.1.6)

MO BHSM m/sgs : 0.5 msgs per sec per subs
Avg Octet size : 200 octets per transaction
SMS traffic in octets : = 139 * 200 = 27,778 octets/sec/million subs
MSC sms lsl/mil. Subs : = 27778/8000 * 30 % = 12 LSLs from MSC

SGW <-> SMSC

MT BHSM m/sgs : 0.5 msgs per sec per subs
SMSC Avg Octet size : = 200 + 150 = 350 octets per transaction
SMS traffic in octets : = 139 * 350 = 48,611 octets/sec/million subs
MSC sms lsl/mil. Subs : = 48611/8000 * 30 % = 20 LSLs from SMSC

SGW <-> HLR

MT BHSM m/sgs : 0.5 msgs per sec per subs
Route query avg size : 150 octets per transaction

Author : Page 90



_______________________________________________________________________________________________

___________________________________________________________________________________________
Routing traffic in octets : = 139 * 150 = 20,833 octets/sec/million subs
HLR lsl/mil. Subs : = 20833/8000 * 30 % = 9 LSLs towards HLR

SCP/ IN Calculations

MSC <-> SGW <-> SCP (Refer Section 5.2.1.7)

Voice BHCA m/sgs : 3 call attempts per sec per subs
Other Svcs using IN : 0.5 (SMS) + 0.7 (assume) = 1.2
(SMS, Bal. query etc)
CAP BHCA m/sgs : 4.2 msgs per sec per subs

Using the formula as refered above,
L
LSL
= Max(Roundup(Tot
BHCA
* 4 * 124 /3600/8000/0.4,0),2)

MSC cap lsl/mil. Subs : 4.2 * 1000000 * 4 * 124 / 3600 / 8000 / 0.3 = 241

All the above traffic is directed towards IN platform from SGW and calculation for IN
Platform as below

IN cap lsl/mil. Subs : 4.2 * 1000000 * 4 * 124 / 3600 / 8000 / 0.3 = 241

ISUP Calculations

MSC <-> SGW <-> PSTN (Refer Section 5.2.1.8)

Voice BHCA m/sgs : 3 call attempts per sec per subs

Using the formula as refered to in the above section,
LSL
ISUP
= Max(Roundup(Tot
BHCA
* p * 150 * 5 / 3600 / 8000 / 0.4,0),2)

m2p + p2m + : 10 + 30 + 30 = 70 %
Inter MSC (50% of 60%)
MSC ISUP lsl/mil Subs : 3 * 1000000 * 70% * 150 * 5 / 3600 / 8000 / 0.3
= 182

Tabulating all the above calculations as below,

MSC HLR SCP SMSC
LSL / mil subs 104 104
MAP
LSL / mil subs 12 9 20
SMSC
LSL
CAP
/ mil subs 241 241
LSL
ISUP
/ mil subs 182
Total / mil subs
LSL
539 113 241 20

Resulting in a total LSL of 913 per million subscribers.

Author : Page 91



_______________________________________________________________________________________________

___________________________________________________________________________________________

Additionally a 20% margin is added to the above to cater to other services such as location based
services, OTAPA etc and above interface capacity is then split into LSL (25%), HSL (25%) &
Sigtran (50%). This is further proportioned on the basis of subscriber population and growth
expected in Phase 1, 2, 3. On the basis of PLMN categorisation to belong to a particular model,
interfaces are provisioned for the highest subscriber population within that model bracket.

HLS/HSS Dimensioning

Required to supply HLR of following configurations, 1 million, 2 million, 3 million, 4 million, 5
million and 6 million subs capacity. Geographical redundancy with Disaster recovery required,
hence 2+1 configuration offered. Per the RFP requirement, following are the number of
signalling links to be provisioned,

HLR/HSS Model Minimum 1 000
000
2 000
000
3 000
000
4 000
000
5 000 6 000
000 000
Specification
s

Signalling Links 2.5 Link/10k 250 500 750 1000 1250 1500
C&D per 10k subs
Gc One pair 2 4 6 8 10 12
Gr 1 Link/10k
>32
100 200 300 400 500 600
GMLC(h) >8 8 16 24 32 40 48
MMSC >8 8 16 24 32 40 48
SMSC >8 8 16 24 32 40 48
IN >8 8 16 24 32 40 48
OTA >8 8 16 24 32 40 48
SIP AS >8 8 16 24 32 40 48
OSA (sh) >8 8 16 24 32 40 48
CSCF (Cx) >8 8 16 24 32 40 48
IM SSF (SI) >8 8 16 24 32 40 48
3GPP AAA ------- N/A N/A N/A N/A N/A N/A N/A
Total 424 848 1272 1696 2120 2544

Per the configurator, the number of FE and BE required for above configurations listed,

HLS model 1000000 2000000 3000000 4000000 5000000 6000000
HLR Front-Ends 6 8 12 15 18 26
HLR Back-Ends 3 6 9 12 18 21
Phase 1
Adax PCI Cards (HLR) 50% of
qty
3 4 6 8 9 13
Sun Quad Ethernet Cards For SIGTRAN (HLR) 50% of
qty
3 4 6 7 9 13

Author : Page 92



_______________________________________________________________________________________________

___________________________________________________________________________________________
Sun Quad Ethernet Cards For DIAMETER
(HSS)
3 3 3 3 3 3
Sun Quad Ethernet Cards For DIAMETER 2 2 2 2 2 2
Phase 2
Adax PCI Cards (HLR) 3 4 6 8 9 13
Sun Quad Ethernet Cards For SIGTRAN (HLR) 3 4 6 7 9 13
(HSS)
3 3 3 3 3 3

Phase 3
Adax PCI Cards (HLR) 3 4 6 8 9 13
Sun Quad Ethernet Cards For SIGTRAN (HLR) 3 4 6 7 9 13
(HSS)
3 3 3 3 6 6

As above, each FE is provided with 1 Adax card. Each Adax card can terminate 4 E1 links. Each
link has 31 signalling time slots hence each card can handle 31 x 4 = 124 signalling TSs. This
results in a total signalling interface of 124 x 3 = 372 LSL. In addition 3 Sigtran interface cards
are provided and each Sigtran card can handle 124 LSL equivalents resulting in a total capacity of
2 x 124 = 372 LSL. Combined total therefore is 372 + 372 = 744 LSLs which is more than 424
LSLs as requested in the RFP for 1 million subs configuration.

SMSC Dimensioning

SMSC interfaces with MSC, HLR, IN (for CAMEL PH III & above) through SS7 interfaces. SMSC
interactions with other network element such as VMS, UMS, OTAPA, WAP etc happens through
the SMPP protocol. As for MSC and HLR interactions, RFP states the requirements to be at least
512 LSL equivalents (to cater to MO SMS traffic as well as other interfaces such as Gs, IN
platform etc)and for expansion phases, the calculation is performed as highlighted in Section
5.2.1.6. Considering an average SMS of 240 octets/message, and using the formula for Phase 2
and 3 as below

* AvSMSsize/3600/8000/0.3,0),2) H
LSL
= Max(Roundup(Tot
BHSM

wherein,

Tot
BHSM
/zone as per RFP (Ph 2,3) = 1500000
AvSMSsize = 240

No of LSL for SMS = 1500000 * 240 / 3600 / 8000 / 0.3 = 42 lsls

Above LSLs if needed to be provisioned as Sigtran interface, then the bandwidth needed for the
same would have to accommodate instead of MTP 2/ MTP3 overheads, SCTP/IP overheads.
SCTP/UDP overheads approximate to 100 octets/message (M3UA ~ 25 + SCTP ~ 48 + IP ~ 20
Octets)

Sigtran Bandwidth for SMS = 1500000 * (240 + 100) /3600 /1024 / 1024 /0.3 = 4 Mbps

Author : Page 93



_______________________________________________________________________________________________

___________________________________________________________________________________________
Depending on the actual planning need - part or whole of traffic may be transported through
Sigtran and/or LSLs.

MMS Dimensioning

UMS is unified messaging system that takes care of Voice mail as well as Welcome service
functionalities. This interfaces with HLR for locating MT subscribers SMSC on the basis of which
SMS is sent to the mobile in case of legacy mobile and MMS forwards the MMS message to the
mobile itself. Route query dimensionining as in Section 5.2.1.16

= Max(Roundup (Tot * 150/3600/8000/0.4,0),2) MM
5 LSL BHMM

As per RFP Tot
BHMM
= 600000
Therefore MM = 600000*150/3600/8000/0.3 = 11 LSL
5lsl

MCA Dimensioning

Missed Call Alert is detected by UMS server which outdials to Voicemail subscribers a missed call
to the intended recipient of call to notify of the missed call event. As explained bandwidth
required for outdial in Sect 5.2.1.17,

Outdial Erlangs = Tot
BHMCA
* HT / 3600 Erl
min

Per RFP MCA subscribers for one zone = 2184000
Percentage of this subscriber using outdial = 1 % => 21840
Total incoming calls per day = 8
Percent of calls happening during BH = 10 %
Outdial calls in BH = 21840 * 8 * 10 % = 17472
HT
min
assumed = 15 secs
Erlangs of traffic generated due to outdial = 17472 * 15 /3600 = 72.8 Erl
Number of trunks needed for 5 % blocking = 80 trunks = 3 E1 s

Welcome Server Dimensioning

Welcome server is employed in welcoming roamers into the current network. As explained in Sec
5.2.1.18, the LSL requirement is,

Welcome Server LSL reqmnt
= Roundup(Tot
Avmsg
* Tot /3600 / 8000 / 0.3 , 0)
Roam

Where Tot
Avmsg
= (LU +CL +ISD +SAI) * Tot +(SRI +SRI )* Tot
BHLU SM FORWARDSM BHSM

As an eg., plugging values for above events may be approximated as below for one sub/day,
(120 +120 +810 +110)*4 +(270 +110)* 0.5 =4830 Octets /sub/day

Per RFP calls occuring during BH = 10%
Per RFP number of Roamers (5% of population) = 108333
Total traffic to be handled = 108333 * 4830 * 10 % = 53234839
Octets /hour

Author : Page 94



_______________________________________________________________________________________________

___________________________________________________________________________________________
LSL requirement = Roundup ( 53234839 / 3600 / 8000 /
0.3, 0) = 7 LSL

USSD Dimensioning

USSD provided in the network had to cater to a number of services such as personalised services,
Call back services etc. Dimensioning of the same as illustrated under Sec 5.2.1.19, reproduced
below,
= Max(Roundup(Tot * 60 / 3600 / 8000 / 0.3, 0),2) HLR USSD
LSL BHUSSD

USSD is a regional element and the capacities of subscribers it needs to cater to for a
representative region as per RFP is 15,480,000.

Number of USSD req/hr/million subs (given) = 12000 * 20 %
Personalised USSD req for subs base/sec = 15480000 * 12000 * 20% / 1000000
/3600
= 11
Number of Callback req/hr/million subs (given) = 5000
Callback USSD req for subs base/sec = 15480000 * 5000 / 1000000 / 3600
= 22
= (11 + 22) * 3600 = 33 * 3600 Total USSD requests per BH - Tot
BHUSSD

= 33 * 3600 * 60 /3600 / 8000 / 0.3 HLR USSD
LSL
= 1 LSL

USSD MSC = Max(Roundup( 2 * Tot
LSL BHUSSDCB
* 400 / 3600 /
8000 / 0.3, 0), 2)

Total USSD Call Back req/Hr - Tot
BHUSSDCB
= 22 * 3600

= 2 * 22 * 3600 * 400 / 3600 / 8000 / 0.3 USSD MSC
LSL
= 8 LSLs

Author : Page 95

Core Network Design Guide V2.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Core Network Design Guide V2.0

Uploaded by

Copyright:

Available Formats

___________________________________________________________________________________________

Issue :One Date : 20 Nov. 06

You might also like