IMS END to END NETWORK

DIMENSIONING – MODULE 1 –
BASICS OF DIMENSIONING
OBJECTIVE & SCOPE
Objective
Basics of End to End Network
Dimensioning for IMS.

Scope

› Why dimensioning?
› Importance of dimensioning in
network.
› IMS & dimensioning
› IMS Services implementation
› User traffic model
WHY DIMENSIONING?
WHY DIMENSIONING?
› Network Dimensioning is all about ensuring the
right network capacity everywhere & at all times.

› Solution capacity should be measured instead

of node that will help plan the expansion’s
before hitting the thresholds.

› During dimensioning we need to ensure that the

adjacent nodes (nodes which send traffic to IMS
eg, MME in LTE) are configured in a way not to
overload the HSS in this case as an example.

› All SME’s from different domains should work

together to perform the dimensioning of their
domains eg, IMS, EPC, LTE etc as to avoid
surprises later.
DIMENSIONING CHALLENGE
Network dimensioning targets:
› Guarantee end user quality of service
› Minimize the investment for desired QoS

Optimum dimensioning:
• Maximum utilization of network elements
SBG, CSCF, CUDB, IP, MME …
• Accurate forecast of traffic growth
Right capacity at the right places at the right time
• While end user gets desired QoS
• Valid input (not just default traffic model and
assumptions should be used)
Benefits of End-To-End
Network Dimensioning

› Multi vendor, multi technology solution,

covering both the logical (“mobile network”)
and IMS aspects into one product

› Maximize Qo$ by adjusting properly the QoS:

Each $ is spent exactly where and when it is
required

› Adjust investments (minimum CAPEX) by:

– Applying accurate predictions for estimating
future traffic demand.
– Advanced analytical models (accurate prediction
of the network behavior)
– Harmonization in every part of the network (IMS,
EPC, LTE, IP)
– Minimizing engineering and operational costs
(OPEX) thanks to the harmonization and
replicable processes
IMS & DIMENSIONING
INTERFACES & PROTOCOLS
IMS services
implementation
› Session based services
– Voice is such a service
– SIP INVITE used for the set up of the
session
– Normally includes media
› Session less services
– Messaging could be such a service
– SIP MESSAGE used
– No media included
› Application Server based services
– Typically more advanced features
› Group sessions i.e. conferencing etc.
› Client based services
– Typically less advanced features
– Mainly applicable for the control layer
– Media in general from peer to peer
Session set up in IMS (1/4)
PSTN

MTAS IPWorks MTAS

Terminating session
Originating session

MGC MGW

BGCF
S-CSCF I-CSCF S-CSCF

N-SBG
IP IP
A-SBG
A-SBG

IP
Session set up in IMS (2/4)
PSTN

MTAS IPWorks MTAS

Terminating session
Originating session

MGC MGW

BGCF
S-CSCF I-CSCF S-CSCF

N-SBG
IP IP
A-SBG
A-SBG

IP
Session set up in IMS (3/4)
PSTN

MTAS IPWorks MTAS

Terminating session
Originating session

MGC MGW

BGCF
S-CSCF I-CSCF S-CSCF

N-SBG
IP IP
A-SBG
A-SBG

IP
Session set up in IMS (4/4)
PSTN

MTAS IPWorks MTAS

Terminating session
Originating session

MGC MGW

BGCF
S-CSCF I-CSCF S-CSCF

N-SBG
IP IP
A-SBG
A-SBG

IP
Session based services

› Input parameters (user behavior)

– Session attempts / BH (Busy Hour)
– MHT (Mean Holding Time)
– Average BW per session
– Silence suppression / Activity factor
– Service penetration
– Feature penetration i.e. “supplementary services”

The same type of modeling as for voice

 Sessionless in IMS
PSTN

MTAS IPWorks MTAS

Terminating session
Originating session

NoMGC
mediaMGW
Typical example is instant messaging using SIP MESSAGE
BGCF
Also applicable
S-CSCF for SMS over
I-CSCF IP in VoLTE
S-CSCF

N-SBG
IP IP
A-SBG
A-SBG

IP
Presence Use Cases (1/2)

AS AS

NOTIFY
CSCF CSCF

A-SBG A-SBG

IP

One NOTIFY per watcher of status

NOTIFY is sent to each registered terminal separately
Presence Use Cases (2/2)

AS AS

SUBSCRIBE
CSCF CSCF
NOTIFY

One SUBSCRIBE per registered terminal

A-SBG

One SUBSCRIBE per contact in the contact list

IP
One NOTIFY per SUBSCRIBE
One NOTIFY

NOTIFY is sent to each

registered terminal separately
USER TRAFFIC MODEL
Erlang
› Erlang – Unit to measure traffic in telecommunications.

› Statistical measure for

– Carried load
– Offered load
› Carried load
– Average number of concurrent sessions carried by a
resource
– The average load of a resource during a specific time frame
– 0,05 Erlang represent 5% load of a resource
› Offered traffic
– Average number of concurrent sessions
› Unlimited amount of resources
– 5 Erlang represents 5 concurrent session
Erlang B

› A service request that arrives randomly to receive an

exclusive service by a group of service providing elements
› The service request that arrives can be rejected but will
then return again
› No queuing of requests
› Erlang = Arrival rate * Average time of usage
– Numbers/second * seconds
– Numbers/hour * hour
– The Erlang unit is dimensionless
Erlang in Telecom

› Calls arrive randomly

› If no connection is available the user tries again
› The call last for a number of seconds
› Example
– 100 callers
– One call per hour
– Each call last for 360 seconds
› 0,1 E or 100mE per caller
– 1 * 360 / 3600 * 100 = 10 Erlang
– 10 Erlang = 10 concurrent calls on average during the hour
– 10 Erlang -> 10 resources to serve all users without rejection
More definitions

› Values used in the Erlang

calculation is average values
– Mean Holding Time is average
and includes both successful and
unsuccessful calls
– No margins in traffic values – they
should reflect the user behavior
› Grade of Service
– Used to calculate number of
channel based on the Erlang
formula
Using Erlang for voice
calls
TDM interfaces IP interfaces

Caller A Caller B

M-MGW
Memory
CPU
TDM
TDM interfaces
› 10 Erlang
– Needs 10 resources
– 1 resource = 1 time slot
– 10 time slots needed
– A T1 has 24 time slots which means it can carry 24 Erlang
IP
IP interfaces
› 10 Erlang
– Needs 10 resources
– What is a resource in IP?
› Bandwidth per call
– G.711
› X kbps
› This bandwidth is required during the whole call
› 10 * X = Y kbps
› Total bandwidth requirement = Y kbps
› Needed BW / Interface BW
› Silence suppression should be considered
Memory
Memory
› 10 Erlang
– Needs 10 resources
– What is a resource in memory?
› Call footprint
– Each call starts a process
– The process needs a certain amount of memory
› The process stays in the memory during the whole call
› Use an average footprint
› Compare with IP BW calculation
› Needed memory / Available memory
› In case the call process do not reside in the memory for the whole call
another MHT can be used
CPU

› Not using Erlang calculation

CPU
› Capacity measured in the use cases/s
 CPU vs interface

Interface

Interface
Caller A CPU
Caller B

X Erlang

However the interface see the call twice while the CPU see the call only once
Double amount of capacity needed in the interface
Typical traffic model
› Traffic model
– Average Call holding time: 180 seconds

– Busy Hour Call Attempts (BHCA) = 1.7

– On-net to On-net calls: 20%

– On-net to Off-net: 45%
– Off-net to On-net: 35%
– Answered: 80%
– Busy & Unanswered diverted to Voice Mail: 20%

– Feature Usage: 1%
– Abandoned Calls: 12%
– Registration Interval: 3600 seconds
– Client Reg Event Subscription Interval: 3600 seconds
– Voice Mail (Message Summary Event Subscription) :
once every 12 hours
– Average num. of VMN per sub per second: 0.0000167
– Average number of INVITEs to VMS per sub per
second: 0.000057
SUMMARY
SUMMARY

› Why dimensioning
› IMS and dimensioning
› Session and session less services, AS and client based
services
› User Traffic Model
QUIZ
PROPERTIES
On passing, 'Finish' button: Goes to Next Slide
On failing, 'Finish' button: Goes to Next Slide
Allow user to leave quiz: After user has completed quiz
User may view slides after quiz: At any time
User may attempt quiz: Unlimited times