Download - Next Generation Network Modeling
-
8/9/2019 Next Generation Network Modeling
1/14
-
8/9/2019 Next Generation Network Modeling
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
-
8/9/2019 Next Generation Network Modeling
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.
-
8/9/2019 Next Generation Network Modeling
4/14
212 Bell Labs Technical Journal DOI: 10.1002/bltj
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.
-
8/9/2019 Next Generation Network Modeling
5/14
DOI: 10.1002/bltj Bell Labs Technical Journal 213
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.
-
8/9/2019 Next Generation Network Modeling
6/14
214 Bell Labs Technical Journal DOI: 10.1002/bltj
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.
-
8/9/2019 Next Generation Network Modeling
7/14
DOI: 10.1002/bltj Bell Labs Technical Journal 215
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
IMSIP Multimedia Subsystem
IPInternet Protocol
Domaingateway
node
Figure 3.Peer-to-peer and client-server bearer traffic.
-
8/9/2019 Next Generation Network Modeling
8/14
216 Bell Labs Technical Journal DOI: 10.1002/bltj
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.
-
8/9/2019 Next Generation Network Modeling
9/14
DOI: 10.1002/bltj Bell Labs Technical Journal 217
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.
-
8/9/2019 Next Generation Network Modeling
10/14
218 Bell Labs Technical Journal DOI: 10.1002/bltj
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
-
8/9/2019 Next Generation Network Modeling
11/14
DOI: 10.1002/bltj Bell Labs Technical Journal 219
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
-
8/9/2019 Next Generation Network Modeling
12/14
220 Bell Labs Technical Journal DOI: 10.1002/bltj
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
IMSIP Multimedia Subsystem
IPInternet Protocol
P-CSCFProxy CSCFTASTelephony application server
S-CSCFServing CSCF
Figure 5.
Sessions library: composite IMS-to-IMS call session data.
-
8/9/2019 Next Generation Network Modeling
13/14
DOI: 10.1002/bltj Bell Labs Technical Journal 221
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.
-
8/9/2019 Next Generation Network Modeling
14/14
222 Bell Labs Technical Journal DOI: 10.1002/bltj
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.