Chapter 20 ThePresenceServiceintheIMS Chapter 19 gave an overview of the presence service on the Internet, as defined by the IETF. This chapter focuses on the use of the presence service in the IMS. We explore the IMS architecture that supports the presence service and the applicability of presence to the I MS. 3GPP has defined, in 3GPP TS 24.141 [51], a presence service that runs over IMS, but mostly, 3GPP is just maintaining the specification, not actively progressing it. The presence service in IMS has since moved to OMA. OMA considers the presence service as an enabler, i.e., the set of specifications that enables a service. The m ain specification of the OMA Presence SIMPLE enabler is the OMA Presence SIMPLE specification [246]. This chapter describes this OMA Presence SIMPLE enabler. 20.1 The Foundation of Services When we described the presence service on the Internet we unveiled a few of the powerful and rich possibilities that th e presence service can offer to both end-users and other services. On the one hand, end-users benefit from the presence service since they decide what information related to presence they want to provide to a list of autho rized watchers. Presentities can decide the information they want to publish, such as communication address, capabilities of the terminals, or availability to establish a commu nication. Watchers receive that information in real time and decide how and when to interact with the presentity. All of these features enrich the end-user communication experience. On the other hand, presence information is not only available to end-users but also to other services. These other services can benefit from the presence information supplied. For instance, an answering machine server is interested in knowing when users are online to send them an instant message announcing that they have pending voicemails stored in the server. A video server can benefit by adapting the bandwidth of the streaming video to the characteristics of the network where the presentity’s device is connected. For all of these reasons we refer to the presence service as the foundation for service provision, as depicted in Figure 20.1. 20.2 Presence Architecture in the IMS Figure 20.2 depicts the presence IMS architecture in conjunction with the Service configu- ration offered by the XDM architecture. The IMS terminal plays the role of both a watcher ´ıa- M ar t´ın The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A. Garc © 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1 444 CHAPTER 20. THE PRESENCE SERVICE IN THE IMS Figure 20.1: Presence service: the foundation of all the services and a PUA (Presence User Agent), in addition to an XDMC). Central to the architecture is the function of the Presence Server (PS), which acts as a Presence Agent ( PA) and is located in the home network. The PS is complemented with a Content Server, a Presence XDMS, and with a Presence Content XDMS. All o f these are Application Servers from the IMS architecture point of view. Typically presence requires the management of lists. A Resource List Server (RLS) provides the required functionality to host different lists. The RLS is complemented with a RLS XDMS and a Shared XDMS. All of these are Application Servers from the IMS architecture point of view. Finally, Application Servers can also act as watchers of presence information. Typically a watcher in the presence service is implemented in connection to some other service that needs to keep track of the user’s presence. There are a number of interfaces in the Presence service, of which a non-comprehensive view is provided in Figure 20.2. However, most of the interfaces are realizations of the generic ISC interface, which is based on SIP, and the Ut interface, which is based on XCAP. The PS can also implement the Sh interface, which is based on Diameter. SIP interfaces are used for real-time presence data whereas XCAP interfaces are used for configuration. 20.3 Presence Publication When the I MS presence application is launched, e.g., in an IMS terminal, the application publishe s the current presentity’s presence information. Figu re 20.3 shows the flow and, as we can see, there is not much difference from the mechanism we explained in Section 19.4. The IMS terminal sends a PUBLISH request (1) that contains an Event header set to presence and includes a Presence Information Data Format (PIDF) document that describes the presence information. The S-CSCF receives the request (2) and evaluates the initial filter criteria for the presentity. One of the initial filter criteria indicates that PUBLISH requests containing an Event header set to presence ought to be forwarded to the PS where the presentity’s presence information is stored. So, the S-CSCF forwards the PUBLISH 20.3. PRESENCE PUBLICATION 445 Figure 20.2: SIP-based presence architecture in the IMS Figure 20.3: The IMS terminal publishing presence information request (3) to that Application Server. The PS authorizes the publication and sends a 200 (OK) response (4). Apart from the IMS term inal, any o ther network entity can act as th e source o f presence information and publish the user’s presence information. These entities are called Presence Network Agents (PNAs) and the publish presence information on behalf of the user in a similar manner as the PUA would: using the SIP PUBLISH method that contains a PIDF document. Any network entity can act as a PNA: A Mobile Switching Center (M SC) server, a Gateway GPRS Support Node (GGSN), a Serving GPRS Support Node (SGSN), a Home Location 446 CHAPTER 20. THE PRESENCE SERVICE IN THE IMS Figure 20.4: Watcher subscription to her own list Register (HLR) or Home Subscriber Server (HSS), a S-CSCF, a Gateway Mobile Location Center (GMCL), etc. 20.4 Watcher Subscription A u ser such as Alice is operating an IMS terminal that can act as a watcher. When she starts the presence application, he r IMS terminal subscribes to the pre sence information of her presentities. Although IMS allows watchers to subscribe individually to each of their presentities, as mentioned in Chapter 19, typically watchers subscribe to one or a few own presence lists, which are hosted in an RLS in their home network. This performs a very efficient batched subscription in a single shot, saving enormous amount of time to complete the subscriptions and saves quite a lot of bandwidth. The flow is illustrated in Figure 20.4, which assumes that the RLS is provisioned with a list of URIs of p resentities to which Alice eventually wants to sub scribe. The watcher application residing in the IMS terminal sends a SUBSCRIBE request (1) addressed to her 20.5. WATCHER INFORMATION AND AUTHORIZATION OF WATCHERS 447 list (e.g., sip:alice-list@home1.net). The SUBSCRIBE request contains a Require header field set to eventlist to indicate that the subscription is addressed to a list rather than a single presentity. An Event header field set to presence indicates that the subscription is for the presence event p ackage. The SUBSCRIBE request (2) is received at the S-CSCF, which evaluates the initial filter criteria. One of those criteria indicates that SUBSCRIBE requests whose Event header field is set to presence and Require header field is set to eventlist, such as the received one, ought to be forwarded (3) to an Application Server that happen s to be an RLS. The RLS, after verifying the identity of the subscriber and auth orizing the subscription, sends a 200 (OK) response (4). The RLS also sends an initial NOTIFY request (7) that does not contain any presence information at this stage. The RLS subscribes one by one to all of the presentities listed in the resource list and, when enough information has been received, generates another NOTIFY request (13) that includes a presence document comprising the aggregated presence information of the other presentities. Figure 20.5 shows the RLS subscribing to one of the presentities contained in the resource list upon the arrival of a subscription to a list. The process is repeated for each of the URIs included in the list. The RLS sends a SUBSCRIBE request (1) addressed to a presentity in the list. The request contains an Event header field set to presence. The request is forwarded via the S-CSCF in the RLS home network (2) to the I-CSCF in the presentity’s network. The I-CSCF queries the HSS using the Diameter protocol, (3), (4) in Figure 20.5, to locate the S-CSCF allocated to the presentity and forwards the SUBSCRIBE request (5) to the allocated S-CSCF. The S-CSCF evaluates the initial filter criteria where there is a criterion indicating that the request ought to be forwarded to the presentity’s PS (6). After sending the 200 (OK) response (7) the PS sends a NOTIFY request (11) that contains the presentity’s presence information. I n the example in Figure 20.4 neither the presentity’s S-CSCF nor the presentity’s I-CSCF record the route. Therefore, the PS sends the NOTIFY request (11) directly to the next node that recorded the route: the S-CSCF in the RLS n etwork. The lack of this S-CSCF record route avoids the S-CSCF becoming locked when the presentity is not registered. So, if the presentity registers later th ere will be an S-CSCF allocation th at may lead to a different S-CSCF. 20.5 Watcher Information and Authorization of Watchers As described in Section 19.13, watcher information allows presentities to be informed of who is watching their presence information and what is the state of those watcher subscriptions. Typically, when the p resence application is started in the IMS terminal, p resentities subscribe to their own watcher information state, so that they can later receive notifications of watcher subscriptions when they occur. The high-level watcher information flow is presented in Figure 20.6. For the sake of clarity, the flow assumes that the PS and the Presence XDMS are co-located. The IMS terminal of the presentity subscribes to its own watcher information by sending a SUBSCRIBE request (1) addressed in the Request-URI to the user’s own Public User Identity. The Event header field is set to the value presence.winfo. The PS receives the SUBSCRIBE request (3), acknowledges with a 200 (OK) response (4), and generates an immediate NOTIFY request (7) as with any subscription. At some point later in time, a watcher wants to subscribe to this user’s presence information, so they send a SUBSCRIBE request (13) that is received in the PS. Since the PS does n ot have authorization from the presentity for this new watcher, the watcher subscription is set to the “pending” state. The PS answers the SUBSCRIBE request (13) with 448 CHAPTER 20. THE PRESENCE SERVICE IN THE IMS Figure 20.5: The RLS subscribes to a presentity a 202 (Accepted) response (14) and immediately sends a NOTIFY request (15) that contains a Subscription-State header field set to pending. Then it also generates a NOTIFY request (17) to the presentity that includes a body describing the watcher information details, such as the watcher’s public user identity and the subscription state, which is in pending state. The presence application in the IMS terminal can bring the pending authorization of a watcher to the attention of the user. So, how can the presentity auth orize this watcher su bscription? The presentity uses XCAP and the Presence authorization rules XCAP application usage to provide that authorization. We discussed Presence authorization rules in greater detail in Section 19.14 in the context of the Internet. In IMS, the presence authorization rules are stored in the Presence XDMS. Wh en the presentity wants to auth orize a new watcher, it executes an XCAP operation invoking the HTTP PUT method (23) with the XCAP AUID set to pres-rules. This HTTP PUT request (23) includes an XML document that adds or modifies the entry pertaining to the identity of the new watcher and their subscription state is set to active state. The same XML document can also indicate which information of the presentity’s PIDF is provided to this new watcher. The Aggregation Proxy receives the HTTP PUT request (23) and forwards it (24) to the Presence XDMS that communicates the new authorization to the PS. The PS now generates a NOTIFY request (27) to the watcher to indicate that is subscription has been set to active state. This NOTIFY request (27) can also contain a PIDF document that contains the presentity’s presence information authorized by the presentity to be received by this particular watcher . 20.6. PRESENCE OPTIMIZATIONS 449 Figure 20.6: Subscription to own watcher information 20.6 Presence Optimizations In particular, when the IMS terminal is wireless, there is a strong requirement to minimize the bandwidth used over the air interface. This has lead to the development of a few extensions that try to minimize the number of bits transferred over the air interface. Some of these extensions are applicable to any SIP subscription notification event package, while others are specific to the presence event package. We have discussed some of these optimizations in previous sections. Others are briefly mentioned here. 450 CHAPTER 20. THE PRESENCE SERVICE IN THE IMS Section 4.15.1.1 discussed the event throttling mechanism, which allows the rate of notifications in any event package to be limited. In certain scenarios it is possible to suppress the body of notifications, if the event state has not changed with respect to a previous notification. Sometimes it is even possible to suppress the complete NOTIFY request. Conditional event notification was described in Section 4.15.1.2. Section 19.16.3 described the event notification filtering mechanism, which lets the watcher indicate the specific components of the PIDF it is really interested in receiving. Then, the PS removes those non-wanted components in the PIDF, saving unneeded information from being transmitted. Partial notificatio ns of presence information, which we already described in Sec- tion 19.16.1, allows the PS to include only a delta of the PIDF with respect an earlier version, saving lots of bandwidth when there are small changes in the PIDF. Its corresponding partial publication of presence information, described in Section 19.16.2, applies the same techniques to the publication of presence information. Section 4.16 described SigComp (Signaling Compression), a mechanism that allows us to compress SIP and SDP (and make it compressed binary). SigComp is implemented in the P-CSCF and the IMS terminal. While the general SigComp mechan ism is applicable to compress the SIP of SUBSCRIBE, NOTIFY, and PUBLISH requests, it will not have substantial effect in XML bodies such as the PIDF. To address this problem, a Presence- specific dictionary for SigComp, specified in RFC 5112 [149], is able to boost compression of PIDF bodies as well. In Section 4.17 we d escribed the content indirection mechanism. This mechanism allows an endpoint to include a reference to content (e.g., files) which is stored in a server. The reference is transmitted to a remote endpoint, which may download it, if it is in the user’s interest. The benefit is that the downloading typically uses HTTP, therefore, downloading does not involve SIP servers, which are relieved from treating typically large pieces of data. Within the presence server in IMS, a user may store files in a content server, using HTTP, and manage those files through the content XDMS, using XCAP. The Presence service in IMS is intending to support a mechanism to suppress presence notifications during a the duration of a subscription . The exact mech anism details are still under design at the time of this writing. 20.7 OMA Extensions to PIDF The Open Mobile Alliance (OMA) has defined a small number of additional elements that complete the standard PIDF for mobile purposes. Consider the PIDF example in Figure 20.7, which contains all of these new OMA-defined elements. OMA defines a willingness element, which can be used to indicated the user’s willingness to receive incoming communications for the specific application and device. The element can take the values open or closed. This element is part of the service component of the presence data model. A session-participation element indicates whether the user has at least one active session of a p articular service. The element can take the values open or closed and is included in the service component of the presence data model. The registration-state element indicates the presentity’s registration state pertain- ing to a particular service. The e lement can take the values active or terminated and is included in the service component of the presence data model. 20.7. OMA EXTENSIONS TO PIDF 451 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" entity="pres:alice@example.com"> <tuple id="3bfua"> <status> <basic>open</basic> </status> <op:willingness> <op:basic>open</op:basic> </op:willingness> <op:session-participation> <op:basic>closed</op:basic> </op:session-participation> <op:registration-state>active</op:registration-state> <op:barring-state>terminated</op:barring-state> <op:service-description> <op:service-id> org.openmobilealliance:PoC-session </op:service-id> <op:version>1.0</op:version> </op:service-description> <contact priority="0.8"> sip:alice@pc.example.com </contact> <timestamp>2005-06-05T07:52:14Z</timestamp> </tuple> <dm:device id="vjsa43"> <op:network-availability> <op:network id="IMS"> <op:active/> </op:network> </op:network-availability> <dm:deviceID>urn:device:001349038B74</dm:deviceID> <dm:note>PC</dm:note> </dm:device> <dm:person> <op:override-willingness>open</op:override-willingness> </dm:person> </presence> Figure 20.7: Example of a PIDF extended with OMA information 452 CHAPTER 20. THE PRESENCE SERVICE IN THE IMS The barring-state element indicates whether the user has activated the incoming barring communication service of a particular service. The element can take the values active or terminated and is included in the service component of the presence data model. A service-description element is u sed to indicate OMA-specific services. The element can have two children elements: service-id and version.Theservice-id element identifies the service and can take a number of values defined by OMA; the version element identifies the version of the service. The service-description element is included in the service component of the presence data model. A network-availability element is used to indicate the type of network the user’s device is connected to. The network-availability element contains a network element that includes an id attribute set to the type of connected network. This id attribute can take the value IMS to indicate an IMS application network, but it also can take any IP-CAN access type with the same value as the P-Access-Network-Info takes. The network element contains a child element set to either active or terminated, whose actual semantics depend on the type of network. The network-availability element is included in the device component of the presence data model. A presentity can use the override-willingness element to provide a generic will- ingness for all applications. As a consequence, the presence of the override-willingness takes precedence over the application and device specific willingness.The override-willingness element can take the values open or closed, and it is included in the person component of the presence data model. . Chapter 20 ThePresenceServiceintheIMS Chapter 19 gave an overview of the presence service on the Internet, as defined by the IETF. This chapter focuses on the use of the presence service in the. of these reasons we refer to the presence service as the foundation for service provision, as depicted in Figure 20. 1. 20. 2 Presence Architecture in the IMS Figure 20. 2 depicts the presence IMS. id=" ;IMS& quot;> <op:active/> </op:network> </op:network-availability> <dm:deviceID>urn:device:001349038B74</dm:deviceID> <dm:note>PC</dm:note> </dm:device> <dm:person> <op:override-willingness>open</op:override-willingness> </dm:person> < /presence& gt; Figure 20. 7: Example of a PIDF extended with OMA information 452 CHAPTER 20. THE PRESENCE SERVICE IN THE IMS The barring-state element indicates