tag:blogger.com,1999:blog-47061386977252585072024-03-13T14:13:01.168+01:00The IMS LanternA blog to discover the nuggets (well) hidden in the 3GPP IP Multimedia Subsystem specificationsUnknownnoreply@blogger.comBlogger65125tag:blogger.com,1999:blog-4706138697725258507.post-21508685936342660502009-04-25T10:38:00.003+02:002009-04-25T11:04:38.372+02:00Fixed Mobile Convergence(s)The term "fixed mobile convergence" is very ambiguous. In this post, I will try to clarify the concept by distinguishing between different types of convergence and by positioning IMS with regards to them.<br /><br /><span style="font-weight: bold;">Device convergence</span><br /><br />This type of convergence essentially relies on the ability of a device to connect to a single or to separate networks using either fixed or mobile access (typically WiFi behind xDSL and GSM/UMTS).<br /><br />UMA (Universal Mobile Access), also called Generic Access Network (GAN) in 3GPP, is a potential solution for this type of convergence, as it permits to add an IP access to the mobile core network while keeping the higher level signaling stacks, thus enabling standard handover between, e.g. WiFi and cellular access. UMA/GAN requires the support of a dedicated "base station" in the access network to add the new access to the mobile core.<br /><br />The IMS Voice Call Continuity (VCC) specification supports a similar feature, but this time handover is performed through switching between an IMS core network and the mobile core network. An issue with VCC is that voice services are supported across two different core networks (IMS and the pre-IMS mobile core), which may cause trouble with regards to the execution of value added services that should be unified or at least coherent across the two networks. The 3GPP IMS Centralized Services (ICS) initiative could be a way to address this issue, by locating value added voice services for both IMS and the pre-IMS mobile core network in a single IMS Telephony Application Server (TAS)<br /><br />Overall, device convergence suffers from the significant hurdle to rely on dual mode devices, with the need for associated market penetration. It may also face technical issues related for instance to the quality of user experience or battery consumption. Note that this is the only type of convergence which relies on the ability of a device to connect to the network through different access types.<br /><br /><span style="font-weight: bold;">Service convergence</span><br /><br />Service convergence relies on the support of convergence through service implementation.<br /><br />Typically, fixed and mobile devices each access their own network through their specific access. A service is then made convergent by an ad hoc implementation permitting the coherent delivery of the service across the different access technologies and devices. This generally implies federation between fixed and mobile identities, the usage of a converged service profile and a consolidation of fixed and mobile OSS/BSS functions in order to deliver a coherent provisioning and a converged bill.<br /><br />The drawback with this approach is that services have to be made convergent one by one, either by totally service-specific implementations or by the integration with a usually proprietary convergence framework dealing for instance with identity federation and shared fix / mobile service profiles. This type of convergence may be costly to support, difficult to evolve, and may sometimes be limited due to technical issues.<br /><br /><span style="font-weight: bold;">Network convergence</span><br /><br />Network convergence relies on the ability of a core network to support different types of devices using different access technologies.<br /><br />A single IMS core network may for instance support a variety of access technologies among GSM, UMTS, LTE, Femtocells, WiFi, WiMax, xDSL, FTTH, circuit-switched fixed access and cable, and consequently the devices making use of them.<br /><br />IMS based network convergence requires the ability of the device to connect with IMS, either through native or acquired internal support, through a home gateway or through a network gateway. On the other hand, it does not require the device to support various access technologies (like WiFi and GSM/UMTS).<br /><br />Taken in isolation, network convergence is essentially a cost reduction feature as it permits to avoid deploying access-specific core networks, thus cutting in the CAPEX and OPEX of the operator. Fixed and mobile devices can still make use of different user identities associated to different service profiles, and providing access to discriminated services or service implementations.<br /><br />However, network convergence can also be seen as a support facilitating the implementation of service convergence, as it implies the support of the same (IMS) protocols by the devices (or through gateways) as well as a unified access to application servers through the unique core network. IMS-based network convergence can therefore be used to support convergent services in a more cost effective and simplified manner.<br /><br />Network convergence is currently <a href="http://theimslantern.blogspot.com/2009/04/list-of-ims-deployments.html">a strong IMS driver</a> for operators deploying new access technologies (e.g. WiMax, LTE) or targeting specific convergent services (e.g. enterprise FMC, converged messaging) across these new or legacy access technologies.<br /><br />In addition, IMS-based network convergence can also be seen as a step towards the ultimate goal of user convergence.<br /><br /><span style="font-weight: bold;">User convergence</span><br /><br />User convergence relies on the support of a unique converged subscription possibly making use of converged user identities (i.e. user identities shared between fixed and mobile devices). It builds and extends upon network convergence.<br /><br />In this approach, the operator provisions a unique user profile in the HSS, which may include converged identities, separate fixed and mobile identities if needed, and access specific information like authentication methods and credentials (e.g. UMTS AKA for mobile and SIP digest for fixed).<br /><br />In the most advanced scenario, the user can concurrently register the same user identity (e.g. <span style="color: rgb(51, 51, 255);">sip:john.smith@operator.com</span>) from multiple fixed and mobile devices. The service profile stored in the HSS and associated to the shared identity supports converged access to IMS application servers, which associate a converged user profile to this identity. In this approach, every service deployed on the IMS framework and associated to a converged identity is <span style="font-style: italic;">de facto</span> converged because immediately accessible from various devices using vaious accesses.<br /><br />SIP requests addressed to the converged identity (e.g. incoming calls, incoming instant messages) can be handled intelligently by the IMS core network (and possibly the application layer) with a panel of strategies ranging from alerting the user or delivering the request (e.g. an IM) on several devices to selecting the most appropriate one according to various criteria such as user preferences, device capabilities and more dynamic information such as presence.<br /><br />Other interesting features include session mobility (currently worked on in the IETF and 3GPP) permitting to transfer an ongoing session from one device to another, as well as the possibility to deliver the different components of a multimedia session over different devices (CPM requirement), like delivering the video component of a voice/video session to the TV and the voice one to the mobile phone.<br /><br />I had the opportunity to describe user oriented convergence in <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-1-fixed-mobile.html">a previous post</a>, but I will use this one to demystify prejudices that sometimes exist about it.<br /><br />First, while IMS can eventually support user convergence, it will not mandate it for all users. An operator implementing <a href="http://theimslantern.blogspot.com/2009/03/defining-ims-strategy.html">a coherent IMS strategy</a> will be able to offer convergent subscriptions while keeping the possibility to offer mobile and fixed specific subscriptions as well (using IMS network convergence in this case). Moreover, even for converged subscriptions, the operator will be able to keep separate fixed and mobile identities if the user wishes it or for access to specific services. This is only a matter of user profile provisioning in network databases.<br /><br />Second, user convergence does not necessarily mean the impossibility to distinguish between fixed and mobile access for:<br />- Service discrimination: some services may remain fixed or mobile specific.<br />- Service implementation discrimination: variants may still exist between the implementations of a service depending on the access used to deliver it.<br />- Charging discrimination: differentiated fixed and mobile charging may apply as long as users are informed about it, possibly in an interactive manner before service delivery.<br /><br />The key element permitting to support these differentiations is the fact that all SIP signalling originating from a device includes an identification of the access technology it uses (e.g. UMTS, xDSL). This information can be used for service routing in the network (i.e. definition of<a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-service-profile.html"> initial filter criteria</a>) or within service logic prior to or while delivering the service. A device switching from one access to another during service delivery would inform the network about it, for instance by initiating session re-negotiation, thus permitting the network and services to dynamically adapt to the change.<br /><br />User convergence will not happen overnight, as it implies, besides the addressing of pending technical issues, major changes related to organizations, processes, business models, OSS and BSS, as well as regulation. However, I cannot imagine that it will never happen, whether this is under the control of operators using IMS or through disruptive players using alternative solutions enabled by all-IP networks.<br /><br /><span style="font-weight: bold;">Conclusion</span><br /><br />IMS can support all types of convergence: device convergence, service convergence, network convergence, and user convergence.<br /><br />Personally, I consider that device convergence and service convergence are of a limited and tactical appeal, due to the limitations and costs they imply. Moreover, to support them, IMS is only a candidate framework among others, which alone may not justify an investment.<br /><br />The real interest of IMS for fixed mobile convergence appears when network and user convergence are part of the roadmap for the operator. These targets justify the usage of IMS for device and service convergence, as an initial step towards a more ambitious strategy combining both network and user convergence. Network convergence in itself can be used as an intermediate step towards user convergence, which will be a true revolutionary aspect of IMS, together with its ability to support <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">multimedia communication</a>, to combine services and to merge the Internet and telecommunications domains.Unknownnoreply@blogger.com272tag:blogger.com,1999:blog-4706138697725258507.post-42489199355028345852009-04-11T09:39:00.007+02:002009-04-11T12:07:04.750+02:00Who reads The IMS Lantern?<span style=";font-family:times new roman;font-size:130%;" >As a complement to <a href="http://theimslantern.blogspot.com/2009/04/list-of-ims-deployments.html">my latest post on IMS deployments</a>, I think that an analysis of the audience of The IMS Lantern can provide interesting insights about the IMS community all over the world.<br /><br />Since June 2007, this blog generated over 41,000 visits from 132 countries.<br /><br /></span><div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <span style="font-weight: bold;font-family:times new roman;font-size:130%;" >Worldwide audience<br /><br /></span> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">From a continental perspective, Europe accounts for half of the traffic and generated more than twice as many visits as the Americas and Asia, which are head to head.<br /><br />However, the USA are, by a large margin, the country which tops the others in terms of traffic.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">Here are the top 20 countries:</span></div> <table style="font-family:times new roman;"> <tbody><tr> <td><span style="font-size:130%;">1.</span></td> <td><span style="font-size:130%;"> United States</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">2.</span></td> <td><span style="font-size:130%;"> France</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">3.</span></td> <td><span style="font-size:130%;"> India</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">4.</span></td> <td><span style="font-size:130%;"> Germany</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">5.</span></td> <td><span style="font-size:130%;"> United Kingdom</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">6.</span></td> <td><span style="font-size:130%;"> Sweden</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">7.</span></td> <td><span style="font-size:130%;"> Canada</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">8.</span></td> <td><span style="font-size:130%;"> Spain</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">9.</span></td> <td><span style="font-size:130%;"> South Korea</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">10.</span></td> <td><span style="font-size:130%;"> Switzerland</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">11.</span></td> <td><span style="font-size:130%;"> Italy</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">12.</span></td> <td><span style="font-size:130%;"> Netherlands</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">13.</span></td> <td><span style="font-size:130%;"> Japan</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">14.</span></td> <td><span style="font-size:130%;"> Slovenia</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">15.</span></td> <td><span style="font-size:130%;"> Israel</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">16.</span></td> <td><span style="font-size:130%;"> China</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">17.</span></td> <td><span style="font-size:130%;"> Singapore</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">18.</span></td> <td><span style="font-size:130%;"> Taiwan</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> <tr> <td><span style="font-size:130%;">19.</span></td> <td><span style="font-size:130%;"> Austria</span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> <td><span style="font-size:130%;"><br /></span></td> </tr> </tbody></table> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-weight: bold;font-family:times new roman;"><span style="font-size:130%;"><br />Companies<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">Visits come from three main types of companies:<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">- Big network equipment vendors including those leading on the IMS market, but not only.</span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">- Operators, mainly from the USA, Canada, France, Spain, Germany, South Korea, Japan and Australia.</span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">- Application service suppliers, with a huge domination from India.</span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"><br />However, a significant part of the traffic is also generated by smaller vendors providing equipments, services or OSS/BSS systems, by suppliers of service platforms, and by research centers, engineering schools and universities.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-weight: bold;font-family:times new roman;"><span style="font-size:130%;">Subjects of interest<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">Visitors are mainly interested in posts describing technical details about <a href="http://theimslantern.blogspot.com/2007/06/ims-service-routing-big-picture.html">the IMS service architecture</a>, <a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">IMS identities</a>, <a href="http://theimslantern.blogspot.com/2007/05/standardization-scim-service-broker.html">the SCIM,</a> and <a href="http://theimslantern.blogspot.com/2007/05/user-application-data-panorama.html">IMS data management</a>. This may hint at a deficiency in the way the literature, courses and IMS specifications address these topics.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">Just behind come posts dedicated to the innovative features of SIP and <a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">the IMS service architecture</a>, like <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-3-user-oriented.html">the User Oriented Architecture (UOA)</a>, <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-1-fixed-mobile.html">fixed mobile convergence</a>, <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">multimedia SIP sessions</a> and <a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">CPM</a>, and the various <a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">service patterns</a> I had the opportunity to describe. I am personally very happy to see that CPM, which is by far the most ambitious IMS standardization initiative, attracts a lot of curiosity and is often entered as a keyword in search engines. Moreover, the post dedicated to it is the one visitors spend the most time on. Another source of more personal satisfaction is to see that the concept of User Oriented Architecture that I associated to the IMS has started to spread outside of the blog, even if it is far from having reached mainstream acceptance yet.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">The IMS Lantern therefore seems to be accessed as both an educational and thought-provoking resource on the IMS.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-weight: bold;font-family:times new roman;"><span style="font-size:130%;">Sources of traffic<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">Visits mainly come from search engines with IMS-related queries and from people who regularly visit the blog or get notified about new posts.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">A smaller portion of the traffic comes from links on other sites (mainly blogs addressing telecom or technological topics). I have done very little to advertise The IMS Lantern on the Internet, but do not hesitate to link to it if you have the opportunity to do so.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-weight: bold;font-family:times new roman;"><span style="font-size:130%;">Influence<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">Does The IMS Lantern have an influence on the work of some people or companies in the industry?<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">I know from direct contacts and some references visible on the Internet that The IMS Lantern has influenced research activities, the writing of theses, articles and even a book that will be published in the coming months.<br /><br /></span></div> <div style="font-family:times new roman;"><span style="font-size:130%;"> </span></div> <div style="font-family:times new roman;"><span style="font-size:130%;">It is a great source of motivation for me to learn that others can benefit from what I am writing and I have no problem with the reuse of ideas and information I am providing through this blog. So don't be shy: if this blog has a direct or indirect influence on what you are doing, just let me know.</span></div>Unknownnoreply@blogger.com17tag:blogger.com,1999:blog-4706138697725258507.post-66960365190508221772009-04-08T21:52:00.006+02:002009-04-10T12:36:25.008+02:00A List of IMS DeploymentsWhile I was doing research for this post, I stumbled upon a March announcement which provides an ideal introduction to it.<br /><br />Infonetics Research issued <a href="http://www.infonetics.com/pr/2009/4q08-ims-market-highlights.asp">a 2008 4th quarter report</a> claiming that:<br />- Worldwide sales of IMS equipment nearly doubled in 2008 over 2007, up 94%<br />- Unlike many other markets during the worldwide economic crisis, the IMS equipment market is expected to grow in 2009 and 2010<br />- Infonetics’ IMS Deployment Tracker shows Ericsson, Alcatel Lucent, Nokia Siemens (NSN), NEC, and Huawei leading the way with core IMS equipment<br /><br />In this post, I am trying to list done or ongoing deployments of IMS core networks all over the world. This list is based on publicly available contracts announcements and, in case I was not able to find such material, public evidence or strong hints that such deployments were at least under way. When available, I mention the date of the contract, the supplier of the core network, and the intended focus of the deployment, at least in its initial phase. Otherwise, question marks replace the information.<br /><br />My intention is to maintain this list over time, based on new annoucements as well as the additions or corrections you might be able to give to me by email (cgourraud at yahoo.ca) or by posting a comment. For instance, in many cases, a press release relates to a contract signed at a group level or for a specific country for service providers operating over several ones, and any precision on the actual country(ies) targeted for deployment would be useful.<br /><br />I hope this list can be of interest to you. The idea came to me from recurent requests to provide information of IMS deployments in Europe, North America and Asia.<br /><br /><span style="font-weight: bold;">Europe</span><br /><br />Armenia<br />ArmenTel: 8/2008, Ericsson, Fixed Network -> FMC<br /><br />Austria<br />Mobilkom: 1/2009, Nortel, Mobile network<br /><br />Azerbaidjan<br />Delta Telecom: 9/2008, Alcatel Lucent, WiMax network<br /><br />Belgium<br />Belgacom: 4/2008, Alcatel Lucent, Fixed network<br /><br />Bulgaria<br />Vivatel: 11/2008, NSN, Mobile network<br /><br />Cyprus<br />CYTA: 12/2006, Ericsson, FMC<br /><br />Czech Republic<br />Eurotel: 12/2005, NSN, Mobile network<br />Vodafone: 9/2007, Ericsson, Enterprise FMC<br /><br />Denmark<br />TDC: 6/2005, Ericsson, Enterprise<br /><br />Estonia<br />Elion: 9/2006, Ericsson, Fixed network<br /><br />France<br />Bouygues Telecom: ?, ?, RCS<br />France Telecom/Orange: ?, ?, RCS<br />Hub Telecom: 11/2008, Alcatel Lucent, Enterprise FMC<br />SFR: ?, ?, RCS<br /><br />Germany<br />Arcor: ?, ?, ?<br />Deutsche Telekom: ?, in-house solution?, ?<br />T-Mobile: ?, ?, RCS<br />Vodafone: 7/2007, Ericsson, Consumer & Enterprise<br /><br />Greece<br />Hella Online: 1/2008, Ericsson, Fixed network<br /><br />Greenland<br />Tele Greenland: 1/2008, Ericsson, FMC<br /><br />Hungary<br />Magyar Telekom: 7/2006, Huawei, FMC<br />T-Mobile & T-Com: 7/2006, Huawei, Mobile network / FMC<br /><br />Ireland<br />O2 Ireland: 8/2006, Ericsson, Mobile network<br />Vodafone: 7/2008, Ericsson, Mobile network<br /><br />Italy<br />Telecom Italia: 2/2005, Ericsson, Fixed network<br />Telecom Italia Mobile: 2005, Ericsson?, RCS<br />Wind Telecomunicazioni: ?, ?, RCS<br /><br />Netherlands<br />KPN: 9/2006, Alcatel Lucent, Fixed PSTN replacement<br /><br />Poland<br />Exatel: 10/2007, Alcatel Lucent, Fixed network<br />Netia: 9/2005, Alcatel Lucent, Fixed network / Enterprise services<br />Telekomunikacja Polska: 3/2007, Ericsson, FMC<br /><br />Portugal<br />Optimus: 3/2006, Ericsson, Mobile network<br />Portugal Telecom: ?, 2007?, FMC / PSTN replacement<br />Sonaecom: 7/2008, Ericsson, Fixed network/IPTV<br />TMN: 6/2005, NSN, RCS<br />Vodafone: 7/2007, Ericsson, FMC<br /><br />Russia<br />Comstar: planned in 2009, to be selected, fixed network / PSTN replacement<br />Sibirtelecom: 6/2006, Nortel, ?<br /><br />Spain<br />Telefonica: 4/2005, Ericsson, Fixed network<br />Telefonica/O2: ?, ?, RCS<br /><br />Sweden<br />Com Hem: 6/2007, NSN, Fixed network<br />Telenor: 7/2007, Ericsson, Enterprise FMC<br />TeliaSonera: 5/2007, NSN, FMC?<br /><br />Switzerland<br />Swisscom: 2/2007, Ericsson, FMC<br /><br />Turkey<br />Turkcell: ?, ?, Mobile network / FMC<br /><br />UK<br />BT: 4/2005, Ericsson?, Fixed PSTN replacement<br /><br /><span style="font-weight: bold;">North America</span><br /><br />Canada<br />Bell Canada: ?, ?, FMC<br />Rogers Cantel: ?, ?, ?<br /><br />USA<br />AT&T: 10/2005, Alcatel Lucent, Mobile network<br />Bellsouth - now AT&T (USA): 11/2005, Alcatel Lucent, Fixed network<br />Cox Communications: 2007?, ?, Cable network<br />Sprint Nextel: ?, ?, FMC<br />SureWest Communications: 4/2008, Alcatel Lucent, Fixed network<br />TerreStar Networks: 7/2007, Alcatel Lucent, Satellite and Cellular convergence<br />Time Warner Cable: 4/2009, NSN, Cable network<br />Verizon Communications: 3/2007 - 2/2008, Alcatel Lucent & NSN , Mobile network/PSTN network replacement/FMC<br /><br /><span style="font-weight: bold;">South America</span><br /><br />Brazil<br />Brasil Telecom: 5/2008, Ericsson, Mobile network<br /><br /><br /><span style="font-weight: bold;">Asia & Oceania</span><br /><br />Australia<br />Commander Communications: 9/2005, Ericsson, Fixed network<br />Telstra: ?, Alcatel Lucent?, ?<br /><br />China<br />Beijing Netcom: 4/2007, Ericsson, Fixed network<br />China Mobile: ?, ?, RCS<br />China Netcom: ?, Alcatel Lucent?, ?<br />China Unicom: 7/2007, Alcatel Lucent, Mobile network<br />Fujian Telecom: 12/2006, NSN, FMC<br /><br />Hong Kong<br />NWT: 7/2006, Alcatel Lucent, Fixed network<br />SmarTone-Vodafone: 4/2008, Ericsson, Mobile network<br /><br />Indonesia<br />Telkomsel: 8/2006, NSN, Mobile network<br /><br />Japan<br />KDDI: 1/2006, NEC, RCS<br />NTT: ?, ?, ?<br />Softbank Mobile: 12/2006, Ericsson, Mobile network<br />Softbank Mobile: 9/2008, NEC, Femtocells network<br /><br />Malaysia<br />Celcom: 7/2006, NSN, Mobile network<br /><br />Philippines<br />Globe Telecom: 9/2006, NSN, FMC<br /><br />South Korea<br />KTF: ?, ?, RCS<br />SK Telecom: 2005 or 2006, ?, FMC/RCS<br /><br />Taiwan<br />Chungwa Telecom: 12/2007, NSN, Fixed network<br />FarEasTone: 9/2006, Ericsson, Mobile network<br /><br />Vietnam<br />Saigon Postel Telecommunication: 11/2006, Ericsson, Fixed network<br /><br /><span style="font-weight: bold;">Middle East & Africa</span><br /><br />Bahrain<br />Mena Telecom: 8/2007, Motorola, WiMax network<br /><br />Pakistan<br />Wateen Telecom: 5/2006, Motorola, Fixed network<br /><br />South Africa<br />Telkom: 2008?, ?, ?<br /><br />Uganda<br />Warid Group: 10/2007, Huawei, Mobile/WiMax networkUnknownnoreply@blogger.com43tag:blogger.com,1999:blog-4706138697725258507.post-759067072873058382009-03-28T14:21:00.002+01:002009-03-28T14:31:33.268+01:00Defining an IMS Strategy<div><br />As a set of specifications or as a set of products provided by telecom suppliers, IMS is not the answer about how to ensure a bright future for telecom operators.<br /><br /></div> <div> </div> <div>Basically, IMS should be perceived as a toolkit, which can be used alternatively or successively in various manners leading to drastically different results. As a consequence, an operator needs to define a short, mid and long term strategy based on IMS that suits its business strategy, and it has to take the adequate measures to apply this strategy. Here, we are touching the biggest IMS issue. It is not technical but rather cultural, practical and organisational.<br /><br /></div> <div> </div> <div>In this post, I will try to outline some potential elements of an IMS strategy.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Deploying IMS<br /><br /></div> <div> </div> <div>While some operators may simply decide to deploy IMS as part of their network evolution roadmap, many require an initial motivation to take the decision to go for it.<br /><br /></div> <div> </div> <div>At the time being, the main triggers for deciding to deploy an IMS network are certainly the following:</div> <div>- Replacement of the legacy circuit-switched network for fixed telephony services (IMS used as PSTN emulation subsystem).</div> <div>- Deployment of a carrier grade VoIP solution for fixed residential customers, possibly with mobile/fixed convergence services including or not call contuinity between fixed and cellular access (knowned as voice call continuity).</div> <div>- Deployment of carrier grade enterprise services including for instance business trunking, IP centrex or fixed mobile convergence.</div> <div>- Deployment of a compelling set of mobile services through the Rich Communication Suite (RCS) or something else.</div> <div>- Deployment or migration of an IPTV solution making use of IMS.</div> <div>- Deployment of a selected set of IMS-enabled fixed mobile services.<br /><br /></div> <div> </div> <div>However, such initial motivations are not always strong enough to validate investments in IMS.<br /><br /></div> <div> </div> <div>For instance, a fixed operator may wonder why it should invest in IMS to reimplement a telephony service whose revenues are rapidly decreasing and which is likely to eventually be offered for free. Likewise, the usage of IMS for a specific service like IPTV or RCS or for a specific business segment like enterprise may not be economically worth for the operator.<br /><br /></div> <div> </div> <div>It is therefore necessary for the operator to have a strategy for extending the usage of IMS beyond its initial deployment scope in order to have an optimal return on investment. Such a strategy is also fundamental for the operator to decide on future investments.<br /><br /></div> <div> </div> <div>More especially, any decision to eventually replace a pre-IMS service implementation (e.g. telephony, messaging, IPTV) with an IMS one may impact the investment and evolution plan for the pre-IMS implementation.<br /><br /></div> <div> </div> <div style="font-weight: bold;">The Future of Telephony<br /><br /></div> <div> </div> <div>The future of existing telephony services and their implementation is a tricky issue that needs to be addressed carefully.<br /><br /></div> <div> </div> <div>Basically, IMS permits to:</div> <div>- Re-implement classical telephony services for legacy terminals and narrowband access (IMS as a PSTN emulation subsystem in ETSI TISPAN)</div> <div>- Implement a new generation of voice-centric telephony services for new terminals (e.g. SIP phones) and broadband access</div> <div>- Implement a new multimedia communication experience, in which voice is only a media component among others, whether they are related to person to person communication (e.g. messaging, video), content (e.g. streaming video, files) or data (e.g. events, application sharing, shared browsing).<br /><br /></div> <div> </div> <div>The operator needs to clearly identify these services, decide which ones it wants to deploy, how, and in which timeframe.<br /><br /></div> <div> </div> <div>Once this diversity has been understood and associated decisions have been taken, the operator can start to think about the implementation of related value-added services. For instance, are or should the value added services be the same or be different for each variant? Should they be implemented on the same or different platforms?<br /><br /></div> <div> </div> <div>The operator can also think, if relevant with its plans, about how these different types of voice-related services should co-exist and possibly interwork.<br /><br /></div> <div> </div> <div>The relationship between IMS and classical telephony services is of particular interest. It goes beyond the question of replacing the circuit-switched core network with an IMS based IP network as the two networks will co-exist for some time, and during this transition phase the support of value-added telephony services for both may be a question in itself.<br /><br /></div> <div> </div> <div>The operator may have the choice between several alternatives and decide to opt for one or to evolve from one to the other over time:</div> <div>- Using different service implementations in both networks (e.g. Intelligent Network in CS and a Telephony Application Server (TAS) in IMS)</div> <div>- Reusing legacy Intelligent Network solution(s) in IMS</div> <div>- Re-implementing services on a new platform able to support both IN and IMS ISC interfaces</div> <div>- Reusing the IMS TAS for delivering value-added services to circuit-switched voice, in replacement to Intelligent Network servers (ongoing standardisation in 3GPP as IMS Centralized Services)<br /><br /></div> <div> </div> <div style="font-weight: bold;">The future of messaging<br /><br /></div> <div> </div> <div>In mobile networks, various messaging services can exist such as SMS, MMS and IMPS (OMA standard for mobile Instant Messaging).<br /><br /></div> <div> </div> <div>IMS messaging has the potential to emulate all these messaging services and to add more to the user experience. The operator may therefore have to decide if and when it wants to eventually replace all of the existing messaging services and how it wants to manage the transition phase during which IMS messaging takes off and co-exists with them.<br /><br /></div> <div> </div> <div>Moreover, as for voice, the multimedia nature of IMS makes that messaging may eventually cease to exist as a standalone service and be part as a multimedia component, of a more global and powerful multimedia communication paradigm. Should the operator skip the silo IMS messaging step and go directly to the multimedia communication service or should it implement one after the other? If so, how should the migration be performed?<br /><br /></div> <div> </div> <div style="font-weight: bold;">IMS as a multi-service platform<br /><br /></div> <div> </div> <div>An important feature of the IMS service architecture is its ability to support the harmonious co-existence of multiple services related to communication, content and data. This is a discriminating feature compared to a non-IMS SIP network, which lacks a standard service architecture and requires ad-hoc and often cumbersome support for the co-existence of several services, with limited multivendorship possibilities, and this until the architecture explodes after the hack too much (as this happens with all silo architectures whose limits are pushed too much).<br /><br /></div> <div> </div> <div>An advantage of using an IMS core network as a multi-service platform is its ability to factorize and make coherent such functions as service discovery, user identification, user authentication, QoS and policy control, security, detection of the access technology used by the subscriber for service adaptation purpose (e.g. UMTS vs. LTE, xDSL vs FTTH) or interworking among operators, among others.<br /><br /></div> <div> </div> <div>There are important cost savings to be achieved through deploying multiple services on IMS, both in terms of simplifying service implementation and harmonizing the support of functions common to multiple services.<br /><br /></div> <div> </div> <div>There can also be important benefits related to the centralized knowledged in the IMS of service usage by subscribers, like the ability to apply QoS policies that take into account the multiple services used in parallel from the same home or device.<br /><br /></div> <div> </div> <div>The operator needs to prepare and plan for the gradual support of new services and the porting of existing ones on IMS. This implies, among other things, not to take architectural decisions related to IMS that are specific to one service and may prevent the deployment of new ones in the future. To take a simplistic example, an Initial Filter Criteria routing all SIP INVITEs to a TAS may work as long IMS is used to support a single telephony service. On the other hand, it can be a source of nightmare as soon as an IPTV or IMS Messaging service (both making use of INVITEs as well) is introduced.</div> <div> </div> <div>Using IMS as a multi-service platform is not always straightforward for operators which are used to deploy silo services and whose decision processes and organizations are defined according to this paradigm. An IMS strategy may therefore include organizational and decision process changes as well.<br /><br /></div> <div> </div> <div style="font-weight: bold;">IMS for new services<br /><br /></div> <div> </div> <div>I have often read that IMS cannot support new services. This is a wrong assessment.<br /><br /></div> <div> </div> <div>The versatile nature of the SIP protocol, illustrated by the invaluable concept of event packages, the ability to integrate the IMS application layer in a more global SOA (Service Oriented Architecture) and UOA (User Oriented Architecture) framework, and the possibility to strongly integrate IMS with the Internet and its services create thousands of opportunities for new services, many of which are not connected to person to person communication.<br /><br /></div> <div> </div> <div>The operator needs to define a strategy related to this opportunity for innovation: whether it wants to use this opportunity, how, what changes need to be done in organizations, skills and practices.<br /><br /></div> <div> </div> <div style="font-weight: bold;">IMS for a new user experience<br /><br /></div> <div> </div> <div>Possibly more important than new services, IMS permits to create a brand new user experience which makes that the frontier between services as we know them can totally disappear.<br /><br /></div> <div> </div> <div>As already mentioned above, multimedia sessions permit to deliver communication, content and data services in a combined context.<br /><br /></div> <div> </div> <div>Moreover, IMS-based fixed mobile convergence has the potential of eventually making the device and access technology used by the subscriber a mere detail of service delivery. Using a converged subscription, a user could access all its services from all its device, from all access technologies (whether fixed or mobile) and with the same identity.<br /><br /></div> <div> </div> <div>Such a full convergence cannot happen overnight due to various reasons related to organizations, existing business processes, cultures, regulation, and to a much lesser extent, technical issues.<br /><br /></div> <div> </div> <div>The operator must therefore plan and prepare for these evolutions, defining clear steps towards a the target. For instance, the operator may initially decide to use the cost savings aspect of IMS based fixed mobile convergence, by sharing the same IMS core network between fixed and mobile subscriptions. It also must decide if and how it eventually wants to support full convergence. For instance, will the operator eventually offer only converged subscriptions or will it permit subscribers to chose between converged and non-converged subscriptions? In this latter case, what would be the implications?<br /><br /></div> <div> </div> <div style="font-weight: bold;">Managing the complexity of the IMS application layer<br /><br /></div> <div> </div> <div>This blog has often tried to describe the fantastic power of the SIP protocol and the IMS service architecture to deliver rich services.<br /><br /></div> <div> </div> <div>One of the outstanding features of the service architecture is its ability to combine services or service logic components residing in the devices, in the operator's network and across different operators' networks, the Internet or Enterprise networks, in a very flexible manner.<br /><br /></div> <div> </div> <div>There are basically two composition mechanisms:</div> <div>- Implicit composition: device and network based service logic or services are chained in the SIP signalling path.</div> <div>- Explicit composition: device and network based service logic or services make use of each other through an appropriate interface like SIP, web services, HTTP, RTSP, H.248 or another protocol.<br /><br /></div> <div> </div> <div>While very powerful from a functional perspective, this potential leads to new complexity related to distribution, compared to the traditionally centralized implementation of telecommunications services.<br /><br /></div> <div> </div> <div>The operator must therefore find ways to deal with this complexity by addressing issues like the definition of relevant compositio handling functions like the SCIM, the management of service composition data like Initial Filter Criterias and SCIM information, the addressing of potentially redundant or conflicting functions across different servers, or the determination of approaches to measure quality of experience or determine root causes for potential problems.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Optimizing the IMS application layer<br /><br /></div> <div> </div> <div>These distribution and composition mechanisms also lead to potentially critical optimization issues.<br /><br /></div> <div> </div> <div>These optimization issues may for instance relate to:</div> <div>- End-to-end performance if too many physical servers are involved in service delivery. In an extreme case, a spectacular service on paper may simply be irrealistic in practice due to disqualifying delays in service delivery to the end user.</div> <div>- The load of IMS entities, more especially the S-CSCF and application servers, which are essential components in service delivery and composition.</div> <div>- The cost of deploying and operating services if the application layer is too heterogeneous and too distributed or if features are duplicated across multiple servers.</div> <div>- The impact of the failure of a server, for instance an application server, on subscribers. For instance, how many users will be impacted by the failure of an AS and for which services?<br /><br /></div> <div> </div> <div>The operator must therefore define an optimal strategy to deploy services, which optimizes the user experience while minimizing costs and risks. This issue has to deal with service platforms and service topology. For instance, IMS offers alternatives to the dedication of an application server to a certain service for a large portion of subscribers by permitting on the contrary an application server to support a variety of interdependent services for a smaller subset of subscribers.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Service Platforms<br /><br /></div> <div> </div> <div>The choice of service platforms is a key component of an IMS strategy, though only one component among others.<br /><br /></div> <div> </div> <div>An operator has basically the choice between two alternatives for a service platform:</div> <div>- A black box delivered by a service supplier.</div> <div>- An open service platform delivered by an IT vendor, usually called Service Development Platforms (SDPs) in a telecom context, on which services are applications delivered by application providers or implemented in-house by the operator.<br /><br /></div> <div> </div> <div>Concerning SDPs, the operator has further choices between alternatives like IT-centric platforms (e.g. J2EE, .Net) or telecom centric ones (e.g. JAIN SLEE, OSA application servers).<br /><br /></div> <div> </div> <div>Each approach has its advantages and drawbacks, and these may differ depending on the considered timeframe. The operator should therefore define criteria permitting to select the most appropriate platform for a given service in the short, mid and long term, and prepare for the potential migration from one to the other, when appropriate.<br /><br /></div> <div> </div> <div style="font-weight: bold;">IMS clients and devices<br /><br /></div> <div> </div> <div>The best package of IMS services is useless if it is not adequately supported by clients and devices.<br /><br /></div> <div> </div> <div>The operator must address such key issues like:</div> <div>- The distribution of service logic between devices and the network. Note that depending on the characteristics of a device (e.g. high end vs low end, mobile vs. fixed), a given service may require different implementations or implementation variants for access by different devices.</div> <div>- The distribution of service logic and IMS support between different devices on the customer premises, e.g. a home gateway and end-devices.</div> <div>- The management of IMS client updates to support new IMS services.</div> <div>- Optimizing device management by using IMS-intrinsic benefits.</div> <div>- Spreading IMS support in the wider range of devices.</div> <div>- Presenting IMS services in an optimal way to end-users in order to make them attractive and make their access and usage intuitive.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Conclusion<br /><br /></div> <div> </div> <div>IMS by itself is not an answer to the challenges an operator will face in the future. An operator should define a coherent strategy comprising which components of the IMS potential it wants to use, in which timeframe and how.<br /><br /></div> <div> </div> <div>While many operators have already deployed IMS or are planning to do so, usually with a well defined short term objective, I have the feeling that only a few are actively working on a mid and long term IMS strategy.<br /><br /></div> <div> </div> <div>This is a pity, because defining such a strategy would permit to:</div> <div>- Help IMS acceptance in the company by outlining the short, mid and long term benefits expected from it.</div> <div>- Anticipate on changes required in organizations, practices, and skills to apply the strategy. By doing so, speed up the implementation of the strategy.</div> <div>- Have a better control of short and mid term investments, for instance by avoiding excessive investments in implementations or services whose lifetime will be shortened by the implementation of the IMS strategy.<br /><br /></div> <div> </div> <div>As you may infer from this post, I have put a lot of thoughts in these topics. Do not hesitate to contact me on this.<br /><br /></div> <div> </div> <div>Christophe</div>Unknownnoreply@blogger.com12tag:blogger.com,1999:blog-4706138697725258507.post-86301759083303696012008-10-03T12:51:00.001+02:002008-10-04T00:25:56.612+02:00The Service Broker / SCIM market<meta equiv="Content-Type" content="text/html; charset=utf-8"><meta name="GENERATOR" content="BLOCKNOTE.NET"><title></title><style>BODY { FONT-FAMILY:Verdana; FONT-SIZE:10pt } P { FONT-FAMILY:Verdana; FONT-SIZE:10pt } DIV { FONT-FAMILY:Verdana; FONT-SIZE:10pt } TD { FONT-FAMILY:Verdana; FONT-SIZE:10pt } </style><basefont style=";font-family:Verdana;font-size:85%;"><span style="font-size:100%;"><span style="font-family:verdana;">The concepts of SCIM or Service Broker were introduced in 3GPP IMS specifications, but so far have never been adequately defined (I had the opportunity to address this topic <a href="http://theimslantern.blogspot.com/2007/12/index-for-ims-lantern.html">several times</a>).
<br />
<br /></span></span><div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">However, this does not mean that there are no SCIM or Service Broker products (or product components) on the market!
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Light Reading has just issued a report called <a href="http://biz.yahoo.com/prnews/080930/ny35913.html?.v=1"><strong>Combining Telco Services: The Network Service Broker Opportunity</strong></a>. As they provide a list of vendors they have surveyed for their report, I decided to have a look at what these companies actually provide by looking at documentation available on their web sites. In this post I will summarize my findings, which are only based on my (potentially erroneous or biased) interpretation of usually high level product descriptions.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>Call Control / IN Centric Service Broker / SCIM
<br />
<br /></strong></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Most of these products are presented as equally applicable to Intelligent Networks and IMS, which in some cases might mean that the product is an Intelligent Network one that has been upgraded to support SIP, or that the supplier hopes that what is good for IN will also be good for (telephony-centric) IMS.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">As described by Aepona, their Service Broker is primarily a proxy Service Switching Function (SSF) between the switch and multiple IN servers (thus permitting service invocation in multiple servers, what a switch is usually unable to do). As an IMS "SCIM", it performs a similar function between the S-CSCF and multiple ASs. Because of its dual SIP/IN nature, the Service Broker can also serve as a gateway between IMS and IN (the "IM SSF" entity in 3GPP IMS specifications).
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The description of the AppTrigger's Ignite Application Session Controller (ASC) includes a "SCIM+". Like Aepona's Service Broker, ASC sits between the network and the "application cloud". IMS is explicitly listed along legacy TDM networks that can appear below the ACS, but the figure on the web page does not show IMS at all, only entities of a fixed IP access network. The product supports Parlay X, MAP/CAMEL and SIP. It also supports SIP to IN interworking (IM SSF).
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">OpenCloud is the supplier of a JAIN SLEE platform, a standardized Java service execution platform that was initially targeted at new generation IN services (IN services implemented in Java on an open platform and possibly using non-call related service capabilities like location or SMS as part of their logic). Such a platform can also support SIP and Diameter interfaces and can therefore be positioned as a SIP AS platform as well. On their page, Opencloud speak about a Service Interaction SLEE (SIS) for IN, and another one for IMS. The SIS supports service interaction and composition. The SIS can also offload an IN server by supporting some IN logic itself (logic as it is based on an IN service platform).
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">jNetX is another supplier of a JAIN SLEE platform. I was not able to find any information about a SCIM or Service Broker on their site, but if they have one it is very likely to be similar to what Aepona, AppTrigger and Opencloud offer.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">I could not find a precise description of Tekelec's TekSCIM Service Mediator. However, as it is supposed to provide a seamless experience to TDM and IMS users, and its IMS role is to manage and simplify complex service interactions, I assume this is more or less the same type of product.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">These products often have a clear interest in a TDM IN context, and I think this should be the primary reason why an operator might be interested in them. On the other hand, I am more doubtful about their value in an IMS context, even for the support of telephony services, and this for the following reasons:</span></div> <div style="font-family:verdana;"><span style="font-size:100%;">- An IMS S-CSCF has the capability to chain several ASs in SIP signalling, so such a feature supported by a SCIM/SB would be functionally redundant.</span></div> <div style="font-family:verdana;"><span style="font-size:100%;">- Call control Service Interaction Management is an important issue that has never been addressed in a satisfactory generic manner in IN networks, more especially when implemented in a standalone box outside of application servers. Why would this change now and more especially in an IMS context?</span></div> <div style="font-family:verdana;"><span style="font-size:100%;">- Unless it is used to emulate the TDM network, IMS is a very different type of network, and SIP has nothing to do with INAP or CAP. What is good and necessary for TDM is not obviously good and necessary in IMS.</span></div> <div style="font-family:verdana;"><span style="font-size:100%;">- Providing added value call control services in IMS is necessary, but it is not what operators will make money with. A SCIM/SB centered around voice-centric call control is by no means the magic box that will solve all operators' IMS related problems.</span></div> <div style="font-family:verdana;"><span style="font-size:100%;">- The interest of an IM SSF function is questionable. IN platforms are often old and costly, and operators often have to fully rely on the supplier of the platform for developing new services. Is it interesting for operators to extend the life of these platforms for many years by positioning them in their long term IMS strategy? On the contrary, many would prefer to replace their IN servers by new application servers able to control TDM calls as well as IMS ones, and this is exactly what the ongoing 3GPP IMS Centralized Services (ICS) initiative is trying to achieve.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>TCAP / Web Services Gateway
<br />
<br /></strong></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Convergin's Accolade WCS SCIM seems to be a gateway supporting translation between TCAP and web services. It is not clear to me if this is only this and if it is limited to TCAP (leaving the task of supporting CAP, MAP or INAP to the application) or if it also supports a direct translation of these protocols to web services.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The first thing to say is that this does not correspond at all to what someone can expect from a product called "SCIM".
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The second thing to say is that, whether the name is appropriate or not, this component can be very interesting in an IMS context, when it is associated to an IP-centric service platform, which lacks native support of legacy SS7-based protocols to access legacy service capabilities in the TDM network. This is typically the case of J2EE platforms supporting SIP servlets for IMS, which are offered by well known companies like IBM, Oracle or Sun.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">These platforms are ideal to implement innovative IMS applications which can combine usage of SIP, HTTP, Diameter and web services, thus permitting convergence between the Internet, Enterprise IT and the new Telco domains. So far, the lacking capability has been the possibility to conveniently connect with the legacy TDM telco world (OSA/Parlay gateways have not proved to be simple and cost effective enough).
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">I do not think that such a product would allow a J2EE server to become a suitable platform to implement classical IN services. On the other hand, they could permit to implement new TDM-centric services that make use of IMS enablers like presence or instant messaging, or IMS-centric services that need to use TDM capabilities like starting a pure TDM call.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Consequently, this is not a surprise if Convergin seems to be in business with the J2EE suppliers I mentioned.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>SIP-level Orchestration Engine
<br />
<br /></strong></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">This is the approach adopted by suppliers of J2EE platforms (IBM, Oracle/BEA, Sun?), which usually clearly distinguish between the need to orchestrate web services, using a standard like BPEL, and the need to orchestrate services invoked through SIP requests. Differences may lie in both semantical and performance aspects.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">In this context, the SCIM/SB corresponds to the concept of application router, defined in JSR 289, the latest SIP servlets specification. The original mechanism specified for invoking SIP servlet applications, based on servlet mapping rules that are quite similar to web servlet mapping rules in the fact that they rely on a quite simplistic analysis of incoming SIP messages, has proved to be inadequate for a proper selection and composition of IMS services hosted by a J2EE platform. The application router permits to replace the servlet mapping rules by an intelligent component tailored to the needs of the operator.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The intelligence itself is not standardized, and this is therefore an important differentiation area for suppliers or for operators who may decide to specify and possibly implement their own application router.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The service invocation and chaining logic may take into account subscription information (which services the user is subscribed to) as well as other information related to the user, such as presence, service preferences (e.g. the user wants this service to be executed at certain times) or calendar information.There might also be more or less sophisticated rules related to the composition of services.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The ideas for a SCIM I exposed on this blog fit in this context, with the concern to remain as simple as possible and avoid too much intelligence, complexity and processing delays in this component. I think that the suppliers of J2EE platforms are trying to offer the possibility for more sophisticated rules, adding both more potential and more risks to the concept.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>Global Orchestration Engine
<br />
<br /></strong></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">This seems to be the case for the Alcatel-Lucent Service Broker, implemented by Bell Labs, which is part of the Alcatel Lucent Service Delivery Platform (SDP). The component supports both SIP and web services interfaces, and examples given illustrate access to user subscription information, service preferences, presence, as well as access to other services like IPTV through web services.*
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">This Service Broker therefore seems to be an integrated equivalent to the combination of a web services orchestration engine and a SIP application dispatcher as proposed by J2EE suppliers.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">A potential reason for this difference is that Alcatel Lucent provide their own SIP servlets container, which is a standalone component that needs to be integrated with a third party J2EE platform for converged services. The service broker would therefore permit integration with J2EE web containers (integration which is much tighter in J2EE platforms supporting both web and SIP servlets) and would transfer web services orchestration to the Alcatel Lucent SIP-centric component as well.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Such an approach might offer advantages, more especially in terms of performance, but could also come with associated complexity, a lack of compliance to web services orchestration standards, and the gain obtained through a tighter integration of different orchestrations may also lead to less flexibility for the operator. However, this would be an aspect to investigate.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>Service Management Mediation
<br />
<br /></strong></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Leapstone's CCE ServiceBroker is a tool that applies both to legacy networks and IMS. It aims at making easier the management and provisioning of packaged services, including subscriber management and live management of composition and interaction rules between blended services.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">From an IMS perspective, this means that the operator may use serviceBroker to define service composition rules and to generate appropriate data for an HSS (Initial Filter Criteria) and a SCIM, as well as for other network databases.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">As such, ServiceBroker appears to be a management complement associated to what is usually called a SCIM or Service Broker. More generally, this is a service and subscriber management mediation tool as can already be found on the
<br />market, but enriched with IMS-specific service composition requirements.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Such a tool is very important but also requires ad-hoc adaptations in order to fit in specific environments, considering that management interfaces are usually vendor-specific. Concerning the SCIM/SB, this is even worse as this component is not standardized and leaves room for very different implementations, as can be seen in this post.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>Other SCIMs / Service Brokers
<br />
<br /></strong></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Considering the list provided by Light Reading, I was not able to find anything about the Ericsson and Huawei implementations of the concept.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>Conclusions
<br />
<br /></strong></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The concept of SCIM / Service Broker, which is part of IMS specifications but has never been specified, leaves room to multiple interpretations and very different products claiming this label can be found on the market.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">You can basically find two mainstream interpretations:</span></div> <div style="font-family:verdana;"><span style="font-size:100%;">- The SCIM / SB is a standalone component that takes care of classical call control and IN issues related to the support of multiple application servers and complex interactions between call control services. The concept is primarily aimed at legacy networks and is also promoted as being equally applicable (and important) for IMS. The telephony context is clear and while everyone can have its own opinion on the interest of such a product for IMS, I will assume that no-one can seriously claim that this component will help an operator finding new sources of revenue with IMS (the key term here is "leveraging", applied to TDM and IMS in the context of telephony).</span></div> <div style="font-family:verdana;"><span style="font-size:100%;"><strong>- </strong>The SCIM / SB is a component part of a service delivery platform, and its aim is to complement what the IMS core network component called S-CSCF can do for the composition and "blending" of several services. Such a SCIM / SB can be specialized in SIP-level orchestration (a dedicated engine will do the equivalent for web services) or can address both SIP and web services orchestration.</span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">
<br />The first interpretation is closer to the initial motivation for introducing the concept in 3GPP specifications, while the second is closer to what the real IMS need actually is.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">A major architecture difference between the two interpretations is that the first one is a standalone product standing between the IMS core network and application servers, while the second is an added-value component of a more comprehensive product usually called service delivery platform in the telecom context (an application server in its own right).
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">The description I made of a SCIM on this blog is essentially one of the second category. However, since then I thought a little bit about what a standalone SCIM / SB could be, in the terms of which value it could provide to a SCIM / SB embedded in a service platform can do.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">I cannot divulge here the content of these thoughts, as they are being discussed with a customer company of Arismore, but to make it short I think there is a lot of added-value a standalone SCIM / Service Broker could<strong> </strong>add to a service platform -embedded one, while being very different from what the market has to offer right now. More especially, such a product would have no relationship to IN and call control.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">If you are knowledgeable in some of the products I surveyed in this post, do not hesitate to contact me in order to correct or complement it. I will gladly compile and post feedbacks, including those that make a point against my assertions.
<br />
<br /></span></div> <div style="font-family:verdana;"><span style="font-size:100%;"> </span></div> <div style="font-family:verdana;"><span style="font-size:100%;">Christophe</span></div>
<br />Unknownnoreply@blogger.com85tag:blogger.com,1999:blog-4706138697725258507.post-91904627746902665282008-04-15T16:43:00.008+02:002008-09-27T11:34:59.382+02:00Course on the IMS Application Layer<span style="color: rgb(204, 0, 0);">Through my company Arismore, I am offering a 2-day course on the IMS application layer. It can be delivered either in French or in English (all the material is in English). There are sessions regularly organized in my company's premises in Saint-Cloud, Paris, France, which are open to individuals. The course can also be delivered on site, within or outside Europe.</span><br /><br /><span style="color: rgb(204, 0, 0);">What makes this course unique is that, while others usually provide a litteral description of IMS specifications and essentially concentrate on the IMS core network, largely overlooking the IMS service architecture, sometimes even delivering misleading information, this one totally concentrates on this domain in which resides the true potential of IMS for differentiation and revenue generation (both for operators and suppliers). You can take this course after a regular IMS one, but my experience shows that even IMS novices can follow it without missing any core network background.</span><br /><br /><span style="color: rgb(204, 0, 0);">The course does not only describe IMS application-related specifications that span multiple standardization organizations (3GPP, the IETF, OMA, ETSI TISPAN). It also helps understanding what lies behind them, by providing revealing insights on how they were produced (e.g. historical timeline, assumptions, mistakes, conflicts between companies, need to address specific issues), shows in details how they effectively work, explains how they can optimally be exploited to deliver innovative services or innovatively deliver existing ones, and finally addresses the main opportunities and challenges that IMS brings to the industry. After this course, the student can understand what IMS can deliver, why there exist so many conflicting perceptions of IMS, and why IMS is as much a challenge as a promise.</span><br /><br /><span style="color: rgb(204, 0, 0);">Several on site sessions have been given or are planned in the near future, and the response has been so positive that these sessions usually lead to discussions about further collaboration between the customer company and Arismore.</span><br /><br /><span style="color: rgb(204, 0, 0);">Contact me at <span style="color: rgb(0, 0, 102);">cgourraud@yahoo.ca</span> if you are interested in either an on site session or in a session organized in our offices in Paris (planned dates can be found in the side bar of the blog).</span><br /><br /><span style="color: rgb(204, 0, 0);">Here follows a description of the course. You can also request from me a slightly more detailed powerpoint content description.</span><br /><br /><span style="font-weight: bold;">Part 1: The IMS Service Architecture</span><br /><br />This is the most comprehensive part of the course. It addresses several objectives: understanding how the IMS service architecture works (dynamic view), getting an overview of the specifications (static view), understanding the drivers behind standardization decisions (motivations, design by accident, pending issues), understanding how the architecture can be used (application layer architecture, service patterns).<br /><br />Standardized topics include:<br />- Overview of the architecture<br />- IMPUs & PSIs<br />- ISC usage scenarios & examples<br />- Details of ISC<br />- Service profiles and initial filter criterias (iFCs)<br />- OSA SCS / IM SSF / SIP AS<br />- MRFC/MRFP<br />- SCIM & Service Broker<br />- IMS Communication Services<br />- User Data Management (Sh, OMA XDM, GUP)<br /><br />The service features of SIP are treated as a specific topic. It highlights the potential of the protocol when used in IMS or in other networks:<br />- Multimedia sessions<br />- Event packages<br />- Routing alternatives (SIP forking, callee capabilities/caller preferences), GRUUs)<br />- Support of Group Services<br />- Combination with other protocols (content indirection, SIP REFER, SIP session, body in SIP message)<br />- Interoperability aspects (between SIP profiles, between SIP and other protocols)<br /><br />Service oriented features specific to the IMS service architecture, and complementing the intrinsic SIP ones are also detailed. This part permits to understand the value IMS adds on other SIP-based networks:<br />- Service composition<br />- Logic mutualization<br />- Personalization / Differentiation of user experience<br />- Simple access to services<br />- Service flexibility / agility<br />- Authorization to services<br />- Unlimited service scalability<br />- Multi-vendorship / Differentiation for each service<br />- Service anthropomorphism<br />- Usage of a single identity for multiple services<br /><br /><span style="font-weight: bold;">Part 2: IMS standardized services and enablers</span><br /><br />This part covers IMS services and enablers standardized or under standardization in 3GPP, OMA and ETSI TISPAN. As for Part 1, background information about the standardization process is given.<br /><br />User data services & enablers:<br />- Presence (IETF, 3GPP, OMA specifications)<br />- Group Management / Group Services<br /><br />Voice oriented services & enablers:<br />OMA Push To Talk Over Cellular (Poc) V1 and V2<br />3GPP Combining circuit-switched and IMS services (CSI)<br />3GPP Voice Call Continuity (VCC)<br />3GPP/TISPAN Multimedia Telephony (MMTel)<br />3GPP IMS Centralized Services (ICS)<br />3GPP Conferencing<br /><br />Messaging services & enablers:<br />OMA SIP Push<br />Messaging (IETF IM, 3GPP IMS Messaging, OMA SIMPLE IM)<br />3GPP SMS over generic IP access<br />OMA Converged IP Messaging (CPM) - Messaging part<br /><br />Multimedia services & enablers:<br />OMA Converged IP Messaging (CPM) - Multimedia part<br />TISPAN IPTV<br /><br />This part ends with a description of the Rich Communication Suite (RCS) initiative<br /><br /><span style="font-weight: bold;">Part 3: Opportunities & Challenges</span><br /><br />This final part addresses essential topics which go beyond IMS specifications.<br /><br />It is structured around the following topics:<br />- Fixed Mobile Convergence (from technical to user oriented convergence: opportunities and challenges)<br />- Which role(s) for the operators (e.g. bitpipe provider, intelligent pipe/channel provider, service provider with more or less control)<br />- Exploiting IMS Capabilities (e.g. User Oriented Architecture, Distributed Service Architecture, need for optimizing the IMS service architecture)<br />- Service Platforms (e.g. black boxes vs. open platforms, JAIN SLEE, J2EE)<br />- IMS as a service integration framework (different types of IMS services, how to integrate non-IMS services into IMS, relationship to 3rd party service providers)<br /><br />ChristopheUnknownnoreply@blogger.com286tag:blogger.com,1999:blog-4706138697725258507.post-79992217632626562482008-04-09T11:40:00.000+02:002008-04-09T11:58:45.550+02:003GPP Communication ServicesIn the past, I had the opportunity to write three posts (<a href="http://theimslantern.blogspot.com/2007/05/danger-ims-communication-services.html">here </a>and <a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-uncut.html">there </a>and <a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-latest-news.html">there</a>) about the 3GPP concept of Communication Service. These posts were written in the heat of possibly major IMS-defining decisions being taken, in order to warn about some risks related to some options. Time has passed and the concept is now (nearly totally) specified in IMS. In this post I will describe Communication Services and how they can be used by operators.<br /><br /><span style="font-weight: bold;">Definition</span><br /><br />According to TS 23.228, <span style="font-style: italic;">"an IMS communication service is a type of communication defined by a service definition that specifies the rules and procedures and allowed medias for a specific type of communication and that utilises the IMS enablers."</span><br /><br />Examples of Communication Services are OMA Push To Talk over Cellular (PoC) or OMA SIMPLE Instant Messaging (also called IMS Messaging in 3GPP specifications).<br /><br />In other words a Communication Service is a set of communication media and the rules that govern the possible (i.e. permitted) transactions between them. For instance, OMA SIMPLE Instant Messaging only permits SIP sessions to include messaging components. Trying to upgrade a messaging session into a voice session is not part of the OMA SIMPLE IM service, and can be considered as a violation of the OMA SIMPLE IM Communication Service.<br /><br />A Communication Service is identified in SIP signalling through an IMS Communication Service Identifier (ICSI). The format as well as an example of ICSI can be found in TS 24.229:<span style="color: rgb(0, 0, 153);">urn-xxx:3gpp-service.ims.icsi.mmtel</span> (Multimedia Telephony).<br /><br />An IMS application can use a Communication Service to be delivered to the end-user. For instance, an application could push content to a user by using the OMA SIMPLE IM Communication Service. Such an application can be identified in SIP signalling through an IMS Application Reference Identifier (IARI) for which TS 24.229 also provides an example: <span style="color: rgb(0, 0, 153);">g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-application.ims.iari.game-v1"</span>. Note that IARIs are only meaningful for IMS clients and are totally ignored by IMS core network entities. This is why I will not mention them much in the following.<br /><br />The list of Communication Services associated to a user is provisioned in the service profile of the user in the HSS. This list is used by the S-CSCF for its processing of SIP requests. It is also provisioned in IMS clients for usage.<br /><br />The <a href="http://tools.ietf.org/html/draft-drage-sipping-service-identification-01">IETF draft</a> describing the necessary SIP extensions to support the concept of Communication Service states that all the information required for a network to understand the service requested by a user should be derivable from the SIP request (e.g. by looking at the SDP and the request-uri in a SIP INVITE), without the need for an explicit identifier like an ICSI. It accordingly states that the ICSI is a way for the network to save computational resources required to inspect the SIP request. I would tend to disagree with this analysis. First, the ICSI does not only define how a user wants to start the session, it also explicitly defines that the user will not try or may not be allowed to later renegotiate the session in a way that is not specified by the service definition. Moreover, an IMS S-CSCF will not make the economy of analyzing the request, as it will have to ensure that the ICSI and both the initial and subsequent INVITEs in the session are coherent one with the others. Therefore, the usage of Communication Services will rather increase the need for computational resources in the S-CSCF than lower it.<br /><br /><span style="font-weight: bold;">What Communication Services could have been</span><br /><br />The company which introduced the concept of Communication Service in 3GPP had a quite radical proposal of how it would be used:<br />- The usage of a Communication Service would have been mandatory in all SIP requests initiated by an IMS client. A side-effect was that all IMS applications would have had to rely on a Communication Service, thus strongly limiting opportunities for IMS services.<br />- Two SIP clients would not have been able to set up a session together if they did not share the same Communication Service. This would have implied that a client supporting OMA SIMPLE IM and a client able to support both messaging and voice within the same SIP session would not be able to establish a session together, even if they shared a common media component permitting to communicate. This would also have implied that a SIP client without any knowledge of IMS-specific ICSIs would not have been able to set up sessions with an IMS client.<br />- Usage of Communication Services totally relied on the IETF-specified Contact and Accept-Contact headers (in which ICSIs and IARIs would have been included as media feature tags), thus using a standard IETF header in a non-standard way and adding to interoperability issues with non-IMS SIP clients.<br /><br />Would have they been accepted, these proposals would have raised important barriers to service innovation in the IMS domain, and would have caused huge interoperability problems between IMS and non-IMS clients, de facto creating a walled garden out of IMS.<br /><br />A side effect is that the concept would have created a two-tiered IMS application layer, with application servers supporting (standardized) Communication Services at the bottom, and application servers supporting applications making use of Communication Services at the top. The lower tier would typically have consisted of standardized services implemented as black boxes supplied by classical network equipment suppliers, and the (rather power-less) upper tier by open platforms provided by IT suppliers (more or less what you can find in a pre-IMS telecommunications network, with OSA/Parlay usually defining the frontier between the two layers). This two-tiered architecture would have been reproduced within IMS clients.<br /><br />However, in their current state, due to the involvement of the IETF and the consensus imposed by companies which did not endorse this original view, 3GPP specifications are quite far from this.<br /><br /><span style="font-weight: bold;">General benefits of Communication Services</span><br /><br />Communication Services can be useful to all operators, even if their strategies clearly differ, as long as each operator has options about how it wants to use them. Representing an operator, I had in the past the opportunity to discuss the issue with the supplier promoting the concept. After expressing my concerns about it and hearing their arguments in its favor, I told them: "Communication Services are fine with me as long as, as an operator, I can use them when I see an interest for it and not use them when I do not see any". Since then, this possibility to use Communication Services <span style="font-style: italic;">a la carte</span> is what has been specified.<br /><br />These usage options start at the IMS client, which may but is not mandated to insert an ICSI (and possibly IARI) in a SIP request it generates. They also exist further in the processing of SIP signalling by the IMS core network, as you will see below.<br /><br />But first, let us consider the aspects of Communication Services that may appeal to all operators.<br /><br />Communication Services can make the life of operators easier in some aspects.<br /><br />Put a label on a service, transport this label end-to-end in SIP signalling, and you get a practical handle for charging (more especially when several operators and/or transit network suppliers are involved in the end-to-end communication), QoS and policy control, and to set your initial filter criteria for involving ASs supporting the service. However, this does not mean that the IMS core network should ease on its processing. For instance, current IMS specifications permit to charge a session based on both accounting information related to SIP signalling (e.g. this is a messaging session with a beginning and an end) and media level information (e.g. this is indeed messaging that goes through). It would be risky for an operator to assume that because an ICSI states that the session is about messaging and messaging only, this is actually the case. If so, Communication Services could be a great weapon for fraud.<br /><br />The usage of ICSIs in users' service profiles to determine the routing to application servers can be of great interest as I will illustrate now. Imagine that an IMS client initiates an INVITE for messaging while the operator has deployed OMA IM SIMPLE, OMA CPM and OMA PoC V2, which all may start with such an INVITE. The operator may face the tricky challenge to decide to which application server the request should be routed in the case where the user is subscribed to at least two of these services. By placing an ICSI identifying the service it wants to use, the IMS client indicates to the network that this is this service and not this one that it intends to use.<br /><br />Passed these basic, different handling of communication services are possible, which map to different strategies.<br /><br />The two sections below describe these potential differences. What is common between both is that an IMS client may insert an ICSI in a SIP request it generates, but this is not a mandatory standard procedure. When a client wants to use a communication service (and possibly a specific application making use of it), it inserts the ICSI in a header called P-Preferred-Service. It may also include the ICSI and IARI in Accept-Contact headers (currently 3GPP is not clear about the exact procedure for this).<br /><br /><span style="font-weight: bold;">Communication Services for advanced user control</span><br /><br />The S-CSCF serving a user (the originating one for requests initiated by the user, the terminating one for requests received by the user) may be mandated to insert an ICSI in all the requests it receives. For doing so, it compares the request with the list of ICSIs provisioned in the user's service profile for a match. This ICSI is inserted in a P-Asserted-Service header created by the S-CSCF. In the case where the IMS client created a P-Preferred-Service header, it is removed by the S-CSCF, and it is possible that the ICSI inserted by the S-CSCF and the original ICSI are different. The S-CSCF will also insert an ICSI in SIP requests which did not have any P-Preferred-Service header.<br /><br />When an ICSI inserted by a user does not match the request (e.g. the user inserted an OMA SIMPLE IM ICSI and actually has an SDP body for a voice session) or the ICSI in the SIP request is not in the list of authorized ICSIs in the user's service profile, or the S-CSCF cannot map the request to any of the ICSIs authorized for the user, the S-CSCF may simply reject the request.<br /><br />Once a SIP session has started, the S-CSCF may also reject renegotiations of the session that do not correspond to the service definition (e.g. a user tries to upgrade an OMA SIMPLE IM session to voice).<br /><br /><span style="font-weight: bold;">More liberal usages of Communication Services</span><br /><br />An operator may inhibit all the restrictive behavior of the S-CSCF by not provisioning any ICSI in the service profile of a user. In this case, an IMS client can still insert an ICSI in a SIP request (the ICSI may have been provisioned in the client or may be hard-coded) and the ICSI may still be used to route the request to an application server, for charging, QoS or policy control, but the S-CSCF cannot insert an asserted ICSI and reject any request. Note that such an ICSI cannot be trusted by the core network but an AS can be used for this purpose.<br /><br />If an operator provisions ICSIs in the service profile of the user, it can still decide that the S-CSCF should not reject requests as in the specification this decision is left to the operator's policy. The S-CSCF will just insert the P-Asserted-Service header.<br /><br />Finally, even if the most restrictive S-CSCF behavior could apply, its potential impossibility to unambiguously associate one ICSI to a request (e.g. the user is authorized to use an OMA SIMPLE IM and an OMA CPM ICSI while both services can start with a messaging session) mandates it not to insert any ICSI in the request, <span style="font-style: italic;">de facto</span> inhibiting its restrictive processing.<br /><br /><span style="font-weight: bold;">Interoperability with non-IMS cients</span><br /><br />The IETF solved the potential interoperability issues between IMS and non-IMS clients by clearly discriminating between, on the one hand the usage of ICSIs and IARIs in the SIP Accept-Contact and Contact headers, which comply with the IETF procedures for a SIP client to declare its capabilities to a network (so-called <span style="font-style: italic;">callee capabilities</span>) and for a SIP client to indicate preferences or instruct a SIP network about how the request it generated should be routed/forked (so-called <span style="font-style: italic;">caller preferences</span>), and on the other hand the usage of ICSIs for network-centric usage within an IMS network (definition of two 3GPP specific headers: P-Preferred-Service and P-Asserted-Service).<br /><br />Based on 3GPP procedures, a non-IMS client may receive a SIP request from an IMS client that includes a P-Asserted-Service header, but this header will simply be ignored and will not impact processing in the non-IMS client.<br /><br />ICSIs and IARIs populated in the Accept-Contact header do not create interoperability problems either, as this header can (optionally) be used by a client to help selecting an application to be contacted but is primarily aimed at SIP proxies, instructing them about how to route the request.<br /><br />However, there might still be a case where an IETF-compliant usage of Accept-Contact may prevent an IMS client to initiate a session with a non-IMS client: if the Accept-Contact header that includes the ICSI or IARI also includes both the "<span style="font-style: italic;">explicit</span>" and "<span style="font-style: italic;">require</span>" parameters, it instructs the SIP proxy not to route the request to a SIP client that did not explicitly declared its support of the ICSI (or IARI). As non-IMS clients are very likely not to being even aware of IMS ISCIs and IARIs, the IMS client would never be able to set up a session with them (however, the funny thing is that a non-IMS client would be able to set up a session with an IMS one).<br /><br />At the moment, 3GPP did not decide on how ICSIs and IARIs should be used in Accept-Contact, but the risk I just mentioned is explicitly stated as a note in TS 24.229, which indicates that some companies are very wary about the issue. In any case, there is a need to clarify this aspect, and this might have to be done either globally (e.g. an IMS client shall not use these two parameters for ICSIs, but it might use them for some IARIs if the corresponding application requires it), or service per service, unless it is left to the decision of the operator.<br /><br /><span style="font-weight: bold;">Potential issues with ICSIs</span><br /><br />To be used for advanced control, ICSIs require additional provisioning in the service profile of the user (HSS) as well as in IMS clients.<br /><br />ICSIs now make the S-CSCF service aware, as it has to be able to compare ICSIs to SIP requests and SDP bodies into session initiation and session re-negotiation requests. At best this may imply a reconfiguration of the S-CSCF each time a new communication service is introduced (standardized or operator-specific). At worst this may imply an upgrade of the S-CSCF.<br /><br />The S-CSCF processing of ICSIs (checking if a request matches the ICSI in it, trying to find an ICSI for a request without any, checking if session renegotiation matches what is permitted for an ICSI) will add to resource consumption and end-to-end delays. In the case where ICSIs do not significantly simplify other procedures of the IMS core network (and I do not think they will), this is a pure loss for core network characteristics. This might be a minor factor, but it could also be an important one once IMS traffic grows in important proportions.<br /><br /><span style="font-weight: bold;">Any future for Communication Services used for control?</span><br /><br />In its current state of specification, the concept of Communication Service can be used both by liberal operators and by operators wishing to exert a strong control over their customers.<br /><br />In the liberal approach, ICSIs can be used to facilitate the routing of service requests to the right application server(s). No constraining behavior of the S-CSCF will be mandated, and while ICSIs can be used as a convenient way to identify a service (for instance in charging records), they will not significantly help the task of core network entities in their processing (e.g. generating accurate charging records).<br /><br />In the controlling approach, ICSIs can be used as a means to check that users only access (typically silo) services they are explicitly authorized to use, and that they cannot escape control (at least at SIP level) during the session.<br /><br />Maybe the controlling approach will be used by some operators. However, considering the facts that ICSIs do not only come with benefits and that users may be led to draw comparisons between operators with a strong controlling and a more liberal approach, I am not sure right now that Communication Services are promised to a bright IMS future. Future will tell.<br /><br />Christophe<br /><br />References:<br />Definitions and requirements: <a href="http://www.3gpp.org/ftp/Specs/html-info/23228.htm">TS 23.228</a> chapter 4.13<br />Detailed procedures by IMS client: <a href="http://www.3gpp.org/ftp/Specs/html-info/24229.htm">TS 24229</a> chapters 5.1.1.2.1 (declaration of supported ICSIs as callee capabilities at registration), 5.1.2A.1 (generation of SIP request), 5.1.2A.2 (reception of SIP request)<br />Detailed procedures by S-CSCF: <a href="http://www.3gpp.org/ftp/Specs/html-info/24229.htm">TS 24.229</a> chapter 5.4.3.2 (originating requests), 5.4.3.3 (terminating requests)<br />Communication Services in Service Profiles: <a href="http://www.3gpp.org/ftp/Specs/html-info/29228.htm">TS 29.228</a> Appendix B (B.2 and B.2.1A)Unknownnoreply@blogger.com18tag:blogger.com,1999:blog-4706138697725258507.post-55927837897344690362008-04-03T16:44:00.000+02:002008-04-03T16:53:59.172+02:00IMS Service Anthropomorphism<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_pjPCbrdQN1U/R_TtivJE3yI/AAAAAAAAAFE/0VPdq6WkS88/s1600-h/Service+Anthropomorphism.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_pjPCbrdQN1U/R_TtivJE3yI/AAAAAAAAAFE/0VPdq6WkS88/s400/Service+Anthropomorphism.jpg" alt="" id="BLOGGER_PHOTO_ID_5185030252036153122" border="0" /></a><br /><br /><basefont><strong>Anthropomorphism</strong> is the attribution of uniquely human characteristics and qualities to nonhuman beings, inanimate objects, or natural or supernatural phenomena (wikipedia).<br /><br /><div> </div> <div>The pictures taken from various cartoons by Tex Avery that you can see at the top of this post illustrate an anthropomorphic behavior associated to animals.<br /><br /></div> <div> </div> <div>Service anthropomorphism is therefore the possibility for an IMS service to behave and be treated as a human user of the IMS network. This post describes how IMS supports service anthropomorphism and what an anthropomorphic service can do and benefit from.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Symetric usage of SIP between IMS users and IMS services</span><br /><br /></div> <div> </div> <div>The IMS service architecture ensures that every SIP request that is generated or processed by an IMS client can also be generated or processed by an IMS application server.<br /><br /></div> <div> </div> <div>For instance, if an IMS client can generate a SIP instant message, set up a SIP session, or subscribe to the presence of another user, an IMS application server can do it as well.<br /><br />Conversely, if an IMS client can receive a SIP instant message, process a SIP session set up request or process a SUBSCRIBE to any SIP event package (e.g. presence), an IMS application server can also do as well.<br /><br /></div> <div> </div> <div>An interesting consequence of this feature is that the concept of enabler (the possibility for a service to use a remote feature) is simple to implement in an IMS network, and can be extremely powerful.<br /><br /></div> <div> </div> <div>In a traditional telecommunications architecture, some services offered to an end-user can also be used as an enabler by an application server. This is the case for network-based user location in a mobile network, which can accessed in a location server from both a device and an application server hosting location-based services. However, in most cases, the user to service interface and the service to service interface are different, and both need to be specified and implemented for the application to be used as both an end-user service and an enabler by other services. In IMS, as soon as a service is deployed in the network, for which a SIP based interface has been defined for access by IMS clients, the exact same interface can immediately be used by other IMS application servers to access the service as an enabler for their own services. In theory and when it makes sense from a service perspective, every new IMS service can become an enabler for other services, which themselves can become enablers for other services. There is therefore a high potential for an explosion of service opportunities each time a new IMS service is deployed in the network.<br /><br /></div> <div> </div> <div>Another difference with a traditional telecommunications network is that, in such a network, a service enabler is always network-based. As devices are more or less stupid, every added-value logic that can serve other services is located on a server in the network. On the other hand, with IMS, every logic processing SIP requests can theoratically be located both in IMS clients and in IMS application servers. While complex logic (e.g. full-featured presence) will tend to be located in powerful IMS ASs, simpler logic can be located in the IMS client and be accessed by an AS through SIP. For instance, IMS clients can support SIP event packages (using SUBSCRIBE, NOTIFY, PUBLISH) that are able to inform and notify ASs about what is located or is happening in the IMS client: session states, information located in device, information or status about a specific device-based application like a game. This implies that, with IMS, the concept of enabler is extended from the network to the endpoints, and this offers potentially huge service opportunities.<br /><br /></div> <div> </div> <div>Finally, in a traditional network a service and the enabler it accesses are most of the time located in the same operator's domain, as addressing, request routing and security issues are important barriers to overcome for inter-operator interfaces. In an IMS network, SIP routing procedures cross boundaries between networks with secured interfaces, and the addressing of SIP enablers is based on public identities like IMS Public User Identities (IMPUs) and Public Service Identities (PSIs). This implies that, technically, a presence based service from one operator can access the presence of a user subscribed with a different operator (or located in the Internet, but then with security risks).<br /><br /></div> <div> </div> <div>In an IMS network, all SIP requests originate from a public identity (IMPU, PSI) and are addressed to a public identity (IMPU, PSI). How do IMS application servers fit in this picture?<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Service impersonating a user</span><br /><br /></div> <div> </div> <div>An IMS AS can process requests addressed to an IMPU of a user it serves, and can generate a SIP request on behalf of a user, by placing an IMPU as the originator of the request it (the AS) actually generates.<br /><br /></div> <div> </div> <div>For instance, an AS hosting session control logic for a user can receive the INVITEs addressed to an IMPU of this user and serve it on its behalf (e.g. accept or reject the session). In another example, IMS presence requests are always addressed to an IMPU of the user from which the presence is sought. In theory, this request could and should be routed to one or several IMS clients associated to the user, but in practice they are all routed to a network-based AS serving presence requests on its behalf.<br /><br /></div> <div> </div> <div>In yet another example, consider a service that decides on the best way to route messages issued by user A. Possible alternatives include IMS messaging to the same IMPU, IMS messaging to another IMPU, SMS, MMS, email, or an Internet IM service. When user A issues an IMS message to user B, this message is routed to the AS supporting the advanced routing function. This AS can then extract the IMPU of user B from the IM, and generate a presence request originated from user A and addressed to user B. This request will reach the presence server of user B, possibly in another network, which will apply authorization rules associated to user A and generate an appropriate response. This response may provide information to the service about the messaging alternatives available for user B, as well as the associated addresses, preferences, and reachability. It can therefore select the most appropriate approach to deliver the message to user B. In this use case, it is very important for the advanced routing service to endorse the identity of user A, because it acts on its behalf and must benefit from the exact same information as user A would.<br /><br /></div> <div> </div> <div>This means that an IMS service can act as a network-based agent or proxy of a user (and here I do not mean "SIP User Agent" and "SIP Proxy").<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Service acting as itself</span><br /><br /></div> <div> </div> <div>A service can also receive requests addressed to a PSI that identifies itself, or generate a request using its own PSI as the originator.<br /><br /></div> <div> </div> <div>This may permit a service to communicate with a user ("Hey, I am your voicemail") or to benefit from privileges associated to a service (e.g. when the service generates a presence request to a presence server located in the same domain, it has full access rights and top priority toward all users' presence information).<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Group Management</span><br /><br /></div> <div> </div> <div>Group management permits a user (or an operator) to regroup a set of URIs (SIP or others) into a set which is identified and addressable via a PSI. Such a group PSI can then be used in SIP requests, which then automatically become group requests through appropriate support in IMS application servers. For instance, an IM addressed to a group will be exploded to individual IMs sent to each member of the group, a presence request to a group will be decomposed into individual presence requests, and an INVITE to a group will automatically start a conference. Groups can also be utilized within application servers to define, e.g. black or white lists.</div> <div> </div> <div>An IMPU and a PSI have the exact same formats (either a SIP URI or a TEL URI).<br /><br /></div> <div> </div> <div>This means that groups of services identified by a PSI can be defined, as well as groups mixing IMPUs and PSIs. Consequently, everything that can be made towards user groups can also be made towards service groups and service/user groups. For instance, conference session setup can relate to groups including both human beings and automatons like a media server.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Associating services to services</span><br /><br /></div> <div> </div> <div>There exist several approaches to route a SIP request addressed to a PSI to an AS serving this PSI. Most approaches rely on a direct mapping between the PSI (SIP or TEL URI) and the address of a server. They differ by where the mapping is defined (DNS, HSS), constraints on how the PSI URI is constructed, and where the routing is performed (originating S-CSCF, I-CSCF).<br /><br /></div> <div> </div> <div>One approach is different, and while the IMS specifications never describe what it permits, its potential is much more significant from a service perspective. It lies in the association of a service profile to the PSI in the HSS, the same way service profiles are associated to IMPUs, which permit the routing of SIP requests associated to the IMPU to IMS application servers. With this approach a PSI is provisioned in the HSS like an IMPU, except that not all information need to be provisioned (e.g. no need for authentication information).<br /><br /></div> <div> </div> <div>A first interest of this approach is that not all requests addressed to a PSI have to be routed to the same server. Some requests might be routed to one and others to another, based on initial filter criteria in the PSI service profile.<br /><br /></div> <div> </div> <div>A very interesting feature of this approach, which is not related to service anthropomorphism, is that if an IMS user decides to make a user group consisting of the members of its family, identified by a PSI like <span style="color: rgb(0, 0, 153);">sip:MyFamily@operator.com</span>, an INVITE addressed to the PSI might be routed to a conferencing server, a MESSAGE addressed to the same PSI to an IM exploder, and a SUBSCRIBE to the PSI to a resource list server (in order to explode the request toward each member and compile the results in a single NOTIFY). Compare to the other approaches, which will route requests addressed to <span style="color: rgb(0, 0, 153);">sip:MyFamily@operator.com</span> to a single server, actually forcing the user to define a different PSI for each service it would like to apply to its family if it wants different services to apply (e.g. <span style="color: rgb(0, 0, 102);">sip:MyFamily@conferencing.operator.com)</span>. This need to define a specific SIP URI for a combination group/service is also the way you will have to proceed in a non-IMS SIP network. This is an interesting example of how IMS can add value over non-IMS SIP networks and make the life of a user easier.<br /><br /></div> <div> </div> <div>To come back to the subject of this post, let us consider a streaming service for a live event like a concert. An IMS user will typically start viewing the event by generating a SIP INVITE to a PSI identifying the live event. With service profile based SIP routing, the operator could define that a SUBSCRIBE to the presence event package would be routed to a presence server instead of the streaming media server (to which INVITEs will be routed). This would permit to associate presence information to the live event, like a description of the live event, information on how to subscribe to it, and status information (delayed, not started, starting, started). A user subscribing to the live event's presence could then be automatically be notified about when it can start viewing it.<br /><br /></div> <div> </div> <div>In effect, associating a presence to the live event is associating a service to it, the same way presence can be a service associated to a user.<br /><br /></div> <div> </div> <div>But there are other ways to associate a service to a service. Service profile -based routing permits to chain different services in the SIP signalling path. Consider an anti-spam application the operator proposes to its IMS customers. Every message addressed to the user can be routed to this application to be analyzed and possibly blocked. Now consider a discussion forum based on IMS messaging. The name of the forum is identified by a PSI (e.g. <span style="color: rgb(0, 0, 153);">sip:TheIMSLantern@operator.com</span>) so that each IM addressed to the forum is distributed to all the users currently registered with it. Service-profile based PSI routing would permit the operator to route a SIP request addressed to the forum first to the anti-spam application, then to the forum server. This is as if the discussion forum was treated as an IMS user subscribed to the anti-spam service. Now extend this example with an anti-virus application and an archive server, or think of other examples.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">To conclude...</span><br /><br /></div> <div> </div> <div>An IMS service can be anthropomorphic because it can act like a user, it can act as a network-based agent of the user, it can interact with other services like a user, it can communicate with "other" users, and it can be associated to other IMS services just like a user.</div> <div> </div> <div><br />Note that "IMS service anthropomorphism" is not a standard or a commonly used term. I created it. You might therefore want to be careful and cite your source if if decide to use the term in discussions or in documents.<br /><br /></div> <div> </div> <div>Christophe</div><br /></basefont>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-4706138697725258507.post-61806054107836463822008-03-26T00:27:00.002+01:002008-04-09T12:16:15.420+02:00Different Strategies for IMS<basefont>Most operators do not want to be reduced to the role of bitpipe provider, offering low cost connectivity to services supplied by other companies. They want to be service providers themselves, and try to figure out how IMS will help them achieving this objective.<br /><br /><div> </div> <div>This basic point aside, the strategies between operators might diverge, and their differences may essentially lie into the level of control they want IMS to support. This level of control can be illustrated by the following questions, which purposedly address extreme attitudes (it should be understood that intermediate opinions also exist).<br /><br /></div> <div> </div> <div>Should IMS be fully open to other IP networks, and permit communication and service interoperability with devices and service providers located outside of the traditional telecommunications domain, more especially the Internet? Or should IMS, on the contrary, help operators establishing a new "walled garden", forcing or strongly encouraging the customer to use the services provided by telecommunications operator, and preventing or strongly discouraging them to use services provided in the Internet?<br /><br /></div> <div> </div> <div>Should IMS foster service innovation, permitting telecommunications operators to differentiate between themselves and compete on value for money to improve their market share? Or should IMS, on the contrary, be used to maintain the old, slow and standardization driven telecommunications model, in which most operators provide the same mass market services and only differentiate at the margin?<br /><br /></div> <div> </div> <div>Operators in a challenger position, or which are confident in their ability to cope with the new challenges they are facing with the rapid evolution of technologies and customers' habits, are keen on adopting an open IMS and a new approach to service creation. In addition to developing their own services, they are likely to seek other ways to maximize revenues, acting as a channel provider or intelligent pipe provider towards 3rd party service providers, by partnering with them and/or adding values to their services (see <a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">here </a>an example of how IMS can be used by an operator to add value to 3rd party services).<br /><br /></div> <div> </div> <div>Operators with a control freak approach are more in a defensive attitude, having to preserve a market position or facing internal uncertainties about the future world.<br /><br /></div> <div> </div> <div>These diverging strategies do not only concern operators, as they will directly impact the supplier ecosystem the operators will rely on in the years to come.<br /><br /></div> <div> </div> <div>Operators favoring service innovation, short development cycles, high service customization, or niche market services, will have to adopt technologies and practices that come from more dynamic business sectors, where state-of-the-art IT and methods are common place. To develop their services, they are likely to rely on open service platforms (e.g. J2EE), enterprise architecture practices, and to primarily view services as applications, developed in-house, purchased off the shelf, or contracted to IT-centric application providers.<br /><br /></div> <div> </div> <div>On the other hand, operators opting for mass market standardized services, with little differentiation, are likely to maintain the existing ecosystem of traditional equipment and service box suppliers. The more a traditional telecommunications equipment supplier has difficulties to move from telco IT (e.g. proprietary platforms, poor skills at Java, SOA and other advanced IT architecture and programming paradigms, long and costly development cycles) to standard IT, the more this supplier will take as a threat the advent of an all-IP and open IMS era.<br /><br /></div> <div> </div> <div style="font-weight: bold;">How IMS positioned itself a couple of years ago<br /><br /></div> <div> </div> <div>This was a mixed bag.<br /><br /></div> <div> </div> <div>Despite what some people think and claim, 3GPP always ensured that IMS was fully interoperable with non-IMS SIP networks. I already addressed this topic in <a href="http://theimslantern.blogspot.com/2007/04/does-ims-create-new-walled-garden.html">a past post</a>, from which I will only reuse a telling example: IMS session setup.<br /><br /></div> <div> </div> <div>In order to permit IMS calls to replicate the experience an end-user has when establishing a call in the circuit-switched network, IMS opted for a more complex procedure than the basic IETF SIP one, permitting network resources to be reserved before the call is established. An IMS device is mandated to follow this procedure. While this procedure and the related SIP extensions can also be used in non-IMS networks (these are not 3GPP-specific extensions), it cannot be assumed that all SIP clients will ever support it. Not doing anything about this would have prevented an IMS device to set up sessions with most of non-IMS devices. However, 3GPP did something about this: in case the peer device does not support the complex session setup procedure, the IMS device (or a network based agent acting on its behalf) is mandated to revert to the basic IETF procedure.<br /><br /></div> <div> </div> <div>The technical ingredients to support service innovation were also there: the intrinsic power of IP and SIP, the powerful IMS service architecture, the SIP servlets specification permitting the integration of SIP-related service logic into advanced and open J2EE platforms, the endorsement of SIP servlets by all the suppliers of J2EE platforms.<br /><br /></div> <div> </div> <div>However, it did not work out that well, and this can be linked to multiple good and bad reasons: IMS was still a prospective technology (real deployments are starting now), focus was on short-term (hopefully) value generation services (e.g. VoIP, push to talk over cellular), IT-centric platforms were not mature yet, the capabilities of SIP and the IMS service architecture were not well known, no compelling IMS services were proposed, the legacy telecom culture was a handicap that was reflected in the old fashioned silo way OMA (the Open Mobile Alliance) was specifying IMS-based enablers...<br /><br /></div> <div> </div> <div>I would not claim that all these factors have disappeared now, but some progress has been made in the recent time, as IMS is becoming real.<br /><br /></div> <div> </div> <div style="font-weight: bold;">The last two years: hidden fight between various strategies<br /><br /></div> <div> </div> <div>3GPP Communication Services are the textbook example of how suppliers and operators with conflicting strategies have used all the subtle (and less subtle) panoply of standardization tricks to push their agendas and counter-agendas in IMS standardization.<br /><br /></div> <div> </div> <div>I already addressed the topic (<a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-uncut.html">here </a>and <a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-latest-news.html">there</a>) at a time when the fight reached its heights, and I will soon dedicate <a href="http://theimslantern.blogspot.com/2008/04/3gpp-communication-services.html">a post to describe the current status and potential consequences of Communication Services standardization</a>.<br /><br /></div> <div> </div> <div>For now, suffice to say that:</div> <div>- Would all the ideas pushed by Communication Services promoters have been accepted, IMS would certainly have become a walled garden preventing interoperability between IMS and non-IMS SIP devices, and huge barriers to innovation by IMS operators would have been erected.</div> <div>- In the present state of standardization, these risks have been globally averted (thanks to the IETF and some companies active in 3GPP).<br /><br /></div> <div> </div> <div>I personally view <a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">Multimedia Telephony</a> as an initiative that goes in the same control direction. As I already wrote, Multimedia Telephony can be seen as an attempt at defining multimedia sessions as an incremental, person-to-person communication centric evolution of voice telephony. Moreover, at the moment, the content of Multimedia Telephony specifications is limited to the emulation of classical voice telephony services over an IMS network. From this you can derive that, from a target perspective, MMTel is a half full or half empty evolution in direction of the true multimedia experience SIP can provide, and that in any case there is not much hurry to move toward this target.<br /><br /></div> <div> </div> <div>Another initiative I would strongly liken to MMTel is OMA PoC phase 2. While PoC phase 1 can be described as a 2-party or group walkie talkie service (essentially) for mobile phones, PoC phase 2 significantly enriches the user experience with other media, permitting for instance to transform a session from half duplex voice (original PoC) to full duplex voice, to use text messaging or send images, files or video streams in the session. This is still not full multimedia, but a controlled step in the direction, defined as an enrichment of a service silo looking for a future. As such a silo, PoC has a very interesting feature for companies which are not that thrilled with the idea of interworking with non-IMS devices: PoC is the only IMS service that can be described as fully IMS centric. It was totally specified by the IMS community and has no equivalent in the non-IMS SIP community.<br /><br /></div> <div> </div> <div>On the other side of the fence, you can undoubtly place the ongoing <a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">OMA Converged IP Messaging (CPM)</a> initiative. CPM intends to use the full capabilities of SIP sessions and IMS convergence features. It is multi-access, multi-party, multi-media in the most advanced meaning, and multi-device, supporting both person-to-person and person-to-service sessions. If every thing goes well, instead of a fully standardized service like telephony or PoC, CPM should end up being an architectural framework permitting operators to place or allow any media component one can think of in an IMS session, thus realizing (and possibly improving on) everything one can implement in the Internet using the SIP protocol.<br /><br /></div> <div> </div> <div>Until recently, I tended to see 3GPP as the standardization body with the most coherent and liberal approach to IMS, and OMA as the organization which, through its heavy pre-IMS heritage and its inadequate organization, would keep on standardizing good old service silos (with overlapping features). However, it looks like this time is over, at least for OMA. This said, thinking about it, this OMA organizational problem (the fact that each group standardizing a service works in parallel to the others while the architecture group works on its own topics instead of ensuring the overall coherency of the OMA architecture like SA2 does in 3GPP) is more obvious than ever when you consider the current situation of OMA specifications: as an operator, you now have no less than three alternatives if you want to deploy an IMS messaging solution, OMA SIMPLE Messaging, OMA PoC phase 2 and OMA Converged IP Messaging, among which the last two can claim to support multimedia sessions as well. Finally, I may withdraw my positive comment about OMA as a whole.<br /><br /></div> <div> </div> <div>Christophe</div><br /></basefont>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-4706138697725258507.post-18404447628624110322008-03-10T10:45:00.001+01:002008-03-10T11:15:37.841+01:00IMS Standardization Tracking Report<span style="font-family: arial;">Tracking the standardization of IMS in 3GPP is a difficult and time consuming task. There are so many working groups involved (e.g. SA1, SA2, SA3, CT1), and so many meetings.</span><br /><br /><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >I recently came across <a href="http://www.hsc.com/">Hughes Systique Corporation</a>, a Consulting, Development and System Integration company Headquarted in the US,</span><span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >which seems to be doing a lot of interesting work in the IMS, Web 2.0 and convergence of the same. Of the various other things they offer, they produce</span><span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >an 'IMS Standards Tracking report' which is sent out to their clients once in two months and keeps readers updated on new technology updates</span><span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >in various 3GPP forums, including in IMS-WiMAX interworking. There is an annual subscription at an affordable cost. </span> <span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /><br /></span> <span style="font-family: arial;font-family:sans-serif;font-size:100%;" ><a href="http://www.linkedin.com/in/arjunrc">Arjun </a>, who is responsible for the IMS & Converged Applications practice in the company contacted me recently and emailed me</span><span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >a copy of one of their reports to see. He told me, in addition to the report, they also offer free conversations with the key analysts who prepare it. This is a 100% technology</span><span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >report and not a market one, therefore serving a niche that was missing. With the recently uptake on IMS, Arjun believes this report will be a very cost effective solution for companies</span><span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >who cannot afford to travel or track 300+ 3GPP CRs in each meeting.</span><span style="font-family: arial;font-family:georgia;font-size:100%;" ><br /><br />I encourage you to have a look at it. If your company decides to subscribe to the report, please let HSC know that you got the information from The IMS Lantern.<br /><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >For more details on this report see: <a href="http://www.hsc.com/IMSConsulting/index.aspx">http://www.hsc.com/IMSConsulting/index.aspx</a></span><span style="font-family: arial;font-size:100%;" ><a href="http://www.hsc.com/IMSConsulting/index.aspx"> </a><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >For their IMS blog, see: <a href="http://www.hsc.com/IMSConsulting/Insight.aspx">http://www.hsc.com/IMSConsulting/Insight.aspx</a></span><span style="font-family: arial;font-size:100%;" ><a href="http://www.hsc.com/IMSConsulting/Insight.aspx"> </a><br /></span><span style="font-family: arial;font-family:sans-serif;font-size:100%;" >For Arjun's personal IMS (and other VoIP/SIP/2.0) blog: <a href="http://iconverged.wordpress.com/category/3gpp/">http://iconverged.wordpress.com/category/3gpp/</a></span><span style="font-family: arial;font-size:100%;" ><a href="http://iconverged.wordpress.com/category/3gpp/"> </a><br /><br />Christophe<br /></span><span style=";font-family:georgia;font-size:100%;" ><br /></span><span style=";font-family:sans-serif;font-size:100%;" ></span>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-4706138697725258507.post-40957205134126167282008-03-03T16:10:00.001+01:002008-03-03T16:13:52.900+01:00An Article from MicrosoftJoseph Hofstader, an architect at Microsoft who writes periodically on Telecommunications technologies, sent to me a link to an article he published on Communications as a Service (CaaS). This is the first in a series of about 3 or 4 he has planned on the topic, diving deeper into architecture and infrastructure.<br /><br /><a rel="nofollow" target="_blank" href="http://msdn2.microsoft.com/en-us/library/bb896003.aspx">http://msdn2.microsoft.com/en-us/library/bb896003.aspx</a><br /><br />The article is very interesting, clearly describing the capabilities of SIP as a protocol, and the paradigm shift between the traditional concept of communication services and CaaS.<br /><br />Concerning the IMS related part of the article, readers of The IMS Lantern will understand that I would tend to elaborate more on the IMS service architecture and the unique benefits it can provide, but I understand that this is not the focus of Joe's article. He actually intends to elaborate more on this aspect in his next articles.<br /><br />ChristopheUnknownnoreply@blogger.com3tag:blogger.com,1999:blog-4706138697725258507.post-78224786991060525672008-02-20T11:59:00.001+01:002008-02-20T13:18:37.655+01:003GPP Multimedia Telephony & OMA CPMIn this post, I will address two standardization initiatives that try to define the future of communication services based on IMS, and more especially the support of <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">Multimedia Communication</a>.<br /><br />As you will see, I have a soft spot for one of them (OMA Converged IP Messaging) and a strong bias against the other (3GPP Multimedia Telephony).<br /><br /><span style="font-weight: bold;">3GPP Multimedia Telephony</span><br /><br />3GPP Multimedia Telephony (MMTel for short) has appeared in 3GPP release 7 and will evolve in the next releases. The initiative originates from ETSI TISPAN requirements for fixed networks.<br /><br />The name always made me mad, but it is actually very telling about what MMTel is today.<br /><br />The service is "multimedia" in the sense that it permits the combination and dynamic re-negotiation of different media components within an IMS session. Sample components include full duplex voice, real time video, text communication, file transfer (e.g. video clip, audio clip, pictures). Note that there is no explicit mention of applications, and the 3GPP requirements state that a "typical usage" is speech (voice) and speech combined with other media components.<br /><br />On the other hand, this is a "telephony" service, which seems to anchor its definition to the well-known, decades-old, voice-centric, and circuit-switched implemented telephony service. Basically, you could infer that Multimedia Telephony is an incremental evolution of Voice Telephony with the addition of new media components.<br /><br />This may lead to potential questions when specifying Multimedia Telephony:<br />- Is the service only related to person-to-person communication or can it apply to person-to-service interactions? I already showed <a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">an example of how a multimedia SIP session can be used in a person-to-service relationship</a>, and you will see below that CPM supports it.<br />- Are current classical telephony supplementary services applicable in a new world where a session can be established with a service, where SIP URIs will eventually replace telephone numbers, where the protocol and the core network permit to reach the user on a multiplicity of devices, where enablers like group management and presence can change the users' behaviors to communication (e.g. is the user available for voice communication now? What are the alternatives?) as well as the way network-based call handling services can be implemented (using presence to take an informed decision), where users can negotiate the content of a session when establishing it, and where services can easily redirect users to web pages to allow them to decide how a call should be handled?<br /><br />These questions are not purely theoretical when you consider the current standardization state of MMTel: it solely consists of the specification of how classical telephony services like Original Identification Presentation, Call Forwarding Unconditional or Communication Waiting can be implemented in IMS. The requirements specification clearly states that the behavior of each service, <span style="font-style: italic;">"as perceived by the user, should be consistent with the behavior perceived when using the equivalent services on PSTN/ISDN and CS Mobile networks."</span> Isn't this crystal clear?<br /><br />As such, at the moment MMTel looks like a vehicle to standardize voice-centric telephony services to be supported by a Telephony Application Server (TAS), which may eventually become a Multimedia Telephony Server when voice is not the only media component supported by a call.<br /><br />The MMTel initiative can be associated to another 3GPP one called IMS Centralized Services (ICS) which aims at having an IMS-based TAS for both CS telephony and IMS telephony. The approach would eventually deprecate existing IN servers in legacy networks and see them replaced by a TAS. Put together, both initiatives draw the following potential roadmap:<br />1) A TAS for IMS voice telephony<br />2) A TAS for both CS and IMS based voice telephony<br />3) A TAS to support IMS-based Multimedia Telephony<br />Basically, a TAS at the center of the future telecommunications network.<br /><br />I personally do not believe at all in this incremental approach to Multimedia Communication, as SIP and IMS will drastically change the way people communicate, leaving plain old telephony as a separate service whose usage will gradually decline as people will adopt a totally new way to communicate. A TAS should therefore be seen as an important box in an IMS network, but a box that will remain focused and essentially unchanged until its termination.<br /><br />True Multimedia Communication is to be supported by something else, and this is...OMA CPM.<br /><br /><span style="font-weight: bold;">OMA Converged IP Messaging (CPM)</span><br /><br />OMA Converged IP Messaging is currently under specification within OMA (the Open Mobile Alliance). In my opinion, this is by far to date the most significant step towards an optimal exploitation of IMS capabilities that I described in the past.<br /><br />The name of this enabler may be misleading, as it seems to imply that CPM is a pure messaging service, while it is not.<br /><br />Actually, CPM can be defined as a composite specification addressing two concerns:<br />- Full IMS messaging (OMA SIMPLE IM), including page mode and session-based approaches, as well as transparent interworking with legacy mobile messaging services (SMS, MMS, OMA IMPS). This could certainly be extended to other messaging services like email or Jabber/XMPP in either future versions of the specification or in smart implementations.<br />- Multimedia communication as <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">I had the opportunity</a> to describe it in the past.<br /><br />Let's start with the messaging features.<br /><br />Page mode messaging, which is based on the SIP method MESSAGE can be seen as the equivalent to SMS in the SIP/IMS world. A user can send a page mode short message to another user or a group of users. This message is either delivered instantly over the IMS core network or stored for deferred delivery if the recipient is not available.<br /><br />Session-based messaging is based on a SIP session, with messages delivered through a protocol called MSRP. Session-based messaging essentially serves two requirements that cannot be fulfilled by page mode messaging: the support of chats, in which messages are exchanged between two or more parties within a dialog context; the possibility to send large volume files like music or video clips. In addition, session-based messaging has two important benefits: it minimizes SIP control traffic to session management, and utilizes a specific protocol for the messages itself, permitting to implement an appropriate support in the network; by reusing the concept of SIP session, it permits messaging to be one component among others in a multimedia session.<br /><br />Interworking with legacy messaging services like SMS and MMS permits CPM to be interesting from the start, as it does not rely only on the initially limited IMS community to deliver its services.<br /><br />The scope of multimedia communication supported by CPM is very broad.<br /><br />CPM will support a wide range of discreet (e.g. messaging, files, applications) and continuous (e.g. full duplex voice, video) components. It supports the negotiation of initial components in a session, dynamic renegotiation of components in the session, and does not require any specific component to be part of the session (for instance, it is not mandatory to have a messaging component despite the name of the service). The session can be both person-to-person (2-party or multiparty) or person-to-service (and obviously person-to-person&service).<br /><br />CPM supports a multi-device approach, making use of SIP convergence capabilities. It permits a user to share an identity between several devices and to use several identities per device. A user may have its CPM session shared between several of its devices on a media per media basis (e.g. video sharing on TV and voice on mobile). Session mobility between devices is also supported (e.g. ongoing session transferred from TV to mobile). The user can also define preferences on how CPM should address communication according to its devices (e.g. IMs should be sent only to mobile).<br /><br />In summary, CPM supports both of the three axes I defined for an optimal exploitation of IMS capabilities: <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">multimedia communication </a>and <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-1-fixed-mobile.html">user oriented convergence</a>.<br /><br />CPM supports conferencing through a variety of means supported by SIP and already used in services like PoC or IMS Messaging: sessions to ad-hoc groups (a user sends an INVITE to a group explicitly defined in the INVITE), to pre-defined groups (the INVITE is sent to a <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">PSI</a> identifying a group whose definition is stored in the network), and by adding participants to a session on the fly.<br /><br />Interworking with non-CPM communication means is not limited to messaging. It also includes interworking with non-IMS voice, such as circuit-switched voice. This will be done by reusing current IMS/CS interworking components.<br /><br />In addition, CPM supports a converged address book, converged in the sense that it is aimed at being shared by all the devices owned by the user. It also has an archiving functionality, able to store such things as messages, media objects and session histories. It interacts with presence in order to publish or access presence information for a user. CPM will also support web services towards application willing to use its services. An interesting feature is the possibility for users not to divulge their identity when using CPM, by using a nickname for instance.<br /><br />The CPM architecture is quite straightforward:<br />- A CPM Client in the device supports CPM from a user perspective.<br />- A Converged Address Book component supports the address book for multiple devices.<br />- A Message and Media Storage component archives everything that needs to be archived.<br />- An Interworking Function supports interworking with non-CPM messaging solutions (voice interworking is supported through the IMS core network).<br />- A CPM User Prefs component interfaces with the user for CPM customization.<br />- The CPM Conversation Server supports multimedia sessions, and should in implementations look very similar to what I described <a href="http://theimslantern.blogspot.com/2007/05/enabling-multimedia-communication.html">here</a>. Like PoC and IMS Messaging, it will be subdivided in a Participating Function dedicated to a specific user in the session (called <span style="font-style: italic;">Personal Multimedia Controller</span> in <a href="http://theimslantern.blogspot.com/2007/05/enabling-multimedia-communication.html">my post on the subject</a>) and a Controlling Function component supporting features shared by multiple users like conferencing (I called it <span style="font-style: italic;">Multimedia Focus</span> in <a href="http://theimslantern.blogspot.com/2007/05/enabling-multimedia-communication.html">the same post</a>). These SIP centric components will control media intermediaries for individual components in the multimedia session (I called them <span style="font-style: italic;">Media Mixers</span>). Note that the specification does not mandate network intermediaries for every component, as it allows peer-to-peer media flows between devices when the operator's policies permit it.<br /><br /><span style="font-weight: bold;">Building block standardization approaches</span><br /><br />Both specifications can claim (and actually do) <a href="http://theimslantern.blogspot.com/2008/02/bulding-block-approach-to.html">a building block approach to standardization</a>. However, there are significant differences between them.<br /><br />CPM's approach is IMS-centric, as it intends to reuse IMS enablers like the interworking with the circuit-switched network for voice, presence, group management and to make generic and extend architecture patterns that were introduced with the specification of Push To Talk over Cellular and later reused for IMS Messaging (OMA SIMPLE IM).<br /><br />On the other hand, Multimedia Telephony's approach is pre-IMS centric. The goal is to create within IMS building blocks which mimic pre-IMS voice-centric telephony, with the hope (illusion?) that a multimedia communication experience can be created through the reuse of these basic building blocks that totally ignore the capabilities of IMS.<br /><br />The reader can make its own opinion on the advantages and drawbacks of both approaches.<br /><br />For my part, if I was an operator, I would be very suspicious about suppliers coming with a story of a Multimedia Telephony server defined as an extension of a short-term Telephony Application Server, and would ask them about the positioning of this product with regards to CPM.<br /><br />On the other hand, I would mandate from the potential suppliers of IMS Messaging products to provide a CPM-ready solution with a clear roadmap. Considering that IMS Messaging is a brand new IMS specification, it may be a big mistake to purchase in 2008 or 2009 a solution that has no clear path towards the next big thing: CPM.<br /><br />Links to publicly available specifications:<br />OMA CPM: nothing as this is work in progress<br />Multimedia Telephony Requirements: <a href="http://www.3gpp.org/ftp/Specs/html-info/22173.htm">TS 22.173</a><br />Multimedia Telephony Architecture: section 4.16 in <a href="http://www.3gpp.org/ftp/Specs/html-info/23228.htm">TS 23.228</a> (the AS for Multimedia Telephony is unambiguously called TAS)<br />Multimedia Telephony Protocol Details: <a href="http://www.3gpp.org/ftp/Specs/html-info/24173.htm">TS 24.173</a><br />Architecture for IMS Centralized Services: <a href="http://www.3gpp.org/ftp/Specs/html-info/23292.htm">TS 23.292</a><br /><br />ChristopheUnknownnoreply@blogger.com20tag:blogger.com,1999:blog-4706138697725258507.post-29055305341399049192008-02-12T10:01:00.000+01:002008-02-12T11:02:13.259+01:00A Bulding Block Approach to Standardization<basefont>For decades, the telecommunications industry has standardized solutions from A to Z, with little if any reuse of existing specifications when creating new ones. The progressive migration from circuit switched to IP based services did not initially change this fact much: MMS or OMA IMPS (that I take as an example in this post) are typical examples of creating telco-specific standards based on a loose reuse of IETF ones (SMTP for MMS, HTTP for OMA IMPS).<br /><br /><div> </div> <div>This has changed with IMS, and more especially its SIP component. 3GPP and the IETF collaborate with each other, and needed extensions to the SIP protocol due to IMS requirements are under the control of the IETF.<br /><br /></div> <div> </div> <div>By importing IETF specifications into telecom standards, 3GPP implicitly accepted the building block approach to specifications that is common place in the Internet domain. In this post I will try to describe this approach and its benefits.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Building block standardization of SIP<br /><br /></div> <div> </div> <div>SIP is a textbook example of a building block approach to standardization. The people and groups in charge of specifying SIP constantly try to apply the following rules:<br />- Do not reinvent the wheel. Reuse and adapt existing specifications if they fulfill your requirements. Only create when needed.<br /><br />- Make everything as generic as possible. Even if your requirements are very precise, try to make your solution generic enough to be reused for other requirements.<br /><br /></div> <div> </div> <div>Here follow some examples of how this was applied to SIP standardization:</div> <div><br />- SIP sessions make use of the Session Description Protocol (SDP), which was specified prior to SIP. In effect, it is possible to use SDP without SIP.</div> <div><br />- SIP SUBSCRIBE and NOTIFY methods were initially created to support a very specific requirement, actually related to the telecom domain (the support of the telephony <a href="http://www3.tools.ietf.org/html/draft-roach-sip-acb-00">Automatic Call Back service with SIP</a>). However, it was decided to make the concept a generic and extensible means to distribute event notifications in a SIP network through event packages (see the first draft for SUBSCRIBE/NOTIFY <a href="http://www3.tools.ietf.org/html/draft-roach-sip-subscribe-notify-00">here</a>). When a part of the IETF community decided to support presence through SIP, they simply had to reuse the event package specification and create two presence-specific event packages. While the requirement was initially very specific, it gave birth to a concept that is fundamental for SIP and constantly evolving through the creation of new event packages. It is actually remarkable that this is a telephony -related requirement that led to a SIP concept which opens the door to a large variety of non-telephony related applications of the protocol.</div> <div><br />- In the Instant Messaging (IM) area, presence was initially no more than a single state, describing if a recipient could accept an IM. The IETF decision to support presence through the inclusion of an XML document in the body of SIP methods, and allowing extensions to the basic schema, permitted the definition of presence to be gradually extended to become a large set of information about users (or services), their communication means, terminals and applications.</div> <div><br />- SIP PUBLISH was initially created specifically for a client to remotely update presence information. The first versions of the draft were tightly linked to the presence event package and made impossible the reuse of PUBLISH in different contexts (see the very first draft <a href="http://tools.ietf.org/html/draft-olson-simple-publish-00">here</a>). However, the IETF community rapidly ensured the possibility to reuse PUBLISH for all existing and future event packages. PUBLISH therefore contributed to the enrichment of SIP-based presence, but at the same time a requirement initially scoped to presence contributed to the enrichment of the whole SIP protocol.</div> <div><br />- Instant Messaging through SIP was initially supported only through the creation of a new SIP method: MESSAGE. However, it rapidly emerged that this approach was far from optimal to support all potential requirements associated to instant messaging: the concept of chat, which embeds IMs in a specific dialog context, the need to potentially exchange large documents via IM (e.g. a video file) while SIP is a control protocol and not a transport one like HTTP, or the need to support potentially high IM traffic while a SIP infrastructure might not have been implemented with this purpose in mind. It took time and several tries for the IETF community to address these requirements, and the final decision was to reuse the concept of SIP session as well as another protocol to transport an IM within the session. As a protocol like HTTP was not optimal to support the requirements for this IM transport protocol, it was decided to specify a new one called MSRP. This decision makes the comparison between Jabber/XMPP and SIP to support IM very biased. Maybe Jabber/XMPP is a better protocol than SIP for IM. However, Jabber/XMPP was initially specified and optimized for it, making its extension for, say VoIP, far from straightforward. On the other hand, in a SIP context, IM can be perceived as one communication component among others in a <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">multimedia session</a>.<br /><br /></div> <div> </div> <div style="font-weight: bold;">OMA IMPS vs. IETF Presence and IM<br /><br /></div> <div> </div> <div>The vertical standardization mindset that still prevailed a few years ago in the telecom community can be illustrated with OMA IMPS (initially called Wireless Village), a mobile specification to support instant messaging, chat rooms and presence.<br /><br /></div> <div> </div> <div>Instead of reusing IM and presence related protocols available in the Internet, the Wireless Village group decided to specify a client to server protocol and a server to server protocol that would be specific to the mobile telecom domain, just reusing HTTP as a semantic-less transport protocol for OMA IMPS commands.<br /><br /></div> <div> </div> <div>The group also decided to define IM, chat rooms and presence as tightly coupled together from a protocol and an architecture perspective, and to tightly link presence information to the mobile context.<br /><br /></div> <div> </div> <div>In order to support its requirements, the Wireless Village group had to define various kinds of user lists (or groups) serving different purposes. Instead of creating a generic user group concept, they decided that each group fulfilling a specific purpose was a distinct object. Consequently, each group object led to a set of specific commands in the protocol, for creating/deleting the group, adding/removing elements to it, etc. With such an approach, if you define, say 4 types of user groups and 6 management commands, you end up with 24 distinct commands in the protocol.<br /><br /></div> <div> </div> <div>In comparison, to address similar objectives, the IETF decided to decouple various concerns.</div> <div> </div> <div>While presence is a concept originated in an IM context, the IETF decoupled one from the other, permitting each to evolve independently, thus permitting presence to apply to a much broader scope than simply IM.<br /><br /></div> <div> </div> <div>By reusing the SIP session concept for session-based IM, the IETF permitted both the implementation of IM-specific systems, and multimedia systems using IM as one component among others in a SIP session.<br /><br /></div> <div> </div> <div>The approach to address user groups and associated management, specified in RFCs related to XCAP, followed this approach:</div> <div>- A user group is a user group, no matter what it is used for. The same user group can serve different purposes, and the set of applications for user groups is not arbitrarily bounded.</div> <div>- A user group is user data, and there might be other user data that require similar access and management. No need to specialize access and management methods to user groups.</div> <div> </div> <div>Consequently, <a href="http://theimslantern.blogspot.com/2007/05/user-application-data-panorama.html">XCAP </a>is an HTTP-based protocol defining a few data management methods. The data itself is specified in XML, and there exist specifications for these data being user groups. As one of the requirements associated to data management was to be able to notify a user about changes made to data, the IETF decided to use a SIP event package. In effect, the IETF specifications for user data management include the joint usage of XCAP and SIP.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Building block standardization approach in IMS<br /><br /></div> <div> </div> <div>The building block mindset to specifications has spread to IMS and non IMS standardization into 3GPP.<br /><br /></div> <div> </div> <div>For instance, despite a terminology which is heavily related to SIP sessions (e.g. CSCF - Call Session Control Function), the IMS core network can be seen as a SIP connectivity network able to route SIP signaling, whether it is session-related or not, within an IMS domain, across IMS domains, and between IMS and non-IMS SIP domains.<br /><br /></div> <div> </div> <div>In this context, IMS Presence, Messaging, and Chat Rooms are implemented as independent applications on top of the IMS core network and that make use of it. Once again, the comparison with OMA IMPS is quite interesting:</div> <div>- OMA IMPS specifications lead to an implementation based on a network of IMPS servers over the mobile IP network. An IMS implementation relies on deploying application servers on top of an IMS core network. The IMS core network directly supports some of the requirements that are supported vertically in the OMA IMPS specifications (and implementations), like user authentication or routing and interfacing between various operators' OMA IMPS networks.</div> <div>- OMA IMPS specifications tightly link the concepts of IM, presence and user groups. On the other hand, IMS specifications treat each of them as independent enablers which can be used together or in different contexts.</div> <div>- OMA IMPS specifications were totally under the control of the Wireless Village group, and then OMA. On the other hand, by reusing IETF specifications, IMS specifications directly benefit from the evolutions performed in the IETF community, including some originating from people and companies which do not belong in the telecom or IMS domains.</div> <div> </div> <div><br />A quite similar comparison can be applied to MMS and the equivalent support through IMS messaging.<br /><br /></div> <div> </div> <div>Another interesting example is the <a href="http://theimslantern.blogspot.com/2007/05/user-application-data-panorama.html">3GPP Generic User Profile</a> specification, which permits to provide a centralized and homogeneous access to user data actually residing in various locations (e.g. HLR, HSS, AuC, application servers) and normally accessed through a variety of protocols (e.g. MAP, Diameter, LDAP). At the beginning of the erratic standardization process for GUP, 3GPP intended to standrdize a specific GUP protocol as well as a specific GUP schema to describe user data. Later on, it was decided to align on the specifications for <a href="http://www.projectliberty.org/">Liberty Alliance</a>, which define web services permitting 3rd party service providers to access user data owned by the network operator. As a consequence, GUP can be used directly as the means to access user data in network databases to support the Liberty Alliance web services exposed to 3rd parties.<br /><br /></div> <div> </div> <div>The GUP specifications were also made generic enough to clearly distinguish between the methods used to access and manage user data and the data itself, that needs to be specified by instantiating and extending the generic GUP schema. On the other hand, the GUP specifications also include a SOAP-based user data modification notification mechanism, which duplicates what SIP event packages can and do support for XCAP. However, one can argue that the usage scope of GUP is broader than IMS and cannot rely on a protocol that 3GPP only uses in the context of IMS.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Some advantages associated to building block standardization<br /><br /></div> <div> </div> <div>Reusing existing specifications instead of defining them from scratch permits to speed up the standardization process.<br /><br /></div> <div> </div> <div>A protocol component or an application performing a generic task can be implemented once and reused several times, leading to faster development and validation.<br /><br /></div> <div> </div> <div>In some cases, building blocks can be re-arranged with others to create new solutions. I gave the example of session-based messaging which, by applying the concept of SIP session to instant messaging, permits to integrate IM as one component among others in a multimedia SIP session.<br /><br />Christophe<br /></div></basefont>Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-4706138697725258507.post-22316330588993750122008-01-28T14:04:00.000+01:002008-02-12T10:37:13.214+01:00What is an IMS Service?Considering the current fuzziness around IMS, it is a remarkable fact that there is not even a common understanding of what an IMS service is. For anybody who can't provide such a definition or is giving a wrong one, promoting IMS as the next big thing or dismissing it as the next big telco failure are equally blind statements.<br /><br />In this post I will try to clarify this issue and provide my own definition.<br /><br /><div> </div> <div>In the following, I will often distinguish between SIP, the Internet protocol, and IMS, a specific architecture making use of SIP.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Often Heard<br /><br /></div> <div> </div> <div>For many, an IMS service is a service that is developed specifically for IMS, and which uses SIP as its main, if not unique control protocol. Push to Talk over Cellular (PoC) or VoIP based on SIP and IMS are typical such services.<br /><br /></div> <div> </div> <div>Another common statement is that IMS will not be used to develop new services, but to re-implement existing services with a new architecture and a new control protocol.<br /><br /></div> <div> </div> <div>From these statements can be derived many interesting questions, including the following.<br /><br /></div> <div> </div> <div>Aren't web services a better approach and isn't SOA a more adequate architecture to deliver services?<br /><br /></div> <div> </div> <div>Isn't <a href="http://en.wikipedia.org/wiki/Xmpp">Jabber/XMPP</a> a better protocol than SIP to support Instant Messaging?<br /><br /></div> <div> </div> <div>Isn't the fate of SIP (and IMS) already sealed, considering that many of the most important companies delivering communication services to very large communities over the Internet have decided to go for alternative (standard or proprietary) protocols?<br /><br /></div> <div> </div> <div>Is there any viable future for a network and a protocol that are inherently incapable to foster service innovation?<br /><br />I will come back on these questions in the following, either directly or indirectly.<br /><br /></div> <div> </div> <div style="font-weight: bold;">There will be be a huge (global) IMS and (global) SIP community, covering both telco networks and the Internet<br /><br /></div> <div> </div> <div>First, while this is true that major communication applications running on the Internet do not all make use of SIP, it should be acknowledged that this is not the rule. The popular communication application provided by <a href="http://www.microsoft.com/en/us/default.aspx">the company</a> founded by the wealthiest man on earth is based on SIP, even if some "optimizations" brought to the protocol do not make it directly interoperable with other SIP-based clients. Th <a href="http://en.wikipedia.org/wiki/Gizmo_Project">Gizmo project</a> pushes forward the fact that SIP is a standard, and therefore permits interoperability. A <a href="http://www.yahoo.com/">famous Internet company</a> uses both Jabber/XMPP and SIP for its communication services.<br /><br /></div> <div> </div> <div>IMS is an architecture and a standard supported by standardization forums like 3GPP, 3GPP2, ETSI TISPAN, CableLabs, and the WiMax Forum. As a consequence, every operator in the world supporting a single or a combination of access technologies (ex. fixed broadband, cable, licensed or unlicensed radio access) should to at least consider IMS as a candidate in its roadmap. It is very likely that a significant number of operators will opt for IMS, thus creating a huge community of SIP and IMS users across the world.<br /><br /></div> <div> </div> <div>The intrinsic capabilities of SIP as a control protocol (see <a href="http://theimslantern.blogspot.com/2007/12/index-for-ims-lantern.html">Index </a>for several posts on this subject), and the integration of SIP servlets support in all J2EE platforms, even in the versions that are not aimed at the telecommunications market, make that it is possible to eventually see SIP used in other domains that those which directly relate to telecommunications, and for applications which do not focus on person-to-person communication.<br /><br /></div> <div> </div> <div>All in all, there is a high probability that the SIP community eventually exceeds in dramatic proportions all communities relying on other protocols for communication.<br /><br /></div> <div> </div> <div>Note that as long as interoperability is ensured, there is no need for all parties in this community to rely on the same architecture or on the exact same SIP profile.<br /><br /></div> <div> </div> <div>A very valid question is whether a non-IMS SIP community can supersede and eventually kill an IMS SIP community. The temptation of certain telecommunications actors to artificially create an IMS SIP walled garden by adding barriers in IMS standards between IMS SIP and non-IMS SIP clients and applications is an implicit invitation to a war, which may eventually damage the whole SIP ecosystem (however, it is important to note that many telco actors do not want such a fight and may find ways to eliminate these barriers - this may be stating the obvious, but the telco domain is not only standard-driven: business concerns are more fundamental). Otherwise, I guess that this is essentially a question of service offering and business model. If a user can benefit from similar or better services from an alternative service provider, and for a lower cost, it may be tempted to bypass the IMS-based offer.<br /><br /></div> <div> </div> <div style="font-weight: bold;">SIP does not have to be the only communication protocol to be successful<br /><br /></div> <div> </div> <div>Once again I am stating the obvious, but there is such a thing as protocol gateways, enabling interoperability between communication and control protocols, even if this conversion has to be adapted to semantical differences between protocols and may only address the common functionality between them. In the case where the protocols that need to interoperate are both standard, the conversion may itself be standard, as this is the case between SIP and XMPP (last time I checked the standardization of this particular gateway was work in progress).<br /><br /></div> <div> </div> <div style="font-weight: bold;">An existing service can become an IMS one through integration<br /><br /></div> <div> </div> <div>The thought that a service has to be specifically implemented in order to run on IMS and to be SIP-centric is wrong.<br /><br /></div> <div> </div> <div>Access to a service can be preceded by a SIP interaction. The binding between SIP and the service specific protocol(s) usage can be supported by such SIP mechanisms as content indirection or the use of the SIP method REFER. I wrote <a href="http://theimslantern.blogspot.com/2007/05/service-pattern-ims-content-indirection.html">a post on this subject</a>, giving examples of this type of integration and describing some of the advantages associated to it.<br /><br /></div> <div> </div> <div>Another way to integrate a non-IMS service with IMS is to encapsulate the delivery of the service within a SIP session: SIP is used to manage a session between the IMS client and the server supporting the non-IMS service (or an IMS application server acting on its behalf), while the service specific protocol(s) is (are) used to deliver the service within the session. I also described this approach <a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">here</a>.<br /><br /></div> <div> </div> <div>Integrating a service with IMS does not necessarily require that the existing implementation of the service be modified to incorporate components addressing the SIP specific logic. This SIP logic can be isolated and deployed on a SIP application server that is remote from the server supporting the legacy non-IMS logic, keeping the overall integration process simple from a service delivery perspective.<br /><br /></div> <div> </div> <div>Yet another integration approach can be limited to IMS being used for service discovery, subscription and configuration, while service delivery is integrally supported outside of the IMS domain. I wrote <a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">a specific post</a> on this subject.<br /><br /></div> <div> </div> <div>This integration subject is a central topic of <a href="http://ieeexplore.ieee.org/xpl/selected.jsp?imageField.x=44&imageField.y=13&imageField=View+Selected+Items&chklist=4286914%40ieeejrns">the article </a>I wrote for the IEEE Vehicular Technology Magazine.<br /><br /></div> <div> </div> <div>This means that a lot of future IMS services might already be out there. As an example, an existing Video on Demand (VoD) service might be integrated with IMS using the service discovery, subscription and configuration approach, and/or service delivery through content indirection, REFER, or within a SIP session. The service-specific protocol is RTSP and the binding between the service and IMS for content indirection or REFER is supported through the usage of the RTSP URI within SIP methods.<br /><br /></div> <div> </div> <div style="font-weight: bold;">IMS can be used to combine multiple services<br /><br /></div> <div> </div> <div>A non-IMS service delivered within a SIP session can be combined with other non-IMS services delivered within the same session, either simultaneously or sequentially. In order to optimize this combination from a user perspective, the IMS-based SIP logic might insert an intermediary on the media plane in order to mix/combine the different services at the media level. For instance, the media intermediary might mix the soundtrack of the video with another audio source, or insert textual messages in the video. See <a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">this post</a> for an example.<br /><br /></div> <div> </div> <div>Through <a href="http://theimslantern.blogspot.com/2007/05/enabling-multimedia-communication.html">an adequate conferencing support,</a> the service can be shared between several users, and combined with person-to person communication components. For instance, the video of a VoD service can be viewed by different users in remote locations, who can exchange their comments through a messaging, a video or a voice communication component.<br /><br />If there is the need to find a single reason to integrate a non-IMS service with IMS, then the possibility to combine it with person-to-person communication is this one, considering that communication is the core business of telecom operators. However, I hope I have illustrated in past posts that there could be other important motivations for such a combination.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Existing services can be enriched through SIP and IMS<br /><br /></div> <div> </div> <div>IMS can support a large number of enablers implemented through application residing in SIP application servers or directly supported by terminals or endpoint servers connected to the IMS.</div> <div> </div> <div>This permits existing services to be enriched with logic making use of IMS-based application like presence (providing information about the user, its communication means, its terminals, its applications) and group management (defining a standard way to access and manage groups of users, to which the service can be delivered simultaneously or which define who is authorized to access the service).<br /><br /></div> <div> </div> <div>Enablers supported directly by terminals may enable real time communication between the service and the user, provide real time and accurate information about the user, its terminal(s) and its applications, or use SIP as a transport protocol to exchange service control semantic with a remote application server. SIP event packages may typically be used for this. For instance, existing event packages may permit the service to know if a user is currently involved in a SIP session or typing on its keyboard. New event packages can be defined permitting the service to access information or being notified about events related to the user, a terminal, or a specific application. A straightforward example is one where the service would retrieve the location of a GPS-enabled terminal.<br /><br /></div> <div> </div> <div>Enrichment of an existing service through the usage of IMS-supported enabler(s) requires a modification of the existing service logic to make use of these enablers, even if the SIP/IMS specific part of it can be encapsulated through the usage of appropriate APIs.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Services can be delivered through complementary usage of SIP and other protocols and architectures</span><br /><br /></div> <div> </div> <div>It would be a fundamental misunderstanding to believe that an IMS service has to uniquely or even essentially use SIP to be delivered.<br /><br /></div> <div> </div> <div>The IETF applies a building block approach to specification, with a continuous concern to make every concept as generic as possible, and to always look at what has already been specified, even in adjacent application areas, prior to reinventing the wheel. SIP is a remarkable example of this, and as a result. The IETF community systematically tries to ensure that every SIP extension avoids to betray the spirit that governed the initial creation of the protocol, that every extension is made generic enough to be used beyond its initial purpose, and that mechanisms exist to combine SIP with other protocols that are optimized for fulfilling specific needs. SIP sessions, content indirection and SIP REFER are examples of mechanisms created to enable such a combination see <a href="http://theimslantern.blogspot.com/2007/04/sip-everywhere-but-not-for-everything.html">here </a>or in the <a href="http://theimslantern.blogspot.com/2007/12/index-for-ims-lantern.html">Index</a>). The building block approach to SIP specification is an interesting topic in itself, that I will address in <a href="http://theimslantern.blogspot.com/2008/02/bulding-block-approach-to.html">the next post</a>.<br /><br /></div> <div> </div> <div>Another fundamental misunderstanding would be to believe that the IMS service architecture is incompatible with other service architectures and their associated protocols. It was specified from a SIP-centric perspective, focusing on the relationship between the IMS application layer and the IMS core network. However, 3GPP did not want to address the details of how the the IMS application layer would be implemented, leaving room for integration with other appropriate architectures and protocols.<br /><br /></div> <div> </div> <div>As an example, SOA (Service oriented Architecture) and web services are not alternatives to IMS and its service architecture, but powerful complements to them and the usage of SIP as a service control protocol. I already wrote several times on this particular topic (just look at the IMS Lantern <a href="http://theimslantern.blogspot.com/2007/12/index-for-ims-lantern.html">Index</a>).<br /><br /></div> <div> </div> <div>An important question is how the integration of IMS and SOA should be performed. At the moment, the prevailing understanding is that it should take place uniquely through the definition of web services, permitting to integrate a SIP-centric IMS with a web services and SOA -centric application layer. I believe that this view is incomplete and that the optimal integration between IMS and SOA should be more intimate, considering that IMS service logic should combine the direct usage of SIP and web services for service delivery, instead of only developing SIP-centric logic and web services -centric logic connected through a loose web services adaptation layer, similar to the one that connects the pre-IMS networks with SOA. I gave a name to this more intimate integration architecture, which extends both OSA and the standardized IMS service architecture: the <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-3-user-oriented.html">User Oriented Architecture (UOA)</a>.<br /><br /></div> <div> </div> <div>This distinction between a future service architecture integrating IMS and SOA solely through a web services adaptation layer (which makes that IMS is simply integrated in a SOA-centric service architecture) or through both a web services layer and direct usage of SIP by applications, might look artificial, but it provides alternatives considerations to the following issues:</div> <div>- How to share a service context between IMS-centric logic and web services -centric logic? In the SOA-centric architecture, contextual information needs to be exchanged through web services defined between the IMS domain and the SOA domain, and may be limited to what is feasible or what has been done there. In a UOA architecture, this context can be naturally internal to the logic making use of both SIP and web services.</div> <div>- Which IMS service enablers are provided to services in the application layer? In a SOA-centric application layer, this set of services enablers is limited to the set of web services exposing IMS capabilities to applications, while in a UOA architecture it can be extended to whathever the SIP protocol permits at any time. In a SOA-centric architecture, if no web service has been defined to expose a particular capability to applications, then no application will try to use this capability and the potential for innovative services will be limited. Typically, web services defined by people and organizations viewing IMS as a network and a set of standardized enablers like presence and group management are likely to miss most of the capabilities that are terminal and endpoint -related, as terminals and IMS endpoints tend to be considered more as consumers of network-based services than intrinsic parts of the service architecture. Will the set of web services exposing IMS capabilities to applications ever permit applications to access information generated by another application residing in an IMS terminal, like a game, if the service architecture assumes that IMS capabilities are only those that are accessible through web services defined by network people?</div> <div>- How can IMS service enablers be used by applications? The synchronous nature of web service is likely to limit these enablers to those that can easily be rendered in a synchronous manner. In some cases, mapping the asynchronous capabilities of SIP to a synchronous interface might limit the usability of these capabilities or make them complex and unattractive to use. Directly using an asynchronous protocol like SIP to access asynchronous capabilities is likely to be simpler.</div> <div>- Can all services be efficiently delivered to users? A complex architecture clearly discriminating between IMS/SIP -centric entities on the one hand, SOA/web services on the other hand, and forcing a web services -centric mapping between the two is likely to induce delays in the end-to-end delivery of services, as service delivery needs to cross several technical domains, while these delays could be largely reduced in a more integrated architecture.</div> <div>- What is the cost for IMS services? The previous point hints at a more complex architecture induced by the definition of IMS and SOA -centric servers, and a gateway functionality between them. To this you can add the systematic duplication between web services and SIP interfaces induced by the SOA-centric architecture.</div> <div>- How fast can new services be created and deployed? If you need to specify and implement a web service for each and every IMS capability, service creation is likely to be slower than if direct usage of SIP by applications is possible.<br /><br /></div> <div> </div> <div>In addition to combining SIP with other IP and Internet service control and delivery protocols, like HTTP or RTSP, and integrating SOA and IMS, web services and SIP in a new service architecture called UOA, another important aspect that is not described in IMS specifications is to permit IMS applications to access capabilities available in pre-IMS telco networks, like user location (access to location servers), user registration status in the circuit-switched network, call control in the circuit-switched network, SMS, MMS or email as messaging enablers. Some of these enablers that are IP-based can be used in a straightforward manner. Others may require gateways between the IP and circuit-switched worlds, which may be based, on the usage of OSA/Parlay gateways but also on more specific protocol converters.<br /><br />Therefore, the IMS service architecture can go well beyond the support of SIP and access to access to IMS-based enablers. Here is <a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">an overview</a> of this scope.<br /><br /></div><div> </div> <div style="font-weight: bold;">Conclusions<br /><br /></div> <div> </div> <div style="font-style: italic;">An IMS service is a service that makes use of SIP and the IMS either centrally or marginally.</div> <div> </div> <div><br />SIP itself and even more the combination of SIP with other protocols can give birth to a flurry of new services, some of them implemented on IMS.<br /><br /></div> <div> </div> <div>The ability of SIP to combine various existing services of different types (communication, data, content, applications) can give birth to a new user experience, which is by itself a new service. This is an important matter to consider when comparing SIP with more purpose-centric protocols.<br /><br /></div> <div> </div> <div>These new services can reach a huge community covering all the continents, all types of access technologies and spreading between telco domains, other business domains, and the Internet, possibly redefining the definitions of these domains.<br /><br /></div> <div> </div> <div> </div> <div>IMS and SOA are not alternative architectures to deliver new services. They should rather be seen as building blocks permitting to create a new and more powerful service architecture called UOA.<br /><br /></div> <div> </div> <div>This draws a potential future world, in which there might be a little bit of SIP everywhere, and consequently a a good potential for IMS to fit as a particular SIP service architecture deployed by telco operators.<br /><br /></div> <div> </div> However, history shows that the best technologies do not always prevail. In a possible future, the potential of SIP as a service control protocol used in different architectures including IMS, and/or IMS as a service architecture augmenting the intrinsic capabilities of SIP, might eventually fail. Conversely, would SIP and/or IMS be only used at a fraction of their potential (e.g. for VoIP and a limited set of additional services), they could still be a success.<br /><br />ChristopheUnknownnoreply@blogger.com8tag:blogger.com,1999:blog-4706138697725258507.post-59585280247258251042008-01-15T10:49:00.000+01:002008-01-15T11:19:08.147+01:00A Contribution from the Fraunhofer Institute FOKUS<div style="text-align: left;">Here is a first external contribution coming from the renowned Fraunhofer Institute FOKUS in Berlin. You will also find the main links featured in this post on the right side of the main page.<br /><br />Here are excerpts from the email I received from Peter Weik:<br /><br /></div><span style="font-style: italic;">My name is Peter Weik and I am working with the Fraunhofer Institute</span><span style="font-style: italic;"> FOKUS in Berlin, Germany, an independent R&D organization for applied</span><span style="font-style: italic;"> research in the telecommunications space. We have here been developing</span><span style="font-style: italic;"> with own IMS prototypes and commercial IMS components now for several</span><span style="font-style: italic;"> years in the context of the FOKUS Open IMS Playground (<a href="http://www.fokus.fraunhofer.de/ims/index.php?lang=en">www.open-ims.org</a>)</span><span style="font-style: italic;"> in a true multi-vendor environment (<a href="http://www.fokus.fraunhofer.de/bereichsseiten/testbeds/ims_playground/partner/partner.php?lang=en">www.open-ims.org/partner</a>) for</span><span style="font-style: italic;"> showing not only IMS interoperability (long before the first IMS interop</span><span style="font-style: italic;"> events popped up) but also concepts around it (like e.g. application</span><span style="font-style: italic;"> development or benchmarking of IMS components).</span><br /><br /><span style="font-style: italic;">As you were asking in the latest post for links on what could be done,</span><span style="font-style: italic;"> that exploit what IMS and SIP can offer to deliver innovative services I</span><span style="font-style: italic;"> had to take on that opportunity as one of the lead developers of an open</span><span style="font-style: italic;"> source project ;)</span><br /><br /><span style="font-style: italic;">Well, you could spread the word even more via a blogpost that there is a</span><span style="font-style: italic;"> free open source solution out there that has already enabled many IMS</span><span style="font-style: italic;"> testbeds and developers: the Open IMS Core (<a href="http://www.fokus.fraunhofer.de/ims/index.php?lang=en">www.openimscore.org</a>).</span><br /><br /><span style="font-style: italic;">The Open IMS Core is an implementation of IMS Call Session Control</span><span style="font-style: italic;"> Functions (CSCFs) and a lightweight Home Subscriber Server (HSS), which</span><span style="font-style: italic;"> together form the core elements of all IMS/NGN architectures as</span><span style="font-style: italic;"> specified today within 3GPP, 3GPP2, ETSI TISPAN and the PacketCable</span><span style="font-style: italic;"> initiative. The four components are all based upon open source</span><span style="font-style: italic;"> software(e.g. the SIP Express Router (SER) or MySQL) and are available</span><span style="font-style: italic;"> under the GPLv2.</span><span style="font-style: italic;"> (You may know the project since it is also in the The March 2007</span><span style="font-style: italic;"> special issue of the IEEE Vehicular Technology Magazine on IMS, just</span><span style="font-style: italic;"> three articles further onwards.)</span><span style="font-style: italic;"> The whole idea behind the project is to enable IMS developments and to</span><span style="font-style: italic;"> help an industry to adopt IMS concepts - all of it without huge</span><span style="font-style: italic;"> investments necessary.</span><br /><br /><span style="font-style: italic;">Besides sparking the development of two also freely available IMS</span><span style="font-style: italic;"> clients (the IMS Communicator and the UCT IMS Client), it has also</span><span style="font-style: italic;"> enabled some industry players, universities and R&D departments (see </span><span style="font-style: italic;"><a href="http://www.openimscore.org/quotes">www.openimscore.org/quotes</a>) and is used in current IMS interop events</span><span style="font-style: italic;"> (e.g. at University of New Hampshire,</span><span style="font-style: italic;"><a href="http://www.iol.unh.edu/services/testing/voip/equipment.php#IMS"> http://www.iol.unh.edu/services/testing/voip/equipment.php#IMS</a>).</span><br /><br /><span style="font-style: italic;">But of course we are also looking at own application prototype</span><span style="font-style: italic;"> developments as part of our recently started Open SOA Telco Playgroundxggveqt</span><span style="font-style: italic;"> (<a href="http://www.fokus.fraunhofer.de/ims/opensoaplayground/index.php">www.opensoaplayground.org</a>). What is possible with IMS was shown at our</span><span style="font-style: italic;"> last IMS workshop in November 2007 with the IMS Community Mashup with</span><span style="font-style: italic;"> Facebook (<a href="http://youtube.com/watch?v=b1OwDD6cyBY">http://youtube.com/watch?v=b1OwDD6cyBY</a>).</span><br /><span style="font-style: italic;"><br /></span>Christophe<span style="font-style: italic;"><br /></span>Unknownnoreply@blogger.com8tag:blogger.com,1999:blog-4706138697725258507.post-39923248518124227212008-01-10T14:43:00.000+01:002008-01-10T14:47:11.053+01:00Call For Contributions<basefont>I started the IMS Lantern 9 months ago, and since then published about 50 posts, which essentially try to explain and demonstrate how IMS can support innovative services and provide an innovative approach to access existing services.<br /><br /><div> </div> <div>The IMS Lantern is being read by people representing the whole array of organizations and companies involved in the telecommunications, including traditional operators, innovative service providers, state agencies, all the traditional equipment suppliers, many application service providers, IT companies, universities and research centers, consulting companies, and individuals having an interest in new technologies.<br /><br /></div> <div> </div> <div>These organizations, companies and individuals have ideas, develop prototypes, demos or products making use of IMS and its capabilities.<br /><br /></div> <div> </div> <div>What I would like to do is spreading information about what is being done or what could be done, that exploit what IMS and SIP can offer to deliver innovative services.<br /><br /></div> <div> </div> <div>If you have something like this (an idea, a white paper, a demo, a product, a patent application), please contact me. I will post whatever information can be provided to me, with links to external documentation and web pages.<br /><br /></div> <div> </div> <div>Christophe</div><br /></basefont>Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-4706138697725258507.post-71603327207134666422007-12-17T14:04:00.008+01:002009-04-15T14:43:12.593+02:00An Index for The IMS LanternHere follows an index by themes of the posts on this blog. I will update it as new posts are published.<br /><br />In bold are the posts that are important to me.<br /><br /><span style="font-weight: bold;">The Potential of IMS</span><span><br /><br /></span><a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-1-fixed-mobile.html">Three Axes for IMS: #1 Fixed Mobile Convergence</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">Three Axes for IMS: #2 Multimedia Communication</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-3-user-oriented.html">Three Axes for IMS: #3 User Oriented Architecture</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/does-ims-create-new-walled-garden.html">Does IMS Create a New Walled Garden?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/ims-service-features.html">IMS Service Features</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-service-logic-distribution.html">IMS Service Logic Distribution</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/conservative-progressive-application.html">Conservative & Progressive Application Layers</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/co-existence-of-conservative.html">Co-existence of Conservative & Progressive Application Layers</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/01/what-is-ims-service.html">What is an IMS Service?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">3GPP Multimedia Telephony & OMA CPM</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/04/ims-service-anthropomorphism.html">Service Anthropomorphism</a><br /><br /><br /><br /><br /><span style="font-weight: bold;">Fixed Mobile Convergence<br /></span><span><br /></span><a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-1-fixed-mobile.html">Three Axes for IMS: #1 Fixed Mobile Convergence</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">IMS Public User Identities (IMPUs)</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">3GPP Multimedia Telephony & OMA CPM</a><br /><br /><br /><span style="font-weight: bold;"><br />Multimedia Communication<br /></span><span><br /></span><a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">Three Axes for IMS: #2 Multimedia Communication</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/status-of-multimedia-communication.html">Status of Multimedia Communication</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/enabling-multimedia-communication.html">Enabling Multimedia Communication</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">Use Case: Multimedia Service Delivery</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/conservative-progressive-application.html">Conservative & Progressive Application Layers</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">3GPP Multimedia Telephony & OMA CPM</a><br /><br /><br /><br /><span style="font-weight: bold;">User Oriented Architecture (UOA) and Service Oriented Architecture (SOA)<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/05/soa-ims-same-fight.html">SOA & IMS: Same Fight?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-3-user-oriented.html">Three Axes for IMS: #3 User Oriented Architecture</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">Service Pattern: Automatic Service Discovery & Configuration</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/beatles-stones.html">The Beatles & The Stones</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">An IMS Application Server in Context</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/01/contribution-from-fraunhofer-institute.html">A Contribution from the Fraunhofer Institute FOKUS</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/01/what-is-ims-service.html">What is an IMS Service?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/04/ims-service-anthropomorphism.html">Service Anthropomorphism</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-latest-news.html"></a><span style="font-weight: bold;"><br />The IMS Service Architecture<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/04/beware-of-superficial-descriptions-of.html">Beware of IMS Service Architecture Prejudices!</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">An IMS Application Server in Context</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/conflicting-views-on-ims-service.html">Conflicting Views on the IMS Service Architecture</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-service-routing-big-picture.html">IMS Service Routing: Big Picture</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-service-logic-distribution.html">IMS Service Logic Distribution</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/ims-service-features.html">IMS Service Features</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/conservative-progressive-application.html">Conservative & Progressive Application Layers</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/co-existence-of-conservative.html">Co-existence of Conservative & Progressive Application Layers</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/in-this-post-i-will-start-to-list-some.html">IMS Service Interaction Use Cases: Part 1</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-service-interaction-use-cases-part.html">IMS Service Interaction Use Cases: Part 2</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-service-interaction-use-cases-part_19.html">IMS Service Interaction Use Cases: Part 3</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/01/what-is-ims-service.html">What is an IMS Service?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/04/3gpp-communication-services.html">3GPP Communication Services</a><br /><br /><span style="font-weight: bold;"><br />The SCIM<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/05/standardization-scim-service-broker.html">Standardization: SCIM & Service Broker</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/review-of-typical-scim-features.html">Review of Typical SCIM Features</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/here-is-my-scim.html">Here is my SCIM</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/07/more-on-scim.html">More on the SCIM!</a><br /><br /><br /><span style="font-weight: bold;"><br />SIP<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/04/sip-everywhere-but-not-for-everything.html">SIP Everywhere but NOT for Everything</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/service-pattern-ims-content-indirection.html">Service Pattern: IMS Content Indirection</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">Use Case: Multimedia Service Delivery</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/does-ims-create-new-walled-garden.html">Does IMS Create a New Walled Garden?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/moving-frontier-between-it-and-telco_04.html">Moving the Frontier between IT and Telco (part 2)</a><br /><span style="font-weight: bold;"><br /></span><a href="http://theimslantern.blogspot.com/2008/01/what-is-ims-service.html">What is an IMS Service?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/bulding-block-approach-to.html">A Building Block Approach to Standardization</a><br /><span style="font-size:100%;"><br /><a href="http://theimslantern.blogspot.com/2008/03/article-from-microsoft.html">An Article from Microsoft</a><br /><br /></span><a href="http://theimslantern.blogspot.com/2008/04/3gpp-communication-services.html">3GPP Communication Services</a><br /><br /><br /><span style="font-weight: bold;">IMS as Integration Framework<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">Service Pattern: Automatic Service Discovery & Configuration</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/service-pattern-ims-content-indirection.html">Service Pattern: IMS Content Indirection</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">Use Case: Multimedia Service Delivery</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/01/what-is-ims-service.html">What is an IMS Service?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/bulding-block-approach-to.html">A Building Block Approach to Standardization</a><br /><br /><br /><span style="font-weight: bold;">IMS and the Internet<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/04/does-ims-create-new-walled-garden.html">Does IMS Create a New Walled Garden?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/in-this-post-i-will-start-to-list-some.html">IMS Service Interaction Use Cases: Part 1</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">Use Case: Multimedia Service Delivery</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/conflicting-views-on-ims-service.html">Conflicting Views on the IMS Service Architecture</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">An IMS Application Server in Context</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-uncut.html">IMS Communication Services: Uncut Version</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/bulding-block-approach-to.html">A Building Block Approach to Standardization</a><br /><span style="font-size:100%;"><br /><a href="http://theimslantern.blogspot.com/2008/03/different-strategies-for-ims.html">Different Strategies for IMS</a><br /><br /></span><a href="http://theimslantern.blogspot.com/2008/04/3gpp-communication-services.html">3GPP Communication Services</a><br /><br /><span style="font-weight: bold;"><br />IMS Service Examples and Service Patterns<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">Service Pattern: Automatic Service Discovery & Configuration</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/service-pattern-ims-content-indirection.html">Service Pattern: IMS Content Indirection</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/public-service-identity-service.html">Public Service Identity Service Patterns</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/use-case-multimedia-service-delivery.html">Use Case: Multimedia Service Delivery</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-uncut.html">IMS Communication Services: Uncut Version</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/in-this-post-i-will-start-to-list-some.html">IMS Service Interaction Use Cases: Part 1</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-service-interaction-use-cases-part.html">IMS Service Interaction Use Cases: Part 2</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-service-interaction-use-cases-part_19.html">IMS Service Interaction Use Cases: Part 3</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/01/what-is-ims-service.html">What is an IMS Service?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/04/ims-service-anthropomorphism.html">Service Anthropomorphism</a><br /><br /><br /><span style="font-weight: bold;">IMS Application Servers & Service Platforms<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">An IMS Application Server in Context</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/moving-frontier-between-it-and-telco_04.html">Moving the Frontier between IT and Telco (part 2)</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/09/ims-service-routing-isc-for-ims.html">IMS Service Routing: ISC for IMS Application Servers</a><br /><br /><span style="font-size:100%;"><a href="http://theimslantern.blogspot.com/2008/03/different-strategies-for-ims.html">Different Strategies for IMS</a></span><br /><span style="font-weight: bold;"><br /><br /><br />User Data<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/05/user-application-data-panorama.html">User Application Data: a Panorama</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/user-application-data-opinions.html">User Application Data: Opinions</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/bulding-block-approach-to.html">A Building Block Approach to Standardization</a><br /><br /><br /><span style="font-weight: bold;"><br />Perception Issues with IMS<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/04/why-dedicating-blog-to-ims.html">Why dedicating a blog to IMS?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/classification-of-ims-critics-part-1.html">A Classification of IMS Critics, Part 1</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/classification-of-ims-critics-part-2.html">A Classification of IMS Critics, Part 2</a><br /><span style="font-weight: bold;"><br /></span><a href="http://theimslantern.blogspot.com/2007/04/ims-core-network-or-service-framework.html">IMS: Core Network or Service Framework?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/does-ims-create-new-walled-garden.html">Does IMS Create a New Walled Garden?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/soa-ims-same-fight.html">SOA & IMS: Same Fight?</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/12/conflicting-views-on-ims-service.html">Conflicting Views on the IMS Service Architecture</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/danger-ims-communication-services.html">Danger! IMS Communication Services</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-uncut.html">IMS Communication Services: Uncut Version</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-latest-news.html">IMS Communication Services: Latest News</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/beatles-stones.html">The Beatles & The Stones</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/conservative-progressive-application.html">Conservative & Progressive Application Layers</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/01/what-is-ims-service.html">What is an IMS Service?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">3GPP Multimedia Telephony & OMA CPM</a><br /><br /><span style="font-size:100%;"><a href="http://theimslantern.blogspot.com/2008/03/different-strategies-for-ims.html">Different Strategies for IMS</a><br /><br /></span><a href="http://theimslantern.blogspot.com/2008/04/3gpp-communication-services.html">3GPP Communication Services</a><br /><br /><br /><span style="font-weight: bold;">Details on IMS Specifications<br /><br /></span><a href="http://theimslantern.blogspot.com/2007/05/finding-your-way-on-3gpp-web-site.html">Finding Your Way on the 3GPP Web Site</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">IMS Public User Identities (IMPUs)</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">IMS Public Service Identities (PSIs)</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-service-routing-big-picture.html">IMS Service Routing: Big Picture</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-service-profile.html">IMS Service Routing: Service Profile</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-isc-for-s-cscf.html">IMS Service Routing: ISC for S-CSCF</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/09/ims-service-routing-isc-for-ims.html">IMS Service Routing: ISC for IMS Application Servers</a><br /><span style="font-weight: bold;"><br /></span><a href="http://theimslantern.blogspot.com/2007/05/standardization-scim-service-broker.html">Standardization: SCIM & Service Broker</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/user-application-data-panorama.html">User Application Data: a Panorama</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/danger-ims-communication-services.html">Danger! IMS Communication Services</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-uncut.html">IMS Communication Services: Uncut Version</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-latest-news.html">IMS Communication Services: Latest News</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/3gpp-multimedia-telephony-oma-cpm.html">3GPP Multimedia Telephony & OMA CPM</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/03/ims-standardization-tracking-report.html">IMS Standardization Tracking Report</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/04/3gpp-communication-services.html">3GPP Communication Services</a><br /><br /><br /><span style="font-weight: bold;"><br />General Views on the Industry</span><a href="http://theimslantern.blogspot.com/2007/04/classification-of-ims-critics-part-2.html"></a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-for-mobile-operators.html">IMS for Mobile Operators</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/04/ims-for-fixed-operators.html">IMS for Fixed Operators</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/ims-for-operators-with-mobile-fixed.html">IMS for Operators with Mobile & Fixed Units</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/moving-frontier-between-it-and-telco.html">Moving the Frontier between IT and Telco (part 1)</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/moving-frontier-between-it-and-telco_04.html">Moving the Frontier between IT and Telco (part 2)</a><br /><br /><a href="http://theimslantern.blogspot.com/2007/05/soa-ims-same-fight.html">SOA & IMS: Same Fight?</a><br /><br /><a href="http://theimslantern.blogspot.com/2008/02/bulding-block-approach-to.html">A Building Block Approach to Standardization</a><br /><br /><span style="font-size:100%;"><a href="http://theimslantern.blogspot.com/2008/03/different-strategies-for-ims.html">Different Strategies for IMS</a></span><br /><br /><a href="http://theimslantern.blogspot.com/2009/03/defining-ims-strategy.html">Defining an IMS Strategy</a><br /><br /><a href="http://theimslantern.blogspot.com/2009/04/list-of-ims-deployments.html">A List of IMS Deployments</a> (regular updates to be expected)<br /><br /><span style="font-weight: bold;"><br />External Contributions to the IMS Lantern<br /><br /></span><a href="http://theimslantern.blogspot.com/2008/01/call-for-contributions.html">Call For Contributions</a><span style="font-weight: bold;"><br /><br /></span><a href="http://theimslantern.blogspot.com/2008/01/contribution-from-fraunhofer-institute.html">A Contribution from the Fraunhofer Institute FOKUS</a><br /><br /><span style="font-size:100%;"><a href="http://theimslantern.blogspot.com/2008/03/article-from-microsoft.html">An Article from Microsoft</a><br /><a href="http://theimslantern.blogspot.com/2008/03/ims-standardization-tracking-report.html"><br /></a></span><a href="http://theimslantern.blogspot.com/2008/03/ims-standardization-tracking-report.html">IMS Standardization Tracking Report</a>Unknownnoreply@blogger.com29tag:blogger.com,1999:blog-4706138697725258507.post-70687698350936537902007-12-17T11:28:00.000+01:002007-12-17T11:59:00.490+01:00Use Case: Multimedia Service Delivery<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_pjPCbrdQN1U/R2ZPttfBV0I/AAAAAAAAAEc/Zb6AYiu4GDg/s1600-h/Multimedia+Service+Using+IMS.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp3.blogger.com/_pjPCbrdQN1U/R2ZPttfBV0I/AAAAAAAAAEc/Zb6AYiu4GDg/s400/Multimedia+Service+Using+IMS.jpg" alt="" id="BLOGGER_PHOTO_ID_5144887271039784770" border="0" /></a><br /><basefont>One of the three axes that would permit IMS to revolutionize the telecom world, together with <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-1-fixed-mobile.html">user oriented convergence</a> and the definition of a new service architecture combining the power of SOA with a new <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-3-user-oriented.html">User Oriented service Architecture (UOA)</a>, would be the full exploitation of the <a href="http://theimslantern.blogspot.com/2007/04/three-axes-for-ims-2-multimedia.html">multimedia capabilities</a> supported by the SIP protocol.<br /><br /><div> </div> <div>This post presents an example which makes use of these multimedia capabilities.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">IMS Service Features Illustrated with the Example</span><br /><br /></div> <div> </div> <div>The example I present today shows, among other things...<br /><br /></div> <div> </div> <div>How IMS can be used by an operator to deliver a multimedia service which includes content and application components, but not a single person-to-person communication one.<br /><br /></div> <div> </div> <div>How IMS can be used to share a multimedia content and application experience between several users (not shown on the figure).<br /><br /></div> <div> </div> <div>How IMS can be used to mix person-to-person communication with content and application sharing.<br /><br /></div> <div> </div> <div>How non IMS and even non SIP-aware services can be integrated with IMS (i.e. a service delivered over IMS does not have to be specifically developed for it and does not necessarily require SIP-related application components).<br /><br /></div> <div> </div> <div>How IMS can be used for an operator to offer to its subscribers services actually delivered by 3rd party service providers located in other domains, possibly including the Internet, without requiring a prohibitively strong technical coupling with them.<br /><br /></div> <div> </div> <div>How IMS can permit an operator to add-value to multimedia content delivered to its subscribers by third party service providers.<br /><br /></div> <div> </div> <div>That <a href="http://theimslantern.blogspot.com/2007/04/ims-service-logic-distribution.html">IMS Services might be highly distributed</a>, with application logic running in devices and in a variety of application and content servers. The SIP logic itself might be confined to only a subset of these service entities.<br /><br /></div> <div> </div> <div>Why the existing conferencing solutions available on the market are too limited, and why <a href="http://theimslantern.blogspot.com/2007/05/enabling-multimedia-communication.html">a more generic multimedia conferencing architecture </a>is needed.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Description of the Service</span><br /><br /></div> <div> </div> <div>In order to experience the multimedia service, the user starts a session addressed to a Public Service Identity (PSI) identifying the service. The PSI may be specific to the user and routed to the SIP AS according to the user's service profile (originating trigger). Alternatively, the PSI may be a shared, public one. In this case, the routing to the SIP AS may also be based on the user's service profile (i.e. users need to be authorized to access the service so that their service profile allows routing to the SIP AS), unless it is based on the normal resolution of the PSI to the SIP AS (i.e. all users can access the SIP AS when they issue a request addressed to it). I already described these routing alternatives <a href="http://theimslantern.blogspot.com/2007/06/public-service-identity-service.html">here </a>and also with <a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">another service use case</a>.<br /><br /></div> <div> </div> <div>The user negotiates (and possibly re-negotiates during the session) the content of the service through any appropriate interface. For instance by accessing a web page supported by the SIP AS. Alternatively, this could be through a client downloaded on the terminal and communicating with the SIP AS via an application to application interface, like the exchange of XML documents describing the desired content of the multimedia session.<br /><br /></div> <div> </div> <div>The SIP AS then performs the required actions to deliver the content (e.g. files, streaming media, web pages, applications) within the session. Depending on the type of content, the desired control of the operator over the delivery, and the technical means available for each component, the SIP AS uses the appropriate mechanism for each of the components (which do not have to be co-located with the service control logic hosted by the SIP AS). This may include some of the following:</div> <div>- Establishing a SIP session with the component endpoint and bridging this new session with the user to SIP AS one (typical <a href="http://theimslantern.blogspot.com/2007/09/ims-service-routing-isc-for-ims.html">B2BUA behavior</a>).</div> <div>- Controlling the delivery of the component via an appropriate non-SIP interface (e.g. web services, H.248) towards the component source and negotiating/re-negotiating the SIP session accordingly towards the user.</div> <div>- Providing the user's terminal and/or the component source with appropriate information to establish an end-to-end connection. In an example, the SIP AS would provide within the session a URI (e.g. HTTP URI, FTP URI, RTSP URI) via <a href="http://theimslantern.blogspot.com/2007/04/sip-everywhere-but-not-for-everything.html">SIP content indirection or a referral</a>, permitting the user's terminal to directly connect with the component source. In another instance that I used when I was the architect of an IMS demo for an equipment supplier, the SIP AS retrieves from the source the information required to connect to a whiteboard server, and transmits it to the user's terminal, so that a whiteboard client connects to the server and interfaces with it through the relevant whiteboard protocol. In yet another instance, the SIP AS provides the component source with the information relevant to push the content to the user's terminal. In any of these instances, the SIP AS may keep a control interface towards the component source in order to terminate the delivery of the component when the service session is completed (the idea is to ensure that the component is not delivered anymore after the service session is ended).<br /><br /></div> <div> </div> <div>During session establishment or session renegotiation for a specific component, the SIP AS may decide to insert a number of media-level intermediaries (typically media servers) between the user's terminal and the component source(s). In such a case there is no peer to peer connection between the user's terminal and the component source, as both connect to the intermediary which is under the control of the SIP AS. The potential control interface between the SIP AS and the intermediary in the network might be an alternative way for the SIP AS to synchronize the delivery of the service component with the service session (start/stop delivery). However, the usage of a media intermediary may serve other more added-value objectives, like combining/mixing different components together (e.g. inserting text information in a video stream), caching media for better delivery quality, transcoding media to fit the capabilities of the user's terminal, or inserting localized advertizement in the media stream (possibly to decrease the service fee to be paid by the user).<br /><br /></div> <div> </div> <div>It should be noted that the component sources may be provided by the operator or by 3rd party service providers located in other domains, and possibly in the Internet. In this case, the operator acts as a service broker, adding value to individual components by integrating them in a single multimedia session, acting on the media plane, and providing the level of access (no need for the user to authenticate to each individual service component provider), the QoS and the security that can be expected by the user from its telecommunications operator.<br /><br /></div> <div> </div> <div>The service session, which takes place between the user's terminal and the SIP AS (usage of SIP for the service may be confined to these two entities), may terminate when either the user or the SIP AS decides that it is time to. As for individual components in the session, their delivery may be terminated through either the user's terminal, the component source, or the SIP AS if it has the control means to do it.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Some of the Benefits of Using IMS to Deliver the Service</span><br /><br /></div> <div> </div> <div>As I already described in <a href="http://theimslantern.blogspot.com/2007/05/service-pattern-ims-content-indirection.html">an earlier post</a>, using SIP has a prerequisite to access a service has numerous advantages for both the operator and the user, and using a SIP session to deliver the service even adds on top of this:</div> <div>- The SIP signalling generated by the user's terminal and reaching the SIP AS transports meaningful service information, such as the authenticated identity of the user, information relevant to charging like the address of the charging nodes and correlation identifiers which will permit the billing system to correlate charging information generated at the media plane level (e.g. type and volume of media), at the IMS core network level (duration of the session), and at the SIP AS level (any additional application-level event), information about the location of the terminal (e.g. cell ID), and information about the access technology used by the terminal, which can be exploited by the SIP AS to optimize the delivery of the components.</div> <div>- Routing of the SIP signalling between the user's terminal and the SIP AS may be directly linked to the authorization of the user to access the service (see above).</div> <div>- The establishment and re-negotiation of the session permits the user's terminal and the SIP AS to re-use core network support to set the relevant QoS and security associations just like for a person-to-person voice or multimedia session.</div> <div>- The SIP session determines a well defined context for the delivery of the service, with a clear begining and end.</div> <div>- The session permits the coherent combination and aggregation of individual components within a multimedia service.</div> <div>- The session offers the possibility for the operator to insert media-level intermediaries for both control and added-value purposes. This example thus illustrates how an operator can both use multimedia sessions to deliver its own services, and add value to peer-to-peer multimedia exchanges.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Some Possible Extensions to the Use Case</span><br /><br /></div> <div> </div> <div>Though not supported by the standards today, the service could be extended with session continuity, permitting the terminal to switch from one access to another (e.g. WiFi to UMTS) without stopping the service session and the delivery of its components.<br /><br /></div> <div> </div> <div>Currently under work in the IETF, session mobility would permit the user to transfer the ongoing session from a terminal to another (e.g. mobile phone to TV set) without stopping it. Such a transfer could be necessary from a convenience perspective (e.g. the user started the service on the run and is now at home, benefiting from terminal alternatives), or depending on the renegotiation of the service session (e.g. the user would like to add a component like an application, which is not available on the terminal he or she is using). It would also be possible for the user to receive the content or run applications on several terminals, each optimized for a subset of the components or applications.<br /><br /></div> <div> </div> <div>While the example concentrated on the delivery of a mutimedia service to a single user, it would be possible to share the experience between multiple ones. This could be done by providing a conferencing entity to the architecture. As this conferencing support would not be limited to person-to-person communication (e.g. voice, messaging), this would require <span style="text-decoration: underline;"><span style="font-weight: bold;"></span></span>a more generic conferencing architecture than those proposed today by suppliers. I tried to describe a potential architecture in <a href="http://theimslantern.blogspot.com/2007/05/enabling-multimedia-communication.html">a past post</a>. Sharing the same experience could imply the synchronization of applications on each of the users' terminals, permitting for instance shared browsing, a shared whiteboard, or multi-player gaming.<br /><br /></div> <div> </div> <div>As soon as multiple users are involved in the service session, person-to-person communication would be an appreciated plus and would be enabled by the conferencing support permitting to add bi-directional communication components between the participants. Such a possibility would make the use case come back to the core concern of the operator: delivering person-to-person telecommunication.<br /><br /></div> <div> </div> <div>A service supporting both the delivery of content/application and person-to-person communication may experience different modes. In addition to this example in which a service session is extended to communication, an alternative use case would see a communication session between two or more users extended to shared multimedia service delivery.<br /><br /></div> <div style="font-weight: bold;"> </div> <div><span style="font-weight: bold;">Everything is Possible, Nothing is Given</span><br /><br /></div> <div> </div> <div>Obviously, such a service would require an adequate support in terminals (application architecture, application components and an intuitive user interface), a relevant architecture in the IMS application layer, the right agreements and technical settings between the operator, its SIP AS, and the 3rd parties and their servers, and an attractive business model for all the parties (the operator would need to find the right charging policy for its subscribers).<br /><br /></div> <div> </div> <div>It would require that ongoing standardization efforts in 3GPP do not prevent, through artificial barriers, the delivery of such a service or similarly out-of-the-mainstream others. I will come back on this topic in a future post.<br /><br /></div> <div> </div> <div>Christophe</div><br /></basefont>Unknownnoreply@blogger.com50tag:blogger.com,1999:blog-4706138697725258507.post-82631849410563017562007-12-11T16:17:00.000+01:002007-12-12T11:05:09.927+01:00Conflicting Views on the IMS Service Architecture<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_pjPCbrdQN1U/R16xAWIeWWI/AAAAAAAAAD8/RyYwwx4O6sk/s1600-h/IMS+Service+Architecture+-+3GPP.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp3.blogger.com/_pjPCbrdQN1U/R16xAWIeWWI/AAAAAAAAAD8/RyYwwx4O6sk/s400/IMS+Service+Architecture+-+3GPP.jpg" alt="" id="BLOGGER_PHOTO_ID_5142742444002924898" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_pjPCbrdQN1U/R16xBGIeWXI/AAAAAAAAAEE/7lULEbb97cY/s1600-h/IMS+Service+Architecture+-+TIL.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_pjPCbrdQN1U/R16xBGIeWXI/AAAAAAAAAEE/7lULEbb97cY/s400/IMS+Service+Architecture+-+TIL.jpg" alt="" id="BLOGGER_PHOTO_ID_5142742456887826802" border="0" /></a><br /><br />The two figures above both depict the IMS Service Architecture.<br /><br />The first one is taken from the 3GPP specifications and is therefore the primary basis for anyone to understand the IMS Service Architecture.<br /><br />The second one is my own representation of the IMS service architecture, based on the exact same specifications, and is therefore only accessible by the readers of this blog. As I have not seen so far a similar representation anywhere else, you can assume that this is not at the moment the mainstream perception of the IMS service architecture in the telco community.<br /><br /><span style="font-weight: bold;">IMS as a New Intelligent Network (IN)</span><br /><br />The 3GPP representation of the IMS service architecture is network centric. It represents the IMS application layer solely according to its interface to the IMS core network, placed at the center of the figure with the S-CSCF.<br /><br />This representation is potentially misleading as technicians with a classical telecom background can perceive the IMS service architecture as an IP replica of the Intelligent Networks that can be found in all existing fixed and mobile circuit-switched networks. Actually, I have seen this view supported numerous times, both by these people who know everything about telecommunications and by alleged IMS experts.<br /><br />This IN perception of the IMS service architecture is re-inforced by the fact that two of the IMS application server types represented in the figure are tightly linked to IN: the IM SSF is a gateway between IMS and an IN application server, and the OSA gateway is usually (and rightly) perceived as being essentially an API on top of IN. Adding to the confusion, the terminology used for the IMS service architecture (e.g. <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-service-profile.html">trigger points</a>) heavily borrows from IN (to be frank, some companies participating to IMS standardization did see this architecture as an IN one).<br /><br />In an IN network, the (fixed or mobile) switch interfaces with the application server through a dedicated control interface (e.g. INAP, CAP, an IS.41 subset), which permits the application server to control the switch by issuing instructions to it. These instructions essentially serve the purpose to control voice calls, as the circuit-switched network is voice centric.<br /><br />In such an architecture, the basic voice services are supported by the core network, which is complemented by application servers for the delivery of "supplementary" or "value-added" services.<br /><br />With this kind of background, it is easy to perceive ISC as the IMS equivalent to INAP/CAP and the IMS application servers as an extension to the core network. Some might even argue that the IMS application layer is not needed, if you can implement all the required supplementary services within the S-CSCF.<br /><br /><span style="font-weight: bold;">IMS as a Totally New Service Architecture</span><br /><br />However, the IN-oriented interpretation of the IMS service architecture does not resist a thorough analysis of the specifications that I tried to describe in past posts (<a href="http://theimslantern.blogspot.com/2007/06/ims-service-routing-big-picture.html">here</a>, <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-service-profile.html">there</a>, <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-isc-for-s-cscf.html">there </a>and <a href="http://theimslantern.blogspot.com/2007/09/ims-service-routing-isc-for-ims.html">there</a>).<br /><br />First, with the exception of the <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-isc-for-s-cscf.html">user registration part of the ISC reference point</a> (which permits the S-CSCF to notify application servers about registration events, but does not permit the AS to block registrations), ISC cannot be seen as a logical interface between the S-CSCF and the application server.<br /><br />On the contrary, ISC is only one branch in an end-to-end SIP interaction between the application server and other application-related entities. In such an interaction, the S-CSCF and the whole IMS core network only act as intermediaries and service-related routing functions between application-related entities. This is why I tend to represent the whole IMS core network as a SIP-oriented service bus supporting the IMS application layer (I will come back on this in a future post). This bus is essential for the IMS application layer, but its significance is close to zero from a service perspective. Suffice to say that it duly supports its service bus role, and that the best additional value it can offer to applications is to be totally transparent to them.<br /><br />The second essential characteristic of IMS that dismisses the claims of an IN replica is that <a href="http://theimslantern.blogspot.com/2007/04/sip-everywhere-but-not-for-everything.html">SIP is not the equivalent of SS7 over IP</a>:<br />- SIP sessions are not voice calls. They are much more generic service sessions, which may even not include any voice or person-to-person communication component.<br />- SIP is not only about SIP sessions. Other SIP methods make SIP <a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">a very generic service control protocol</a>.<br /><br />With such a knowledge in mind, it is irrelevant to represent the IMS service architecture without representing what is on the other side of ISC (and other SIP-relate reference points supported in the IMS core network). My figure tries to represent all the possibilities.<br /><br />However, this figure is still incomplete, as it focuses on the SIP dimension of the IMS service architecture. For a more complete view, look at <a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">this previous post</a>.<br /><br /><span style="font-weight: bold;">The End-To-End IMS Service Architecture (SIP Dimension)</span><br /><br />Many possibilities exist, that I already described in the past (<a href="http://theimslantern.blogspot.com/2007/04/in-this-post-i-will-start-to-list-some.html">here</a>, <a href="http://theimslantern.blogspot.com/2007/04/ims-service-interaction-use-cases-part.html">there </a>and <a href="http://theimslantern.blogspot.com/2007/04/ims-service-interaction-use-cases-part_19.html">there</a>), but I will summarize below (note that the examples are very basic).<br /><br />An IMS endpoint (terminal, endpoint application server) in the operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.<br /><br />An IMS endpoint (terminal, endpoint application server) in another operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.<br /><br />An endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. enterprise network, the Internet) initiates a service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence. Note that the non-IMS endpoint may either use SIP or another protocol to initiate the interaction. In the latter case, a protocol converter (e.g. Jabber to SIP) will translate the initial request into SIP.<br />Specific case: the non-IMS endpoint is an application server (e.g. Internet application requiring user's presence).<br /><br />The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in the same operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user.<br /><br />The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in another operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user of another operator.<br /><br />The application server initiates a SIP service interaction with an endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. in an enterprise network or in the Internet). ISC is the first branch used in this interaction. Example: application server sends instant message to user in the Internet. Note that the non-IMS endpoint may either accept SIP requests or not. In the latter case, a protocol converter (e.g. SIP to Jabber) will translate the initial request to the required protocol.<br />Specific case: the non-IMS endpoint is an application server (e.g. presence server).<br /><br />The application server initiates a SIP service interaction with another IMS application server in the same operator's domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.<br /><br />The application server initiates a SIP service interaction with another IMS application server in another operator's IMS domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.<br /><br />An IMS application server acts as an intermediary in any of the interactions listed above, plus the essential case where none of the service interaction endpoint is an IMS application server (e.g. two IMS devices, an IMS device and a non-IMS device, an IMS device and a non-IMS endpoint application server). The idea is for the intermediary AS to either control or add-value to the end-to-end interaction. ISC is a branch somewhere in the middle of the SIP signalling path. Note that several IMS ASs can be inserted as intermediaries in the signalling path, forming a chain of combined services. Examples: IMS AS authorizes and/or charges for access to service, IMS application server inserts media plane intermediary to improve user experience (e.g. media mixing, media transcoding).<br /><br /><span style="font-weight: bold;">User Oriented Service Routing</span><br /><br />The SIP dimension of the IMS service architecture relies on two SIP routing mechanims:<br />1) Standard SIP routing (labelled in the figure as IETF SIP routing) based on the resolution of the target SIP address towards an endpoint.<br />2) IMS User Oriented and Service Profile based routing (labelled in the figure as user profile based routing), which permits to dynamically alter SIP routing on a user-per-user basis towards IMS application servers. The service profiles stored in the HSS can be seen as service routing routing under the control of the operator and modifiable over time. This permits to incrementally modify SIP routing as applications are added or removed from the network, and this without impacting endpoints.<br /><br />This draws a service architecture which is very flexible in terms of service logic location (in service entities like application servers in the network, endpoint application servers, devices), very flexible in terms of location of service entities in different domains (the operator's domain, another operator's domain, an enterprise domain, the Internet) and very agile in its possibility to dynamically modify service logic at work in the network.<br /><br />ChristopheUnknownnoreply@blogger.com6tag:blogger.com,1999:blog-4706138697725258507.post-1480027326845321892007-09-08T15:50:00.000+02:002007-09-08T16:30:45.605+02:00IMS Service Routing: ISC for IMS Application Server<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_pjPCbrdQN1U/RuKpCsWf6dI/AAAAAAAAADk/l_8MDJleVOQ/s1600-h/ISC+for+IMS+AS.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp1.blogger.com/_pjPCbrdQN1U/RuKpCsWf6dI/AAAAAAAAADk/l_8MDJleVOQ/s400/ISC+for+IMS+AS.png" alt="" id="BLOGGER_PHOTO_ID_5107830791121922514" border="0" /></a><br /><br /><basefont>After a long summer break, here is a fourth post on the details of the IMS service architecture related to the handling of SIP signalling. While the <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-isc-for-s-cscf.html">previous post</a> described ISC from the perspective of the IMS core network (S-CSCF), this one concentrates on the other side of the interface: the <a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">IMS Application Server</a>.<br /><br /><div> </div> <div>The details of the procedures to be supported by an IMS application server for ISC can be found in chapter 5.7 of <a href="http://www.3gpp.org/ftp/Specs/html-info/24229.htm">TS 24.229</a>. This post does not intend to describe all the details of the IMS AS procedures (for instance I will not address such specific issues as the handling of GRUUs, local numbering or carrier selection - the reader is invited to read the specification for this). I will only provide my own description of the basics, sometimes summarizing the specification, sometimes going beyond them or placing them in a larger context.<br /><br /></div> <div> </div> <div>In the following, I decided to distinguish between two cases.<br /><br /></div> <div> </div> <div>In the first one, the IMS application server receives a SIP request that was originated by another SIP entity. This entity could be an IMS client (e.g. phone, TV set, home PC) or an IMS application server (e.g. a messaging server, a multimedia content server). It could be located in the same operator domain as the IMS application server, or in a different one (e.g. an IMS client or an IMS application server of operator X issues a SIP request received by an IMS application server of operator Y).<br /><br />This entity could also be a client or application server located in a non-IMS network, like an enterprise network or the Internet. A SIP request originated from outside the IMS and routed to it can be discriminated from an IMS-issued request, and the IMS application server can adapt its behavior to this origination. For instance, a request originated from the Internet was not authenticated by the IMS, and has to be processed accordingly.<br /><br /></div> <div> </div> <div>In the second case, the IMS application server issues a SIP request to another SIP entity. This SIP request may be the consequence of the initial reception of a SIP request (first case), but it is not directly related to it. For instance, upon the reception of a call set up request for user A, the IMS application server issues an instant message to user A (or B). It may also be generated out of the blue, or through an initial interaction based on, e.g. web services or the access of a user to a web page. The SIP request may be addressed to an IMS client or IMS application server located in the same or a different operator domain (e.g. a service from operator X accesses the presence of an IMS user located in operator Y's domain). Alternatively, it may be addressed to a client or a server located in a non-IMS network, like an enterprise network or the Internet.<br /><br /></div> <div> </div> <div>Note that, through the usage of appropriate gateways, the IMS application server may use SIP to interact with entities which do not reside in the IMS and do not support the SIP protocol.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">IMS Application Server Receiving SIP Requests from the Network</span><br /><br /></div> <div> </div> <div style="font-style: italic;">SIP Roles<br /><br /></div> <div> </div> <div>When an IMS application server receives a SIP request from the core network - request which may have been initiated by an IMS client, a non-IMS client or an entity in a non-IMS network - it may support one of four different roles.<br /><br /></div> <div> </div> <div>Acting as a <span style="font-weight: bold;">SIP User Agent</span>, the IMS application behaves as an endpoint for the SIP request. The request may have been addressed to a service or service feature supported by the IMS application Server (typically when the request-uri is a <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">Public Service Identity</a> or PSI), or it may have been addressed to an IMS user (the request-uri is an IMS Public User Identity, also known as <a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">IMPU</a>). In this latter case, the service logic hosted by the IMS application server decides to terminate the request on behalf of the user it is addressed to. This is typically the case for presence requests terminated at a presence server (the presence request is addressed to the user whose presence is sought). Other examples include a call termination service or an IMS messaging store that decide that the destination user cannot accept the call or the message right now.<br /><br /></div> <div> </div> <div>Acting as a <span style="font-weight: bold;">SIP redirect</span>, the IMS application server will redirect the initiating party to another destination. I do not expect an IMS application server to extensively support this (feature-poor) role.<br /><br /></div> <div> </div> <div>The IMS application may also decide to act as an intermediary in the end-to-end SIP interaction that takes place between two SIP entities (e.g. client to client, client to other AS, other AS to other AS, other AS to client).<br /><br /></div> <div> </div> <div>Acting as a <span style="font-weight: bold;">SIP proxy server</span>, the IMS application server has very little opportunity to impact the end-to-end interaction. This behavior is adequate in cases where the AS hosts service logic that has to apply only prior to enabling the end-to-end interaction (e.g. authorization, target selection): the AS performs its logic, then lets end-to-end SIP signalling go on without any interference. It can also be used when the AS hosts service logic that monitors end-to-end SIP signalling without any intention to interfere.<br /><br /></div> <div> </div> <div>When the AS hosts service logic that requires greater control on the end-to-end SIP interaction, it has to support the so-called routeing back-to-back user agent (<span style="font-weight: bold;">routeing B2BUA</span>) behavior. As a B2BUA, the AS acts as an endpoint to both parties in the SIP interaction. Doing so, it may decide to explicitly appear as an endpoint to them (by inserting a PSI as recipient / originator of the SIP interaction) or to remain transparent to the endpoints. Here are examples of situations where service logic needs to rely on a Routeing B2BUA role: need to modify the body of a SIP request (e.g. change a codec in session description), potential need to transfer a session during its course (e.g. to another party, to an announcement), need to insert a media plane intermediary in a multimedia session (e.g. to mix/adapt/control content, to insert advertizement).<br /><br /><span style="font-style: italic;">I expect the latter example of the insertion of a media plane intermediary in an end-to-end multimedia session to be a fundamental IMS service use case in the future.</span><br /><br /></div> <div> </div> <div style="font-style: italic;">Direction of Requests<br /><br /></div> <div> </div> <div>This is possibly the most important feature of the IMS service architecture when you want to integrate a non-IMS SIP application server with an IMS network, more especially in the context of VoIP services: the ISC interface (more especially the initial filter criteria that govern the forwarding of SIP requests over ISC) distinguishes between requests that originate from a certain IMS identity (IMPU or PSI) and those that terminate to this IMS identity. Moreover, it permits to distinguish between the case where the IMS identity is currently registered with IMS or not (only from 3GPP R7 for requests originating from a non-registered identity, i.e. requests initiated on behalf of a non-registered user by an IMS application server).<br /><br /></div> <div> </div> <div>This architectural feature (shared with IN) permits to execute different service logic depending on the direction of a request. For instance, taking classical call control services, it permits to execute an outgoing call screening service only for originating call requests, and call forwarding services only for terminating call requests. It also permits to forward an IMS instant message to a store and forward messaging AS only in the case where the recipient of the message is currently not registered with IMS, and therefore unreachable through IMS connectivity.<br /><br /></div> <div> </div> <div>A clear distinction between originating and terminating parties (and their respective services) is mandatory in a multi-operator environment, in which the parties might be subscribed to different operators. However, most of VoIP application servers that exist on the market today were implemented for a closed, single service provider, environment like the enterprise. They therefore tend to execute both originating and terminating services at once. Such a behavior is incompatible with the IMS service architecture, and must be corrected when the AS is ported on IMS. On the other hand, the direction of SIP requests is not a issue when porting a presence server on IMS (the presence logic depends on the SIP requests more than their direction).<br /><br /></div> <div> </div> <div>Note that, while the direction of a request (originating, originating unregistered, terminating, terminating unregistered) is an information used to determine how SIP requests should be forwarded to IMS application servers, it is not specified how to convey this information in the SIP request that is to be forwarded. A typical approach to make the AS aware of the direction is to define a distinct AS SIP URI for each direction in the <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-service-profile.html">initial filter criterias (IFCs)</a>, or to add a specific parameter in the AS address. In both case, the information about the direction is made explicit when provisioning AS addresses for iFCs in the HSS.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">Authentication</span><br /><br /></div> <div> </div> <div>Authentication aspects are clearly described in section 5.7.1.4 of <a href="http://www.3gpp.org/ftp/Specs/html-info/24229.htm">TS 24.229</a>.<br /><br /></div> <div> </div> <div>In short, a SIP request may originate from an authenticated identity that required privacy (it will be considered as "anonymous"), from an authenticated identity whose identity can be found in a 3GPP-specific header called P-Asserted-Identity, or from a non-authenticated identity (typically originating from a non-IMS network) that either set itself as "anonymous" or to a certain value. The IMS application server is then supposed to act according to the case it handles. For instance, if a non-authenticated identity was provided in the request, it may challenge it for authentication, typically in an Internet manner (e.g. using SIP digest). In another example, the AS may host service logic that applies to anonymous users or not.<br /><br /></div> <div> </div> <div>Is is an important IMS feature, that SIP requests initiated from IMS entities are authenticated by the IMS core network, and that the authenticated identity is transported across IMS entities and IMS networks sharing a security trust relationship. This implies that a SIP request issued by a subscriber of operator X can reach an IMS application server from operator Y, without the need for the AS to authenticate the user, as it was already authenticated by operator X and the fact that it was authenticated as well as the authenticated identity are transported in the SIP request. This can be seen as a cross-network single sign on feature of the IMS network, that benefits all IMS services reached through SIP.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">P-Headers</span><br /><br /></div> <div> </div> <div>As already described in <a href="http://theimslantern.blogspot.com/2007/05/service-pattern-ims-content-indirection.html">a previous post</a>, a SIP request reaching an IMS application server includes a set of IMS-specific headers ("P-" headers) which are either important for the proper behavior of the IMS application server (e.g. the already mentioned P-Asserted-Identity header, the two headers related to charging) or which can benefit the logic it supports (e.g. information about the access technology currently used by the IMS client).<br /><br /></div> <div> </div> <div>With the direction of the request, this is the other part of ISC which may require an evolution of a SIP application server to be ported on IMS.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">What is Possible, What is Not</span><br /><br /></div> <div> </div> <div>In the case where a SIP request initiates a dialogue (e.g. a session, subscription to events), the <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-service-profile.html">initial filter criterias</a> and <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-isc-for-s-cscf.html">associated procedures at the S-CSC</a>F may make that this request is forwarded to an IMS application server (or several). The IMS application server may either decide that it will only process this initial request (including the responses to it) or that it will process the whole dialogue initiated by this request until the end.<br /><br /></div> <div> </div> <div>This means that the following cases are not possible:</div> <div>- An AS cannot get involved in the middle of an ongoing dialogue: it has to be involved from the start.</div> <div>- An AS cannot cherry pick the SIP signalling it wants. Either it handles the initial request and its responses, or it handles the whole signalling in the dialogue.</div> <div>- Once it has decided to be involved in a dialogue past the initial request, an AS cannot drop an ongoing dialogue it is involved in before the end.<br /><br /></div> <div> </div> <div>Any deviation from this approach would be a betrayal of core SIP routing procedures. This implies that what would be gained (an alleged flexibility in the relationship between the IMS core network and the IMS application layer) would be at the expense of the integrity of the SIP protocol, and everything it can bring to the delivery of next generation services.<br /><br /></div> <div> </div> <div>This feature of the IMS service architecture is sometimes regarded as one of its "limitations". My belief it that those who think this is a limitation of the IMS service architecture are only projecting their own thinking limitations upon the IMS. They would like to engineer an IMS application layer exactly the same way they would engineer a circuit-switched application layer, instead of creating an application layer optimized around and making use of the unique features of IMS and the SIP protocol.<br /><br /></div> <div> </div> <div>This feature also implies that the concept of "subsequent filter criteria", initially introduced in IMS specifications and never defined afterwards will never come to a reality, as they would violate the basic SIP routing procedures used over ISC. Subsequent filter criteria were introduced to mimic dynamic triggers in the Intelligent Network, which permit an application server to dynamically inform the switch about the events it is interested in.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">Registration Case<br /><br /></span>The IMS application server may reeive <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-isc-for-s-cscf.html">3rd party registration requests from the</a><a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-isc-for-s-cscf.html"> S-CSCF</a>, indicating that an IMPU has registered/re-registered/de-registered with the IMS core network. this implies that in that case the AS acts as a <span style="font-style: italic;">SIP registrar</span>.<br /><br />As the 3rd party registration provides little details about the registration (for instance the capabilities of the IMS client are not provided), the IMS AS may need to automatically SUBSCRIBE to the registration event package asociated to the IMPU as soon as it has received the 3rd party REGISTER indicating it has registered.<br /><span style="font-style: italic;"></span><br /></div> <div> </div> <div><span style="font-weight: bold;">IMS Application Server Initiating SIP Requests to the Network</span><br /><br /></div> <div> </div> <div>An IMS application server can issue SIP requests on its own, without this request being tightly related to a request the AS previously received. The generated request might be a side effect of one or several SIP requests previously received by the AS, of interactions with an end-user performed through a non-SIP interface (e.g. web page, SMS), of interactions with a 3rd party service (e.g. web services), but these are only examples: anything can do, and the more intelligent the service is, the more spontaneous the generation of SIP requests can be.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">SIP Roles</span><br /><br /></div> <div> </div> <div>The IMS application server can act as a <span style="font-weight: bold;">SIP User Agent</span>. It is the initiator of the request and it will support the end-to-end SIP interaction with its SIP peer, whether this is an IMS client, an IMS application server, or another SIP entity outside of the IMS.<br /><br /></div> <div> </div> <div>The IMS application server can also act as the 3rd party initiator of a dialogue between two other SIP endpoints, like two IMS clients or an IMS client and an IMS application server. In this case, the AS acts as an initiating back-to-back user agent (<span style="font-weight: bold;">initiating B2BUA</span>). This role can be used for example by a service to automatically set up a call between two users or implement a click-to-dial-back feature supported by a web page (the user clicks on a link to get called back by an operator. the service logic selects the operator and establishes the call between the two).<br /><br /></div> <div> </div> <div>Note that an alternative way to implement 3rd party control is for the application server to use SIP REFER towards one of the SIP entities it wants to involve in the dialogue (e.g. the AS asks user A to set up a session with user B). This approach is simpler to implement from an application server perspective, as it does not require the usage of an initiating B2BUA, but it also requires the support of the REFER method by the SIP client, which is not a given in current SIP networks. The approach may also have an impact on how charging will be performed.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">Originating IMS Identity</span><br /><br /></div> <div> </div> <div>When it initiates a SIP request towards another IMS or non-IMS entity, the IMS application server (more precisely the service logic it hosts) has the choice between two possibilities.<br /><br /></div> <div> </div> <div>The AS may act on behalf of an IMS user, and use an IMPU of this user as the identity initiating the request. Doing so, the AS can impersonate a user it serves, and for instance send an instant message or subscribe to the presence of a 3rd party just like the user would.<br /><br /></div> <div> </div> <div>Note that this ability of an AS to issue a SIP request on behalf of a user (which may not be registered with the network at the time the request is initiated) is the reason why 3GPP had to introduce the initiating unregistered session case in the R7 specifications of initial filter criterias.</div> <div> </div> <div><br />The AS may alternatively populate the P-Asserted-Identity header with a PSI, thus endorsing an identity associated with the service logic that initiates the request. For instance, an application server may initiate a request as a specific conference, voice mail account, or chat room.<br /><br /></div> <div> </div> <div>Because it has a secure connection with the IMS core network and it is part of the IMS trust domain, the AS can directly set up the P-Asserted-Identity header with the IMPU of the user whose behalf it acts on or a PSI, ensuring that the IMS request was duly authenticated by the IMS network.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">Routing of the Request</span><br /><br /></div> <div> </div> <div>3GPP initially tended to be very restrictive about how the routing towards the IMS core network of a SIP request initiated by an AS could be performed. Fortunately, the latest specifications permit room for variants.<br /><br /></div> <div> </div> <div>When the request is sent on behalf of a user, the AS may have to route the request to an S-CSCF serving the IMPU of the user, in order for originating services associated to the user to be executed (in this case the AS has to insert the "orig" parameter to indicate this is an originating request). The routing of the request to this S-CSCF might be direct, which implies that the AS knows the address of an S-CSCF serving the IMPU (possibly through a previously received request, or by retrieving it from the HSS via Sh), or through an entry point to the network serving the IMPU (which is less efficient but requires less knowledge from the AS).<br /><br /></div> <div> </div> <div>Alternatively, and if the operator policy allows it, the AS may directly route the request to the network serving the destination address, thus bypassing potential originating services and charging procedures associated to the IMPU. This flexibility was not part of initial 3GPP ideas, but I always supported it as a simpler approach placing fewer constraints on the AS, and which is certainly adequate for some services.<br /><br /></div> <div> </div> <div>The procedure for the case where the request is initiated by a PSI is similar, except that when the request is routed to an S-CSCF serving the PSI in order to apply originating procedures and execute originating services, the address of this S-CSCF is a priori static and can be configured in the AS (but it can also be retrieved from the HSS as well).<br /><br /></div> <div> </div> <div>Note that the case where the AS has to route the request to a S-CSCF serving the IMPU or PSI requires an IMS-specific behavior that will impact non-IMS SIP application servers when they are ported on IMS.<br /><br /></div> <div> </div> <div><span style="font-style: italic;">P-Headers</span><br /><br /></div> <div> </div> <div>This is another constraint associated to an IMS application server, and which needs to be considered when porting a non-IMS AS on IMS: the IMS AS is responsible for generating and inserting 3GPP-specific headers in the SIP request prior to forwarding it to the IMS core network.<br /><br /></div> <div> </div> <div>Beside the already mentioned P-Asserted-Identity header, the AS has to insert a P-Charging-Vector header including a unique id for the transaction/dialogue (called icid) as well as an identifier for the network the request originates from (called orig-ioi). It will also have to process 3GPP-specific information coming from responses, like the identity of the terminating network (term-ioi).<br /><br /></div> <div> </div> <div><span style="font-style: italic;">Non-SIP Interfaces</span><br /><br /></div> <div> </div> <div>Just a reminder: SIP is only one of the protocols that may be used by an IMS client to access an IMS application server. Therefore, this post is focusing on just one part of the inclusion of <a href="http://theimslantern.blogspot.com/2007/06/ims-application-server-in-context.html">the IMS application server in its environment</a>.</div><br /></basefont>Unknownnoreply@blogger.com53tag:blogger.com,1999:blog-4706138697725258507.post-53036087532435588102007-07-18T13:16:00.000+02:002007-07-19T13:02:54.617+02:00IMS Service Routing: ISC for S-CSCF<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_pjPCbrdQN1U/Rp32tfVIZEI/AAAAAAAAADE/Avw8ycPEd3c/s1600-h/ISC+for+S-CSCF.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_pjPCbrdQN1U/Rp32tfVIZEI/AAAAAAAAADE/Avw8ycPEd3c/s400/ISC+for+S-CSCF.png" alt="" id="BLOGGER_PHOTO_ID_5088494415363204162" border="0" /></a><br />This is the third (but not last) post in a series that tries to describe the service-related and IMS-specific mechanisms used to route SIP requests in an IMS network.<br /><br /><div> </div> <div>After <a href="http://theimslantern.blogspot.com/2007/06/ims-service-routing-big-picture.html">a first post</a> that set the scene, and positioned IMS service routing into a bigger end-to-end context (big picture), after <a href="http://theimslantern.blogspot.com/2007/07/ims-service-routing-service-profile.html">a second post</a> that described the concept of IMS service profile, this post will describe how the IMS core network entity called S-CSCF makes use of the service profile to route SIP requests to application servers over the ISC reference point in the phases 2 and 5 of the big picture.<br /><br /></div> <div> </div> <div>However, it takes two to tango. While this post concentrates on ISC from an S-CSCF perspective, the next one will address it from the point of view of an IMS application server.<br /><br /></div> <div style="font-weight: bold;"> </div> <div><span style="font-weight: bold;">Where to Look in 3GPP Specifications</span><br /><br /></div> <div> </div> <div>The ISC procedures at the S-CSCF are not described in a dedicated document or in a dedicated chapter of a 3GPP specification. They are embedded in the detailed description of the S-CSCF procedures in <a href="http://www.3gpp.org/ftp/Specs/html-info/24229.htm">TS 24.229</a>.<br /><br /></div> <div> </div> <div>Though it definitely makes sense to read other parts of the specification in order to fully understand the procedures, the following sections are the most important:</div> <div>- Section 5.4.3.2 describes the procedures at the S-CSCF when it receives a request initiated by the user it serves. This corresponds to the phase 2 in <a href="http://bp0.blogger.com/_pjPCbrdQN1U/RoUwukvHv9I/AAAAAAAAABc/898fstq9b-Y/s1600-h/E2E+IMS.png">the big picture diagram</a>.</div> <div>- Section 5.4.3.3 describes the procedures at the S-CSCF when it receives a request that is terminated at the user it serves. This corresponds to phase 5.</div> <div>- Subsections in 5.4.1 address IMS registration procedures, which imply a specific ISC behavior.</div> <div> </div> <div><br />As always, I recommend to read the specifications, while on my side I will try to provide a different description of the procedures, that can help the reader to more easily decrypt the occasionally obscure wording and the untold stories from the specifications.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Overview of the Procedure</span><br /><br /></div> <div> </div> <div>When it receives an initial or standalone SIP request that is originated by or terminated to a "user" (<a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">IMPU</a>, <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">PSI</a>) it serves, the S-CSCF processes the initial filter criterias in the service profile associated to the IMPU or PSI, according to their priority. If the trigger point in a filter criteria is true, the S-CSCF forwards the SIP request to the corresponding application server.<br /><br /></div> <div> </div> <div>If the application server sends a related SIP request back to the S-CSCF, it proceeds with the next iFC, and so on until a terminating condition is met.<br /><br />This may lead to the so-called chaining of several application servers in the signalling path that originated from a SIP endpoint (client or application server) and will terminate at another one (client or application server). This chaining may take place on both sides of the end-to-end signalling path (i.e. phases 2 and 5).<br /><br /></div> <div> </div> <div>When a terminating condition is met and there is still a SIP request to be processed, the S-CSCF then proceeds with normal SIP routing procedures in the IMS (phase 3 or 6).<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">iFCs Are Only Applied on Standalone or Initial Requests</span><br /><br /></div> <div> </div> <div>A SIP standalone request is an isolated transaction requiring a single final reponse. An example of standalone request is MESSAGE.<br /><br /></div> <div> </div> <div>A SIP initial request starts a dialogue, which will include a set of related transactions. a SIP session started with an INVITE is an example of SIP dialogue, but there are others, like dialogues initiated by SUBSCRIBE or REFER.<br /><br /></div> <div> </div> <div>The S-CSCF applies service profile based routing only on standalone or initial requests. If an AS is contacted and decides to act as a SIP proxy or Back-to-Back User Agent (B2BUA), for an initial request starting a dialogue, it determines if it wants to remain in the signalling path for the subsequent requests of the same dialogue. This decision is recorded in a specific header called Record-Route.<br /><br /></div> <div> </div> <div>The S-CSCF then processes the subsequent requests in the same dialogue according to normal SIP routing procedures. These subsequent requests may either be routed to the AS or not, depending on its initial decision.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">The Original Dialogue Identifier</span><br /><br /></div> <div> </div> <div>The original dialogue identifier is described in section 5.4.3.4 of TS 24.229.<br /><br /></div> <div> </div> <div>You can read the technical details by yourself, but this token inserted by the S-CSCF in the SIP request before it is forwarded to an AS is a kind of secret word, that the S-CSCF will recover from the SIP request (or a derived one) when it comes back.<br /><br />This secret word, both created and consumed by the S-CSCF serves two purposes.<br /><br /></div> <div> </div> <div>This is first a convenient way for the S-CSCF to discriminate between the SIP requests it receives from the core network and those that are coming back from the application layer. When the SIP request includes an original dialogue identifier, it can be associated to an ongoing ISC procedure (i.e. ongoing processing of iFCs).<br /><br /></div> <div> </div> <div>However, the original dialogue identifier was introduced for another reason.<br /><br /></div> <div> </div> <div>When an application server receives a request originated from A and addressed to B, as it is shown in <a href="http://bp0.blogger.com/_pjPCbrdQN1U/RoUwukvHv9I/AAAAAAAAABc/898fstq9b-Y/s1600-h/E2E+IMS.png">the big picture</a>, it may decide to insert itself in the signalling path between the two endpoints. One way to do it is to just proxy the initial request back to the S-CSCF. However, a proxy behavior is very constraining, and does not permit the AS to have much control on the future SIP dialogue. For instance, the AS cannot change the SIP request as it wants, or temper with its body (e.g. change a codec in the SDP). Moreover, in the case of a SIP session, if the AS acts as a SIP proxy, it cannot decide during the session to e.g. play an announcement or transfer the session to another user.<br /><br /></div> <div> </div> <div>In order to do this, the AS has to act as a Routeing Back-to-Back User Agent (B2BUA), which makes it act as an endpoint towards A and as another endpoint towards B. In the process, it may decide to make itself visible (i.e. place a PSI in the SIP requests towards A and B) or transparent (i.e. A and B cannot see there is a B2BUA, i.e. a service, inserted between them).<br /><br /></div> <div> </div> <div>The problem is that when it acts as a routeing B2BUA, the AS creates a brand new SIP dialogue on the B-side and the S-CSCF has no standard SIP way to relate this new dialogue to the one on the A-side. The original dialogue identifier serves this purpose.<br /><br />The procedure at the AS when it acts as a routeing B2BUA mandates it to copy the header in which the original dialogue identifier was placed (the Route header) in the request starting a new dialogue downstream (the second half of the B2BUA).<br /><br /></div> <div> </div> <div>When it matches the original dialogue identifier from an incoming request with one it inserted in an outgoing request to the AS, the S-CSCF knows that the two requests relate to the same logical dialogue. This is important for charging, but also for being able to proceed with the evaluation of iFCs and associated service routing until the end.<br /><br /></div> <div style="font-weight: bold;"> </div> <div><span style="font-weight: bold;">iFC Processing Termination Condition</span><br /><br /></div> <div> </div> <div>When does the S-CSCF stop processing iFCs?<br /><br /></div> <div> </div> <div>There can be three conditions for the S-CSCF to stop its processing of iFCs:<br /><br /></div> <div>1) An application server has decided to serve as an endpoint for the SIP request (not a routeing B2BUA, a real endpoint). The AS provides the responses to the request and does not proxy it further. Routing of the SIP request in the IMS stops there (phase 2 or 5).<br /><br /></div> <div>2) This is a terminating case (phase 5) and an application server has modified the request-uri (i.e. intended destination) of the SIP request. The S-CSCF then processes the request according to this new request-uri, without any attempt to apply other iFCs that related to the previous request-uri.<br /><br /></div> <div>3) All the iFCs in the service profile have been processed, and there is still a SIP request to be routed further (phase 3 or 6).<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Requests Initiated by an Application Server</span><br /><br /></div> <div> </div> <div>An AS can decide at any time to initiate a new SIP request towards the IMS core network. This SIP request may be generated totally out of the blue, or be the side effect of an interaction with a user or a 3rd party through e.g. a web page or web services. It may also be the side effect of an incoming SIP request. For instance, when receiving an INVITE from A to B, the AS may decide to send an instant message to A, B, or C.<br /><br /></div> <div> </div> <div>In some cases the request is initiated on behalf of a user. In that case, the AS inserts the IMPU of the user (e.g. A) as the initiator of the request. As it acts on behalf of a user, its request must be processed as if it was really originated by the user. It must therefore be routed to an S-CSCF serving the user so that it applies originating procedures (phase 2), which include the processing of the service profile associated to the IMPU.<br /><br />Similarly, if the AS uses a PSI as the originator identity for the SIP request, it may need to route it to an S-CSCF, so that originating procedures apply as well, this time for the PSI.<br /><br /></div> <div> </div> <div>An S-CSCF uses different ports to process incoming and terminating SIP requests. However, in the standards, an AS has no means to know which port an S-CSCF uses for originating requests, it only knows the port for terminating requests. This is the reason why the specifications mandate that when an AS issues a SIP request on behalf of an IMPU (PSI) towards an S-CSCF serving this IMPU (PSI), it includes a specific parameter called "orig", which permits the S-CSCF to detect that the request that is coming on the terminating port should actually be processed as if it was coming on the originating one (see section 5.4.3.1 in TS 24.229).<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Support of IMS Registration Notification</span><br /><br /></div> <div> </div> <div>For an application server, knowing when an IMPU registers and de-registers from the IMS core network might be an essential information. For instance, a message store might want to be notified when a user registers, and is therefore able to receive a message that is anxiously waiting for her.<br /><br /></div> <div> </div> <div>However, SIP REGISTER is the only SIP request that cannot be forwarded by the S-CSCF for the simple reason that the S-CSCF, acting as a SIP registrar, is itself the endpoint for it.<br /><br /></div> <div> </div> <div>Consequently, in order to notify application servers about registration events as requested in the service profile (i.e. registration, re-registration, de-registration) , the S-CSCF issues a 3rd party REGISTER towards them. This is, the S-CSCF registers the IMPU of the user in the application server on behalf of the user.<br /><br /></div> <div> </div> <div>The information in this 3rd party register is more limited than the in the original REGISTER issued by the IMS client towards the S-CSCF. For instance, 3rd party registration does not permit the application server to discover the capabilities of the IMS client (which can be very important for some services), and it only provides information about a single IMPU being registered, while the user might register several IMPUs at once.<br /><br />For accessing more information about the registration, the application server can subscribe to the registration event package (using SIP SUBSCRIBE). It will receive the registration information in the body of the NOTIFY(s) issued by the S-CSCF. The registration event package is also an alternative to 3rd party registration for the AS to be notified of de-registration and re-registration events.<br /><br /></div> <div> </div> <div>Note that, if 3rd party registration (a standard IETF mechanism) is specific to the ISC reference point in the IMS architecture, the usage of the registration event package is not: the I-CSCF and standard IMS clients are supposed to subscribe to this event package in order to be notified about de-registration when it has been decided by the IMS core network (e.g. the operator has decided to de-register the IMPU).<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Details of SIP on ISC</span><br /><br /></div> <div> </div> <div>SIP messages over ISC include IMS-specific headers, some of which I already listed in <a href="http://theimslantern.blogspot.com/2007/05/service-pattern-ims-content-indirection.html">a previous post</a>.<br /><br /></div> <div> </div> <div>However, it is important to note that none of these headers is specific to ISC. These are IMS SIP headers that are also used on other reference points.<br /><br /></div> <div> </div> <div>Therefore, there is no such a thing as a specific SIP that would be used only on the ISC reference point. What makes ISC special from a core network perspective is essentially the usage of a service profile by the S-CSCF for deciding on how to route an incoming SIP request to possibly multiple IMS application servers.<br /><br /></div> <div> </div> <div>Christophe</div>Unknownnoreply@blogger.com55tag:blogger.com,1999:blog-4706138697725258507.post-15045686422263860332007-07-06T15:25:00.000+02:002007-07-06T15:52:34.725+02:00More on the SCIM!Today is a "lazy post" day. I think I might do it from time to time.<br /><br />In April, I made a series of three posts on the infamous IMS Service Capability Interaction Manager (SCIM).<br /><br />In the <a href="http://theimslantern.blogspot.com/2007/05/standardization-scim-service-broker.html">first one</a>, I described the history of the concept in 3GPP. In the <a href="http://theimslantern.blogspot.com/2007/05/review-of-typical-scim-features.html">second one</a>, I reviewed the features usually associated to the SCIM, mainly to say that I do not like them. <a href="http://theimslantern.blogspot.com/2007/05/here-is-my-scim.html">Finally</a>, I presented some of my ideas on what a SCIM could be, would it try to add value on top of the intrinsic capabilities of IMS.<br /><br />As the SCIM is a topic that seems to interest a lot of people, I decided to add a little bit more meat on this subject.<br /><br />You can find below three sides I made two years ago, when I first tried to formulate my vision of the SCIM. I think I still stand behind most of what is written there, and normally (hopefully) this should be consistant with my previous post on the topic.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_pjPCbrdQN1U/Ro5Ix0vHwJI/AAAAAAAAAC8/NKYxbSLl_EI/s1600-h/My+SCIM+Part+1.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_pjPCbrdQN1U/Ro5Ix0vHwJI/AAAAAAAAAC8/NKYxbSLl_EI/s400/My+SCIM+Part+1.png" alt="" id="BLOGGER_PHOTO_ID_5084081050154942610" border="0" /></a><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_pjPCbrdQN1U/Ro5Hy0vHwGI/AAAAAAAAACk/MgtIo_Xm-b8/s1600-h/My+SCIM+Part+2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_pjPCbrdQN1U/Ro5Hy0vHwGI/AAAAAAAAACk/MgtIo_Xm-b8/s400/My+SCIM+Part+2.png" alt="" id="BLOGGER_PHOTO_ID_5084079967823183970" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_pjPCbrdQN1U/Ro5Ht0vHwFI/AAAAAAAAACc/b0bnB4QzLuY/s1600-h/My+SCIM+Part+3.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_pjPCbrdQN1U/Ro5Ht0vHwFI/AAAAAAAAACc/b0bnB4QzLuY/s400/My+SCIM+Part+3.png" alt="" id="BLOGGER_PHOTO_ID_5084079881923838034" border="0" /></a><br />ChristopheUnknownnoreply@blogger.com269tag:blogger.com,1999:blog-4706138697725258507.post-80606205317202608612007-07-04T09:59:00.000+02:002007-07-04T11:11:23.418+02:00IMS Service Routing: Service Profile<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_pjPCbrdQN1U/RotT2EvHwDI/AAAAAAAAACM/-pWH55XuXTo/s1600-h/Service+Profile+1.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_pjPCbrdQN1U/RotT2EvHwDI/AAAAAAAAACM/-pWH55XuXTo/s400/Service+Profile+1.png" alt="" id="BLOGGER_PHOTO_ID_5083248792867160114" border="0" /></a>In the <a href="http://theimslantern.blogspot.com/2007/06/ims-service-routing-big-picture.html">previous post</a>, I showed that, in a typical end-to-end SIP interaction between two IMS clients, there is a succession of routing phases. Two of them (phases 2 and 5) make use of an IMS-specific mechanism, which does not exist as a standard in any other SIP network: <span style="font-style: italic;">service profile</span> -based SIP routing.<br /><br />In this post I will describe what an IMS <span style="font-style: italic;">service profile</span> is. In the next one, I will detail how a <span style="font-style: italic;">service profile</span> is used in the interactions between the IMS core network and the IMS application layer.<br /><br /><basefont><span style="font-weight: bold;">Service Profiles in Short<br /><br /></span> <div> </div> <div>IMS <span style="font-style: italic;">service profiles</span> can be seen as SIP routing information stored in a network database called the <a href="http://theimslantern.blogspot.com/2007/05/user-application-data-panorama.html">Home Subscriber Server (HSS)</a>.<br /><br /></div> <div> </div> <div>This SIP routing information can be associated to the two types of public identities that exist in the IMS: <a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">IMPUs</a> (for users) and <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">PSIs</a> (for services and service-related resources). An IMS <span style="font-style: italic;">service profile</span> therefore influences the routing of SIP requests that are either originated or addressed to a particular IMPU or PSI.<br /><br /></div> <div> </div> <div>The IMS core network entity that utilizes <span style="font-style: italic;">service profiles</span> for SIP routing is the S-CSCF, which retrieves them from the HSS over the Cx (Diameter-based) reference point. A <span style="font-style: italic;">service profile</span> is transferred over Cx in a standardized XML format.<br /><br /></div> <div> </div> <div>A <span style="font-style: italic;">service profile</span> is composed of a list of <span style="font-style: italic;">initial filter criterias</span> (iFC), which are processed one after the other by the S-CSCF. An iFC essentially consists of a condition to be met by the SIP request and the address of an application server the SIP request should be routed in that case.<br /><br /></div> <div> </div> <div>The processing of a <span style="font-style: italic;">service profile</span> by the S-CSCF may lead to the routing of a SIP request to several application servers over the <span style="font-style: italic;">IMS Service Control</span> (ISC) reference point. If no application server decides to serve as an endpoint to the SIP request, the S-CSCF then proceeds with normal SIP routing procedures (i.e. phase 3 or phase 6).<br /><br /></div><basefont><span style="font-weight: bold;">Service Profile in 3GPP Specifications<br /><br /></span> <div> </div> <div>While this post provides a description of IMS <span style="font-style: italic;">service profiles</span>, nothing can replace a direct access to the sources.<br /><br /></div> <div> </div> <div>Section 5.2 in <a href="http://www.3gpp.org/ftp/Specs/html-info/23218.htm">TS 23.218</a> provides a quick overview of the <span style="font-style: italic;">service profile</span>, as well as the associated procedures for the S-CSCF.<br /><br /></div> <div> </div> <div>However, the best information can be found in the annexes of <a href="http://www.3gpp.org/ftp/Specs/html-info/29228.htm">TS 29.228</a>, which specifies the Cx reference point:</div> <div><span style="font-weight: bold;">Annex B</span> provides a UML model for the HSS <span style="font-style: italic;">user profile</span>, which essentially consists of the <span style="font-style: italic;">service profile</span>. The figures in this post are taken from this annex.</div> <div><span style="font-weight: bold;">Annex C</span> describes the conjunctive and disjunctive normal forms that can be used to define <span style="font-style: italic;">initial filter criterias</span>. This is also the place where you can find an XML sample of a <span style="font-style: italic;">service profile</span>.</div> <div><span style="font-weight: bold;">Annex D</span> provides the specification of the XML schema used to transfer the <span style="font-style: italic;">service profile</span> over Cx.<br /><br /></div> <basefont><span style="font-weight: bold;">Service Profiles in More Details<br /><br /></span> <div> </div> <div>The figure at the top of this post (click to enlarge) shows that a <span style="font-style: italic;">service profile</span> is associated to possibly several IMPUs or PSIs. In the case of IMPUs, they are part of the same IMS subscription (i.e. they correspond to the same subscriber, typically a user in a mobile context).<br /><br /></div> <div> </div> <div><span style="font-style: italic;">Core Network Service Authorization</span> identifies a policy (through an integer) which is supposed to be used by the S-CSCF to decide which types of media are authorized inside a SIP session associated to the IMPU or PSI. In the latest version of the specification, <span style="font-style: italic;">Core Network Service Authorization</span> also includes a list of <a href="http://theimslantern.blogspot.com/2007/05/danger-ims-communication-services.html">communication service identifiers</a> that are authorized for the IMPU/PSI. However, <a href="http://theimslantern.blogspot.com/2007/06/ims-communication-services-latest-news.html">the recent decision</a> to let the IETF specify the support of <span style="font-style: italic;">communication services</span> in IMS may possibly lead to future changes to this part. As of now, most IMS implementations I know do not support <span style="font-style: italic;">Core Network Service Authorization</span> yet.<br /><br /></div> <div> </div> <div>The most important part of the <span style="font-style: italic;">service profile</span> is the set of <span style="font-style: italic;">initial filter criterias</span> that constitute it.<br /><br /></div> <div> </div> <div>In order to optimize the provisioning and storage of <span style="font-style: italic;">service profiles</span>, the concept of <span style="font-style: italic;">Shared iFC sets</span> was introduced. These are sets of <span style="font-style: italic;">initial filter criterias</span> that are shared among multiple subscribers. Instead of being integrally defined in the <span style="font-style: italic;">service profile</span>, they are referenced through an integer. According to the specification, this integer points at iFC sets that are locally stored in the S-CSCF.</div><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_pjPCbrdQN1U/RotTyUvHwCI/AAAAAAAAACE/PfVoV5vIdNI/s1600-h/Service+Profile+2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp1.blogger.com/_pjPCbrdQN1U/RotTyUvHwCI/AAAAAAAAACE/PfVoV5vIdNI/s400/Service+Profile+2.png" alt="" id="BLOGGER_PHOTO_ID_5083248728442650658" border="0" /></a><basefont><span style="font-weight: bold;">Initial Filter Criterias (iFCs)<br /><br /></span> <div> </div> <div>An iFC is composed of the following elements.<br /><br /></div> <div> </div> <div>A <span style="font-style: italic;">Priority</span>, which is defined as an integer. The term might be misleading, as each iFC in a <span style="font-style: italic;">service profile</span> must have a different priority, permitting the S-CSCF to process the iFCs in a deterministic order.<br /><br /></div> <div> </div> <div>A <span style="font-style: italic;">Trigger Point</span>, which consists of a set of criterias to be met by the SIP request to be routed to an AS. These criterias are defined as a set of <span style="font-style: italic;">Service Point Triggers</span> (SPT) that are linked through logical boolean operators (AND, OR, NOT).<br /><br /></div> <div> </div> <div>The SIP URI of an <span style="font-style: italic;">Application Server</span>, to which the request should be routed if the <span style="font-style: italic;">Trigger Point</span> is true.<br /><br /></div> <div> </div> <div>A <span style="font-style: italic;">Default Handling</span> element, which indicates what the S-CSCF should do in case the AS does not respond (continue with processing or reject the SIP request).<br /><br /></div> <div> </div> <div>An optional <span style="font-style: italic;">Service Information</span> element, which is a string provisionned in the <span style="font-style: italic;">service profile</span>, that the S-CSCF should place in the body of the SIP request before it is sent to the AS (the AS is supposed to know what to do with it). Originally, it was assumed that a <span style="font-style: italic;">Service Information</span> element could be added in every SIP request that the S-CSCF would forward (proxy) to an AS. This could have been interesting, for instance, to provide a kind of identification of the iFC that led to the forwarding (based on this ID, the AS could determine what services need to be executed). However, it soon appeared that tempering with the body of a SIP request is incompatible with the behavior of a SIP proxy. The possibility to use <span style="font-style: italic;">Service Information</span> is therefore limited to the only SIP request issued to an AS that does not result from a proxy behavior: REGISTER (see next post). Consequently, the usage of <span style="font-style: italic;">Service Information</span> should remain very limited in the future.</div><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_pjPCbrdQN1U/RotTuUvHwBI/AAAAAAAAAB8/idKg7dNWGBU/s1600-h/Service+Profile+3.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp1.blogger.com/_pjPCbrdQN1U/RotTuUvHwBI/AAAAAAAAAB8/idKg7dNWGBU/s400/Service+Profile+3.png" alt="" id="BLOGGER_PHOTO_ID_5083248659723173906" border="0" /></a><br /><basefont><span style="font-weight: bold;">Trigger Point & Service Point Trigger<br /><br /></span> <div> </div> <div>A <span style="font-style: italic;">Trigger Point</span> consists of a set of <span style="font-style: italic;">Service Point Triggers</span>, that are linked through boolean operators: AND, OR, NOT.<br /><br /></div> <div> </div> <div>The characteristics of a SIP request that SPTs permit to check are as follows.<br /><br /></div> <div> </div> <div>The <span style="font-style: italic;">Session Case</span> permits to define if the request was originated by the public identity while it was registered, if it was originated by the public identity while it was not registered, if it terminated to the public identity while it was registered, or if it terminated to the public identity while it was not registered.<br /><br /></div> <div> </div> <div>Originating cases correspond to the phase 2 described in the <a href="http://theimslantern.blogspot.com/2007/06/ims-service-routing-big-picture.html">previous post</a>, while terminating cases correspond to the phase 5.<br /><br /></div> <div> </div> <div>The <span style="font-style: italic;">terminating unregistered</span> case corresponds to the situation where a request is addressed to a public identity while no IMS client is currently reachable with this identity. The request may then be routed to an application server that supports service logic that handles this situation (e.g. call forwarding, message store). Alternatively, though addressed to an IMPU, the request may not be targeted at an IMS client, but to an IMS application server hosting logic for this IMPU, and which should always be reachable. This is for instance the case for presence (presence requests are addressed to an IMPU but should reach a presence server) or for <a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">the automatic service discovery and configuration example</a> I gave in a past post.<br /><br /></div> <div> </div> <div>The <span style="font-style: italic;">originating unregistered</span> case corresponds to the situation where an application server issues a request on behalf of an IMPU that is not currently registered with IMS. For instance, the service logic sends an instant message on behalf of a user, even if this user is not currently registered. This case is also required for Voice Call Continuity (VCC).<br /><br /></div> <div> </div> <div>The <span style="font-style: italic;">SIP Method</span> element permits to check if the SIP request is an INVITE, a SUBSCRIBE, a MESSAGE, a PUBLISH or... any method that may be created in the future (the type is a string, not an enumeration).<br /><br /></div> <div> </div> <div>The <span style="font-style: italic;">Request-URI</span> element permits to check the URI the SIP request is addressed to. This is typically used for iFCs that relate to <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">private or restricted access to a PSI</a> (the request-URI is the PSI).<br /><br /></div> <div> </div> <div>The <span style="font-style: italic;">SIP Header</span> element permits to check if a particular header exists in the SIP request, as well as the content of this header. It is possible to use a wildcard in the value of the content. Note that once again, there is no pre-conception about the header, which can be any standard, non-standard or future standard header.<br /><br /></div> <div> </div> <div>Finally, the <span style="font-style: italic;">Session Description </span>element permits to check the Session Description Prototocol (SDP) body that may be attached to the SIP request it it is an INVITE. The SDP permits to describe the details of the content of a session (e.g. media, application, codec).<br /><br /></div> <div> </div> <div>With these elements, it is possible to determine the routing to an IMS application server of any existing and future SIP message, based on any combination of criteria met by this SIP request.<br /><br /></div> <div> </div> <div>In addition, a specific element, <span style="font-style: italic;">Registration Type</span>, permits to inform the S-CSCF that it should notify an AS of one or several IMS registration events associated to an IMPU: initial registration, de-registration and re-registration (renewal of a registration before the registration timer expires).<br /><br /></div> <div> </div> <div style="font-weight: bold;">An Example<br /><br /></div> <div> </div> <div>John has a <span style="font-style: italic;">service profile </span>associated to the <span style="color: rgb(0, 0, 153);">sip:John@operator</span> IMPU whose translation in plain English is:<br /><br /></div> <div> </div> <div style="font-style: italic;">(Priority 10): every registered originating INVITE for a voice session should be routed to sip:vcc_server@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div style="font-style: italic;">(Priority 20): every registered originating INVITE should be routed to sip:multimedia_session_control_orig@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div style="font-style: italic;">(Priority 25): every terminating INVITE should be routed to sip:multimedia_session_control_term@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div style="font-style: italic;">(Priority 30): every terminating INVITE for voice should be routed to sip:vcc_server@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div style="font-style: italic;">(Priority 32): every originating MESSAGE to request-URI sip:My_Family@operator should be routed to sip:message_exploder@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div style="font-style: italic;">(Priority 40): every originating INVITE to request-URI sip:My_Family@operator should be routed to sip:multimedia_conference_server@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div style="font-style: italic;">(Priority 50): every terminating SUBSCRIBE with a header called "event" whose value is "presence" should be routed to sip:presence_server@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div style="font-style: italic;">(Priority 60): every originating PUBLISH or SUBSCRIBE to Request-URI sip:John@operator with a header called "event" whose value is "presence" should be routed to sip:presence_server@operator<br /><br /></div> <div style="font-style: italic;"> </div> <div>The overall sequencing permits to prioritize the processing of some requests (e.g. session set up) over others (e.g. presence requests).<br /><br /></div> <div> </div> <div>There are cases where the iFCs are mutually exclusive (e.g. 10 and 25, 30 and 32). It does not really matter if one is processed before the other.<br /><br /></div> <div> </div> <div>There are cases where several iFCs may be true for the same SIP request. It is very important to define a coherent sequencing between them. For instance, if John issues an INVITE for a voice session addressed to a user group representing his family, it is important that the following order is respected: voice call continuity server (in case there is the need to switch the call between IMS and circuit-switched), multimedia call features server for originating calls (e.g. call blocking), and then a conferencing server that will start a multiparty call between John and all the members of the family group. In a typical case, the INVITE will chain the VCC server, the multimedia call features server and the conferencing server together. It will terminate at the conferencing server which serves as a bridge between all the participants in the conference, including John.<br /><br /></div> <div> </div> <div>iFCs 10 and 20 hint at the possibility to indicate the direction of the request (originating, terminating) in the SIP URI identifying the IMS application server (an alternative would be to add a parameter in the URI). The two SIP URIs may point at the same AS, but permit the AS to determine the direction of the request and may help it determine which services should be invoked.<br /><br /></div> <div> </div> <div>iFCs 32 and 40 show that a service profile may combine a <span style="font-style: italic;">Request-URI</span> (the usual information used to route a SIP request) with othercharacteristics of the SIP message to decide on its routing.<br /><br /></div> <div> </div> <div>iFCs 50 and 60 could be combined into a single iFC.<br /><br /></div> <div> </div> <div>Christophe</div>Unknownnoreply@blogger.com69tag:blogger.com,1999:blog-4706138697725258507.post-91009255135017679432007-06-29T15:04:00.000+02:002007-06-29T20:50:34.824+02:00IMS Service Routing: Big Picture<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_pjPCbrdQN1U/RoUwukvHv9I/AAAAAAAAABc/898fstq9b-Y/s1600-h/E2E+IMS.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_pjPCbrdQN1U/RoUwukvHv9I/AAAAAAAAABc/898fstq9b-Y/s400/E2E+IMS.png" alt="" id="BLOGGER_PHOTO_ID_5081521331250905042" border="0" /></a><br /><basefont><br />This post is the first in a series that will describe how the routing of SIP service-related requests is performed in the IMS.<br /><br />Before going into the details of service profiles, initial filter criteria and the ISC (IMS Service Control) interface, I will start with an attempt at placing IMS service routing in the larger context of end-to-end SIP routing within IMS.<br /><br />I think this is something missing in most representations of the IMS service architecture, which tend to fragment the overall perception of this architecture, and make it more difficult to comprehend for the novice.<br /><br />The figure you can see at the top (click to enlarge) shows the end-to-end interaction between two IMS users. However, there exist variants related to which entity initiates the SIP interaction (IMS client or IMS AS), which entity terminates the SIP interaction (IMS client or IMS AS), and whether the end-to-end SIP interaction fully takes place between IMS entities or involves entities in an external network like the circuit-switched network or the Internet. I will address these variants below using specific colors.<br /><br />Before describing what IMS SIP routing permits to achieve, let's start with one of its apparent limitations compared with how SIP can be used in a non-IMS network.<br /><br /><div style="font-weight: bold;">Restriction to IETF SIP Routing<br /><br /></div> <div> </div> <div>The routing of a SIP request to its destination is based on the resolution of the <span style="font-style: italic;">request-uri</span> address (IMPU or PSI in IMS) to one or several targets. However, before reaching its destination, the SIP request may traverse several servers, and the originator of the request may itself define in a specific Route header (part of) the path to be followed .<br /><br /></div> <div> </div> <div>This may permit the client to decide the routing of the SIP request through a set of servers that will deliver added-value services.<br /><br /></div> <div> </div> <div>This is not possible in the IMS. More precisely, whatever SIP route an IMS client may define in a SIP request it originates will be discarded by the IMS core network (the P-CSCF for that matter) and replaced by another route which ensures the phase 1 of IMS SIP routing described below.<br /><br /></div> <div> </div> <div>Is this a limitation to the power of IMS, compared to what is possible in, say, the Internet? I don't think so.<br /><br /></div> <div> </div> <div>I do not think that relying on a SIP client to determine a set of application servers supposed to add value to the end-to-end SIP interaction is a very pragmatic and agile approach to service delivery. The mechanism is limited by the knowledge and sophistication available in the SIP client, which may be put under pressure as soon as more than one application server needs to be inserted in the signalling route (which application servers? In which order?).<br /><br /></div> <div> </div> <div>Then, you have to compare what is lost (the possibility for an IMS client to define a service route) with what is gained with the IMS architecture: service profile based routing.<br /><br /></div> <div> </div> <div>The IMS routing of SIP requests based on service profiles (phases 2 and 5 below), is sophisticated, very agile and permits to keep IMS clients very simple, as they do not have to care about service-related routing. It also accurately reflects the business relationship between an IMS user paying an operator, and the operator providing value for money in return.<br /><br /></div> <div> </div> <div>While some may look at the IMS architecture as a way to deprive users from their freedom to access the services they want to access (note anyway that the limitation is only in the route to access a destination, not the destination itself), others can see the same architecture as a way to simplify the life of users (and their devices) and to concentrate service-related complexity in the hands of those who are asking money for value.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Service Routing for Each Party (See Figure)<br /><br /></div> <div> </div> <div>An important feature of the IMS service architecture, which is not apparent in figures taken from IMS specifications, is the fact that each party in a two-party or multiparty SIP interaction benefits from its own service routing, and therefore its own services.<br /><br /></div> <div> </div> <div>As shown in the figure above, an end-to-end SIP interaction between John and Mary will first lead to the invocation of services associated to John (phase 2), and then to services associated to Mary (phase 5).<br /><br /></div> <div> </div> <div>This feature is very natural for a telecommunications service architecture (it is similar to IN), but it is not to most of the non-IMS SIP implementations, more especially those supporting enterprise VoIP services. Typically, these non-IMS implementations will combine the execution of features that apply to all parties of a call. This difference is usually the most important one to overcome when porting a non-IMS application server on the IMS.<br /><br /></div> <div> </div> <div>In the IMS architecture, a specific party in an end-to-end SIP interaction is either identified by an <a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">IMPU</a> or a <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">PSI</a>. While the figure shows an example of IMPU to IMPU interaction, the following alternatives could also exist:</div> <div>- IMPU to PSI: an IMS client or an AS-based application acting on behalf of a user interacts with an AS-based application identified by a PSI.</div> <div>- PSI to IMPU: an AS-based application interacts with an IMS client.</div> <div>- PSI to PSI: an AS-based application interacts with another AS-based application.<br /><br /></div> <div> </div> <div>Here is a practical advice for when you define or analyze an IMS message flow: S-CSCFs do not hang just like that in the architecture; they always serve someone or something, and it certainly helps to make it explicit (see for instance the figures in this or <a href="http://theimslantern.blogspot.com/2007/06/public-service-identity-service.html">the previous post</a>).<br /><br /></div> <div> </div> <div style="font-weight: bold;">Preliminary to the Description of End-To-End IMS Signalling<br /><br /></div> <div> </div> <div>Here follows the decomposition of an end-to-end SIP interaction into 6 distinct phases.<br /><br /></div> <div> </div> <div>But first a couple of things...<br /><br /></div> <div> </div> <div>There is of course a pre-requisite: John is registered with IMS. This implies that his client discovered the P-CSCF it will be associated to (according to 3GPP or TISPAN procedures), and performed the IMS registration procedure leading to John's authentication, the association of an S-CSCF to him, and the setting up of a security association between its client and the P-CSCF.<br /><br /></div> <div> </div> <div>The figure shows direct interfaces between different operators' networks. However, the GSM Association (GSMA) defined the possibility for 3rd party transit networks to be used in-between, in order to reduce the need for bilateral operator agreements.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Phase 1: routing of the SIP request to the S-CSCF serving the originating party<br /><br /></div> <div> </div> <div>As described above, the P-CSCF removes any potential route defined by the IMS client and replaces it with a route to the S-CSCF serving the user in its home network. This route was defined during the IMS registration of the user, and may traverse an I-CSCF in case the home network wants to hide its network topology to the potential visited network (note that in practice a border gateway might be used instead).<br /><br /></div> <div> </div> <div style="font-weight: bold;">Phase 2: service profile -based routing for originating user<br /><br /></div> <div> </div> <div>The S-CSCF serving the originating party applies the service profile for the originating IMPU. This service profile consists of a list of initial filter criteria. It corresponds to the set of services the originating party is associated to. In practice, this means that the service route for the SIP request originated by John is defined by the operator and implemented by the S-CSCF.<br /><br /></div> <div> </div> <div>In this phase, the S-CSCF may route the SIP request to 0, 1 or several application servers (one after the other in a signalling chain or pipe).<br /><br /></div> <div> </div> <div>It is possible that one of the application servers terminates the SIP request (i.e. acts as a SIP User Agent). This may happen in three cases:</div> <div>1) The request was addressed to a PSI hosted by the application server (e.g. user tries to access content)</div> <div>2) The originating party issued a request addressed to itself, which was actually targeted at one of its services in the network. For instance, SIP requests that update the presence information of a user (PUBLISH for presence event package) are addressed to the user's own IMPU. Another example can be seen in <a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">the automatic service discovery and configuration</a> example I described in an earlier post.</div> <div>3) The application server terminates the request on behalf of the B-party. This may happen, for instance, with services that block traffic to unauthorized destinations. Another example could be the case where a service, potentially after having accessed the presence of the B-party, decides to transform an IMS instant message (SIP MESSAGE) into an email, an SMS, or an Internet IM. In this case, IMS SIP routing is terminated to be superseded by an alternative protocol outside of IMS.<br /><br /><span style="color: rgb(204, 0, 0);">Signalling path termination: the SIP interaction may terminate at phase 2 if one of the application servers decides to act as an endpoint for the SIP request.<br /><br /></span></div> <div> </div> <div><span style="color: rgb(153, 51, 153);"><span style="color: rgb(102, 0, 204);">IMS exit point: the SIP interaction may exit IMS at phase 2 if an application server serves as a gateway towards a different protocol/domain (e.g. email, SMS, MMS, Internet IM protocol). Note that phase 2 takes place before the IMS core network tries to route the SIP request based on the <span style="font-style: italic;">request-uri</span>. This means that the <span style="font-style: italic;">request-uri</span> might not be an IMS routable URI: it could be a URI specific to the protocol and/or domain to which the SIP request is actually targeted.</span><br /><br /></span></div> <div> </div> <div>In case no application server terminates the SIP request, the S-CSCF proceeds with the next phase.<br /><br /></div> <div> </div> <div style="font-weight: bold;">Phase 3: routing of the SIP request to the destination network<br /><span style="font-weight: normal;">The S-CSCF routes the SIP request according to its <span style="font-style: italic;">request-uri</span>.</span><br /><br /></div> <div> </div> <div>In case the <span style="font-style: italic;">request-uri</span> is a TEL URI, the S-CSCF may route the request to the circuit-switched network (see <a href="http://theimslantern.blogspot.com/2007/06/ims-public-user-identities-impus.html">previous post</a> - the request will be routed to the circuit-switched network when the TEL URI does not resolve into a SIP URI through ENUM).<br /><br /></div> <div> </div> <div>Through DNS, the S-CSCF may also determine that the domain of the <span style="font-style: italic;">request-uri</span> is resolved into a non-IMS network like the Internet.<br /><br /></div> <div> </div> <div style="color: rgb(102, 0, 204);">IMS exit point: the SIP request is routed outside of IMS by the IMS core network if it is a TEL URI that does not resolve into a SIP URI, or if it is a SIP URI whose domain is outside of the IMS (e.g. in the Internet).<br /><br /></div> <div> </div> <div style="font-style: italic;">Side comment: to come back to the possibility for an IETF SIP client to define by itself a route towards application servers... If it is not possible for an IMS client to define such a route, it is possible for an IMS application server to do it on behalf of the client. This route could binclude application servers in the Internet and could be provided by the IMS client to the IMS AS through signalling or self-provisioning.<br /><br /></div> <div> </div> <div>In case the B-party is an IMS user (same or different operator), DNS resolves the <span style="font-style: italic;">request-uri</span> to an I-CSCF of the target operator, that acts as an entry point to its network. The request may traverse an I-CSCF of the originating network, in order to hide the network topology to the destination network (note that in practice a border gateway might be used instead).<br /><br /></div> <div> </div> <div style="font-weight: bold;">Phase 4: routing of the SIP request to the S-CSCF serving the destination user<br /><br /></div> <div> </div> <div>Either the B-party is registered with IMS or not.<br /><br /></div> <div> </div> <div>If it is, the I-CSCF retrieves the location from the HSS and routes the request to the S-CSCF serving it.<br /><br /></div> <div> </div> <div>If it is not, there is a procedure to dynamically allocate an S-CSCF to the B-party and to route the request to this S-CSCF. The rationale is that the B-party's IMS services in the network might need to be reachable even when the B-party is not available (e.g. presence, a voice call continuity server that will route the call to the circuit-switched network, a call forwarding service).<br /><br /></div> <div> </div> <div>Alternative entry points to phase 4: instead of originating from the IMS and having followed phases 1 to 3, the request received by the I-CSCF may originate from the circuit-switched network (request is received from MGCF, i.e. signalling gateway with CS), or from a non-IMS network like the Internet.<br /><br /><span style="color: rgb(0, 102, 0);">IMS entry point: instead of an S-CSCF in the originating network, the request may come from the circuit-switched network (through an MGCF), or from a non-IMS SIP network (e.g. the Internet).</span><br /><br /></div> <div> </div> <div><span style="font-weight: bold;">Phase 5: service profile -based routing for the terminating user</span><br /><br /></div> <div> </div> <div>The S-CSCF serving the terminating party applies the service profile associated to the IMPU (or PSI) corresponding to the <span style="font-style: italic;">request-uri</span>. This service profile consists of a list of initial filter criteria. It corresponds to a set of services associated to the terminating party.<br /><br /></div> <div> </div> <div>In this phase, the S-CSCF may route the SIP request to 0, 1 or several application servers (one after the other).<br /><br /></div> <div> </div> <div>It is possible that one of the application servers terminates the SIP request (i.e. acts as a SIP User Agent). This may happen in two cases:</div> <div>1) The request was addressed to a PSI hosted by the application server (e.g. user tries to access content, user posts message in chat room). This is the case where an operator offers services to the world. Note that there exist alternative mechanisms to route a request to a PSI.</div> <div>2) The application server terminates the request on behalf of the B-party. This might be the case for presence (the request was addressed to the B-party but was actually aimed at its presence server) and any other service acting on behalf of the terminating party (e.g. voice call continuity, call or message blocking or forwarding services).<br /><br /></div> <div> </div><span style="color: rgb(204, 0, 0);">Signalling path termination: the SIP interaction may terminate at phase 5 if one of the application servers decides to act as an endpoint for the SIP request.<br /><br /></span> <div> </div> <span style="color: rgb(153, 51, 153);"><span style="color: rgb(102, 0, 204);">IMS exit point: the SIP interaction may exit IMS at phase 5 if an application server serves as a gateway towards a different protocol/domain (e.g. email, SMS, MMS, Internet IM protocol).<br /><br /></span></span><div> </div> <div><span style="font-weight: bold;">Phase 6: delivery to the terminating party</span><br /><br /></div> <div> </div> <div>In case there is still a SIP request to be delivered to a B-party, the S-CSCF routes the request to the P-CSCF(s) serving the B-party (there might be several in case several endpoints are registered with the same IMPU), which in turn contacts the device of the B-party.<br /><br /></div> <div> </div> <div><span style="font-weight: bold;">SIP requests issued by application servers</span><br /><br /></div> <div> </div> <div>This post essentially addressed the situation where the SIP request is initiated by an IMS client corresponding to an IMPU. However, to be complete, you also have to consider that IMS application servers are able to generate SIP requests, using either an IMPU or PSI as the originating party, and an IMPU or PSI as the <span style="font-style: italic;">request-uri</span>.<br /><br /></div> <div> </div> <div>When an AS issues a request with an IMPU as originating address, it is supposed to route it to an S-CSCF serving the IMPU. Starting with 3GPP R7, it is possible to allocate an S-CSCF to the IMPU even if it is not registered with IMS (i.e. the IMS AS issues a request on behalf of an IMPU which is not registered with IMS). IMS routing then proceeds with phase 2.<br /><br /></div> <div> </div> <div>When an AS issues a request using a PSI as the originating party, it may either reach a S-CSCF serving the PSI, or route the request directly to an I-CSCF for the terminating party. Depending on the case, IMS routing then proceeds with phase 2 (the service profile is associated to the PSI) or directly with phase 4.<br /><br />A specific case for having an IMS AS issuing a SIP request to the IMS is when it acts as a gateway towards another protocol and/or domain. This is the symetric case to what was described in purple for phases 2 and 5 above.<br /><br /></div> <div> </div> <div>Christophe<br /><br />There is no direct relationship to this post, but I just added the initial architecture proposed in 3GPP for the SCIM in <a href="http://theimslantern.blogspot.com/2007/05/standardization-scim-service-broker.html">the first post I wrote about it in May</a>.<br /></div><br /></basefont>Unknownnoreply@blogger.com42tag:blogger.com,1999:blog-4706138697725258507.post-32314071447885627252007-06-26T20:37:00.000+02:002007-06-26T21:54:11.996+02:00Public Service Identity Service Patterns<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_pjPCbrdQN1U/RoFuvV_8IJI/AAAAAAAAABU/rrdwaYfwDTE/s1600-h/PSI+Service+Pattern.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_pjPCbrdQN1U/RoFuvV_8IJI/AAAAAAAAABU/rrdwaYfwDTE/s400/PSI+Service+Pattern.png" alt="" id="BLOGGER_PHOTO_ID_5080463614288863378" border="0" /></a><br />In this post, I will try to present some potential usage of Public Service Identities (PSIs) for the delivery of IMS services.<br /><br /><div> </div> <div style="font-weight: bold;">Services to the World<br /><br /></div> <div> </div> <div>PSIs were standardized for this, but it might be useful to highlight it: PSIs permit an operator to provide services that are accessible from any SIP network.<br /><br /></div> <div> </div> <div>This means that the IMS Lantern chat room from <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">the previous post</a>, or any content identified through a PSI, is potentially accessible to all IMS subscribers of the world, whether their subscription is a fixed, mobile, cable, or converged one.<br /><br /></div> <div> </div> <div>This also means that the same service is accessible from non-IMS networks with SIP connectivity like the Internet.</div> <div><br /></div> <div style="font-weight: bold;">Combination of Private/Restricted and Public Access to a PSI<br /><br /></div> <div> </div> <div>The previous post might have given the impression that a PSI can either be accessed by a happy few or by everybody.<br /><br /></div> <div> </div> <div>Actually, this does not have to be. A PSI can be accessed in one way by a happy few, and in another way by all the others, and the way a PSI is accessed can determine the logic that is executed to process the corresponding SIP request in the IMS application layer.<br /><br /></div> <div> </div> <div>Private/Restricted access to a PSI is determined by the service profile associated to the originator of the SIP request addressed to the PSI (i.e. the service profile of the user includes one or several initial filter criteria that relate to the PSI and permit to route the request to an application server).<br /><br /></div> <div> </div> <div>What happens for users who initiate a SIP request to the PSI and do not have a PSI-aware service profile?<br /><br /></div> <div> </div> <div>The IMS core network will try to route the SIP request anyway, and then there are two cases:</div> <div>1) There is no way to match the PSI to a physical address, i.e. there is no service profile associated to the PSI, and it is not defined in any DNS (or ENUM) server or in the HSS. In that case, the PSI is really accessible by a happy few.<br /></div> <div>2) There is a "public" PSI routing mechanism, i.e. one of the three mechanisms described in <a href="http://theimslantern.blogspot.com/2007/06/ims-public-service-identities-psis.html">the previous post</a>. In that case, the PSI is also accessible to everybody. The public access mechanism may route the request to another application server or to the same one as the private/restricted access procedure. In any case, it is possible for an application server to determine how the SIP request was routed to the application server (i.e. either as an originating or a terminating request), and consequently to apply a different logic for each case.<br /></div> <div><br /><span style="font-weight: bold;">Automatic Service Discovery and Configuration<br /><br /></span></div><div> </div> <div>I already gave an example of this mechanism with <a href="http://theimslantern.blogspot.com/2007/04/service-pattern-automatic-service.html">the automatic service discovery and configuration service pattern</a>. In this example, John is subscribed to Service X, and consequently benefits from the restricted access configuration information associated to the service. His girlfriend Mary is not subscribed to Service X. If she issues a request addressed to <span style="color: rgb(0, 0, 153);">sip:ServiceX@operator.com</span> in order to retrieve service X's configuration information, the request will be routed to an alternative service logic, which will deny access to the information.<br /><br /><span style="font-weight: bold;">Restricted Access for Management of Public User Groups<br /><br /></span></div> <div> </div> <div>Another example would correspond to a user group identified by the PSI <span style="color: rgb(0, 0, 153);">sip:Friends_of_IMS@operator</span>.<br /><br />Anybody can use this PSI to send an instant message to members of the group, access their presence information, or start a multimedia session with them (public access to the PSI). All these services are accessed through the initiation of an adequate SIP request addressed to the PSI (i.e. MESSAGE, SUBSCRIBE for presence event package, INVITE). Routing to the relevant application server is based on the service profile associated the PSI (i.e. MESSAGEs go to messaging server, SUBSCRIBEs for presence event package go to the resource list server, INVITEs go to the multimedia conferencing server).<br /><br />On the other hand, only a few users can manage the user group, i.e. add/remove users to it. This implies that SIP requests that permit to access and modify the definition of the user group (SUBSCRIBE, PUBLISH for a group management event package) are restricted to a limited set of people. These people will have their service profile defined in such a way that their management requests to the <span style="color: rgb(0, 0, 153);">sip:Friends_of_IMS@operator</span> PSI will be routed to the application server managing the user group. The same management requests issued by a non authorized user will not be routed to any application server and will be rejected by the IMS core network (the service profile associated to the PSI does not define any routing for PUBLISH and SUBSCRIBE requests related to the group management event package).<br /><br /><span style="font-weight: bold;">Differentiated Access to Content (see figure, click to enlarge)<br /><br /></span></div> <div> </div> <div>The third example is illustrated by the picture at the top. The PSI<span style="color: rgb(0, 0, 153);"> sip:This_Content@operator</span> identifies a specific content (e.g. a video) that can be accessed through a SIP session initiated by the user.<br /><br /></div> <div> </div> <div>Four application servers serve the same PSI.<br /><br />A and B serve the subscribers of the operator who are authorized to access the content. Access to these application servers is based on the service profiles associated to each subscriber. The service profiles associated to subscribers in the partition #1 route the service request to A, while service profiles associated to subscribers in the partition #2 route the service request to B. Service logic on A and B delivers the content.<br /><br /></div> <div>C serves the subscribers of the operator who are not authorized to access the content. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is the one of the operator shall be routed to C. The service logic on C may show a preview of the content and propose the user to subscribe to the content.</div> <div><br />D serves subscribers of other operators and users from the Internet. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is not the one of the operator shall be routed to D. The service logic on D may propose the user to pay for viewing the content.<br /><br />It would be possible to further discriminate between users trying to access the content. For instance, the service profile associated to the PSI could determine that SIP requests which do not include a <span style="font-style: italic;">P-Asserted-Identity</span> header (i.e. requests originated from a non-IMS network) should be routed to an application server E.<br /><br /></div> <div> </div> <div>Christophe</div>Unknownnoreply@blogger.com10