Content for TS 22.141 Word version: 18.0.1
4.1 Informative models p. 10
The below models of the presence service and presence information are not definitive, and no implementation model or architecture is implied or required by them, and are solely provided to describe the functions and roles that shall be provided by the presence service.
4.2 Roles in the presence service p. 10
The presence service may be considered to support two main roles, as depicted in Figure 4.2-1 "Presence service model".
For the purposes of this TS, the following roles are identified to support the presence service:
- Suppliers of presence information This role represents those entities that supply presence information.
-
Requesters of presence information
This role represents those entities which request (and subsequently receive) presence information of a presentity. The presence information may also maintain data on requesters of presence information, which may also be potentially distributed (on request) to requesters of presence information. The term watchers is used to identify the requesters of presence information.
The requesters of presence information may be associated with 2 modes of operation:
- Information Mode This mode corresponds to a request-response mode and represents those entities (i.e. watchers) which simply request the current presence information of a presentity. The term "fetchers" is used to identify the receivers of this type of presence information of a presentity. The term "pollers" identifies the type of fetchers that request the presence information of a presentity on a regular or periodic basis.
- Notification Mode This mode corresponds to a 'push-type' mode and represents those entities (i.e. watchers) which request notifications on (future) changes in presence information of a presentity. The term subscribed-watchers is used to identify the receivers of these notifications. Watcher-subscriptions for subscribed-watchers are soft-stated i.e. they are time-bound, notifications of presence information cease on expiry of the negotiated interval. The subscribed-watcher is allowed to 'refresh' a watcher-subscription at any time. Watcher-subscription refreshes overwrite an existing watcher-subscription for the same presentity, subject to the presentity's access rules.
The key concepts captured in Figure 4.2-2 are as follows:
- a principal may be associated with one or more watchers
- a watcher is associated with one principal
- a presentity is associated with one principal
- a principal may be associated with one or more presentities.
- a presentity may be associated with one or more presence-tuples
- a watcher can have a watcher-subscription to one or more presentities
- a presentity may be watched by one or more watchers
4.3 Presence information p. 12
A logical model of a presentity's presence information consists of an arbitrary number of elements, known as presence tuples, as depicted in Figure 4.3-1. Presence information for each presentity is identified by a unique identifier.
Each such presence tuples contains the following information as described in RFC 2778 [3]:
- status
| Item | Explanation | Example Values |
|---|---|---|
| status | Indicates the current condition of the device or service represented by the presence tuple | open, closed, online, offline, busy, away, do not disturb etc. |
- communication address consists of a communication means and a contact address
| Item | Explanation | Example Values |
|---|---|---|
| communication means | Information indicating a method whereby communication can take place | service type (e.g. telephony, SMS), media type (e.g. audio, video, text message), multimedia messaging service, instant messaging service etc. |
| contact address | Information indicating a specific point of contact via some communication means | E.164, URI, instant inbox address etc |
- other presence markup any additional presence information
