Many of these features directly relate to what I consider to be the fundamental trait of the IMS service architecture: its user orientation.
The power of SIP
The example permitted to exhibit two important features of the SIP protocol, that I have already presented:
- SIP event packages can be used to distribute information and event notifications in a SIP network.
- Content Indirection is a privileged way to combine SIP and other protocols for e.g., redirecting a user to a web page (a service portal in the example), or retrieving large volume data (e.g. the content of the service registry).
User-based Service Routing
The SIP request that permits John to retrieve information from his service registry is routed to the right destination thanks to the following criteria: the request originated from John, it is addressed to John, and it happens to be a SIP SUBSCRIBE for a specific event package. Would one of these criteria be missing, the request would be routed elsewhere.
Similarly, the request that permits John to retrieve configuration information for service X is routed to the right server because it was originated from John, it is addressed to service X, and this is a SIP SUBSCRIBE for a specific event package.
Concerning Mary's request to access John's service profile, the routing is based on the fact that the request is addressed to John and does not originate from him. The fact that it originates from Mary, and that Mary is a special being for John may also impact the routing and make the request reach the right destination.
Finally, Mary is unable to access service X in spite of generating an adequate request addressed to the service. This is because the request originates from her, and her service profile does not include the right service routing information.
User-centric Service Architecture
Because John and Mary have a different service profile, the same SIP request issued by each of them can be routed to a different server. For instance, the SIP SUBSCRIBE permitting John to access Service X is routed according to John's service profile, while the same SIP SUBSCRIBE permitting Mary to access Service X (in case she is also subscribed to it) can be routed to a different server because it depends on Mary's service profile.
This mechanism, which permits the same service to be located in different application servers for different users permits:
- Service scalability to infinity. If you reach the vertical scalability of an application server, just deploy another one and populate service profiles for new subscribers with the address of the new server.
- The support of service variants for different market segments. For instance, simple or more sophisticated presence depending on the subscription.
- Multi-vendorship for a given service implementation, which is difficult to achieve in pre-IMS telco networks (e.g. MMS).
Implicit Addressing for Some Personal Services
In the example, the service registry is a personal service to John. The way for John to access the service registry is to issue a SIP request that is addressed to himself, and not to a specific location. The IMS service architecture, and more especially service routing based on John's service profile stored in the HSS does the trick.
A consequence of this approach is that John's client does not need to be provisioned with the location of the service registry to access its content. John's client can simply use one of John's Public Identities the client has been registered to IMS with.
Similarly, the application server hosting service X benefits from this implicit addressing, as it just has to generate a SIP request addressed to a user identity that has just been provisioned in order to publicize its availability to John.
Single User Identity / Multiple Services
The example shows that Mary can try to access John's service registry through the usage of one of his Public Identities. The same identity could be used to start a voice call with John, to initiate a gaming session, to send an IM to him, or to retrieve his presence.
Virtual Service Location
In the example, John, Mary or service X either use John's Public Identity or a Public Service Identity to access a specific service located on a specific server. The mapping between the identity and the actual location of the service is based on a service profile stored in an HSS.
Any change to the service profile may change the location, without any impact on the underlying addressing mechanism. It is therefore possible to change the location of a service over time, without impacting the way to access it. An example is when you want to switch to a new service implementation.
Network-based Service Authorization
In the example, routing of a service request to John's service registry and to Service X requires the existence of specific service routing information (Initial Filter Criteria) in the service profile associated to John.
This permits to directly link service authorization to SIP routing mechanisms in the IMS service architecture.
The example also showed that a service request that is not routed to the application server where the service is hosted can still be routed to alternative destinations, which may provide an appropriate response to the unauthorized service request. For instance, the alternate server can explain why the request was rejected, provide a limited trial version of the service, a pay per usage option, or simply propose the user to subscribe to the service and redirect it to a subscription web page.
Personalized and Shared Service Access
When John accesses Service X through his service profile, this access is personalized for John and points at an instance of Service X that can be highly customized according to John's preferences.
When Mary tries to access the same service using the same SIP request, this request is routed to a server according to service routing mechanisms associated to the service itself and not to Mary (as she is not subscribed to Service X). This access to Service X is shared with all other users that are not subscribed to Service X...
...Or at least a subset of them. The operator may actually route shared service requests to different application servers depending on the originator of the request. For instance, by checking the domain of the originator, the operator may define in Service X's service profile different service routing mechanisms for non-subscribed users that 1) are subscribers of this operator and may add this service to their service registry, 2) foreign users who are IMS subscribers of another operator, 3) service requests coming from the open Internet.
Integration of non-IMS services with IMS
In the example, the IMS-based automatic service discovery and configuration framework is applicable to both IMS and non-IMS services. This is, SIP and the IMS service architecture are used to get information about services, but the services themselves do not need to be accessed through SIP and the IMS service architecture.
This shows that IMS should be seen as a service framework, which does not necessarily require services to be implemented specifically for it. Non-IMS services can be integrated in this framework and benefit from its capabilities, without any impact on their implementation. Other examples of such integration will be presented in the future.
Service Anthropomorphism
Anthropomorphism: Attribution of human motivation, characteristics, or behavior to inanimate objects, animals, or natural phenomena
IMS service anthropomorphism is the ability for a service to act or be treated as an IMS user. I will come back on this concept, but here it can be seen that Service X publishes its availability by issuing a SIP request which could also be generated by one of John's client. Service X can either use its own public identity or impersonate John for this. Service X therefore has its own motivation and acts as if it was another IMS user.
Christophe
Stumble It!
