Enabling Network Based Presence Aggregation using IMS

Kavitha Valsala Wireless & Multimedia Practice

Infosys Technologies Ltd Email: kavitha_valsala@infosys.com

Abstract— IP Multimedia Subsystems (IMS) and Presence are the biggest buzzwords in the telecom industry today. Almost all major service providers are strategizing and planning roll out of IMS compliant network and value added services, to provide rich user experience. Moving to the hyper connected world, users have to manage multiple identities, corresponding to each connection, spread across multiple networks. Multimedia services are envisioned to be delivered seamlessly across the multiple devices of the same user. Current implementations around Presence agent aggregating presence information have limitations due to user identities spreading across multiple access devices. This limited the power of rich presence and mostly application tends to use presence aggregation around enterprise applications like email, calendars and Instant Messengers. With the advent of IMS technology, we can foresee a world exploring the benefits of presence from different networks, with presence being aggregated at the network rather than presence agents. IMS architecture eases the aggregation of presence from multiple sources and technologies. The access agnostic IMS architecture also promises one unified identity for a user spread across multiple devices and media types and thus making communication user centric. This paper details how IMS architecture can be envisioned to provide network based presence aggregation and demonstrates how the presence aggregation can be used to implement complex new services. It reports how a person’s availability across multiple devices and networks can be traced out with a single identity in IMS world and how the IMS network nodes interwork for this scenario.

Keywords; IMS; Presence; Presence Aggregation

I. INTRODUCTION

A. Presence: Enabler for multimedia services Presence an enabler for interactive communication is now

becoming a key technology powering real-time communication. Alone a simple concept, but when managed effectively presence can become a precious commodity to the enterprise and communication world. The future convergence world considers Presence as the integral part of all multimedia applications, enabling service providers and telecom operators to enhance the appeal of application services to the end users.

Presence is nothing but the real time network availability of a user, device, service or application. Presence is not limited to people or services. Any entity with real time network connectivity can be interactively communicated when enabled with presence technology. The magic of rich presence can even expose the subtle information about the presentity, such as how, when, where it is available in real time. Presence is the

horizontal enabler for next generation communication network. Enterprises and service providers are competing to make use of the presence, as an opportunity to make a footprint in the fastest growing telecom market.

B. Challenges in Presence Aggregation Future hyper connective world expects services to be

delivered seamlessly across multiple access domains including WiFi, WiMax, UMTS, DSL, Broadband cable etc. Hyper connectivity simply means a user can simultaneously connect to the real time network with varied set of devices or identities. Presence service has to signal the availability of entities across myriads of multimedia interactions. This necessitates ubiquitous presence to be carefully managed and integrated from devices and services across different network technologies. The limits of consumer oriented IM services become clear when enterprises and service providers attempt to integrate the presence into more critical real-time telecom systems. Pre-IMS world wedged in vertical-silo service architecture faced the big challenge of inter-network interaction. Traditional approach with stove piped vertical architecture demands access tailored services or applications. Aggregating the presence information across diverse platforms require interoperability, which is the key hurdle in service integration.

Lack of some sort of horizontal integration of the underlying network prevents the deployment of common service architecture. The power of presence-enabled systems cannot be fully explored with present service silos. Next generation networks that envision seamless access interaction, when coupled with the presence technology can provide feature rich service offerings.

II. NETWORK BASED PRESENCE AGGREGATION

Beyond the simple IM-based presence aggregation paradigm, the converged world is foreseeing a network initiated presence consolidation. Following sections describe some standard presence aggregation approaches which can be considered for a hyper connected world with people and services having access to multiple domains and technologies..

A. Presence Aggregation – A staggered approach Apart from cross technology interactions, the challenges for

presence aggregation across diverse domains are

� Availability of presentities in each domain which can collect presence information

� Availability of an intelligent presence aggregator logic, which can gather information from multiple sources, consolidates them and publishes it out for efficient communication usage.

The presentities in each access domain must keep track of presence information of the entities connected to that network. For the presence to be integrated at the network level, aggregator service has to interact with the presence sources in all the technologies, collect the availability information of network-connected entities from the sources and consolidate it. The applications or services, which require rich presence, can subscribe to the presence aggregator to get the integrated presence service.

Figure 1. Presence Aggregation:- Staggerd approach

B. Presence Aggregation – An integrated approach Moving from the legacy silo approach of technologies, each

domain can push in the presence information of the available entities in their access domain to the presence aggregator service.

Figure 2. Presence Aggregation:- Integrated approach

Instead of having a presence source at each domain, the information can be stored at a common place serving all domains, in the presence aggregator itself. The applications at the service layer could use these aggregated presence

information to orchestrate rich multimedia services. Following sections describe how an IMS based architecture can implement this integrated presence aggregation approach.

III. IMS BASED PRESENCE AGGREGATION

IP Multimedia Subsystem (IMS) is an evolution path for the existing telecom system to a converged network, providing the capability to deliver rich multimedia services. It provides an access agnostic service delivery platform and efficient service enablers (like Instant Messaging, Presence, Location Service etc) to deploy multimedia rich, integrated solutions to the mass market. In contrast to the traditional vertical silos in the telecom world, the IMS converged network decouples the underlying access network architecture from the services platform with a horizontal layered approach. IMS framework enables wireless, wireline and cable operators to provide with rich video, voice and multimedia services even across legacy networks. Horizontalization of networks allows services and applications to seamlessly interact with entities in any access technology and deliver an access independent communication experience to the user. The converged network plane can reuse the common functional/service entities across the domains, as it removes the challenge of integrating information from multiple sources and technologies. The architecture also allows a high degree of flexibility to integrate new and existing services across different access domains.

The IMS is the best fit for the integrated presence aggregation approach discussed in the previous section and it eases the task of the presence data aggregation due to the access agnostic nature. The high level architecture of the IMS based presence aggregation is depicted in Figure 3.

Figure 3. Presence Aggregation:- IMS based approach

The ease of inter-network interaction and the availability of a single unifying identity (PSI and IMPU) for service/user across the diverse access domains are the main advantages offered by IMS for presence service integration. Session Initiation Protocol (SIP), the common signaling protocol used by IMS service delivery architecture is the main technological building block, which allows the traditional incompatible networks to interact smoothly. IMS powered by SIP

technology will be well suited for real time interaction with both legacy and new generation networks.

The next section describes how the IMS based presence aggregation solution can be used to deliver complex presence enabled services.

IV. PRESENCE AGGREGATION: USE CASE ARCHITECTURE

A. Presence Server architecture A presence server with presence aggregation capability

included in the IMS network can provide the network based presence consolidation. The use case diagram depicted below includes the high level architecture of the presence server.

Figure 4. Presence Aggregation Use case Architecture

1) Interfaces required for presence server � Diameter Sh interface with HSS to obtain subscription

information

� SIP (SIMPLE)interface with presentities and watchers

2) Entities that interact with the presence server � HSS which stores the service specific information � Presentities which are the real time services, user

devices or applications which send in the availability information to the server

� Watchers which are services that interact with the presence server for getting presence information of other services or users.

3) Functional modules within presence server The functional modules of the server are:-

� Presence database which stores the presence information as given by the presentities

� Presence core which handles all the publish, subscription and notifications events

� Presence aggregator which consolidates the presence information of multiple identities of the same user.

� Transport Layer which provides the interfaces of SIP, Diameter Sh, XMPP(if required)

� Presence subscription/watcher module which stores the list of subscriptions

B. Enhancement in the SIMPLE interface With the existing interfaces in IMS architecture, presence

from different sources can be aggregated at a common application server. A slight modification in SIMPLE interface can be proposed to fully utilize the rich presence aggregation and its availability to the watchers. The current SIMPLE protocol (RFC 3856) does not support a single retrieval of the presence information. As per standard, if the “Expires” header has value “0” in SUBSCRIBE request, then presence server gives NOTIFY only once, but with state as “Subscription-state” as “Terminated” and with no presence information. With “Expires” header set to “1”, it will result in two NOTIFY requests (one with presence info and one with empty presence stanza). Hence the service logic at the application layer need to be intelligent enough to handle the asynchronous last NOTIFY request (which might come even after the end of the service).

To support future complex solutions, a slight enhancement in the SIMPLE interface is proposed., A new header “Data” with values “Expand” and “Consolidated” is introduced in SUBSCRIBE message. The “Data” header will have significance only if the “Expires” header is having a value “0”. For this case, the Presence server will return only one NOTIFY, but with the latest presence information. For the cases with “Data” set as “Expand”, the presence stanza in the NOTIFY message will include the presence of all the public identities of user A along with the aggregated presence information of service. The value “Consolidated” in the “Data” Header indicates that consolidated presence information of the presentity is given to the watcher.

The next section will cover how presence aggregation can be utilized in building up a complex application service in the IMS network. The usage of enhanced SIMPLE interface is also covered in the use case.

C. Complex New Application service: Solution Overview The horizontal architecture of the IMS network and the

presence function being at the service enabler layer opens up wide range of opportunities to create complex presence enabled services. This section describes how the network based aggregation can assist to create one such service.

In the complex hyper connected world, users need to manage multiple service and device identities for each connection spread across different networks. A new application service, Presence Based Call Disposition (PBCD) described here emphasizes the use of unified identity for

communication, to make the future communication user centric. Once deployed, this service logic can enable application service providers and operators to deliver “ anytime anywhere any device communication” using single identity. The figure-4 depicts how this service is deployed using IMS architecture. The user-A has multiple devices and has unique public and private identities for each of those. PBCD provides a new service using IMS where in the same user-A can be reached by a unique public service identity (PSI) on any of his device. The choice of the termination to which device will be based on various parameters like the presence, location, service rule engine (which is configurable by the user). For e.g. if the user-B wants to contact the User-A, he will dial the User-A’s PSI instead of the device specific Identities. Depending on the service logic at the IMS core which in turn uses the presence aggregation, the call will be routed to the device of User-A’s choice and availability.

The presence aggregator plays a major role in providing this service and interacts with various IMS nodes like HSS and external location Provider (GMLC) to provide the aggregated presence information of the user from multiple devices. Following sub sections describe various requirements of this service and how this service is implemented using IMS.

1) High Level Requirements for PBCD Service � Service need to interact with devices connected to

multiple technologies � Service must give the flexibility to use single unified

identity across all networks � Service must provide provision for the user to select

his preferred mode of communication. At any point of time, user will be connected using many devices. User must be able to provision priority for each of identities

� Service must have the flexibility to get the consolidated presence information of a user or get the detailed presence information of all the identities of the user from the presence server.

2) Requirements for Presence Server in the IMS core for

PBCD � Presence server must have the capability of presence

aggregation. � Presence server must be able to get the presence

information of all the identities of the user when provided with the unified single identity. It must consolidate the information and pass it down as a consolidated single presence or detailed presence list to the service which has requested for it.

3) Detailed Description of PBCD Solution

Presence Based Call Disposition is a service logic, which determines a person’s availability across multiple devices and networks with a single unified identity in the IMS world. Users subscribed to this service will be uniquely identified by public service identity (PSI). In the architecture diagram (Figure-4), the service logic lies in the Application server which uses the presence server to obtain the aggregated

presence and GMLC to get the latest location information of the device if that is mobile equipment.

When a user subscribes for the presence based call disposition service; he has to provide the list of all device identities (IP Multimedia public identities - IMPU) along with their priority to the service. This will be used as the input to the rule engine in the application server. Along with the aggregated presence information from presence server, the rule engine in the application server will route the call to the appropriate user device.

Whenever the user connects/registers to the network through any of his devices, the presence information of the specific user device will get updated in the presence server as part of Publish procedure. The presence server will store the availability information of its presence sources in the database. This is depicted in the figure in dotted lines.

User subscribed for Presence based call disposition logic can use this service for any kind of real time multimedia communication.

Refer the use case architecture in Figure 4 to map the steps mentioned below.

Step (1) - In the use case, User A is subscribed for presence based call disposition service. Other users can place a request to this service for a video/voice call, with the call to the unique service identity (PSI) instead of User-A’s device specific public identity. Basically the identity which will be published to all will be this PSI. In this example, User B is trying to call User A on User A’s public service identity (UserA@call_disposition.com).

Step (2) - The service logic at the application server will first contact the presence server to get the presence information of the PSI. This is achieved by sending a SUBSCRIBE to the presence server. A SUBSCRIBE request for the PSI is sent to Presence Server with a “ Data” header with value “ Expand” or “Consolidated” and “ Expires” header with value “ 0” .

Step (3) - Presence server informed with the caller’ s PSI will then contact the HSS to get the service specific information associated with the PSI. The Presence Server uses the UDR/UDA dialog over the Sh-interface for this purpose (with Data-Reference AVP for the UDR Diameter message as IMSPublicIdentity). HSS will provide the list of registered public identities of the user to the Presence server as it already contains the mapping between the PSI and all related public identities. The presence aggregator module in the server will then fetch the presence information of each of the identities and based on the aggregator rule engine, it prepares the consolidated presence information. The rule engine is based on XML format and could be either stored in the Presence Server or in the HSS (in which case, it could be fetched by a UDA for service data). However the most viable implementation will be a aggregation rule engine configurable at the presence portal. The portal will present the list of Public Identities fetched from HSS only using UDR and UDA and the user could configure the aggregation information.

Step (4) - Service will be notified with this aggregated availability information by the presence server. The service

logic can use this information to contact the destination’ s available public identity. For the cases with “ Data” set as “ Expand” , the presence stanza in the NOTIFY message will include the presence of all the public identities of user A along with the aggregated presence information of service. The value “ Consolidated” in the “ Data” Header indicates that a consolidated presence information of the User-A is only required by the service.

Step (5) – Based on the service rule engine on the application server, it then send a request to the external Location provider like GMLC to obtain the latest location information if the aggregated presence indicates a mobile device to be contacted. It could be quite possible that the User-A might be roaming in internationally and might not want to take any incoming call on his device. In this case, the Presence information received by means the “ Expand” value of the “ Data” header of SUBSCRIBE will be used to make further decision on where the call will be routed to. In case the previous request in Step-2 is not having the “ Expand” field, another SUBSCRIBE request will be triggered with “ Expires” as “ 0” and “Data” as ” Expand” values to obtain a NOTIFY with detailed presence information along with the consolidated presence.

Step (6) – The service logic redirects or place the multimedia call based on the consolidated presence information and location of the user. In this case, it’ s routed to D2 of User A.

Step (7) - Once the call is connected, rest of the signaling takes place directly between the user entities.

4) Presense Stanza in NOTIFY and SUBSCRIBE message Extensions(RFC 3856)

The IETF draft on Rich Presence Information Data Format for Presence based on the Session Initiation Protocol (RPIDS), provides a detailed data format to handle the aggregated presence information of a service from multiple devices, users etc. The same format can be reused for sending the aggregated availability information from the presence server to the application server. A sample RPIDS for the aggregated presence information is as follows:-

<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" xmlns:cap="urn:ietf:params:xml:ns:sip-prescaps" xmlns:ep="urn:ietf:params:xml:ns:sip-rpids"> <entity="UserA@call_disposition.com"> <tuple id="35bs9r" class="service"> <status> <basic>available on softphone </basic> </status> <contact=UserA@service.com</contact> </tuple> <tuple id="35bs9s" class="softphone"> <status> <basic>open</basic> </status> <contact priority="10"> D2_UserA@infosys.com</contact> </tuple> <tuple id="35bs9t" class="mobile">

<status> <basic>not reachable</basic> </status> <contact priority="10"> 9995557777@mobile.com</contact> </tuple> </presence>

In this solution, the entity element indicates the public service identity (PSI).

The sample of the SUBSCRIBE request with the proposed extension is as follows

SUBSCRIBE sip:UserA@call_disposition.com SIP/2.0 Via: SIP/2.0/TCP

userB.example.com;branch=z9hG4bKnashds7 To: <sip:UserA@call_disposition.com> From: <sip:UserB@example.com>;tag=xfg9 Call-ID: 2010@UserB.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Expires: 0 Data: Expand Content-Length: 0

V. CONCLUSION Enabling Network Based Presence Aggregation using Next

generation networks like IP Multimedia Subsystem will provide more opportunities to service providers and operators to enrich their services with the benefits of rich presence. The service logic supported by the aggregated presence and other service enablers are going to enable the IMS architecture to deliver presence enabled multimedia services. The proposed service logic architecture in IMS can be used for application services which are planning to deploy network initiated presence aggregation. The extensions proposed for RFCs when included can provide more flexibility to the watchers to get the aggregated presence information from the presence server

REFERENCES

[1] Third Generation PartnershipProject Specifications,TS 29.328 IMS Sh

interface : signalling flows and message contents, TS 29.329 IMS Sh interface based on Diameter Protocol :Protocol details

[2] Internet Engineering Task Force Internal Drafts draft-ietf-simple-rpids-01, draft-ietf-simple-partial-pidf-format-08 PIDF Extension for Partial Presence

[3] Internet Engineering Task Request For Comment 3261 SIP for Instant Messaging and Presence Leveraging Externtions

[4] Network Working Group Request For Comment 3856 A Presence Event Package for the Session Initiation Protocol