5 High level requirements

22.1413GPPPresence serviceStage 1TS

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

5.1 Home Environment requirements

The presence service shall provide the ability for the home environment to manage the presence information of users’ devices, services and service media, even when roaming. The home environment shall be able to be both the supplier of presence information (i.e. presentities), as well as the requesters of presence information (i.e. watchers). The presence service can be regarded as a Home Environment service or a Home Environment – Value Added Service Provider (HE-VASP) service.

The home environment requirements for the support of the presence service are defined in 5.3 General requirements, and the applicable requirements in 5.4 Management requirements and 5.5 Notification and acknowledgement requirements.

External networks (e.g. those in other PLMN’s, the Internet, LANs etc.) currently support several different forms of presence service. The presence service shall enable the network to present a consistent and interoperable support of presence, such that the presence capability users can interwork with one or more other external presence services.

5.3 General requirements

The following general requirements for the presence service shall be supported:-

a) Presence information

i) presence information for presentities shall be made available in a standardised presence information format to enable interoperability within networks.

ii) presence information for presentities shall be made available in a standardised presence information format to enable interoperability with IETF specified presence information formats (e.g. RFC 2778 [3], RFC 2779 [4] and RFC3863 [5])

iii) presence information for presentities shall be extensible to represent additional information, without undermining the standardised format (e.g. device capabilities)

iv) presence information for presentities shall include a means to uniquely identify the presentity

v) presence information for presentities shall define a particular type of presentity, representing a subscriber, with a minimum set of attributes as described below for interoperability within networks. The values for these attributes are to be determined in the Stage 2/3 specifications.

In addition to the generic requirements described above, the presence information representing a subscriber:

a) may include a subscriber’s status attribute describing the subscriber’s willingness to communicate (e.g. available, unavailable). It does not identify the status of the device (e.g. registration or attachment to the network) or of any application.

This attribute is controlled by the subscriber. It shall be possible for this subscriber’s status to be provided by the subscriber, or by the network on behalf of the subscriber (subject to the subscriber’s agreement). For example the subscriber could define that he’s unavailable each day between 10 p.m. and 7 a.m., and the network would then be responsible for the subscriber’s status update.

The format and values of this attribute shall be standardised.

Note: It is to be determined in the Stage 2/3 specifications how the Status field (in RFC2778 [3]) in notifications is completed, and whether or not the values in the subscriber status attribute, network status attribute or other information are used.

b) may include a network status attribute describing the connectivity state of the device used by the subscriber. This attribute could for example be defined using information describing the subscriber’s state of connectivity to the network (e.g. attached, call active, CS attached, CS Call active with bearer information, IMS registered, PDP context information etc…).

This attribute is controlled by the network.

The format and values of this attribute shall be standardised.

c) may include one or more communication means (e.g. SMS, telephone, e-mail, multimedia session…) and their contact addresses (e.g. MSISDN, e-mail address, NULL…) by which the subscriber may be contacted.

This attribute is controlled by the subscriber. It shall be possible for this information to be provided by the subscriber, or by the network on behalf of the subscriber (subject to the subscriber’s agreement).

The format and values of the communication means shall be standardised, and the format of the contact address shall be standardised.

d) may include two types of location information, one provided by the network (e.g. geographical co-ordinates) and/or one provided by the subscriber (e.g. “at home”).

The network provided location is controlled by the network, and the subscriber provided location information is controlled by the subscriber. It shall be possible for the subscriber provided location information to be furnished by the subscriber, or by the network on behalf of the subscriber (subject to the subscriber’s agreement).

The format of the network provided location shall be standardised, and the format of the subscriber provided location shall be standardised.

e) may include a priority attribute giving a relative priority for each of the defined communication means and contact address pairs. It is via this priority attribute that the subscriber can indicate his preference for the order in which the communication means and contact address pairs should be used.

This attribute is controlled by the subscriber. It shall be possible for the priority information to be provided by the subscriber, or by the network on behalf of the subscriber (subject to the subscriber’s agreement).

The format and values of this attribute shall be standardised.

f) may include a text attribute (e.g. “In a meeting until 4 p.m.”)

This attribute is controlled by the subscriber. It shall be possible for the text information to be provided by the subscriber, or by the network on behalf of the subscriber (subject to the subscriber’s agreement).

The format of this attribute shall be standardised.

b) A means to uniquely identify the watcher

c) Forward compatible presence service

Presence service shall leverage current and evolving presence technology by re-using existing standards as far as possible and proposing extensions (as necessary) to existing standards.

d) Interoperability with external presence services

e) Consistent and interoperable presence service

Regardless of the service using presence information, the presence service shall be supported in a consistent and interoperable manner between the UE and the network

f) Transport independence

It shall be possible to use the presence service independent of the bearer or transport mechanism. Restrictions may apply due to the nature of the underlying transport mechanism (e.g. a CS or PSTN terminal may not be capable to supply the same presence information as a terminal attached to the IM CN Subsystem)

g) Presence service quality of service

i) the Presence Service shall enable a watcher, if required, to request a time after which delivery of the requested information shall not take place.

ii) the Presence Service shall enable a presentity to indicate an expiry time for the presence information, if required.

iii) the Presence Service shall enable presence information delivered to a watcher to be marked with an expiry time, if required.

h) Presence and other user services

The operation of Presence Service may be offered both in parallel and independent of other services, e.g. supplementary services, teleservices, bearer services or any other services.

i) Simultaneous access to presence information from multiple terminals

It shall be possible to access presence information simultaneously from multiple terminals (e.g. presentity or watcher would be able to access the presence service via mobile phone and PC).

j) Access to the presence service from external applications

It shall be possible for external applications to be presentities/watchers.

5.4 Management requirements

The following management requirements shall be supported for the presence service:

a) Access control to the presence information

The presentity shall be able to manage the access to its presence information in compliance with the principal’s privacy and access rules requirements detailed in 6.1 and 6.2.

The presentity shall have the ability to accept or reject a request for presence information on a per watcher basis, with the option:-

i) once only per watcher (e.g. set up access rules for known watcher, groups of watchers, anonymous watcher-subscriptions, etc.),

ii) for each presence information request (e.g. for watchers that are unknown or not set up in the current access rules).

It shall be possible for the presence service to make access control decisions on behalf of the presentity (e.g. when the presentity is out of contact) subject to the principal’s privacy.

It shall be possible to inform the presentity of watcher-subscription requests

It shall be possible to report existing watcher-subscriptions to the presentity (on request or periodically).

It shall be possible for the presentity to request the watcher information.

b) Not used

c) Supplying data to the presence information

When supplying data it shall be possible to update only part of the presence information.

d) Requesting data from the presence information

It shall be possible to request the current value of presence information data on demand at any time (i.e. a fetcher) or on a periodic basis (i.e. a poller) subject to principal’s privacy, or to be notified of subsequent changes in presence information data (except when such notification is prevented by access rules

It shall be possible for a watcher to define which parts of a presentity’s presence information it receives, subject to the principal’s privacy requirements.

It shall be possible for watcher to request presence information anonymously (i.e. the watcher’s identifier will not be revealed to the presentity). This request can be accepted or rejected, depending on the principal’s privacy.

A Watcher’s interest to a presentity’s presence information shall not be revealed to other watchers.

Watcher-subscription to a presentity’s presence information

i) an entity shall be able to watcher-subscribe to a presentity’s presence information at any time, i.e. to request notification from the presence service of (future) changes in any of the attributes or only in the attributes specified by the watcher (subject to the principal’s privacy). Note, that by this watcher-subscription the entity becomes a subscribed-watcher.

ii) subscriptions are soft-stated. The subscribed-watcher shall be able to refresh a watcher-subscription to the presentity’s presence information at any time. A watcher-subscription refreshes overwrite an existing watcher-subscription for the same presentity, subject to the presentity’s access rules – the duration of a watcher-subscription starts from the time it is accepted.

iii) the subscribed-watcher shall be able to determine the status of his watcher-subscription to that presentity’s presence information, at any time.

iv) the subscribed-watcher shall be able to cancel his watcher-subscription to a presentity’s presence information at any time. Whenever a subscribed-watcher withdraws its watcher-subscription from a presentity’s presence information, the subscribed-watcher shall no longer be receiving notifications regarding the presentity’s presence information.

v) an unauthorised third party shall not be able to cancel a subscribed-watcher’s watcher-subscription to a presentity’s presence information

e) User availability and mobility

The presence service shall continue to be supported if the environment into which the user has moved supports presence service. The presence service shall take into account changes in the availability of users (e.g. the user is out of contact or not reachable, despite having activated his presence) or his mobility (e.g. wherever he may be in his home environment or in a visited network).

f) Not used

g) Access to presence service

i) it shall be possible for the presence service to accept presence information from a presentity at any time

ii) it shall be possible for the presence service to accept requests from, and provide presence information to, an authorised watcher at any time

5.5 Notification and acknowledgement requirements

The following notification and acknowledgement presence service requirements shall be supported:-

a) Presence data modification and monitoring requests

The presence service shall be able to support the acknowledgement of any requests to monitor a presentity’s presence information (i.e. from watchers)

If a subscribed-watcher establishes a watcher-subscription to a presentity’s presence information:-

i) the presence service, depending on the presentity’s access rules, shall inform the subscribed-watcher if the presentity refused the subscribed-watcher’s watcher-subscription

ii) if the subscribed-watcher’s watcher-subscription to presentity’s presence information is cancelled, the presence service shall inform the subscribed-watcher of the cancellation

iii) it shall be possible for the presentity to configure the presence service to deny a subscribed-watcher’s subscription, whilst appearing to the subscribed-watcher as if the subscription has been granted (this is sometimes called "polite blocking")