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.
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.
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.
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.
Contact me at cgourraud@yahoo.ca 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).
Here follows a description of the course. You can also request from me a slightly more detailed powerpoint content description.
Part 1: The IMS Service Architecture
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).
Standardized topics include:
- Overview of the architecture
- IMPUs & PSIs
- ISC usage scenarios & examples
- Details of ISC
- Service profiles and initial filter criterias (iFCs)
- OSA SCS / IM SSF / SIP AS
- MRFC/MRFP
- SCIM & Service Broker
- IMS Communication Services
- User Data Management (Sh, OMA XDM, GUP)
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:
- Multimedia sessions
- Event packages
- Routing alternatives (SIP forking, callee capabilities/caller preferences), GRUUs)
- Support of Group Services
- Combination with other protocols (content indirection, SIP REFER, SIP session, body in SIP message)
- Interoperability aspects (between SIP profiles, between SIP and other protocols)
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:
- Service composition
- Logic mutualization
- Personalization / Differentiation of user experience
- Simple access to services
- Service flexibility / agility
- Authorization to services
- Unlimited service scalability
- Multi-vendorship / Differentiation for each service
- Service anthropomorphism
- Usage of a single identity for multiple services
Part 2: IMS standardized services and enablers
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.
User data services & enablers:
- Presence (IETF, 3GPP, OMA specifications)
- Group Management / Group Services
Voice oriented services & enablers:
OMA Push To Talk Over Cellular (Poc) V1 and V2
3GPP Combining circuit-switched and IMS services (CSI)
3GPP Voice Call Continuity (VCC)
3GPP/TISPAN Multimedia Telephony (MMTel)
3GPP IMS Centralized Services (ICS)
3GPP Conferencing
Messaging services & enablers:
OMA SIP Push
Messaging (IETF IM, 3GPP IMS Messaging, OMA SIMPLE IM)
3GPP SMS over generic IP access
OMA Converged IP Messaging (CPM) - Messaging part
Multimedia services & enablers:
OMA Converged IP Messaging (CPM) - Multimedia part
TISPAN IPTV
This part ends with a description of the Rich Communication Suite (RCS) initiative
Part 3: Opportunities & Challenges
This final part addresses essential topics which go beyond IMS specifications.
It is structured around the following topics:
- Fixed Mobile Convergence (from technical to user oriented convergence: opportunities and challenges)
- Which role(s) for the operators (e.g. bitpipe provider, intelligent pipe/channel provider, service provider with more or less control)
- Exploiting IMS Capabilities (e.g. User Oriented Architecture, Distributed Service Architecture, need for optimizing the IMS service architecture)
- Service Platforms (e.g. black boxes vs. open platforms, JAIN SLEE, J2EE)
- 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)
Christophe
Tuesday, April 15, 2008
Wednesday, April 9, 2008
3GPP Communication Services
In the past, I had the opportunity to write three posts (here and there and there) 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.
Definition
According to TS 23.228, "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."
Examples of Communication Services are OMA Push To Talk over Cellular (PoC) or OMA SIMPLE Instant Messaging (also called IMS Messaging in 3GPP specifications).
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.
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:urn-xxx:3gpp-service.ims.icsi.mmtel (Multimedia Telephony).
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: g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-application.ims.iari.game-v1". 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.
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.
The IETF draft 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.
What Communication Services could have been
The company which introduced the concept of Communication Service in 3GPP had a quite radical proposal of how it would be used:
- 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.
- 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.
- 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.
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.
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.
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.
General benefits of Communication Services
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 a la carte is what has been specified.
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.
But first, let us consider the aspects of Communication Services that may appeal to all operators.
Communication Services can make the life of operators easier in some aspects.
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.
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.
Passed these basic, different handling of communication services are possible, which map to different strategies.
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).
Communication Services for advanced user control
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.
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.
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).
More liberal usages of Communication Services
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.
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.
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, de facto inhibiting its restrictive processing.
Interoperability with non-IMS cients
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 callee capabilities) 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 caller preferences), 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).
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.
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.
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 "explicit" and "require" 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).
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.
Potential issues with ICSIs
To be used for advanced control, ICSIs require additional provisioning in the service profile of the user (HSS) as well as in IMS clients.
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.
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.
Any future for Communication Services used for control?
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.
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).
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.
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.
Christophe
References:
Definitions and requirements: TS 23.228 chapter 4.13
Detailed procedures by IMS client: TS 24229 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)
Detailed procedures by S-CSCF: TS 24.229 chapter 5.4.3.2 (originating requests), 5.4.3.3 (terminating requests)
Communication Services in Service Profiles: TS 29.228 Appendix B (B.2 and B.2.1A)
Definition
According to TS 23.228, "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."
Examples of Communication Services are OMA Push To Talk over Cellular (PoC) or OMA SIMPLE Instant Messaging (also called IMS Messaging in 3GPP specifications).
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.
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:urn-xxx:3gpp-service.ims.icsi.mmtel (Multimedia Telephony).
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: g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-application.ims.iari.game-v1". 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.
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.
The IETF draft 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.
What Communication Services could have been
The company which introduced the concept of Communication Service in 3GPP had a quite radical proposal of how it would be used:
- 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.
- 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.
- 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.
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.
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.
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.
General benefits of Communication Services
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 a la carte is what has been specified.
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.
But first, let us consider the aspects of Communication Services that may appeal to all operators.
Communication Services can make the life of operators easier in some aspects.
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.
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.
Passed these basic, different handling of communication services are possible, which map to different strategies.
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).
Communication Services for advanced user control
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.
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.
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).
More liberal usages of Communication Services
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.
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.
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, de facto inhibiting its restrictive processing.
Interoperability with non-IMS cients
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 callee capabilities) 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 caller preferences), 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).
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.
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.
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 "explicit" and "require" 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).
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.
Potential issues with ICSIs
To be used for advanced control, ICSIs require additional provisioning in the service profile of the user (HSS) as well as in IMS clients.
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.
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.
Any future for Communication Services used for control?
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.
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).
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.
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.
Christophe
References:
Definitions and requirements: TS 23.228 chapter 4.13
Detailed procedures by IMS client: TS 24229 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)
Detailed procedures by S-CSCF: TS 24.229 chapter 5.4.3.2 (originating requests), 5.4.3.3 (terminating requests)
Communication Services in Service Profiles: TS 29.228 Appendix B (B.2 and B.2.1A)
Thursday, April 3, 2008
IMS Service Anthropomorphism
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.
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.
Symetric usage of SIP between IMS users and IMS services
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.
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.
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.
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.
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.
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.
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.
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).
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?
Service impersonating a user
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.
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.
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.
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").
Service acting as itself
A service can also receive requests addressed to a PSI that identifies itself, or generate a request using its own PSI as the originator.
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).
Group Management
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.
An IMPU and a PSI have the exact same formats (either a SIP URI or a TEL URI).
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.
Associating services to services
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).
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).
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.
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 sip:MyFamily@operator.com, 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 sip:MyFamily@operator.com 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. sip:MyFamily@conferencing.operator.com). 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.
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.
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.
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. sip:TheIMSLantern@operator.com) 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.
To conclude...
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.
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.
Christophe
Subscribe to:
Posts (Atom)
Stumble It!
