Chapter 20 - The Presence Service in the IMS

Chia sẻ: Nguyễn Văn Chiến | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

128
lượt xem 13
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Chapter 19 gave an overview of the presence service on the Internet, as deﬁned 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 IMS. 3GPP has deﬁned, in 3GPP TS 24.141 [51], a presence service that runs over IMS, but mostly, 3GPP is just maintaining the speciﬁcation, not actively progressing it.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Chapter 20 - The Presence Service in the IMS

Chapter 20 The Presence Service in the IMS Chapter 19 gave an overview of the presence service on the Internet, as deﬁned 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 IMS. 3GPP has deﬁned, in 3GPP TS 24.141 [51], a presence service that runs over IMS, but mostly, 3GPP is just maintaining the speciﬁcation, 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 speciﬁcations that enables a service. The main speciﬁcation of the OMA Presence SIMPLE enabler is the OMA Presence SIMPLE speciﬁcation [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 the presence service can offer to both end-users and other services. On the one hand, end-users beneﬁt from the presence service since they decide what information related to presence they want to provide to a list of authorized watchers. Presentities can decide the information they want to publish, such as communication address, capabilities of the terminals, or availability to establish a communication. 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 beneﬁt 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 beneﬁt 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 conﬁgu- ration offered by the XDM architecture. The IMS terminal plays the role of both a watcher The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A . Garc ıa-Mart´n ´ ı © 2008 John Wiley & Sons, Ltd. ISBN: 978-0-470-51662-1
CHAPTER 20. THE PRESENCE SERVICE IN THE IMS 444 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 of 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 conﬁguration. 20.3 Presence Publication When the IMS presence application is launched, e.g., in an IMS terminal, the application publishes the current presentity’s presence information. Figure 20.3 shows the ﬂow 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 ﬁlter criteria for the presentity. One of the initial ﬁlter 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 terminal, any other network entity can act as the source of 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 (MSC) server, a Gateway GPRS Support Node (GGSN), a Serving GPRS Support Node (SGSN), a Home Location
CHAPTER 20. THE PRESENCE SERVICE IN THE IMS 446 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 user such as Alice is operating an IMS terminal that can act as a watcher. When she starts the presence application, her IMS terminal subscribes to the presence 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 efﬁcient batched subscription in a single shot, saving enormous amount of time to complete the subscriptions and saves quite a lot of bandwidth. The ﬂow is illustrated in Figure 20.4, which assumes that the RLS is provisioned with a list of URIs of presentities to which Alice eventually wants to subscribe. 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 ﬁeld set to eventlist to indicate that the subscription is addressed to a list rather than a single presentity. An Event header ﬁeld set to presence indicates that the subscription is for the presence event package. The SUBSCRIBE request (2) is received at the S-CSCF, which evaluates the initial ﬁlter criteria. One of those criteria indicates that SUBSCRIBE requests whose Event header ﬁeld is set to presence and Require header ﬁeld is set to eventlist, such as the received one, ought to be forwarded (3) to an Application Server that happens to be an RLS. The RLS, after verifying the identity of the subscriber and authorizing 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 ﬁeld 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 ﬁlter 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. In 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 network. 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 there will be an S-CSCF allocation that 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 presence application is started in the IMS terminal, presentities subscribe to their own watcher information state, so that they can later receive notiﬁcations of watcher subscriptions when they occur. The high-level watcher information ﬂow is presented in Figure 20.6. For the sake of clarity, the ﬂow 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 ﬁeld 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 not 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
CHAPTER 20. THE PRESENCE SERVICE IN THE IMS 448 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 ﬁeld 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 authorize this watcher subscription? 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. When the presentity wants to authorize 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 modiﬁes 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 notiﬁcation event package, while others are speciﬁc to the presence event package. We have discussed some of these optimizations in previous sections. Others are brieﬂy mentioned here.
CHAPTER 20. THE PRESENCE SERVICE IN THE IMS 450 Section 4.15.1.1 discussed the event throttling mechanism, which allows the rate of notiﬁcations in any event package to be limited. In certain scenarios it is possible to suppress the body of notiﬁcations, if the event state has not changed with respect to a previous notiﬁcation. Sometimes it is even possible to suppress the complete NOTIFY request. Conditional event notiﬁcation was described in Section 4.15.1.2. Section 19.16.3 described the event notiﬁcation ﬁltering mechanism, which lets the watcher indicate the speciﬁc 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 notiﬁcations 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 mechanism 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- speciﬁc dictionary for SigComp, speciﬁed in RFC 5112 [149], is able to boost compression of PIDF bodies as well. In Section 4.17 we described the content indirection mechanism. This mechanism allows an endpoint to include a reference to content (e.g., ﬁles) 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 beneﬁt 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 ﬁles in a content server, using HTTP, and manage those ﬁles through the content XDMS, using XCAP. The Presence service in IMS is intending to support a mechanism to suppress presence notiﬁcations during a the duration of a subscription. The exact mechanism details are still under design at the time of this writing. 20.7 OMA Extensions to PIDF The Open Mobile Alliance (OMA) has deﬁned 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-deﬁned elements. OMA deﬁnes a willingness element, which can be used to indicated the user’s willingness to receive incoming communications for the speciﬁc 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 particular 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 element 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 open open closed active terminated org.openmobilealliance:PoC-session 1.0 sip:alice@pc.example.com 2005-06-05T07:52:14Z urn:device:001349038B74 PC open Figure 20.7: Example of a PIDF extended with OMA information
CHAPTER 20. THE PRESENCE SERVICE IN THE IMS 452 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 used to indicate OMA-speciﬁc services. The element can have two children elements: service-id and version. The service-id element identiﬁes the service and can take a number of values deﬁned by OMA; the version element identiﬁes 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 speciﬁc 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.