Next Generation Network Modeling

8/9/2019 Next Generation Network Modeling

1/14


2/14

210 Bell Labs Technical Journal DOI: 10.1002/bltj

can be used to determine application impact as part of

a comprehensive design, capacity planning, or busi-

ness case analysis. For a given application mix, ACTM

provides models for signaling and bearer functionalcall paths and calculates:

Signaling traffic load at each signaling functional

element,

Bearer traffic load at network edge routers/switches,

and

Aggregate point-to-point traffic matrices.

In developing the modeling technique, we iden-

tified the key input parameters that impact application

traffic (with defaults when possible) and created a

library of application building blocks. ACTM allows

these building blocks to be combined in flexible waysto model a new application quickly and provides a

method for calculating signaling and bearer traffic

based on the model. ACTM can then combine the

traffic from a set of applications with different media

types and non-coincident busy hours.

ACTM is generic enough to be able to handle

applications that are currently unknown. It also

enables the designer to perform what if studies to

look at the trade-offs between different network

deployments and to determine the impact of uncer-

tainty in various parameters.

The Control Plane

The NGN architecture is based on separation of

the application and control planes from the under-

lying bearer transport plane. The control plane in

NGNs may be architected either as a softswitch-based

implementation or as an IP Multimedia Subsystem

(IMS)-based implementation with many functional

elements that can be deployed in a distributed fash-

ion. In this paper, we will focus on the IMS archi-tecture in our examples for the control plane. IMS

helps service providers offer next-generation serv-

ices to their customers by providing a generic ses-

sion handling control structure enhanced by a

number of application enablers. In addition, the con-

trol plane is largely independent of the access device

and network.

IMS assumes an underlying IP connectivity net-

work for its control signaling and utilizes a number of

protocols, notably the Session Initiation Protocol (SIP),

H.248 for gateway control, and Cx for database queries.IMS is also designed to provide control and bearer

interworking with public switched telephone networks

(PSTNs). In this way, many applications can be offered

to numerous device types, and basic services will work

across the IMS-to-PSTN network boundary.

The application and control planes have been bro-

ken down into distinct functional entities, which can

be highly distributed in terms of implementation and

physical location. The signaling protocols are string-

based, with many optional parameters, and can con-

tain a significant amount of addressing and routinginformation. The result is a signaling traffic load that

consists of many messages that can be relatively large

in size. For example, a simple Voice over Internet

Protocol (VoIP) call between two end points in an IP

Multimedia Subsystem control architecture can

involve 140 messages that average over 1000 bytes

Panel 1. Abbreviations, Acronyms, and Terms

ACTMApplication characterization and trafficmodeling

CSCFCall session control functionHSSHome subscriber serverIMSIP Multimedia Subsystem

IPInternet ProtocolLANLocal area networkMGMedia gatewayMPLSMultiprotocol label switchingNGNNext-generation networkPDFPolicy decision function

PSTNPublic switched telephone networkQoSQuality of serviceRACFResource and admission control functionRFIRequest for informationRFPRequest for proposal

RLSResource list serverSCIMService capability interaction managerSIPSession Initiation ProtocolTASTelephony application serverVoIPVoice over Internet Protocol


3/14

DOI: 10.1002/bltj Bell Labs Technical Journal 211

in length. The load on each functional element

(e.g., call session control function (CSCF), home sub-

scriber server (HSS), or media gateway (MG)) can

vary greatly depending on the mix of applications,

and how they are used. So for the control plane, it is

important to estimate the signal processing load at

each of the signaling control functional elements, aswell as the load and routing of the signaling traffic

over the bearer transport plane.

The key factors in determining the amount of

signaling traffic for each application are described

below:

The generic call flows associated with an applica-

tion. These have been modeled for a set of com-

mon applications and are stored in a library. New

applications can be modeled more quickly by

using a set of application building blocks.

A set of generic application parameters thatinclude the number of times a subscriber is likely

to invoke the application, the length of each ses-

sion, and the number of end points involved.

These parameters have default values for common

applications if the exact values are unavailable.

The number of subscribers, the predicted take

rates for each application, and the locations at

which they connect to the network. This infor-

mation is specific to a particular providers imple-

mentation and must be obtained from the

providers existing network data and marketingforecasts.

The traffic profile which describes how the appli-

cation traffic varies over the course of a day.

Default traffic profiles obtained from public data

are provided.

The QoS and reliability requirements. Defaults

from standards or regulatory bodies can be used.

The degree to which the traffic crosses network

boundaries. This is specific to a particular imple-

mentation and must be specified by the provider.

In summary, NGN control plane traffic modelingintroduces a number of complexities:

It has a complex call processing architecture:

Functionality is distributed,

Flexibility in location/grouping of functions,

Applications increasingly traverse multiple

networks and technologies.

It has dynamic usage patterns:

Flexibility in subscriber locations (roaming

and nomadicity),

Variety of subscriber devices,

Multiple media types (voice, video, data),

Non-coincident busy hours of the various

applications, and Third party application providers with servers

located behind a gateway.

NGN signaling traffic and capacity engineering

complexity must be simplified to deliver the promise

of revenues through migration and rapid introduc-

tion of new services while maintaining the high level

of reliability and QoS that telecom customers have

come to expect. The modeling presented in this paper

was undertaken to address this problem.

The Bearer PlaneThe bearer plane in NGN is packet-based and gen-

erally assumed to use Internet Protocol (IP) over one

or more lower-layer protocols such as Multiprotocol

Label Switching (MPLS) or Ethernet. Estimating the

amount of traffic produced by a single application in

this environment can be a complex job and involves

consideration of a number of factors. These factors

have been modeled as input parameters, and, when-

ever possible, default values of the parameters for

known applications are provided.

The key factors used to model the traffic flows arebriefly described in the following. All of the factors

used in determining the signaling traffic described ear-

lier are also used for the bearer plane. In addition, the

following must also be specified:

Traffic descriptors which describe the mean and

peak bandwidth required for an individual ses-

sion, and the degree of burstiness of the traffic.

These values can be provided for some common

applications for which empirical data is available.

For new applications it must be estimated on the

basis of similar applications. Whether the sessions involved in an application

are peer-to-peer between two or more end

points or client-server between an end point

and some type of network server. This informa-

tion is stored in the application library when an

application is defined.


4/14


When multiple applications are carried over

the same bearer infrastructure, as will normally be the

case in NGNs, the traffic estimation becomes even

more complex. The traffic for the individual applica-

tions must be overlaid using statistical multiplexing

methods, and a composite picture obtained. On the

basis of the relative take rates of the various applica-tions and their traffic profile, the composite load and

busy hour for the network nodes can be calculated

and used for engineering purposes. This information

becomes input to the design process that routes the

traffic through the network.

Methodology

The methodology used to address the problem of

NGN application traffic modeling is based on the fol-

lowing procedure. It is important to note that step 2

and step 3 are required only oncethe first time a

new application is definedand the results are stored

in a library that can be reused for new studies.

1. Select the set of applications to be supported by

the NGN.

2. Determine the functional network architecture

for each application (library).

3. Model the signaling and bearer call flows for each

application (library).

4. Characterize each application by setting parame-

ters on the basis of how it will be used in the

NGN, and the number and location of subscribers.5. Calculate the number of sessions of each type,

and the sources and sinks of the traffic.

6. Calculate the total signaling load at each signaling

functional element, and the bandwidth of the sig-

naling load that must be carried over the bearer

plane.

7. Determine the location of various control plane

servers (predetermined or using an external

model).

8. Calculate the total bearer load at the edge nodes

of the network where sessions are originated orterminated. Add the signaling load at appropri-

ate nodes.

Step 1: Select the Set of Applications

For our project, we chose to model a set of appli-

cations that are planned for deployment by many

service providers. These include PSTN-like services

such as VoIP and associated telephony features; IMS

features such as presence, location, and instant mes-

saging; data services such as Web browsing; and trans-

port services.

Step 2: Determine the Functional Network Architecture

In order to model the network traffic for an appli-

cation, it is necessary to specify the functional net-

work architecture. This consists of the set of network

servers and databases which control the application,

the set of network elements used to route the bearer

traffic, and the customer equipment and software

clients. For the set of applications that we modeled,

we assumed a generic IMS network control architec-

ture based on 3GPP* standards and an IP-based trans-

port network.

For each application, it was assumed that an

application server was required, such as the telephony

application server (TAS) for telephony applications,

and a presence server and resource list server (RLS)

for presence applications. Each application can be

modeled by determining the end points, the network

servers/databases that must communicate, and the

protocols that are used. In most cases there are mul-

tiple functions and protocols involved.

Step 3: Model the Signaling and Bearer Call Flows

The next step is to determine the signaling and

bearer call flows between the functional elements ofthe network architecture. For modeling the signaling

control plane call flows, we utilized a systematic

building-block methodology.Figure 1 illustrates the

concept of control plane building blocks. Each appli-

cation is composed of several session flows. A session

flow is identified by characterizations of network

interconnection, subscriber device type, and applica-

tion feature and is a complete end-to-end description

of all messages exchanged between all network ele-

ments required to set up, execute, and tear down an

application session.Each session flow is composed of several atoms.

An atom consists of a set of messages exchanged

between a small number of functional network

elements to execute a specific task, e.g., set up the

originating leg of a session or query a database.


5/14


The contents of the atom include the network ele-ments, the messages and protocols used, message sizes,

processing delays, originating/terminating message

segment, and subscriber device roaming behavior.

These atoms can be reused in different call flows

in various permutations. The reusability of the atoms

makes it easier to model new applications without

having to recreate all of the detailed modeling. This

speeds up the process of defining new applications,

and further automation of this capability is possible.

For example, the consumer VoIP application can

have 24 possible session types depending on the endpoints of the call (e.g., IMS-to-IMS, IMS-to-PSTN, or

PSTN-to-IMS), how the call terminates (e.g., success-

fully, unsuccessfully, or redirected), and whether cer-

tain features are invoked (e.g., call hold or call waiting).

With the building block approach of atom-

session-application, a library of session flows and mes-

sage flow atoms can be developed and systematically

reused for IMS control plane traffic analysis. This

reduces the complexity of modeling the signaling call

flows and results in a faster and more consistent

analysis of IMS control plane traffic. Figure 2 illus-trates the atom-session-application architecture of two

applicationsVoIP and instant messaging. It shows

that atoms are reused and different sessions are devel-

oped as needed. In the set of applications we have

modeled, there are 80 unique sessions or call flows

that are made up of 75 unique atoms. Each atomrecurs in an average of six different sessions, and some

in as many as 50 sessions. Experience has shown

the reusability rate of atoms to be quite high. As more

applications have been modeled, session reusability

has also been significantly improved.

For modeling the bearer call flows, when each

session type is defined in the library, it is specified as

either a peer-to-peer session or a client-server session.

For peer-to-peer applications, the end points will nor-

mally be a pair of subscriber devices. For client-server

sessions, end points will often be a subscriber deviceinteracting with a server but may also be a pair of

servers interacting with each other. Figure 3 illus-

trates peer-to-peer bearer sessions and client-server

bearer sessions for both in-domain and out-of-domain

connections. The session type information indicates

the end points between which the bearer traffic must

be routed, and it is used to construct the node-to-

node traffic matrices that are used in the design of

the network and the routing of traffic. The percentage

of traffic that crosses domain boundaries must be

routed through one or more domain gateways thatinterconnect the two domains.

Step 4: Characterize Each Application

Set parameters on the basis of how they will be

used in the NGN. There are a number of parameters

Applications Sessions Atoms

Application A

Session flow

Session flow

Session flow

Message atom

Message atom

Message atom

Message atom

Message atom

Figure 1.Concept of building blocks.


6/14


that can be set for each application that will be used to

calculate the number of sessions of each type; the

characteristics of the sessions, including duration and

bandwidth requirements; and QoS requirements.

Wherever possible, the parameters have default val-

ues in the library for each application which can be

modified. The model is highly parameterized to allow

for customization.

VoIP

IM

ApplicationSession flowAtom

Sessions for VoIPAtoms for IMS_IMS_Call Session

Different sessions* are needed for IM

*Note: Sessions are also highly reusable among IP multimedia services applications.

EtoEEnd to End

IMInstant messaging

IMSIP Multimedia Subsystem

IPInternet Protocol

PSTNPublic switched telephone network

VoIPVoice over Internet Protocol

Atoms are highly reusable

Consumer_VoIP

EtoE_Message_Session_Relay_Protocol

IMS_IMS_Call

IMS_PSTN_Call

PSTN_IMS_Call

PRACK_T

PRACK_O

PROGRESS_O

PROGRESS_T

INVITE_T

DNS_O

INVITE_O

ApplicationSession flowAtom

Instantmessaging

Session_Based_IM_Conference

INVITE_O

DNS_O

INVITE_T

MSRP_V

RINGING_T

RINGING_O

ANSWERSUP_T

IM_Register

Figure 2.Examples of atom-session-application architecture and atoms reuse.


7/14


Step 5: Calculate the Number of Sessions

The ACTM engine will compute the number of

sessions of each type, and the sources and sinks

of the traffic, i.e., where it originates and terminates.

It does this on the basis of data input describing the

network topology, the number and location of sub-

scribers of each type, and the parameters described

earlier. The node data will indicate how many sub-

scribers with each type of subscriber device are located

at each node. The take rate indicates the percentage of

these that subscribe to each application on the basis of

device type. The average number of times per day

that an application is invoked, along with the daily

traffic profile and holding time, are all used to calcu-

late the number of simultaneous sessions originated

and terminated at each node for each hour of the day.

Depending on the type of application, there may

be additional parameters used to calculate the number

of each type of session. For example, applications that

use contact lists, such as presence-based applications,

will have varying numbers of sessions depending on

the average length of the subscribers contact list, and

how frequently the list is updated.

Step 6: Calculate Total Signaling Load

A transform function is now used to combine

the number of sessions of each type at each node in the

network with the signaling call flows described in step

3 to determine the signaling load at each functional

network element, and the messages between each sig-

naling element pair. The amount of traffic from all of

the applications is then consolidated to get a complete

picture of what is happening at each functional net-

work element type, and the amount of signaling traf-

fic that must flow between any two functionalelement types, i.e., the bandwidth of the signaling

load that must be carried over the bearer plane.

Step 7: Determine the Location of Control Plane Servers

In order to determine the sources and sinks of sig-

naling traffic, the model must have input the location

Metro 2

Backbone

Metro 1

ENA ENB

ENP

Peer-to-peer sessions

Out-of-domain

Client-server sessions and IMS signaling

Metro 3

Out-of-domain traffic

(GW)

END

(GW)

(GW)

(GW)

(GW)

In-domain

In-domainOut-of-domain

ENC

ENQ

ENZ

ENR

ENEndpoint

GWGateway


IPInternet Protocol

Domaingateway

node

Figure 3.Peer-to-peer and client-server bearer traffic.


8/14


of the various signaling functional elements, i.e.,

which of the network edge nodes they are connected

to. This either is pre-specified by the network opera-

tor (and based on many different factors such as avail-

able space, power, and operations personnel) or is the

design output of another model. The traffic loads pro-

duced by the previous step of this model can be usedto perform the design.

Step 8: Calculate Total Bearer Load and Add

Signaling Load

The bearer load is calculated by knowing the loca-

tion of the sources and sinks of each application

demand and the traffic descriptors discussed earlier.

For peer-to-peer sessions within a domain, a weighted

distribution can be used to distribute the traffic pro-

portionally to the product of the demands at each

node pair. For peer-to-peer sessions that have to leave

the domain, however, demand must be routed

through a domain gateway. For client-server type ses-

sions, the demand is between the node where the

subscriber is located and the node where the server is

located, subject to domain boundary constraints

which may involve routing through a domain gate-

way. Once the bearer traffic between each point-to-

point node pair has been computed for each

application, the composite demand for all applications

can be computed. This is normally aggregated by con-

solidating application traffic that has the same or simi-

lar QoS requirements, which can be routed together

through the network.

The signaling traffic must be overlaid on the

basis of the locations of the various signaling ele-

ments to get a complete picture of all network

demands. Much of the signaling traffic is either

between the client and a server or between two

servers. The locations of the servers are needed to

determine whether they are collocated, in which

case all traffic remains on the local area network

(LAN) within the location, or whether they are geo-

graphically separated, in which case the server-to-

server traffic must be routed across the transport

network. A method very similar to the client-server

method described is used to build the traffic demand

matrices for the signaling traffic, utilizing domain

gateways when needed. The signaling traffic is then

aggregated into a single QoS class and overlaid on

the bearer traffic node-to-node demands.

Applications Network Traffic Modeling Example

We illustrate the application modeling technique

described here by showing how the notion of reusable

atoms along with an understanding of an applicationsuse via parameter settings lead to the creation of

demand load quantities on network elements. Let us

suppose that we wish to be able to compute the total

traffic both through and between all the network

functions required for a VoIP Application.

Applications Network Traffic Process

The process, as it would be used in a design tool,

is described in Figure 4. The user of the tool, referred

to as the modeler, is responsible for selecting the

applications and entering the parameters. When pos-

sible, default values are provided for the parameters

for pre-defined applications.

The next steps lead to a computation of hourly

session counts for each session within an application at

each node using the traffic profile and other input

parameters. Then, the tool would help the modeler

input parameters for VoIP use that are critical and for

which defaults should not be assumed. Examples

include take rates, as in number of subscribers utilizing

the VoIP application, or the breakdown of on-net and

off-net calling (IMS-to-IMS or IMS-to-PSTN). There

needs to be a mapping of a set of subscribers and their

associated traffic onto a set of network elements within

the network to be designed. This is network-specific

and must be input by the modeler. Other inputs would

have defaults that would be made available to the

modeler but could be changed. A typical example of

defaults for VoIP would be the breakdown of call

attempts into successful and unsuccessful calls and fur-

ther breakdowns into types of unsuccessful calls.

The inputs allow the tool to quantify the num-

ber of daily successful IMS subscriber-to-IMS sub-

scriber VoIP Calls (labeled IMS_IMS_CALL in this

example.) These daily quantities can be used with

selectable hourly distributions, or the traffic profile, to

define hourly session counts. An hourly view of ses-

sions captures the effect of non-coincident busy hour

data in the design process.


9/14


The next step in the process is a transform step

that makes use of the library to derive the traffic load

at each network element by using library data and

the sessions data. An example of a typical load for a

VoIP application would be the message counts in and

out of the various call session control functions

(CSCFs) assigned to the subscribers of these sessions,

and the bearer packets that must be transported

between the two end points. It is this library that is

created by the tool designers utilizing the techniques

of atom-session-application already described.

Using this transform technique over all sessions

composing an application and accumulating hourly

loads provide the total load on an element for that

application. In addition, the amount of signaling and

bearer traffic between any two nodes can be derived.

Furthermore, all applications contributions to ele-

ment load can be derived in a similar fashion.

Sessions to Load Transform Process

The use of the sessions library and an example of

how the library may be implemented in a tool are

described using Table I, Table II, and Figure 5. Adding

applications to the library or augmenting existing

application entries is simplified using the techniques

of reusable atoms and a suitable automated data

transformation technique. Such a technique exists

and was used to create the example data structure

entries discussed in the following.

The library contains a predefined catalog that points

to all sessions that constitute an application. A sample

catalog is shown in Table I. For our VoIP example,

Decomposeapplication into

session types

Calculate # of

daily sessions ateach node

Sessionlibrary

Sessionlibrary

Distributesessions over

day

Determine #simultaneous

sessions

Calculatepoint-to-pointloads (EN-EN)

Accumulate hourly loads at eachnode across all apps

User selectsapplications

Transform hourlysessions to

network elementloads

Repeat for all applications

ENEndpoint

User input parametersNumber ofsubscriptions per node

End user devices

Take rate

Sessions/day

Holding time

Traffic descriptors

Off-net proportion

Defaults provided whenpossible

Traffic profile

Figure 4.Application network traffic process: method for deriving network element loads.


10/14


the session of interest here is the IMS_IMS_CALL. The

library identifies all generic atoms that define this ses-

sion (e.g., INVITE_I_I). For each generic atom, there is

a library entry, which constitutes a data design for the

message flows into a tool-usable format. Examples,

shown in Table II, indicate each element pair (a, b) that

is involved in message flows for this atom. For each

pair, the structure identifies the directionality as well

Application Session Atom Atom description

Consumer_VoIP IMS_IMS_CALL INVITE_I_I INVITE messages between IMS end user deviceand IMS end user device

DNS_O DNS messages at the (IMS) originating sidePROGRESS_I_I PROGRESS between IMS end user device and IMS

end user device

UPDATE_I_I UPDATE messages between IMS end user deviceand IMS end user device

RINGING_I_I 100 Ringing messages between IMS end userdevice and IMS end user device

ANSWER_I_I ACK messages between IMS end user device andIMS end user device

CCF_I_I CCF messages for IMS-to-IMS connection

BYE_I_I BYE messages between IMS end user device and

IMS end user device

CCF_I_I CCF messages for IMS-to-IMS connection

Consumer_VoIP IMS_IMS_CALL_NR INVITE_I_I INVITE messages between IMS end user deviceand IMS end user device

DNS_O DNS messages at the (IMS) originating side

PROGRESS_I_I PROGRESS between IMS end user device andIMS end user device

UPDATE_I_I UPDATE messages between IMS end user deviceand IMS end user device

RINGING_I_I 100 Ringing messages between IMS end user

device and IMS end user deviceCANCEL_T CANCEL messages at the (IMS) terminating side

CANCEL_O CANCEL messages at the (IMS) originating side

Consumer_VoIP IMS_IMS_CALL_BUSY INVITE_I_I INVITE messages between IMS end user deviceand IMS end user device

DNS_O DNS messages at the (IMS) originating side

BUSY_T 486 Busy Here messages at the terminating side

..

Table I. Sessions library: application network traffic process.

ACKAcknowledge

CCFCharging collection function

DNSDomain name system

IMSIP Multimedia SubsystemIPInternet Protocol

VoIPVoice over Internet Protocol


11/14


as the number of messages and number of message

bytes involved. The notation for elements includes a

designation of whether or not the element is in the origi-

nating (-1) or terminating (-2) part of the network.

Once all the atoms are identified for this session,

they are combined to form the total session data view.

Figure 5 shows the messaging load on individual func-

tional element types for a single IMS_IMS_CALL ses-

sion. The last computation needed is that of the session

multiplier for the particular network load required. In

our example, we are looking for the total messages

received and sent by the telephony application server

for this session. Inspecting Figure 5 shows that there

are 56 messages per session. It is then easy to com-

pute the total hourly messages by multiplying by the

session counts previously described. Note that these

calculations provide both loads at a network element,

which is useful for nodal equipment engineering and

point-to-point demands, and useful for network con-

nectivity (e.g., transport) engineering.

In this example, the bearer path is a peer-to-peer

connection between the nodes where the subscribers

attach to the network. Since VoIP is a peer-to-peer

session type, a gravity model can be used to distribute

the traffic within a particular network domain. For

traffic that leaves the domain, the bearer path must

include a domain gateway, which adds further com-

plexity to the calculations. Then, for those calls that

are destined to or from the PSTN, the calls must be

routed through a media gateway that transforms

the packet traffic into circuits. It is easy to see that the

traffic calculations can quickly become complex.

Performing such a process requires a mechanized

tool given the very large number of transforms

required and potentially large number of applications

and subscriber communities being modeled.

Comparison With Other Solutions

Our team has studied the work of several others

who have addressed certain portions of this topic.

Cortes, Ensor, and Esteban [2, 3] developed a simu-

lation tool for IMS signaling traffic that focused on

improving the performance of SIP proxies and opti-

mizing the SIP protocol stack. Davis developed a pricing

model that calculates VoIP call sessions and uses ses-

sions and busy hour metrics to estimate required

Atom name

INVITE_I_I

NEa NEb bytes_a_b bytes_b_a mess_a_b mess_b_a Type

UE-1 P-CSCF-1 1200 500 1 1 SIP

P-CSCF-1 S-CSCF-1 1400 500 1 1 SIP

S-CSCF-1 AS-1 2100 2300 2 2 SIP

I-CSCF-2 S-CSCF-1 500 2000 1 1 SIP

I-CSCF-2 HSS-2 500 500 1 1 CxCode

I-CSCF-2 S-CSCF-2 2200 500 1 1 SIP

S-CSCF-2 AS-2 2900 3100 2 2 SIP

S-CSCF-2 P-CSCF-2 2800 500 1 1 SIP

P-CSCF-2 UE-2 3000 500 1 1 SIP

Table II. Sessions library: example generic atom data.

ASApplication server

CSCFCall session control function

I-CSCFInterrogating CSCF

NENetwork element

P-CSCFProxy CSCF

S-CSCFServing CSCF

SIPSession Initiation Protocol

UEUser equipment


12/14


hardware and configurations for bids and proposals.

Urrutia-Valds, Doshi, Chu, and Saleh developed a

network model to estimate traffic and business mod-

els that estimate network expenses and associated

revenue, which is used to build business cases

and respond to requests for information (RFIs) and

requests for proposals (RFPs). Liu, Kipp, and Kim

modeled applications available on Alcatel-Lucent IMSreleases, which were used to validate design and per-

formance of IMS products and form the basis for a

customer engineering aid. Additionally, some simple

models for calculating SIP signaling flow in IMS and

IP mobile networks are available [1, 4].

As a high-level comparison, these other analyses

had a different focus from our work. They were

intended primarily either to analyze and improve a

set of products or to prepare a customer proposal.

They tended to use simplified call models which did

not include all of the transactions that will be requiredin a full-scale IMS network deployment.

Ongoing Work

Ongoing work in this modeling effort is focused

on two fronts: incorporating more functionality to be

included in the atom-session-application paradigm

outlined and developing an automated application

model creation capability.

In terms of adding functional capabilities, work

is under way to incorporate blending into the model

by creating bottom-up models for the service capa-

bility interaction manager (SCIM) and Parlay gate-

way. Modeling of resource and admission control

functions (RACFs) and policy decision functions(PDFs) is also needed.

The bottom-up technique described also lends

itself to automating the models to be applied to new

applications because of the reusability of atoms and

sessions. An effort is under way to create a user-

friendly methodology that takes application descrip-

tors, decomposes these into appropriate building

blocks, defines new atoms and/or sessions as needed

using the current library, and then combines these

building blocks for the new application.

Conclusions

In this paper we have discussed the need for an

automated modeling capability to facilitate the migra-

tion to NGN architecture and realize the economic

benefits therein. We have developed a modeling tech-

nique, which has been implemented in Java* software

Messages sent and received by function IMS_IMS_Call

0

20

40

60

80

100

120

140

S-CSCF TAS P-CSCF I-CSCF CCF DNS HSS

CSCFCall session control function

CCFCharging collection function

DNSDomain name systemHSSHome subscriber server

I-CSCFInterrogating CSCF


IPInternet Protocol

P-CSCFProxy CSCFTASTelephony application server

S-CSCFServing CSCF

Figure 5.

Sessions library: composite IMS-to-IMS call session data.


13/14


that allows the modeler to assess the impact of deploy-

ing multiple diverse applications onto the same core

infrastructure. This model is based on a detailed analy-

sis of the applications and their control signaling as well

as the bearer packets.

For the control plane, the modeling technique is

based on: A set of reusable signaling building blocks,

A set of parameters that allow modelers to char-

acterize the application, and

An engine for computing traffic loads at signaling

network elements.

For the bearer plane, the modeling technique is

based on:

The traffic descriptors,

The quality of service parameter requirements,

The sources and sinks of traffic, and

Whether it is a peer-to-peer or client-server appli-cation.

The value of this methodology is that it can be

used to help service providers more accurately esti-

mate the amount of signaling and bearer traffic that

will be generated by introducing a new set of appli-

cations in order to prevent extensive over- or under-

engineering, thereby saving capital and/or operational

costs and ensuring adequate QoS. This method uses

the building blocks that the NGN architecture pro-

vides, supplies a library of call flows and application

characteristics, has a user-friendly interface for enteringtraffic parameters and providing default values when

possible, and automates the thousands to millions of

calculations that are required. Further refinements

and automation of the model will provide the basis for

a robust network planning methodology that can be

used to facilitate the transformation to next-genera-

tion networks.

Acknowledgements

This work builds on the efforts of many others

within Bell Labs, especially A. Choubey, M. Chu,

A. Cipolone, M. Cortes, E. Davis, S. Doshi, J. R. Ensor,

J. O. Esteban, P. Gagen, V. Katkar, E. Kim, L. Kipp,

Y. Liu, C. Mayer, T. Morawski, R. Novo, K. Ohl,

A. Saleh, B. Tang, C. Urrutia-Valdes, H. Zhang, and

Z. Zhao. We gratefully acknowledge their input

and contributions.

*Trademarks3GPP is a trademark of the European Telecommunica-

tions Standards Institute.Java is a trademark of Sun Microsystems, Inc.

References[1] H. Chebbo and M. Wilson, Traffic and Load

Modeling of an IP Mobile Network, Proc. 4th

Internat. Conf. on 3G Mobile Commun. Technol.(3G 03) (London, Eng., 2003), pp. 423427.

[2] M. Cortes, J. R. Ensor, and J. O. Esteban, On SIP

Performance, Bell Labs Tech. J., 9:3 (2004),

155172.

[3] M. Cortes, J. O. Esteban, and H. Jun, Diabelli:

An IMS Simulation Tool, Bell Labs Tech. J., 10:4

(2006), 255259.

[4] A. A. Kist and R. J. Harris, A Simple Model for

Calculating SIP Signaling Flows in 3GPP IP

Multimedia Subsystems, Proc. 2nd Internat.

IFIP-TC6 Networking Conf. (Networking 02)

(Pisa, It., 2002), pp. 924935.

(Manuscript approved March 2008)

DEIRDRE DOHERTY is a technical manager at

Alcatel-Lucent in Murray Hill, New Jersey,

with expertise in network architecture,

design, and systems engineering. Her

current work focuses on evolution to next-

generation networks. Previously, she

managed a number of network design and systems

engineering groups in Bell Labs and AT&T engineering

and operations organizations and was responsible for

optical and data networking, intelligent networking,

call processing, and network interconnect. Ms. Doherty

holds an M.S. in electrical engineering and computer

science from Princeton University and an M.B.A. from

Rutgers University, both in New Jersey, and a B.S. in

electrical engineering from Stony Brook University in

New York.

RAYMOND A. SACKETT is a distinguished member of

technical staff in the Network Planning,

Performance, and Economic Analysis Center

of Excellence at Alcatel-Lucent in Murray

Hill, New Jersey. He is currently involved in

IMS configuration and IMS network

planning projects. Most recently he has been involved

in developing planning, growth, and configuration

tools for use by the Alcatel-Lucent Services Business

Group. Mr. Sackett has 35 years of experience in

planning, design, and systems engineering of both

wireline and wireless telecommunications networks.


14/14


He earned a B.S. degree in electrical engineering from

the University of Massachusetts and an M.S. degree in

operations research from the University of California at

Berkeley.

PAUL WU is a distinguished member of technical staff

at Alcatel-Lucent in Columbus, Ohio. He is a

leading expert in IMS transformationmethodology and operational expenditure

(OPEX) and control plane modeling. He has

realized robust risk management practices

throughout Alcatel-Lucent and developed network and

software risk management services for key customers,

which led to increased customer revenue and cost

reductions in the hundreds of millions of dollars. He

holds a B.S. degree in industrial engineering from the

National Tsing-Hua University in Taiwan and M.S. and

Ph.D. degrees in industrial systems engineering from

The Ohio State University in Columbus. Dr. Wu has

written previously for the Bell Labs Technical Journal

and has presented at National Institute of Standards

and Technology (NIST) and Institute for Operations

Research and the Management Sciences (INFORMS)

conferences. He served as keynote speaker for both the

Executive Symposium at the City University of Hong

Kong and the Concurrent Engineering Workshop.

Next Generation Network Modeling

Documents

Transcript of Next Generation Network Modeling