Service Pattern: Automatic Service Discovery & Configuration

In this post I will describe a potential IMS service pattern that I presented in a couple of IMS conferences last year.

Overview

John can access IMS services from a set of fixed and mobile devices, including his mobile phone, his TV set at home, his PC, his fixed phone, and his MP3 player.

When connecting a device to IMS (either automatically or manually, depending on the device), the IMS client automatically retrieves from a service registry in the network the list of services John is authorized to access. These services may either be IMS services (i.e. services accessed through SIP) or non-IMS services, like streaming content.

When a new service is made accessible to John (through subscription, for a promotional offer, for free), the service registry is automatically updated and the update is automatically notified to all of John's currently registered devices (for the others, it will be the next time they register to IMS).

If a new service requires specific client update or configuration, the task is automated as well.

Mary cannot access the same set of services and associated configuration information.

Discovery of Services

John's client issues a SIP SUBSCRIBE which both originates from and is addressed to John's Public Identity (e.g. sip:John@operator.com) for a relevant event package (IETF-defined "UA Profile" event package might do it).

As the SIP request originates from John, it is routed to the S-CSCF that serves him. The service profile associated to sip:John@operator.com determines that a SUBSCRIBE originated from John, addressed to John, and whose event package is "UA Profile" shall be routed to John's service registry.

Upon the receipt of the SUBSCRIBE, John's service registry issues a NOTIFY as an answer. The SIP NOTIFY may either transport in its body an XML document including the service list, include an HTTP URI to John's service portal (accessed through content indirection), or both.

Each and every one of John's devices can issue the same request and discover the service. It is possible that differences exist between the list, based on the device, its capabilities or the configuration of each service.

Automated Discovery of New Services

John gets authorization to access a new service.

This service might be accessible through IMS and SIP or not, this is not the point. The point is that the discovery of this service is integrated in the automatic service discovery process, which is based on IMS.

Upon provisioning of relevant subscription information, the application server hosting the service for John issues a SIP PUBLISH for the "UA Profile" event profile. The PUBLISH may either originate from the service's Public Service Identity (e.g. sip:serviceX@operator.com) or from John's identity (sip:John@operator.com), and it is addressed to John.

Because it is addressed to John, the request reaches an S-CSCF serving this user. John's service profile determines that a terminating PUBLISH for the "UA Profile" event package addressed to John shall be routed to John's service registry. John's service registry updates the list of available services.

Then, the service registry issues a SIP NOTIFY towards all of John's devices, which currently have an active subscription to the "UA Profile" event package (i.e. they are monitoring the service registry). These devices automatically and instantly discover the new service (either directly in an XML document or through new content indirection). Other devices will discover it the next time they subscribe to the "UA Profile" event package.

Automatic Service Configuration

In order to be fully usable, the new service must be configured in the device(s), some software components might also need to be downloaded in the client. Details may vary depending on the device.

The new service entry in John's service registry includes information such as a description of service X, means to access it (e.g. HTTP URI, IMS PSI, RTSP URI, application-specific information), and means to configure/update the client if needed. This latter part includes a PSI to be used to access service X configuration information in the network. This PSI might be the same as the one to access the service, in case the service is accessed through a PSI, but it may also be specific to service configuration, more especially if the service itself is not accessed through SIP.

In order to retrieve service configuration information, John's client issues a new SUBSCRIBE for the "UA Profile" event package. This SUBSCRIBE still originates from John, but this time is addressed to the service configuration PSI as included in the service registry (sip:serviceX@operator.com).

The SIP SUBSCRIBE is routed to the S-CSCF serving John. John's service profile determines that a SUBSCRIBE for the "UA Profile" event package, originated by John and addressed to sip:serviceX@operator.com shall be routed to the application server hosting service X for John. This entry in John's service profile was provisioned when John received authorization to access service X.

The application server issues a NOTIFY as an answer, with either relevant service configuration information transported in the body, or an HTTP URI to access it through content indirection.

John's client then receives relevant configuration information and gets ready to access the service. It may use any relevant protocol(s) for it.

What about Mary?

Mary will use the same mechanisms to discover and configure her own services. Mary's identity used in SIP signalling will permit her to access her own service registry and her own services.

In case Mary's client would issue a SIP SUBSCRIBE for the "UA Profile" event package, which is addressed to sip:John@operator.com, the SUBSCRIBE would first reach the S-CSCF serving Mary. Mary's service profile would not determine that such a request addressed to John can reach any of Mary's application server. The IMS core network would then try to proceed with routing of the request. As it is addressed to John, it would then reach an S-CSCF serving John. John's service profile could then determine that the request, as it was not originated by John, should be routed to an application server addressing all inappropriate requests (and possibly reporting them to John and/or the operator). In this case, John's service profile determines that this request, because it is originated by Mary, will reach John's service registry, as Mary is authorized to access it. The registry then provide Mary with a set of John's services (which might be a "guest" view on a subset of John's services, rather than the full set).

Would Mary's client issue a SIP SUBSCRIBE for the "UA event package" addressed to sip:ServiceX@operator.com while she is not subscribed to service X, the request would not be routed to the application server hosting the service through Mary's user profile. As Mary is not subscribed to Service X, her service profile does not include corresponding service routing information. The network would then try to route the request somewhere by trying to resolve the sip:ServiceX@operator.com address. There might then be two cases: either the address does not map to any destination (e.g. no DNS entry) or it does map to one, thanks to a DNS entry or because the service X's PSI has a service profile. If the address is not resolvable, the request will be rejected by the IMS core network and Mary will receive an appropriate error response. If the address maps to an application server, the hosted application knows that the request is coming from a non-authorized user (it did not reach the AS the way an authorized request would). The application server can then provide a polite answer to Mary stating the reason why the request cannot be processed, or it could simply invite Mary to subscribe to the service and redirect her to a subscription web page. Mary could then subscribe to service X, discover it through her service registry, etc.

In the next post, I will come back on this example and underline some of its features.

Christophe

PS: I have a powerpoint presentation which describes this example with graphics. It was publicly presented and can be sent out. Just drop me an email.