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)

18 comments:

Anonymous said...

Hi,

I'm Alisha from Wowzio, and I'm excited to tell you about our new widget platform that helps bloggers increase readership by providing engaging widgets containing your blog's rich content. You can check out widgets customized for your blog here:

Wowzio Widgets for your Blog

I wanted to reach out to you to ask for your feedback on these widgets (feel free to install them on your blog, if you feel they are a good fit). I'm sorry for leaving this message via a comment, it's not at all our intent to spam you ( which is why i'm leaving this comment on an older post and you can always remove this comment ). Again, we would love to hear your feedback.

Thanks,
Alisha Wright
alisha.wright1@gmail.com

Jack Chrysler said...
This comment has been removed by the author.
Anonymous said...

Cool blog as for me. I'd like to read something more concerning this theme. The only thing I would like to see here is some pictures of some gizmos.
Katherine Watcerson
Phone jammers

Viagra Online said...

Communication services is fabulous, especially because ti can be use for all operators, and the other systems no have this quality. it's a great technological advance.

Costa Rica Doctors said...

I have read many articles about this topic but this is unique is very interesting and it has a lot of good information of profit for me... Well keep doing that good job thanks for all..

Buy Zenegra said...

I'd like to read something more concerning this theme. The only thing Generic Viagra,Kamagra,Edegra I would like to see here is some pictures of some gizmos.
Katherine Watcerson.

viagra online said...

Hello really I like your blog.... it's an excellent blog post found here...

Polly said...

Really useful material, lots of thanks for your post.

Anonymous said...

[url=http://www.cheaptimberlandboot1973.com]timberland boots sale[/url] cwoopv http://www.cheaptimberlandboot1973.com [url=http://www.cheaptimberlandbootssale.com]timberland boots sale[/url] kwcild http://www.cheaptimberlandbootssale.com [url=http://www.cheaptimberlandbootsmen.com]cheap timberland boots[/url] lxdiec http://www.cheaptimberlandbootsmen.com [url=http://www.cheaptimberlandbootoutlet.com]timberland boots sale[/url] adiltq http://www.cheaptimberlandbootoutlet.com [url=http://www.saletimberlandboots.org]cheap timberland boots[/url] pbxbzp http://www.saletimberlandboots.org o

Anonymous said...

Hi I was searching for the blogs for many times, now I have reached at the right place.
lookup service

website designing company said...

This is all very helpful for me and this article really opened my views,keep it!

Web Development Company said...

Hi its Really Amazing Articles you are Sharing thanks For sharing this Articles

Netsuite Partners said...

This is Wonderful Great services.. I am impressing Thanks.

Unknown said...

Thanks for sharing the information. It is very useful for my future. keep sharing. Can you play more games at: Friv | Kizi 4 | happy wheels game

Louis Martin said...

Voice Over Services
Thank you for sharing such useful information for voice services.

Louis Martin said...

Voice Over Services

Hey thanks for wonderful post.

Ancy merina said...
This comment has been removed by the author.
Copy Call said...

Thank you for this incredibly amazing blog. This is the right place where there is something for everyone! Thanks for sharing this post..!! Virtual Voicemail Phone Numbers for sale