Download as PDF

Abstract—The IP Multimedia Subsystem (IMS) defined by the 3rd Generation Partnership Projects (3GPP and 3GPP2) can be seen as an unmatched standard for delivering multimedia over the Next Generation Networks. IMS has established itself as a foundation for future wireless and wireline convergence. It provides an opportunity to build up an open IP based service platform that will enable an easy and efficient deployment of new multimedia communication services mixing telecom and data services. The architecture facilitates the efficient provision of an open set of potentially highly integrated multimedia services, combining web browsing, email, instant messaging, presence, VoIP, video conferencing, application sharing, telephony, unified messaging, multimedia content delivery, etc. on top of possibly dissimilar network technologies. Interworking with the Internet and legacy networks is also supported. As 3GPP IMS standards are in their evolving state it becomes very essential to test IMS clients during their development on a platform that behaves exactly like an IMS network. All the error conditions which are not possible to check over a live network can be tested on such a test bed. Testing cost involved while working on the operator’s live network is also high. This paper focuses on discussing an efficient architecture for IMS and our experience of building an IMS client test bed using open source elements like OpenIMScore.

I. INTRODUCTION

Many people nowadays are more interested in accessing web and other IP services over their hand-held devices. This shows that end users are getting more experienced with using Internet-based technologies in their everyday lives outside the closed PC world. This opens up new perspectives regarding “Mobile Internet,” especially when transferring broadband services into the wireless communications world. IMS (IP Multimedia Subsystem) has emerged out as a big name in these circumstances. It is an IP-based core network connected to multiple access networks to provide a converged service to wireless, wireline and cable subscribers. Communication services such as multimedia telephony, push to talk and instant messaging are offered by the IMS network over a session initiation protocol infrastructure. With the development of IMS clients, it also becomes essential to ensure their testing on some platform which is an exact replica of the live network. Here comes in to picture the testbed for IMS clients which can be used to check a client with all possible test cases. Need of a testbed was felt as a live network may not be able to provide all the error conditions, moreover, It is also expensive to rely on operator's network for unit testing requirements of an IMS Client.
This paper first looks at the architecture of an IMS network and then shares our experience of building a testbed using open source tools for testing IMS clients.

Fig. 1: Some of the access networks supported by IMS

IMS architecture which was brought to the 3GPP as part of the standardization work for 3G mobile phone systems in UMTS (Universal Mobile Telephony System Networks). But, the flexibility of IMS network architecture has made it attractive to connect other access network as well. Additional networks, including GSM & CDMA cellular networks, cable TV networks, Wi-Fi networks, WiMax Networks, enterprise and residential networks are being added to this common IMS core, ref to fig. 1. The addition of these additional access networks to an IMS core network provide market differentiating, leading edge, single number services to end users.

II. NETWORK ARCHITECTURE

A. Three layers of core network

The IMS core network is defined as a layered network consisting of a Media Transport Layer (e.g. voice, video, data etc.), Control Layer (e.g. SIP control, transport control etc.) and Service or application Layer (to provide added functionality to IMS core network) ref. to fig 2.

i) Transport layer

This layer is responsible for the network access. It allows different IMS devices and user equipments connect to the IMS network. IMS devices may connect to the network in the transport layer using different techniques like fixed access (DSL, cable modems, Ethernet etc.), mobile access (wideband code division multiple access i.e. WCDMA, GPRS) and wireless access (WiMax or WLAN). This layer also lets IMS devices to receive and place calls to and from the public switched telephone networks (PSTN) or any other circuit switched network through the media gateways. This layer establishes the user equipment IP connectivity. After getting an IP address and ability to exchange SIP messages user equipment will be responsible for its own IMS interaction, independent of the underlying network access technology.

ii) Control layer

This layer is the home of various call session control functions (CSCFs), ref. to Fig 4. Three SIP signaling servers handle these functions:
• The proxy CSCF (P-CSCF)
• The interrogating CSCF (I-CSCF)
• The serving CSCF (S-CSCF)

Fig.2: The three layer architecture

iii) Service or application layer

Two layers mentioned above provide an integrated and standardized network platform to let the service providers offer various multimedia services in the service layer. Application servers provide the interface with the control layers using the SIP protocol.

B. Decription of the components

CSCF: The SIP (Session Initiation Protocol) is used as the signaling protocol that establishes controls, modifies and terminates session of voice, video and messaging between two or more participants. These signaling points are known as Call State Control Functions (CSCFs). The three CSCF’s are described below:

P-CSCF: First contact point within the IMS Core network subsystem is the Proxy Call State Control Function. Its address is discovered by subscriber device. This proxy determines which CSCF will control the call by communicating with I-CSCF either within network the call originated or within the subscribers’ home network, if the subscriber is a visitor.
Various functions performed are:

a) Authorizing the bearer resources for the approproate QoS level.
b) Monitoring
c) Emergency calls
d) Header compression
e) I-CSCF identification

Fig.3: Interaction between various network components [12]

I-CSCF: It is another SIP function located at the edge of an administrative domain. The I-CSCF queries the HSS using the diameter Cx interface to retrieve the user location and then routes the SIP request to its assigned S-CSCF, ref. to fig.3. There may be multiple I-CSCF within an operator’s network. Functions performed are:

a) Assigning a S-CSCF to a user
b) SIP registration
c) Generating charging Data Records
d) Acts as a Topology Hiding Interworking Gateway (THIG).

S-CSCF: The S-CSCF performs the session control services for the subscriber device. It is the central node of the signaling plane. It is also a SIP server but performs session control too. It is always located in the home network. Since, it has no local storage of the user, it uses diameter Cx and Dx interfaces to the HSS to retrieve or send user profiles. All the required information is loaded from the Home Subscriber System (HSS).

Other functions are:

a) It provides routing services, typically using Electronic Numbering (ENUM) lookups.
b) It inspects every message as it sits on the path of all signaling messages.
c) It enforces the policy of the network operator.

HSS: The Home Subscriber Server (HSS), or User Profile Server Function (UPSF), is a master user database that supports the IMS network entities that actually handle calls. It contains the subscription-related information (user profiles), performs authentication and authorization of the user, and can provide information about the user's physical location. The entities that communicate with the HSS are the application server (AS) that hosts and executes services in the IMS environment, and the Call State Control Function servers (CSCF).

AS: Call control can pass through different application servers via SIP messages, depending upon the services subscribed to and invoked by the user. Examples of applications include voice mail, prepaid, unified messaging, push to talk over cellular (PoC), etc. Should special voice and/or video bearer processing be required, the AS will invoke the appropriate MRFC/MRFP.

BGCF: Selects the network in which the connection to the PSTN will be made. It will either forward the call using SIP to another BGCF for further processing or to a MGCF controlling the desired PSTN access [5].

MGCF: Controls the MGW to send or receive calls to/from the PSTN/Circuit-Switched Network. The MGCF uses SIP messages to/from the CSCF or BGCF and uses H.248 (Media Gateway Control) [5] messages to/from the MGW.

MGW: Performs all of the media processing required to process calls to/from the PSTN/Circuit-Switched Network [5].

MRFC: It controls the MRFP to provide media processing required by the Application Servers. It uses SIP messages to/from the Application Servers and typically uses H.248 (Media Gateway Control) messages to/from the MRFP.
MRFP: It performs all of the media processing required to provide media processing in support of the Application Servers for features such as conferencing, voice mail, recording, voice processing etc.

PSTN gateway: A PSTN/CS gateway interfaces with PSTN circuit switched (CS) networks. For signaling, CS networks use ISDN User Part (ISUP) (or BICC) over Message Transfer Part (MTP), while IMS uses Session Initiation Protocol (SIP) over IP. For media, CS networks use Pulse-code modulation (PCM), while IMS uses Real-time Transport Protocol (RTP).
Now we focus on the test bed implementation part. A testbed should be able to provide all the conditions which a client is supposed to come across while working in a live network. Here we present our experiences while building such a test bed that helps in developing an IMS enabled client within the limited space of a laboratory. We attempt to study the interaction between IMS client and the testbed and which can be of great use in order to remove dependency on live commercial setups.

III. WHY IMS ?

Features of IMS which have attracted both wireless and wireline service providers are:

A. Integration of multimedia services

Service providers can integrate voice, video and data services and provide them on a single platform. IMS brings the internet’s power to the communication world. Today voice is the only application that is completely “converged” — all mobiles can access all fixed lines and vice versa. However, it is not always possible to send text from a fixed device, have a PC instant messaging session with a mobile device, or a video call across the two networks. Making this possible clearly has significant revenue implications, and is in line with the trend towards fixed-mobile convergence [1].

Fig 4: Major services available on IMS.

B. Mobility

Without depending upon the location of the user, IMS provides access to the user’s specific set of services.

C. Vendors independence

Due to the modular architecture of IMS various service providers can integrate different components or modules from different solution providers into the same system. This also optimizes the investment involved.

D. Interworking with legacy networks

IMS has modules and gateways that provide interworking with legacy telecommunication systems.

E. Many other features

• IMS also provides features like security and QoS thus making it a perfect and complete service platform for NGN.[8]
• It also provides a uniform environment for billing, enabling more flexible ways for operators to charge subscribers. This is becoming increasingly important as operators try to find the best way to charge for different services as well as put together attractive bundles for different market segments.
• Among the new services being enabled by IMS are: video sharing, presence service, Instant Messaging (IM), VoIP, Push-to-Talk over Cellular (PoC), ref. to fig.4, conferencing, rich-call features, multimedia gaming, and voice messaging.

IV. WHAT ARE THE CHALLENGES INVOLVED ?

Some of the major challenges that were confronted by us while developing the testbed are:

• The test bed should be able to reproduce various link characteristics that the IMS Client is likely to come across as an IMS client can operate on various access networks like LAN, GPRS, EDGE and Wi-Fi.

• The test bed should be able to support all the policies which may be implemented by the operator on a live network. For example, an IMS client might have to work with different versions of IMS network or it might be challenged with different algorithms (AKAv1, MD5 etc.)

• In order to discover the IP address of the P-CSCF, the IMS client needs to work with DHCP and DNS server thus the test bed should be equipped with these servers also.

V. OPTIONS AVAILABLE FOR CLIENT-SERVER CONNECTION

There can many ways in which a client can interact with the server. We build the testbed to check the responses of IMS client for the following access types:

A. Local Area Network (LAN)

In order to realize a wired network access link between the client and the server, a LAN was used. IMS Client acquires an IP address on LAN via DHCP (Dynamic Host Configuration Protocol). This requires the presence of a DHCP server in the test bed and we choose Dynamic Host Configuration Protocol Server (dhcpd). Dhcpd was be configured to send FQDN of SIP server and FQDN was converted to an IP address by hosting a DNS server (bind) in the network, ref. to fig 5.

Fig.5: An IMS client and server connected via a LAN.

B. GPRS/ EDGE

The GPRS/EDGE network does not allow traffic to reach external IP, this is major challenge in front of us and we beat this restriction by configuring the server with in the same IMS client’s radio access network [3]. This was done by using a phone having the same operator SIM card as a modem, ref to fig 6.

Fig. 6: Interaction between IMS client and server over radio access network.

C. Wi-Fi

Now most of the IMS devices are coming with the feature of Wi-Fi so it becomes essential to test the device over a simulated Wi-Fi network. For this we attached both the IMS client and the server on to a same Access Point (AP) ref. to fig 7. This helped us to realize Wi-Fi link between IMS client and server.

Fig: 7 Wi-Fi links between IMS client and server.

VI. OPENIMS CORE AS OUR IMS SERVER

For building the IMS client test bed we used the open source OpenIMScore [7] as the server. Platform used was fedora 9. The Open IMS Core is an implementation of IMS Call Session Control Functions (CSCFs) and a lightweight Home Subscriber Server (HSS), which together form the core elements of all IMS/NGN architectures as specified today within 3GPP, 3GPP2, ETSI TISPAN and the Packet Cable initiative. A snapshot of the HSS management console is given as fig 8.

Fig.8: Snapshot of HSS management console

The four components are all based upon Open Source software (e.g. MySQL). It is a full fledged open source implementation of CSCFs that supports AKAv1 and AKAv2 algorithms. It also supports transport mode security by being fully compliant to TS 33.203. Installation and configuration is relatively easy and the tool runs all CSCFs separately. OpenIMScore can easily simulate the cases like Un-provisioned SIM card registration, network initiated deregistration, and authentication failure. Security has always been an issue which has to be kept in the mind. A fully TS 33.203 compliant IMS client supports transport mode IPSec security. OpenIMScore supports transport mode security as well. Therefore it can be used in such cases. Cases in which a Wi-Fi enabled IMS client needs to make use of IMS services via Wi-Fi, tunnel mode IPSec security association can be used. There are many open source VPN servers that can be used e.g. Openikev2, raccoon2, ikev2 and StrongSwan. We incorporated StrongSwan [14] in our testbed for this purpose. IMS client establishes a tunnel a VPN tunnel with the VPN server. All the SIP messages are transferred via this tunnel and then these messages are decrypted by the VPN server before forwarding them to the P-CSCF server.

VII. STUN SUPPORT FOR IMS CLIENT

In order to support SIP signaling from behind the Network Address Translators, IMS clients are generally equipped with STUN [13]. STUN functionality of the IMS clients can be tested by using Vovida which is an open source STUN server. The client can send a STUN request to Vovida STUN server in the test bed if it wants to know its public IP and NAT type [3], ref. to fig. 9.

Fig.9: Use of a STUN server in our testbed.

VIII. CONCLUSION

This paper has discussed the network architecture of IMS along with its Open Source-based testbed implementation. We have presented the challenges, requirements and discussed our experiences that we had during the whole work. IMS helps standardize protocols to eliminate proprietary technology and enable interoperability for all IP-based services, and provides the opportunity for ubiquitous access for users regardless of service, terminal type or location. Moreover, as the specifications IMS clients are in evolving state, these can be validated by using a testbed as proposed in this paper. This testbed can be used for various purposes including application and prototype development, performance and conformity testing to solutions design, operational support, feasibility studies and technology assessment.

REFERENCES

[1] Ahmed Hasswa, Abd-Elhamid Taha, Hossam Hassanein, “On Extending IMS Services to WLANS”, 32nd IEEE Conference on Local Computer Networks (LCN 2007), 2007

[2] T. Magedanz, D. Witaszek, K. Knuettel, Fraunhofer FOKUS / Technical University of Berlin, Germany “The IMS Playground @ Fokus – An Open Testbed For Next Generation Network Multimedia Services” Proceedings of the First International Conference on Testbeds and Research Infrastructures for the DEvelopment of NeTworks and COMmunities (TRIDENTCOM’05)

[3] Vignesh Karthik M, Shadangi Prateek Motorola India Pvt. Ltd, Banaglore “Building an IMS Client Test Bed With Open Source Tools”. International Conference on IP Multimedia Subsystem Architecture and Applications(IMSAA), 2007.

[4] Benjamin Y. C.Tang “Evolving To Wireless And Wireline Convergence- An Overview Of IMS”. The 14th Annual Wireless and Optical Communications Conference - April 22-23, 2005, NJ, USA.

[5] AudioCodes Application note on IMS, http:// www.audiocodes.com/Data/Uploads/IMS_AN.pdf

[6] Wi-FiTM – Wi-Fi is a non-profit organization with the goal of driving the adoption of a single worldwide-accepted standard for high-speed wireless local area networking

[7] OpenIMScore – Open source implementation of IMS Call Session Control Functions and Home Subscriber Service (HSS) - http://www.openimscore.org/

[8] Hechmi Khlii, Jean-Charles Grégoire, “IMS Application Servers Roles, Requirements, and Implementation Technologies” IEEE Internet Computing, vol. 12, no. 3, pp. 40-51, May/June 2008

[9] Jinho Hwang, Nakpo Kim, Sangyong Kang, Jongseog Koh, “A Framework For IMS Interworking Networks With Quality Of Service Guarantee”, Proceedings of the Seventh International Conference on Networking, p.454-459, 2008.

[10] IMS Growth: The Handset Connection, by Hartmut Schittko, Director of Business Development, http://www.convergedigest.com

[11] Simon Dadswell, Advanced Solutions Marketing Manager, Intec “IMS Deployment: Storing Up Future Problems?” http://www.intecbilling.com/intec/media/articles/2007/ims+deployment+sto...

[12] The IMS Playground @ Fokus - www.open-ims.org

[13] RFC 3489 - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) -http://www.ietf.org/rfc/rfc3489.txt

[14] StrongSwan- Open-source IPsec-based VPN solution for Linux- http://www.strongswan.org