5 Functional Entities To Support Presence Service

23.1413GPPArchitecture and functional descriptionPresence serviceRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Presence Server

The Presence Server shall reside in the presentity’s home network.

The Presence Server shall be able to receive and manage presence information that is published by the Presence User/Network/External agents, and shall be responsible for composing the presence-related information for a certain presentity from the information it receives from multiple sources into a single presence document. The composing process to create the single presence document may involve complex transformations of presence information such as modifying the presence information from one presence source based on information from another presence source. In particular, the Presence server shall be able to receive and manage presence information that is published from multiple Presence User agents of the same presentity. The Presence Server shall be able to process partial publications of information from Presence User Agents. These partial publications contain the presence information of the presentity that has been modified since the latest publication sent to the Presence Server about this presentity.

These Presence User agents may be updating the same parts of the presence information.

The mechanisms for combining the presence related information shall be defined based on presence attributes, and according to certain policy defined in the Presence Server. The Presence Server shall be capable of receiving and composing the Presence information received in the standardized formats from authorized sources regardless of the source of the information or the ability to interpret the information contained in the presence tuples. The information that the Presence Server is not able to interpret shall be handled in a transparent manner.

The Presence Server shall also allow watchers to request and subscribe to either the full set of presence information of a presentity, or only certain information within. Watcher defines the subset of the presence information, that he is interested in, by the filter that is carried in presence information subscription. The Presence Server shall be able to generate partial notifications to a watcher, which has indicated the capability to process them. These partial notifications contain the presence information of the presentity that has been modified since the latest notification sent to the watcher about this presentity, and required additional information to be able to link the partial notification to the information watcher has received earlier. In case the watcher does not indicate the capability to process partial notifications the presence server shall send only full updates.

Before the subscription to presence information is accepted, the Presence Server should attempt to verify the identity of the watcher that subscribes to Presentity’s Presence information, except if the watcher has indicated his desire to remain anonymous. The action taken by the Presence Server if the verification fails may include notifying the Presentity.

The Presence Server shall support SIP-based communications for publishing presence information.

The Presence Server shall support SIP-based communications with the Presentity Presence Proxy. The Presence Server is a SIP Application Server as defined by TS 23.228 [9], and is located using SIP URLs, standard SIP and existing IMS mechanisms (SIP routing, HSS query, ISC filtering, etc…).

The Presence Server shall provide Subscription Authorization Policy. The Subscription Authorization Policy determines which Watchers are allowed to subscribe to a Presentity’s Presence information.

The Subscription Authorization Policy also determines which tuples of the Presentity’s Presence information the watcher has access. It shall be possible for the Presentity’s Presence User Agent to provide the Subscription Authorization Policy or it may be configured by the operator as part of the service provisioning.

The Presence Server may provide a watcher configurable filtering function that is used to limit the information that is delivered to a watcher. After subscription the authorized watchers get notified of the actual Presence Information based on the Subscription Authorization Policy and the filters set by the watcher in the subscription. If the Presence Server does not support the filters as requested by the watcher, this is indicated to the watcher. In this case the notification shall contain the actual Presence information based on the Subscription Authorization Policy and local policy in the Presence Server. The Presence Server may support one or more of the following types of filters: Filters, which allow watchers to define:

– the tuples that the watcher is interested in;
Watcher can define a criteria which allows the complete tuple and all the information within the tuple to be transmitted. E.g. watcher can define the filter to permit notifying all the tuples (and all the information within those tuples) which has "tel:+16305551212" as the contact address or "Instant Messaging" as a communication means.

– the attributes that the watcher is interested in; and
Watcher can define a criteria which result notifies to contain values only for defined attributes (attributes are defined by the filter and values for other attributes are not available in the notifications)

– the triggers when a notification should be sent.
Watcher can define a criteria which specifies when to send a notification. E.g. every time the communication means status attribute changes its value, a notification is sent to the watcher. Another example: filter out and do not send the notifications resulting from the publication of the Presence User agent that is equal to the watcher.

The Presence Server shall collect watcher information to enable presentity to obtain information of the watchers that are or have been requesting, fetching or subscribing presentity’s presence information. Service provider shall be able to define the maximum time period over which information is collected and stored. The watcher information list shall include:

– identity of the watcher (unless anonymity was requested);
In case of anonymous watcher, the identity of the watcher shall not be provided to the presentity. The presentity shall be able to determine that an anonymous watcher has requested, fetched or subscribed presence information of the presentity including related information as specified in this list without revealing the watchers identity.

– time of the request, fetch or subscription;

– length of the subscription; and

– state of the request or subscription.

The Presence Server shall be able to support the presentity obtaining the above watcher information. The Presence Server shall be able to receive watcher information fetches and subscriptions from the presentity. These watcher information fetch and subscribe requests shall be able to contain filters which define:

– what watchers the presentity is interested in;

Possible categories are:
– all watchers;
– defined watchers;
– new, unauthorised watchers; and
– defined and new, unauthorised watchers.

– what information the presentity is interested in; and
The information is all or part of the watcher information list as defined above.

– the length of the watcher information history collection period that the presentity is interested in.

In response to watcher information fetches, the presence server shall be able to provide requested watcher information to the presentity. In response to watcher information subscriptions, the presence server shall provide notification to the presentity of the current state of the subscribed watcher information. When there are subsequent changes in the subscribed watcher information, notifications of the changes in watcher information are sent to the presentity.

The Presence Server may support rate-limiting or filtering of the presence notifications based on local policy in order to minimize network load.

5.2 Presence Agent Elements

The Agent elements in the Presence Architecture are functionally distinct from the Presence Server functional element. The generic function of the Agent elements is to make presence information available to the Presence Server element in standardized formats across standardized interfaces.

5.2.1 Presence User Agent

The Presence User Agent element shall provide the following functionality:

– The Presence User Agent shall collect Presence information associated with a Presentity representing a Principal.

– The Presence User Agent shall assemble the Presence information in the format defined for the Peu and Pep reference points.

– The Presence User Agent shall send the Presence information to the Presence Server element either via the Presentity Presence Proxy over the Pep reference point or over the Peu reference point.- The Presence User Agent shall be capable of managing the subscription authorisation policies.

– The Presence User Agent shall handle any necessary interworking required to support terminals that do not support the Peu and Pep reference points.

– Presence User Agent shall uniquely identify itself (among the Presence User Agents of the presentity) when publishing presence information.

From a conceptual view, the Presence User Agent (PUA) element resides between the presence server and the user’s equipment as illustrated in the reference architecture in figure 4.2-1. In reality, a Presence User Agent may be located in the user’s terminal or within a network entity.

Where the PUA is located in UE, the UE shall support Pep and the Peu reference point to the Presence Server as illustrated in Figure 5.2.1-1 below.

Figure 5.2.1-1: UE based Presence User Agent

The Network based Presence User Agent shall reside in the presentity’s home network.

Where the PUA is located within the network, the particular network entity shall support the Pep and Peu reference point to the presence server as illustrated in Figure 5.2.1-2.. In this case, additional functionality may be required to provide routeing between UE and the Presence User Agent, and, for the Presence User Agent to "register" the user within the "Presence network".

In this case, the interface between the terminal and the Presence User agent is outside of the scope of the present document.

Figure 5.2.1-2: Network based Presence User Agent

5.2.1.1 Relationship of Presence User Agent with IMS entities

When the Presence User Agent is located in an IMS UE the Pep reference point is implemented using the Gm, Mw and ISC reference points as defined in TS 23.002 [18].

– The Gm, Mw, and ISC reference points allow a presentity’s presence information to be supplied to the Presence Server. These reference points also allow for the Presence User Agent to obtain information on watcher subscriptions to the Presentities Presence Information.

– The Peu reference point is implemented using the Ut reference point as defined in TS 23.002 [18]. The Ut reference point provides mechanisms for the Presence User Agent to manage subscription authorisation policies.

Figure 5.2.1-3: Presence User Agent in IMS architecture

5.2.2 Presence Network Agent

5.2.2.0 General

The Presence Network Agent shall reside in the presentity’s home network.

5.2.2.1 Functions of the Presence Network Agent

The Presence Network Agent element shall provide the following functionality:

– The Presence Network Agent shall receive Presence information from network elements within the HPLMN and VPLMN.

– The Presence Network Agent shall be able to send requests to the HSS/HLR to cause other network elements to send (or stop sending) Presence Information to the Presence Network Agent. Note that this only applies where the other network element has Presence Information subscriptions managed via the HSS/HLR.

– The Presence Network Agent shall associate Presence information with the appropriate Subscriber/Presentity combination.

– The Presence Network Agent shall convert the Presence information into the format standardized for the Pen interface.

– The Presence Network Agent shall publish the Presence information to the Presence Server across the Pen reference point.

5.2.2.2 Suppliers of Presence Information

The Presence Network Agent may receive Presence information from one or more of the following 2G/3G network elements over the specified reference point:

Network Element supplying Presence Information	Reference Point
HSS/HLR	Ph
S-CSCF	Pi
MSC Server/VLR	Pc
SGSN	Pg
GGSN	Pk
GMLC	Pl
3GPP AAA Server	Pr
PDG	Pp

It is a matter of implementation and operator choice which reference points the Presence Network Agent supports towards suppliers of Presence information. Where other reference points support such a capability, a Presence Network Agent can use the Ph reference point to activate and deactivate publishing of Presence information via those reference points.

5.2.2.3 Relationship of Presence Network Agent with IMS entities

Figure 5.2.2.3-1 below presents the architecture for the S-CSCF and the HSS to provide presence related information to the Presence Server.

NOTE: The architecture on Figure 5.2.2.3-1 is an IMS-specific simplification of some of the interfaces of the generic Presence reference architecture presented in clause 4.

Figure 5.2.2.3-1: IMS network elements supplying presence information

The ISC interface is used to convey presence information from the S-CSCF to the Presence Network Agent. More specifically, the functions of the Pi interface are taken care of by the ISC interface. As an example, the S-CSCF can convey a user’s IMS-registration status by generating and sending a 3^rd party REGISTER request to the Presence server.

The Sh interface is used to convey information from the HSS to the Presence Network Agent. More specifically, the functions of the Ph interface are taken care of by the Sh interface.

Since the Network Agent is introduced as a functional entity, which models the abstraction from the different presence sources, the network agent and the presence server may be collocated. In case of an IMS-only network environment the Pen reference point is assumed to be realized by an internal interface.

5.2.3 Presence External Agent

The Presence External Agent element shall provides the following functionality:

– The Presence External Agent shall supply Presence information from external networks;

– The Presence External Agent shall send the Presence information across the Pex reference point according to the format standardized for the Pex reference point;

– The Presence External Agent shall handle the interworking and security issues involved in interfacing to external networks;

– The Presence External Agent shall have functionality to resolve the location of the Presence Server associated with the Presentity.

Examples of Presence Information that the Presence External Agent may supply, include:

– Third party services (e.g. calendar applications, corporate systems);

– Internet Presence Services;

– Other Presence Services.

Editor’s Note: The mapping of Pex to IMS reference points is FFS.

5.3 Presence Proxies

5.3.1 Presence Proxies introduction

In order to support a presence service, in particular across PLMN borders, generic network functions are needed, e.g. routing and security. The presence proxies provide these functions. Presence proxies constitute the entry and exit point for presence requests between PLMNs.

5.3.2 Watcher Presence Proxy

When a Watcher application intends to access some presence information of a presentity, it first needs to contact its Watcher Presence Proxy which will contact the Presentity Presence Proxy to find the Presence Server containing this information.

The Watcher Presence Proxy shall provide the following functionality:

– Address resolution and identification of target networks associated with a presentity;

– Authentication of watchers;

– Interworking between presence protocols for watcher requests;

– Generation of accounting information for watcher requests.

5.3.3 Presentity Presence Proxy

The Presentity Presence Proxy shall provide the following functionality:

– Determination of the identity of the presence server associated with a particular presentity;

– Authentication of Watcher Presence Proxy;

– Authentication of the Presence user Agent;

– Generation of accounting information for updates to presence information.

5.3.4 Relationship of Presence Proxies with IMS entities

The functionalities of the Watcher Presence Proxy are then taken care of by the P-CSCF and the S-CSCF:

– The S-CSCF is responsible for authentication according to procedures described in TS 33.203 [5].

– The charging and accounting procedures are conducted as per procedures defined by TS 32.240 [6], TS 32.260 [7].

– The security mechanisms between the Watcher and the Presentity Presence proxy are defined by TS 33.210 [8].

The functionality of the Presentity Presence Proxy is taken care of by the P-CSCF, I-CSCF and the S-CSCF as defined in TS 23.228 [9].

The procedures for locating, routing to and accessing the Presence Server of the presentity are defined in TS 23.228 [9] and TS 23.218 [10]. These procedures also take care of routing and accessing the Presence Server of a presentity that is associated with an unregistered UE.

The functionality of the Watcher Presence Proxy and the Presentity Presence Proxy are allocated to the functional element CSCF as defined in TS 23.002 [18].

Figure 5.3.4-1 below presents the mapping of the Watcher and Presentity Presence Proxy functionalities to IMS network elements when located within the IMS along with the Watcher application. This mapping is based on and restricted to reusing the existing IMS architecture mechanisms and can be clearly seen in the detailed information flows show in annex A.

Figure 5.3.4-1: Both the Watcher application and the Presence Server located within IMS

NOTE: The standard IMS (SIP) routing mechanisms define whether a certain CSCF is indeed included in the path of a SUBSCRIBE or NOTIFY transaction.

As described in IETF RFC 3856 [4], the Watcher Application sends a SIP SUBSCRIBE to Event: presence addressed to the presentity’s SIP URL to subscribe or fetch presentity’s presence information. This SUBSCRIBE transaction will be routed and handled by the IMS infrastructure according to standard IMS routing and ISC procedures defined in TS 23.228 [9] and TS 23.218 [10].

The Presentity’s S-CSCF is not mandated to insert itself into the Record-Route header of the initial SUBSCRIBE request, in case the S-CSCF does not execute any functions for the subsequent requests and responses of the dialog.

The presence document will be provided from the Presence Server to the Watcher Application using SIP NOTIFY along the dialogue setup by SUBSCRIBE either within the NOTIFY payload, or via a URL provided in the NOTIFY. The means to fetch the content can be seen as part of the Pw interface.

5.4 Watcher Applications

5.4.1 Communication between Watcher and Presentity Proxy

Communications between the Presentity Presence Proxy and the Watcher Presence Proxy shall be based on SIP as shown in figure 5.4.1-1 below. Other IP-based mechanisms may also be needed to support the delivery of large amount of presence information. Support for non-SIP based Watchers may be provided by the use of an interworking functions co-located with the Watcher Presence Proxy. In this case the Watcher Presence Proxy interworking function needs to be able to support routing to the non-SIP based watcher.

Figure 5.4.1-1: Communications between the Presentity Presence Proxy and the Watcher Presence Proxy for Watchers

5.4.2 Watcher application in an IMS UE

The Watcher application can be located within a UE registered in the IMS network, it is registered to a S-CSCF via a P-CSCF according to standard IMS procedures as specified in TS 23.228 [9].

Watcher application shall be able to handle full and partial notifications. The capability to process partial notifications shall be indicated to the presence server when making a presence subscription.

The Pet reference point is implemented using the Ut reference point.

5.4.3 Network based Watcher Application Server

The Watcher application can be located within an Application Server behind the ISC reference point. This entity is the Network Based Watcher Application Server.

5.4.4 Watcher application located in the external Internet

If a Watcher application is located in the external Internet, then the Watcher Presence Proxy shall reside in a network capable of executing security functionalities as per procedures defined in TS 33.210 [8].

The interworking with Watcher Applications located in the external Internet not supporting the standard Pw reference point is out of the scope of the present document.

5.4.5 Presence Server located in the external Internet, Watcher application located in the IMS

If a Watcher Application is located in the IMS, the functionalities of the Watcher Presence Proxy shall be as described in clause 5.3.2. Depending on the mechanisms and protocols supported by the external Presence Server, the Watcher Presence Proxy may implement additional functionalities, e.g. protocol mapping.

The interworking with Presence Servers located in the external Internet not supporting the standard Pw reference point is out of the scope of the present document.

5.5 Presence List Server

The Presence List Server stores grouped lists of watched presentities and enables a Watcher Application to subscribe to the presence of multiple presentities using a single SUBSCRIBE transaction. Presence List Server also stores and enables the management of filters associated to presentities in the presence list. Presence list server shall attach associated filter to each individual SUBSCRIBE transaction. The Presence List Server is implemented as a SIP Application Server function as defined in TS 23.228 [9]. For the case where the Watcher Application resides in an IMS UE, the Presence List Server may support the Ut reference point to allow the user to manage his presence lists.