6 Presence attributes

23.1413GPPArchitecture and functional descriptionPresence serviceRelease 17TS

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

6.1 Presence Attributes

Presence attributes describe the presentity. As the type of the presentity can vary significantly the definition of generic attributes is practically impossible. Attributes can be defined by the service providers and manufacturers as part of the other presence markup as specified in IETF (e.g. RFC 2778 [16], RFC 2779 [17]). The values (and process of generating them) and value ranges for all attributes shall be kept relatively simple. It is necessary for the 3GPP subscriber to understand how the values are set/modified as it may have direct impact to whom the access to presence data is given (as defined by the subscription authorisation policies).

6.1.1 Subscriber Presence Attributes and Values

A subscriber is described by attributes: subscriber’s status, communication means status, one or more communication address(es) (containing communication means and contact address), location (subscriber provided location and/or network provided location), priority, text. The attributes can be categorised as communication means and contact address specific information or generic information. Generic information attributes shall be: subscriber’s status, location and text. Communication means and contact address specific information attributes shall be: communication means status, communication means, contact address, priority and text.

– Generic information attributes, if these attributes are used as part of any tuple they shall use following values (values in parenthesis) to enable interoperability:

– Subscriber’s status (willing, willing with limitations, not willing, not disclosed),

NOTE 1: Attribute name subscriber’s status has been defined in stage 1 and it does not imply any mapping to the IETF defined presence model e.g. IETF RFC 2778 [16], IETF RFC 2779 [17].

The subscriber’s status attribute is not intended to be used when interworking with IM clients. Subscribers are able to provide more detailed willingness information as well as other information through the generic Text attribute, and the communication means and contact address specific Text attribute.

– Location (e.g. Last known CGI/SAI and/or geographic co-ordinates and/or free format text and timestamp),

– Text (free format text).

– Communication means and contact address specific information attributes, if these attributes are used as part of any tuple they shall use following values (values in parenthesis) to enable interoperability:

– communication means status (online, offline),

– communication means (Service type (e.g. telephony, SMS, email, multimedia messaging service, instant messaging service)),

– contact address (E.164 (e.g. MSISDN), SIP URL, Email, Instant message address e.g. IM:name@domain name),

– Priority (Priority order for each of the defined communication means and contact address),

– Text (free format text).

NOTE 2: The mapping of these attributes and values to the IETF defined presence model IETF RFC 2778 [16], IETF RFC 2779 [17] may result one or several of the following:

– using existing IETF defined attributes and values (or subset of them)

– using existing IETF defined attributes but extending the value set

– Creating new attributes to the tuples.

The mapping of these values for tuples and different fields of the tuple is defined in stage 3. Furthermore, mechanisms to allow extensibility of the presence information in order to ensure interoperability are defined in stage 3.

All these attributes shall be able to contain value NULL to enable polite blocking.

6.1.2 Presence Structure to Support Multiple Values for Attributes

Attributes shall be mapped to separate tuples which have unique identifiers. If the presentity wants to show different presence information concerning one attribute to different watchers the presentity shall create more than one tuple that contain the same attribute with different value. The association of tuples to different watchers and watcher groups shall be based on the subscription authorisation policies. The presentity controls the value of the attribute by modifying the corresponding tuple. Figure 6.1.2-1 illustrates how different values for different watchers are provided utilising subscription authorisation policies.

NOTE: The figure 6.1.2-1 is illustrative only and it shall not mandate or limit the server implementation options.

Figure 6.1.2-1: Illustration how subscription authorisation lists are utilised to present different values of the same attribute to different watchers

6.2 Presence Information Model

Presence information related to a particular communications means and contact address shall be carried in a presence tuple dedicated to that particular communications means and contact address.

Generic presence information that is not directly applicable to a particular communications means and contact address shall be conveyed in a way that conforms to the IETF presence model e.g. IETF RFC 2778 [16], IETF RFC 2779 [17] (to ensure interoperability) and preferably does not require multiple instances of this information to be sent.

Generic information may be mapped to the tuples specific to each communication means and contact address. In that case the information shall be equal in each tuple. The stage 3 description should use a mechanism which conforms to the IETF presence model.

Application identifiers may be allocated to applications, which are using presence capabilities. The conventions and the allocation mechanism for application identifiers are subject to stage 3 specification. Application identifier(s) are carried as part of the presence information. Application identifier(s) may be added to published presence information on the presentity side. In this case, the presence server shall include this application identifier to the relevant tuple(s) in the presence document together with the published information. On the watcher side the received application identifier may be used e.g. for determining which application should receive and process the related presence information. Details of processing the application identifier(s) on the Presence User Agent and watcher side are out of scope of this specification.