Does IMS Create a New Walled Garden?

Definitly no!

IMS was made from the begining to permit end-to-end SIP signalling between IMS and non-IMS endpoints, and if the non-IMS endpoint does not support SIP, the IMS service architecture permits an easy integration of protocol gateways.

Wikipedia defines a walled garden as follows: A walled garden, with regards to media content, refers to a closed set or exclusive set of information services provided for users (a method of creating a monopoly or securing an information system). This is in contrast to providing consumers access to the open Internet for content and e-commerce.

I have seen in surveys that many operators believe that IMS will permit them to create a new walled garden, and they like the idea very much, even defining it as one of the main advantages of IMS.

But this is not the case, and in this post I will try to clarify some points related to this, as well as give examples of how 3GPP always intended to keep IMS open to non-IMS networks, and more especially the Internet.

I think that creating new walled gardens is not a strategy that will be sustainable for operators in the years to come. Concerning IMS, I believe that the extent of its eventual success will be proportional to the traffic generated between it and the Internet. An IMS with very low traffic to and from the Internet would be an IMS which has failed to deliver any added value to end-users, who would bypass it to directly access services in the Internet. On the other hand, high traffic would means that IMS is integrally part of the place where everything happens.

3GPP IETF Dependencies List

3GPP maintains a long list of dependencies on IETF specifications. Some may interpret it as the sign that IMS is full of telco-specific extensions to the IETF protocols it uses (mainly SIP and Diameter).

This would be totally wrong. 3GPP essentially reuses specifications elaborated within the IETF space. Moreover, more often than not, IMS has been an essential driver to improve and extend SIP-related specifications in the IETF. Without the push from the whole telco industry, I doubt the IETF SIP community would be as dynamic as it is.

The reason for this list is that it is essential for 3GPP specifications to be based on stable RFCs, and not drafts that have an expiration time and may once simply disappear. The list permits 3GPP to clearly identify the IETF drafts that are of importance for IMS, and to speed up their progress towards RFC status.

IMS Proprietary SIP Extensions

In the course of standardizing the IMS core network, 3GPP created new SIP headers, and submitted them for endorsement to the IETF.

Some extensions were accepted, as they were deemed to be useful to all types of SIP implementations. Others, related to e.g. user authentication, QoS, or charging were harder to swallow and led to very harsh discussions. Most of these extensions are directly related to the fact that, unlike the Internet, IMS is a network of privately owned networks, whose usage is supposed to involve money exchanges.

Between 3GPP, which wanted to have IETF RFCs for all IMS SIP extensions, and IETF hardliners, the following compromise was found: the questionable IMS SIP extensions would be specified in IETF RFCs, but they would have a specific "proprietary" status, meaning that their usage is not recommended for general SIP usage. These headers are easy to recognize, as their name starts with "P-".

These P- headers do not threaten end-to-end interworking with non-IMS clients:

- Many of them are used between IMS network entities, and are invisible to IMS or SIP endpoints

- Some might be visible to non-IMS endpoints, but the endpoint does not absolutely need to understand them

- Gateways between IMS and the Internet may perform relevant SIP adaptations, if needed.

IMS specifications explicitly support session setup with non IMS endpoints

In order to offer a user experience that matches the one in a circuit switched network for a voice or video session, IMS adopted a session setup model which is more complex than the basic IETF SIP one. This extended session set up is also possible in the Internet, as it does not make use of any 3GPP-specific extension, but it is only optional and may not be supported by all SIP clients.

3GPP then started a study to address the issue of interworking between IMS-compliant clients and clients that would not support the optional features required by IMS session setup. This resulted in the requirement specified in chapter 5.4.2 of TS 23.228 named "Interworking with Internet" that an IMS client (or a user agent in the network acting on its behalf) must be able to fall back to basic SIP session setup procedures, if the peer cannot support the IMS-required extensions.

IMS Communication Services

In the course of its Release 7, 3GPP defined the concept of "communication service". I will not describe it here, but it is enough to say that some of the requirements associated to Communication Services could possibly lead to the creation of IMS walled garden services.

In order to avert this risk, the following requirements were added to the concept:

- The usage of communication service identifiers shall not adversely affect interoperability between IMS networks and interoperability with external SIP networks and CS networks

- The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

All IMS enablers rely on IETF specifications, and can be implemented in the Internet

This might need to be emphasized.

There is not such a thing as an IMS-specific presence, IMS-specific conferencing or IMS-specific messaging. These enablers and services are implemented in IMS with a specific service architecture, but the protocol(s) and data model(s) used are standard IETF ones.

A small issue is that, thanks to OMA or 3GPP, some IMS services may be associated with explicit OMA or 3GPP names (feature tags) transported in SIP signalling. For instance, IMS messaging as currently specified in OMA makes use of an OMA specific feature tag. This might require some simple SIP adaptation between IMS and non-IMS networks, or the understanding of IMS-specific feature tags by non-IMS client, but this is a minor thing. In any case, I hope that the industry will eventually realize that these OMA/3GPP names should not even exist.

Simple Addition of Protocol / Domain Gateways to IMS

The IMS service architecture makes very simple to deploy protocol converters and gateways, without the need for any specific standardization. Any SIP message originated from or addressed to a user can be routed to such a protocol converter/gateway through the user's service profile provisioned in the HSS. The message can then be routed to any domain using any protocol. Conversely, these converters/gateways can generate IMS-compliant signalling from anything they receive.

It is even possible for an IMS client to use non-SIP user addresses in its SIP messages. For instance, John may issue a SIP/IMS Instant Message towards Mary, whose IM service is not based on SIP and whose IM address is not a SIP or TEL URI. The IMS client could address the IM to e.g., foo:Mary. The address is not routable in an IMS network but this is not an issue. John's request is first routed to an IMS S-CSCF serving John. The S-CSCF then checks John's service profile. The important thing is that the network still not has checked if foo:Mary was an IMS-valid address. John's service profile may define that a request addressed to a user with an addressing scheme "foo:" should be routed to an IM gateway, which will take care of the rest. This is only after, if no gateway was accessed through John's service profile, that the S-CSCF would look into recipient's address, realize that there is a problem, and would therefore reject it.

Christophe

IMS Service Interaction Use Cases: Part 2

The last post presented 6 IMS service interaction use cases, which all had in common the fact that the initiator of the interaction was a client, typically a mobile handset or a PC soft client.

It is now time to consider service interactions initiated by an application server, as an IMS AS can support all the roles possible for a SIP entity, including the SIP User Agent (or client). This means that every SIP message generated or processed by an IMS client can also be generated or processed by an IMS application server. Consequently, you can take all the use cases described in the previous post, replace the client with an Application Server, and see if it makes sense. Alternatively you can keep on reading this post.

A preliminary question is: if a service on an application server can generate SIP messages, under which identity can it do it? There are two possibilities:
1) The service initiates the message under its own identity, which is a Public Service Identity (see previous post).
2) The service initiates the message under the identity of a user it serves, i.e. the service impersonates the user and acts on its behalf. This is acceptable because the application server is within the IMS security domain and under the control of the operator.

#7 John's service initiates interaction with John

The SIP message may be used to contact John himself or an application residing in a device associated to John. It may be targetted to any device or to a specific one. In this latter case, the service will use a Globally Routable User Agent URI (GRUU).

Service examples:
- Content push (SIP method can be MESSAGE, INVITE, REFER or PUBLISH)
- Deferred delivery of a stored message (SIP method can be MESSAGE or INVITE)
- Monitoring of user/application activity, e.g. is the user in a session? Is this application running? (SIP method is SUBSCRIBE)
- Access to local device information, e.g. what are the locally installed application? (SIP method is SUBSCRIBE)
- Initiation of stimulus based service control, i.e. user enters commands through typing on the keyboard or touching screen areas, the stimuli are translated into Keypad Processing Markup Language (KPML) and sent to the application for interpretation (SIP method is SUBSCRIBE, KPML semantic is tansported in NOTIFYs)

#8 John's service initiates interaction with Mary

This is basically the same as #7, except that the service is not associated to the user it interacts with and may even be from a different operator's domain. This is, a service offered by operator X can interact with a user or an application residing in a device of a user subscribed to operator Y.

For this kind of cross-user and potentially cross-domain service interaction, the service should act on behalf of the user it serves (John), so that identification and authorization can be performed adequately. Otherwise, the risk is that John's service, perceived as a total stranger from Mary's side, is authorized to very little if anything.

Service examples can be the same as for #7, except for deferred delivery messaging, which a priori makes sense only for an interaction between a service and the user it serves.

#9 John's service initiates interaction with another of John's services

Either acting with its own identity or on behalf of John, the service initiates a service interaction which is routed through the IMS service architecture to another application server hosting another of John's services.

This use case introduces the possibility for services associated to the same user to collaborate together using SIP, or to put it differently, for an IMS service to use another as an enabler. One can wonder why two IMS services would use SIP to interact when web services and SOA are just made for this. There can be several good reasons for this, including the fact that, as IMS applications, they naturally support SIP and they are just reusing an interface that has been defined for a client to application server usage. More especially, the enabling application will process a request from the requesting application just like it would process a request coming from an IMS client.

Service examples:
- John's session termination agent uses John's presence to decide how to process an incoming session attempt (SIP method is SUBSCRIBE)
- One of John's services issues a message to a group identifying a set of John's buddies. The second service is responsible for "exploding" the message distribution list to each of the intended users (SIP message is MESSAGE or INVITE)
- A service starts a conference call on behalf of John. The second service is the controller for the conference (SIP message is INVITE or REFER).
- One of John's services currently used by John automatically updates John's presence on his behalf (SIP method is PUBLISH)

#10 John's service initiates interaction with one of Mary's services

This use case is to #9 what #8 is to #7. John's service uses Mary's one as an enabler, and both can be located in different domains. Once again, John's service is likely to impersonate John in order for Mary's service to apply authorizations that are associated to John.

Service examples:
- An intelligent message routing service for John accesses Mary's presence to determine what is the best messaging mechanism to contact Mary (e.g. IMS messaging, SMS, MMS, email) right now or to send the message to all possible addresses associated to Mary (SIP method is SUBSCRIBE)
- A phone book service for John automatically retrieves all relevant contact information from Mary by quering her presence and/or other accessible information (SIP method is SUBSCRIBE)

Additional application server to application server use cases could be added, in which either the initiating or the recipient application server is located in the Internet. The use cases would be equivalent to those above, except that they could come with limitations essentially related to user authentication and end-to-end security (e.g. can the IMS application server trust the identity claimed by a request from the Internet?).

Believe or not, I am still not finished with IMS service interaction use case examples. The first 10 ones are simple peer-to-peer interaction use cases, using devices and application servers as peers. The next post will present use cases where application servers are inserted between peer-to-peer service interactions.

Christophe

IMS Service Interaction Use Cases: Part 1

In this post I will start to list some types of SIP interactions that are possible in an IMS architecture between service-related entities, i.e. devices and application servers in the network.

First, you need to know that there exist two types of identities in IMS:
- Public User Identities (IMPUs) are SIP URIs (sip:user@domain) or TEL URIs (tel:+3312345) that identify users.
- Public Service Identities (PSIs) are SIP URIs (sip:service@domain) or TEL URIs (tel:+3354321) that identity services, service features or user groups.

Now, based on standard 3GPP and SIP routing procedures, as well as the IMS service architecture based on service profiles stored in the HSS (see previous post), the following use cases are possible.

#1 John accesses a network-based IMS service he is subscribed to

The service may be explicitly identified via a PSI, or may implicitly be identified by the content of the SIP message (e.g. the message is a PUBLISH, it has a header called "event:" with the value "presence"). In this latter case, the SIP request is likely to be addressed to John himself (self-addressing).

John is a subscriber of the operator offering the service. He may be roaming or not.

Routing to the application server hosting the service is based on John's service profile in the HSS, and the fact that John originated the SIP service request.
This service routing mechanism ensures that John is authorized to access the service. If not, the service profile would not route the request to the application server. Other SIP routing mechanisms would then be used, which would either route the request to an Application Server handling non-authorized requests, or would reject the request if the target address cannot be resolved to an IP address.
It also ensures that the routing to the Application Server can be specific to John and different than the one for another user.

Service examples:
- John publishes new presence information (SIP method is PUBLISH)
- John discovers the services he is subscribed to (SIP method is SUBSCRIBE)
- John records a greetings message for his multimedia mailbox (SIP method is INVITE)
- John starts a Video on Demand session (SIP method is INVITE)
In all cases, John must be authorized to access the service. In the first three cases, the service is personal to John (John's presence, John's service registry, John's mailbox). In the last case, the service can be shared with others (VoD).

#2 John accesses a public network-based IMS service

The service must be explicitly identified via a PSI.

John might be a subscriber of the operator offering the service. He may alternatively be the subscriber of another operator, or simply a user accessing the service from the Internet.

The routing of the SIP request is based on the resolution of the PSI to an application server hosting the service. Either the PSI has a DNS entry, or the PSI is associated to a service profile in the HSS which determines that some SIP messages addressed to it have to be routed to this AS.

Service examples:
- Public news service (SIP method might be SUBSCRIBE or INVITE)
- Pay per view Video on Demand (SIP method is INVITE)
- Discussion Forum (SIP method is INVITE for messaging session)

#3 John accesses a network-based IMS service his girlfriend Mary is subscribed to

John might be a subscriber of the operator offering the service. He may alternatively be the subscriber of another operator, or simply a user accessing the service from the Internet.

The service is implicitly identified by the content of the SIP message, which is addressed to Mary. For instance, the SIP message might be a SUBSCRIBE addressed to Mary, which has a header called "event:" whose value is "presence".

The routing of the SIP message is based on the service profile associated to Mary in Mary's operator network and the fact that the request is terminating to Mary.

Service examples:
- Access to Mary's presence (SIP method is SUBSCRIBE)
- Access to Mary's user groups definitions (SIP method is SUBSCRIBE)
- Update of John's information in Mary's phone book (SIP method is PUBLISH)
These service requests are typically subject to authorization from Mary.

#4 John accesses a client-based IMS service from Mary

As the service is client-based, it might either be offered by the operator(s) of John and Mary, or by other service providers.

The service is implicitly identified by the content of the SIP message, which is addressed to Mary. For instance, the SIP message is an INVITE, and its session descriptor and/or a specific feature tag in the SIP message identifies a game.

Both John and Mary might be roaming.

The routing of the SIP message to Mary's devices is based on standard SIP routing procedures, possibly with forking and more sophisticated target determination mechanisms, in case Mary is reachable on multiple devices.

Service examples:
- Voice call (SIP method is INVITE)
- Multimedia session (SIP method is INVITE)
- Gaming session (SIP method is INVITE)
- Paul's checks if Mary is currently in a session (SIP method is SUBSCRIBE)

#5 John accesses a service located in one of his devices/servers connected to IMS

The service is located in a device or a server that belongs to John and is connected to the IMS network like an IMS user. It could also be accessible through the Internet. It might be offered by John's operator or by another service provider (possibly John himself).

The service is addressed through an identity perceived as a user identity from the IMS network. In a typical case the device or server is registered through John's identity. John therefore issues a SIP request addressed to himself, which will be routed to the device/server through normal SIP routing procedures. In order to route the request to a specific client (and avoid forking procedures), the request is likely to be addressed to the Globally Routable User Agent URI (GRUU) associated to the device or server. The GRUU permits to explicitly identify a device associated to the user.

Service examples:
- John retrieves a secured HTTP link to access private information on his PC (SIP method is SUBSCRIBE, uses the fact that IMS is a secured network and that John's identities are asserted both on the client and the server)
- John programs Windows Media Server to record a specific program (SIP method is PUBLISH)

#6 John accesses a service located in the Internet

The service might be explicitly identified by the SIP URI (kind of PSI) or might be implicitly identified in the SIP message, which is addressed to an Internet user.

The routing of the SIP message to the Internet is based on standard SIP routing procedures applied by the IMS core network.

Service examples:
- Access to presence located in the Internet (SIP method is SUBSCRIBE)
- VoIP session with Internet client
- Chat/IM with internet client

More use cases in the next post...

Christophe