Beruflich Dokumente
Kultur Dokumente
If you are interested in being an actor in the development of converged IP Multimedia applications for fixed and mobile communications, you cant 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 its 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, lets 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 ? Lets 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.
IMS development environment Well, now we have the picture. 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.
OpenIMS core For the XDMS part, which I remind you plays the role of document server and is accessible via XCAP protocol (based on usage of HTTP), Im using an open source solution called openXCAP(http://openxcap.org/). As said in the web site, OpenXCAP is an open source fully featured XCAP server . I use it to remotely store contacts list of users and presence rules. At that time of writing this post, the only Service Enabler I set up is a Presence Server based onopenSIPS solution (http://www.opensips.org/). It accepts presence publication and subscription, and handles user defined presence rules. Note that openXCAP has been designed for a direct integration with openSIPS as SIP presence server. As IMS clients, choice is unfortunately very limited today. Im trying to use solutions targeted for different types of Operating Systems and terminals. Even if restricted, 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). Having said that, here are the clients I use today: uctimsclient (designed for OpenIMS core), (http://uctimsclient.berlios.de/), Mercuro (running on Windows but unfortunately seems to be discontinued) and imsdroid (http://code.google.com/p/imsdroid/) which is a client running on Android (tested on a HTC). For the AS and MRF components Im using several open source solutions depending on the functionalities I want to implement. The most satisfying solution (I mean the one which best corresponds to my needs) is
the Mobicents/JBoss environment (http://www.mobicents.org/products.html). Im not a big fan of JAIN-slee as this is rather destined to pretty complex solutions but servers based on SIP servlet (JSR289), Media Framework (JSR309) and Sh Diameter interface are a good start for multimedia application development. I will come back on this hot topic very soon. No doubt !
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, 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:
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, IVR, etc .. Mobicents / JBoss + eclipseIDE is used as Service Development Platform and implements the following APIS: o SIP Servlet JSR281
o o
Mobicents Media Server is the Media Server made available to all applications running into the Mobicents/JBOSS platform. What is still missing regarding initial objectives is the MSRP APIs since Mobicents does not support it yet (planned for mid 2011?). I will detail in my next post the internal application architecture running in the Mobicents/JBOSS server
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.
Call Forwarding These two very simple examples illustrated the use of service platform during call establishment. Introducing new services in an IMS network simply necessitates the modification of the subscribersservice profile and makes the AS implementing the service accessible from the ISC interface.
Application Servers The IMS architecture basically defined the following gateways:
IM-SSF: allows interfacing with CAMEL network via CAP. The IM-SSF therefore implements CAMEL Service Switching FSM and allows access to legacy Service Control Point (SCP, 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
SCIM: Service Capability Interaction Manager. This optional element manages more efficiently the interaction between the different Application Servers than the S-CSCF can do. I will come back on that topic in a later post.
SCIM
MRF: Media Resource Function. This element can be split into two distinct functions: MRFC (Control) and MRFP (Processing) being respectively responsible for implementing media control and processing functionalities. The Mp reference point allows an MRFC to control media stream resources provided by an MRFP. An Application Server can interact with the MRFC either directly (Cr and Mr interfaces) or via the S-CSCF (ISC and Mr interfaces). Having specialized element like the MRF allows optimizing infrastructure costs by providing common basic functions across service platforms.
As you can imagine, putting all functions together would significantly make the architecture quite complex. This is all the more right, as many other elements can be added to provide supplementary possibilities regarding service development and integration. 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.