Reconciliation of IMS to OPNET IMS

Model
J. Wright
Faculty of Information Technology, Monash University
#21116830, jwri6@student.monash.edu.au

I. INTRODUCTION
This paper documents the findings of an initial investigation of the work needed to complete a suitable
simulation of MIP (Mobile IP) and SIP (Session Initiation Protocol) integration within an IMS-based network
using the OPNET (OPNET Technologies) modelling technology.

II. APPROACH
The current OPNET product ships with a number of pre-defined models. Further to this, are models available
to download from OPNET and independent websites. Some of these are free to use, other must be paid for.
Two models in particular have been identified as suitable feely available candidates for inclusion in the
research, and targets for further scrutiny: mobile_ip (MIP) and sip_ims_model (IMS). Before using these
existing models it is important to understand their strengths and limitations, in particular how they deviate from
the standards specified within the research proposal. Furthermore, it is sensible to appreciate the necessary
changes to the models and any further development needed to create a working simulation.

III. IMS MODEL

OPNET ships with a standard SIP server model which includes rudimentary support for a SIP proxy. The
model comprehends many (but not all) SIP messages and has no SIP Registrar functionality. Furthermore, it is
unsuitable for modelling an IMS architecture because:
 Only one intermediary SIP Proxy is supported whereas IMS will have more.
 There is no support for operator domains, servicing areas and roaming.

 There is no concept of the Call Session

Control Function servers or their control messaging and
scheduling.
 Delays caused by IMS specific processing is
not accounted for.

In an attempt to introduce IMS specific

requirements to the existing OPNET SIP model three
researchers created an OPNET IMS model(Vázquez,
Hernández, & Fernández, 2005). The IMS model,
available from the OPNET website, is the work of
researchers from the Dpto. Ingeniería de Sistemas
Telemáticos at Universidad Politécnica de Madrid. It
Figure 1. CSCF Server Parameters
was published in October 2005, during which time
3GPP released the technical specification 22.228 version 7.2.0 which deals with the requirements for IMS
 Figure 3. IMS Based OPNET Scenario with Roaming

under Release 7 Stage 1. It is unlikely the developers targets any particular release. The model’s make-up and
components are generic to all IMS implementations.
The new model addresses the SIP Server model deficiencies and adds support for the three core IMS
CSCF servers (Interrogating CSCF, Proxy CSCF and Serving CSCF) and their interworking as well as
allowing more than one SIP server to control the flow of messages between users. Furthermore, support is
added for roaming and multiple domains through the introduction of domain and serviced area concepts.
Finally, functionality to inject delays into the simulation is possible in order to emulate the processing latency
encountered in a typical IMS environment (e.g. querying the HSS).
Figure 1 shows the extra parameters included in the standard SIP Proxy Server model which allows it to
simulate an IMS CSCF server. The server is
configured as a Serving-CSCF with the network
operator’s domain ‘operador1.es’ and within the
operator’s serving Area Name of ‘Ciudad Real’. The
domain is simply a way of grouping servers and users,
with the area sub-grouping within a parent domain -
which is supposed to represent a pseudo-geographical
area, or cell. This way, the servers can recognise their
direct counterparts in an IMS configuration.
Figure 2 shows a similar illustration, this time for
the user agent. As with the SIP Proxy Server in Figure
1, the network operator is ‘operador1.es’. However, to
support roaming a user agent node also has the ability
to specify the operator and servicing area in which it
Figure 2. User Agent Parameters
resides. A user agent in a foreign operator’s domain
would specify the foreign domain in the ‘Current Domain’ parameter, and similarly with the ‘Area Name’.

James Wright 2 Integrated IMS Simulation • Nov 2008

 OPNET provides for defining different scenarios, or simulation configurations. The IMS model comes
with three. Figure 3, illustrates clearly some of the constructs made possible from the development of the IMS
specific nodes described above: SIP Proxy Server and User Agent. Two domains, Madrid and Zamora, are
separated by the internet. Each domain contains three CSCF servers (one Interrogating-CSCF, one Proxy-
CSCF and one Serving-CSCF) and one user. User Illamante in the Madrid area, is in his ‘home’ domain,
operador1.es. Whereas, as can be seen from Figure 2, which is the definition of user Ilamado, who is currently
in the Zamora area, in a foreign domain, operador2.es. Iit shares a ‘home’ domain (operador1.es) with user
Illamante.

Figure 4. IMS-Based OPNET Scenario with Serving Areas

Figure 4, shows another scenario, this time one which is played out within the same operator domain, but
containing more than one IMS-based serving area: Ciudad Real and Madrid.
We should note that the application definitions along with the user profiles are included in any scenario.
They define the packet generation profile to fine-tune
network loads. Importantly, it is the users which execute
the applications, no application processing is undertaken
within the server structure. Figure 5, shows the input
into a definition of a resource heavy email session.
Even with these important additions the IMS model
is a scant reflection of the full IMS specification. It is
essentially three SIP proxy servers to which have been
added the ability to recognise each other and exchange a
Figure 5. Email Application Definition number of packets. The next section details a closer
reconciliation of the minimum functionality specified
for any IMS implementation against the IMS model.

A. IMS Model Reconciliation

James Wright 3 Integrated IMS Simulation • Nov 2008

 In this section the OPNET IMS model functionality is reconciled against 3GPP’s IMS specification. The
specification will be the technical specification Release 8, from September 2008. This is the latest release from
3GPP and presents the accumulation of functionality and service requirements from nearly a decade of
development.

James Wright 4 Integrated IMS Simulation • Nov 2008

Table 1. Reconciliation of IMS Functional Specification to OPNET IMS Model

Id Category Sub-Category Specification Ref† IMS Model Deviation

1 Architecture BGCF Determines the next hop for SIP routing. 4.6.4 SIP messaging flows between UE and BGCF’s are not supported.
CSCF functions.
2 Architecture HSS IMS specifies a Home Subscriber Service to provide 4.2.4 A forced delay simulates interaction No HSS. Delay between S-CSCF and HSS not
persistent subscriber data and between I-CSCF and HSS. modelled. S-SCCF uses the HSS to locate the
authentication/authorisation services. Application Server and obtain QoS and
authorisation/Filtering data.
3 Architecture I-CSCF An Interrogating CSCF (I-CSCF) server shall act as the 4.6.2 A SIP server designated as the I-CSCF acts Compliant.
point-of-contact for an operator’s domain or service area as the point-of-contact for an operator’s
from outside the operator’s domain. domain or service area.
4 Architecture Identification IMS specifies that CSCF, BGCF and MGCF entities 4.3.4 CSCF entities are identified by type within URI are not used.
shall be identified by valid SIP URIs. an operator’s domain and area. They are
unique.
5 Architecture Identification Application Services shall be identified by Public 4.3.6 Applications are identified by their profile Service Identity only loosely supported.
Service Identity in the format sip:chat@example.com. name.
6 Architecture MRFC Multimedia Resource Function Controller’s (MRFC) act 4.7 Media flow directly between CSCF and UE. MRFC’s are not supported.
to control the flow of media .
7 Architecture MRFP Multimedia Resource Function Processor’s (MRFP) 4.7 Media flow directly between CSCF and UE. MRCF’s are not supported.
process media flows for processing, mixing and
sourcing.
8 Architecture Multi-Devices IMS supports the ability of a user to access services via 5.0 Only devices are modelled, even though Users are not modelled.
multiple devices simultaneously. they are referred to as ‘users’.
9 Architecture Multi-User Each IMS subsystem can support multiple subscribers. N/A SIP clients reference the counterparts by Only one subscriber is addressable per IMS subsystem.
using the IMS subsystem they are attached
to. Only one user receives messages per
IMS subsystem.
10 Architecture P-CSCF The Proxy CSCF (P-CSCF) server shall exclusively 4.6.1 A SIP server designated as the P-CSCF Limited SIP proxy functionality.
interact with the UE and behaves as a SIP proxy server. accepts messages from the UE and relays
them to the S-CSCF or I-CSCF.
11 Architecture Roaming Users should be able to access services within IMS on 5.0 User equipment can access IMS services in Compliant.
the home or foreign networks either the ‘current’ or ‘home’ domain.
12 Architecture S-CSCF A Serving CSCF (S-CSCF) server shall perform all the 4.6.3 A SIP server designated as the S-CSCF Limited session control functionality.
session control functions on behalf of the UE. relays messages to the UE.
13 Architecture Server The P-CSCF should forward SIP messages to the S- 4.6.1 | The UE specifies its home domain and there Registration process not supported.
Function CSCF specified by the UE on registration. A S-CSCF 5.1.2 is only support for one CSCF server per
shall be assigned to a UE upon registration. Area/Domain
14 Architecture Server There may be multiple I-CSCF’s in a domain. DNS is 4.6.2 Multiple I-CSCF’s are allowed in a domain DNS is not supported. Multiple I-CSCF’s not
Function used to specify an I-CSCF. but are unique within a specified supported in a domain area.
geographical area per domain.
15 Architecture Server The I-CSCF allocates an S-CSCF to a SIP registration 4.6.2 I-CSCF passes the SIP requests to the first No HSS. I-CSCF forwards any message received to the
Function (with the help of the HSS). S-CSCF found within its Area/Domain. first S-CSCF found within the operator’s domain and
service area.

James Wright 5 Integrated IMS Simulation • Nov 2008

Id Category Sub-Category Specification Ref† IMS Model Deviation
16 Architecture Server The S-CSCF forwards media requests to a BGCF for 4.6.3 Only UE’s directly connected to a domain No BGCF or interface to Core Network or PSTN.
Function routing to a PSTN. router are serviced.
17 Architecture Server The S-CSCF may behave as a SIP Registrar (IETF RFC 4.6.3 The S-CSCF is stateless. S-CSCF does not support registration of users.
Function 3261).
18 Architecture Server The S-CSCF may behave as a SIP Proxy (IETF RFC 4.6.3 The S-CSCF behaves as a SIP proxy. Compliant.
Function 3261).
19 Architecture Server The S-CSCF may behave as a SIP User Agent (IETF 4.6.3 The S-CSCF forwards traffic on only. S-CSCF does not support originating SIP transactions.
Function RFC 3261).
20 Architecture UE The User Equipment (UE) can support IPv4 only, IPv6 5.1‡ IPv4 is used throughout. Compliant.
only, or both.
21 Architecture Visited Ability to access services of Home S-CSCF from foreign 4.2.3 User equipment can access ‘home’ domain Compliant.
Network IMS networks. from foreign domains.
22 Messaging De- UE’s should de-register from the IMS before 4.5 TCP Session timeout. No deregistration process.
Registration deactivating from a bearer.
23 Messaging IP Version Optimum use of IPv6. ‡1 5.1 IPv4 is used throughout. Not strictly Compliant.
24 Messaging IP Version The IMS elements can support IPv4 or IPv6 at the ‡1.5.1 IPv4 is used throughout. Compliant.
operator’s discretion.
25 Messaging Mobility Changes in user IP address result in a reset of any active 4.3 IP addresses are allocated by OPNET at Mobility is not supported.
SIP sessions and triggers a re-registration. start-up and do not change.
26 Messaging P-CSCF UE’s should be able to discover the P-CSCF assigned to 4.5 | Discovery process involves iterating over Option 3, pre-configuration is used. Discovery process
Discovery them. Via either 1. Network establishment 2. DHCP or 5.1.1 nodes until it finds the first P-CSCF server does not support more than one P-CSCF.
3. Pre-configuration. in the domain specified by the user as the
home.
27 Messaging QoS End-to-End Quality of Service should be supported. 4.2.5 All messages are sent on best-effort. No Service Level Agreements exist.
28 Messaging Registration UE’s should register with the IMS 4.5 TCP Session is established. No registration process.
29 Messaging Re- UE’s should re-registrar upon changing IP address. 4.5 Entity IP address are allocated by OPNET Mobility Not supported.
Registration on start-up and not altered.
30 Messaging Signalling Session control shall be based on SIP. 4.4 Sessions are based on TCP connections. Weak definition of SIP session.
Messages are relayed between CSCF
servers (SIP servers) to end user.
31 Messaging SIP IMS specifies that a subscriber has a private and public 4.3.3 The first user found within an operator’s Subscriber not referenced directly at all.
Addressing user identity. area receives the message.
32 Messaging SIP IMS specifies a unique combined Public User Identity 4.3.3.2a The first user found within an operator’s User identities are not used.
Addressing and UE identifier to eliminate forking. area receives the message.
33 Messaging SIP Forking IMS allows for multiple destinations for a given Public 4.2.7 The first user found within an operator’s Multiple users within an operator’s area are not
User Identity. area receives the message. supported.
34 Messaging SIP SIP specifies a Registration message between client and 10.2§ Registration is simulated via a TCP session Initial SIP registration procedure not included.
Registration server. between client and server.
35 Messaging SIP Re-Invite SIP specifies a Invite message to update server with new 14§ Omitted. No mobility support.
client details.
36 Services Application There will be latency when accessing services from the 4.2.4 Services are provided by the SIP servers No forced delay.
Delay application layer. IMS uses the ISC interface and SIP with no message delay.
control for this.

James Wright 6 Integrated IMS Simulation • Nov 2008

Id Category Sub-Category Specification Ref† IMS Model Deviation
37 Services Application IMS specifies there to be servers within a logical 8.0‡ Services are provided by the SIP servers. No application layer.
Servers application layer providing services.
38 Services Identification A unique IMS Communication Service Identifier (ICSI) 4.13 Applications are defined within the No application layer. Applications are pre-defined and
shall provide identification of IMS services. Applications node and further specified run within the UE.
within the Profiles node, but run within the
context of the UE.
39 Services Origination Application Servers can originate calls to users. E.g. a 4.2.4 Applications are originated from the UE. No application layer.
calendar function reminding users of key appointments
and dates.
40 Services Profile Expected to have wide variety of usage profiles. N/A Mostly single dimension user profiles. User profiles are limited in scope.

† Reference refers to the 3GPP TS 22.340 v8.1.0 (2008-03); IP Multimedia Subsystem (IMS); Stage 2; Release 8 (3GPP, 2008)
‡ Reference refers to the 3GPP TS 23.221 v8.2.0 (2008-09); Architecture Requirements; Release 8 (3GPP, 2008)
§ Reference refers to the IEFT RFC 3261; SIP: Session Initiation Protocol (Rosenberg, et al., 2002)

James Wright 7 Integrated IMS Simulation • Nov 2008

 IV. MOBILE IP
As with the SIP model, OPNET ships with a standard MIP server model. This model only supports IPv4 and
has no facility for return routability optimisations. Moreover, the mobile node uses 802.11 technologies to
attach to the network. The scenario that most closely resembles our requirements, shown in Figure 5, has a
Role Playing Game (RPG) server communicating with the Mobile Node (MN) by using its home address
(HoA). All packets are directed to the home agent (HA), and depending up on the location of the MN, packets
are forwarded directly to it, or via a connected Foreign Agent (FA).

Figure 6. IPv4-Based Mobile IP OPNET Scenario with Movement Trajectory

V. DEVELOPMENT
The development is split between work that is required to simulate the location update strategy and the work
needed for the location query strategy.
1) Location Update
a) Combine the IMS and MIP infrastructures.
i) Create a single scenario with the SIP end user within the Mobile Node subnet.
b) Add SIP Registration messages
i) The IMS model works using domain and area names. Registration alters the IP address. The
name to IP address cache will have to be updated. It is part of the OPNET TPAL process.
2) Location Query
a) Combine the IMS and MIP infrastructures.
i) Create a single scenario with the SIP end user within the Mobile Node subnet.
b) Add MIP Route Optimisation message
i) The location query strategy works by querying the HA using a Binding Request message
containing the HoA of the device we wish to know the current location of. The return message
the Binding Update message from the HA contains the HoA, CoA and Lifetime. It is this data
which is used to update the SIP layer with the latest information of the whereabouts of the user

James Wright 8 Integrated IMS Simulation • Nov 2008

 equipment. The name to IP address cache will have to be updated. It is part of the OPNET TPAL
process.
ii) The S-CSCF will have to initiate the exchange upon receipt of an SIP INVITE. This is part of the
application process.

VI. REFERENCES
3GPP. (2008). Architecural Requirments TS 23.221 v8.2.0 Release 8. Technical Specification Group Services
and Sytems Aspects. 3GPP.
3GPP. (2008). IP Multimedia Subsystem (IMS) TS 23.228 v8.6.0 Release 8 Stage 2. Technical Specification
Group Services and System Aspects. 3GPP.
OPNET Technologies. (n.d.). Retrieved Nov 17, 2008, from Opnet.com: http://www.opnet.com/
Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., et al. (2002). SIP: Session
Initiation Protocol. IETF.
Vázquez, E., Hernández, A., & Fernández, J. I. (2005). SIP – IMS Model for OPNET Modeler. Universidad
Politécnica de Madrid, Dpto. Ingeniería de Sistemas Telemáticos. Universidad Politécnica de Madrid.

James Wright 9 Integrated IMS Simulation • Nov 2008