This action might not be possible to undo. Are you sure you want to continue?
If you are interested in being an actor in the development of converged IP Multimedia applications for fixed and mobile communications, you can’t ignore IMS architecture. The adoption by operators is already done, at least for their fixed lines offering based on VoIP technology and the use of residential gateways (ADSL or FFTH box). For the mobile network, the limited bandwidth available to mobile terminals (like UTRAN devices) made the deployment of such a complex (and costly ?) architecture less obvious. With the emergence (and deployment) of LTE and its natural integration into a full IP world, it seams clear that it’s time now to fully set up a real converged architecture and to benefit from IMS promises in term of service deployment. From a subscriber point of view, the advantage of an architecture capable of providing a set of converged and adapted services for all his numerous terminals (mobile, smart-phone, PC, IPTV, tablet, etc …) is quite straightforward and IMS is one solution for that. Having said that, let’s come back to the subject of this post. Being a trainer in IMS and multimedia technology, I always tried to illustrate my talks by giving the opportunity to my attendance to use real equipments and to discover by themselves all the technical details they need for their job. Moreover, my activities in multimedia platform integration and application development requires having a real environment at my office for testing purpose. So, how can we set up a complete environment based on IMS architecture, allowing developing, integrating and testing real multimedia services ? Let’s first try and summarize elementary function blocks needed for that:
• • • •
IMS core network: includes P/I/S-CSCF and HSS. Will allow user registration and the invocation of provisioned services. SIP Application Server: will host services available to subscriber. A service execution environment (SLEE-like) allows the execution and the interaction of different applications. Media Server (MRF): allow to play, record and interact with media flow. May be split into a control (MRFC) and processing (MRFP) part. Service Enabler: this element is referenced in the IMS architecture as a basic service made available to other service platforms to create rich and mashed multimedia application (example of enablers: presence service enabler, location service enabler, etc …). Document server (XDMS: XCAP Document Management Server): this server will contain shared documents accessible from application servers and service enablers (address book, presence rules, service configuration, etc …). Access Network: allow to gain access to IP network and IMS core network. Multimedia terminals: should ideally implement all interfaces required to exercise services and establish rich multimedia communications (SIP, RTP, MSRP, XCAP, etc ..). Will be at least capable of registering in the IMS network and make multimedia calls. IDE (Integrated Development Environment): allow to write, compile and deploy applications in your preferred language.
now we have the picture. .IMS development environment Well. This is a very simplified one as you may have noticed that I limited service platform to simple SIP Application Servers. We will see in the next post how to instantiate each of these elements.
(http://uctimsclient. Great job guys ! You need to compile the sources locally and modify default configuration parameters to get it accessible from external servers. current solutions showed me up how far we still are from a full interoperability between terminals themselves and service implementation (like presence and XCAP servers). here are the clients I use today: uctimsclient (designed for OpenIMS core).Setting up an IMS development environment (Part 2) As described in a previous post (here) IMS service architecture relies on a certain number of functional blocks allowing subscribers to access and exercise multimedia services.de/).google. configuration and customization are quite straightforward and well documented. As IMS clients. I’m using an open source solution called openXCAP(http://openxcap. OpenIMS core For the XDMS part. It offers enough stability. It accepts presence publication and subscription. For the IMS core network. Note that openXCAP has been designed for a direct integration with openSIPS as SIP presence server. choice is unfortunately very limited today.org/). This is my personal choice and even if it requires a significant effort in integrating components all together it appears for me as being the more comfortable solution. Note that even in that case functional blocks remain opened and allow you to get access to all standard interfaces as defined by the IMS architecture. I use it to remotely store contacts list of users and presence rules. which I remind you plays the role of document server and is accessible via XCAP protocol (based on usage of HTTP). Mercuro (running on Windows but unfortunately seems to be discontinued) and imsdroid (http://code. robustness and possibilities for most of my needs. Separating basic functional blocks (I/P/S-CSCF and HSS) into distinct servers is possible even though having them running on a single machine is pretty convenient. For the AS and MRF components I’m using several open source solutions depending on the functionalities I want to implement.berlios. As said in the web site. When developing such services it could be interesting to have access to an environment as closed as possible to what may look like a real deployment. and handles user defined presence rules. my choice naturally went to the OpenIMS core developed by Faunhofer Institute. Even if restricted. discontinued ?) and can cover some of your basic use cases you might prefer to get physically access to all unitary functional block. Having said that.org/). Though simulation environment exists (Ericsson SDS: Service Development Studio. The most satisfying solution (I mean the one which best corresponds to my needs) is . At that time of writing this post. Based on OpenSER open source product (now opensips) its installation.com/p/imsdroid/) which is a client running on Android (tested on a HTC). « OpenXCAP is an open source fully featured XCAP server ».opensips. If you are interested in setting it up I recommend you to visit the site ofopenimscore project. I’m trying to use solutions targeted for different types of Operating Systems and terminals. the only Service Enabler I set up is a Presence Server based onopenSIPS solution (http://www.
I will come back on this hot topic very soon.the Mobicents/JBoss environment (http://www.mobicents. No doubt ! .org/products. I’m not a big fan of JAIN-slee as this is rather destined to pretty complex solutions but servers based on SIP servlet (JSR289).html). Media Framework (JSR309) and Sh Diameter interface are a good start for multimedia application development.
etc . IVR. Mobicents / JBoss + eclipseIDE is used as Service Development Platform and implements the following APIS: o SIP Servlet JSR281 o o • Media Framework JSR309 Diameter Sh Application Mobicents Media Server is the Media Server made available to all applications running into the Mobicents/JBOSS platform. My needs can be summarized as follows: • • • being able to set up basic service enablers like presence or location service have media resource function available have a full development and execution environment which can be easily integrated with the IMS core: o o o o SIP. it’s time now to think of which element could be easily used for service plan functions.Setting up an IMS development environment (Part3) – Service Plan As the purpose of this setup is to provide me with an environment for demos and applications integration. I will detail in my next post the internal application architecture running in the Mobicents/JBOSS server . What is still missing regarding initial objectives is the MSRP APIs since Mobicents does not support it yet (planned for mid 2011?).. Diameter and MSRP APIs allowing converged Internet/IMS application development providing service routing management capabilities interfacing with media servers After many attempts and integration works I finally came to the following architecture: Service Plan architecture • • • Opensips is set up as presence server and iFC has been created in the HSS for that purpose Asterisk is used for quick implementation of some basic functionalities like Voice Mail.
In order to facilitate new service introduction and make them easily accessible to any subscriber whatever his current location (visited network). The services themselves are executed in both GSM and IMS by specific servers (INAP/CAP SCP for GSM and SIP AS for IMS) and are conditioned respectively by CSI triggers (GSM) and iFCs (IMS).Comparison IMS vs GSM service architecture Before going further into IMS service plan let’s try and compare GSM and IMS service architecture. This breaks with GSM vision where services invocation is realized under the responsibility of a local element (MSC/VLR). The figure below despites both architecture. GSM vs IMS service architecture . HLR and HSS are the home database hosting all subscribers information including assigned local VLR and home S-CSCF as well as service triggers (CSI and iFC). This function always resides in the user’s Home administrative domain and ensures via trigger point specification (iFCs) that the user will be allowed to access his services even in roaming situation. the IMS architecture relies on a unique function element (S-CSCF) allocated dynamically during user’s registration into the IMS network.
Call Forwarding These two very simple examples illustrated the use of service platform during call establishment. Depending on the AS behavior (see previous post here) the call may end up or not. CSCFs servers (P.I. Remember that due to their specific role.Basic Call Flow Let’s consider two registered users and have a look how service execution can take place during the establishment of a basic call between the two. . S) may be located in different domains: user’s Visited network for the P-CSCF (Proxy role) and Home domain for the I-CSCF (domain entry point) and the S-CSCF (serving call server). In the case the ASs behave like proxy servers we will get something similar to the next figure. Basic IMS call flow with service execution If we take now the example of call diversion service like CFU (Call Forwarding Unconditional) the signaling messages allowing call establishment between calling and diverted called users will be diverted to the corresponding home and visited domain like despited in the figure below. both originating and terminating networks have the opportunity to invoke service platforms by routing SIP message (initial one) to the Application Server for which trigger point is satisfied. Thanks to the service profile and associated iFCs of respective users. Introducing new services in an IMS network simply necessitates the modification of the subscribers’service profile and makes the AS implementing the service accessible from the ISC interface.
SCIM . These gateways may be of different types and facilitate the reuse of legacy service platforms. This optional element manages more efficiently the interaction between the different Application Servers than the S-CSCF can do. As explained in previous posts the S-CSCF is the call server from the control plan responsible for interfacing with the service plan across the ISC interface (SIP protocol). Application Servers The IMS architecture basically defined the following gateways: • • IM-SSF: allows interfacing with CAMEL network via CAP.IMS Service Plan Architecture introduction The IMS service plan basically contains all application servers and gateways used for service execution. I will come back on that topic in a later post. gsmSCF) OSA SCS: Service Capability Server interfacing to the OSA framework (Parlay API) providing third party service platforms with a standardized and secured access to IM subsystem Beside these gateways. The IM-SSF therefore implements CAMEL Service Switching FSM and allows access to legacy Service Control Point (SCP. IMS also defined additional functional elements: • SCIM: Service Capability Interaction Manager. Although service plan is accessed by making usage of the SIP protocol. service gateways allow having application servers being not necessary SIP servers.
as many other elements can be added to provide supplementary possibilities regarding service development and integration. This element can be split into two distinct functions: MRFC (Control) and MRFP (Processing) being respectively responsible for implementing media control and processing functionalities.• MRF: Media Resource Function. . This is all the more right. putting all functions together would significantly make the architecture quite complex. An Application Server can interact with the MRFC either directly (Cr and Mr’ interfaces) or via the S-CSCF (ISC and Mr interfaces). The Mp reference point allows an MRFC to control media stream resources provided by an MRFP. Having specialized element like the MRF allows optimizing infrastructure costs by providing common basic functions across service platforms. You may for example be interested in having high level API making web services more easily accessible. This is the big challenge facing by Telecoms operators in their adoption of the IMS architecture since better ARPU will require better and real value added services to subscribers. As you can imagine.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.