9 Administration
22.1413GPPPresence serviceStage 1TS
The following administration requirements shall be supported.
Note: The different logical steps (provision, registration, activation) might be combined. For example when a principal requests a watcher-subscription, a watcher associated with him is automatically registered in the Presence Service.
9.1 Provision
Provision is an action taken by the service provider to make the presence service available to a principal. Provision may be:
– General: where the service may be made available to all principals without prior arrangements being made with the service provider.
– Pre‑arranged: where the service is made available to an individual principalonly after the necessary arrangements such as login name, password have been made with the service provider.
This provision action shall allow the principals to subsequently register within the Presence Service as a presentity, as a watcher or as both.
9.2 Withdrawal
Withdrawal is an action taken by the service provider to withdraw the presence service from the principal. Withdrawal may be:
– General: where the presence service is removed from all principals
– Specific: where the presence service is removed per principal.
9.3 Registration
Registration is an action taken by the service provider or the principal to provide information necessary for presentities and/or watchers to use the Presence Service. For example, a subscriber could request the creation of a presentity associated with him and provide the corresponding access rules.
It shall be possible to take this registration action under the condition that the presence service is available for the principal. (i.e. the provision has been performed previously).
This registration process may be performed at any time by the principal or service provider to create new presentities/watchers.
The service provider may provide privacy control at registration time on behalf of a presentity.
9.4 Erasure
Erasure is an action taken at any time by the service provider or the principal in order to cancel a registration.
9.5 Activation
Activation is an action taken at any time by the service provider, the presentity or the watcher to bring the Presence Service into the active state.
It shall be possible to activate the service once the presentity or watcher has been registered.
Once the presentity or watcher is in an active state,
– This presentity or watcher may invoke Presence Service features
– Other presentities or watchers may invoke Presence Service features concerning this presentity or watcher (e.g. by subscribing to its presence information)
– The Presence Service may invoke Presence Service features concerning this presentity or watcher (e.g. by notifying changes in the presence information)
9.6 Deactivation
Deactivation is an action taken at any time by the service provider, the presentity or the watcher to bring the Presence Service into the non-active state.
9.7 Invocation
Invocation is an action taken at any time by the presentity or watcher (e.g. by requesting presence information) or by the Presence Service as a result of a particular condition (e.g. by notifying presence information’s changes) in order to invoke the Presence Service features.
Annex A (informative):
Example presence service use cases
Immediate Messaging Use Case
– Premise:
User is in-and-out of coverage
Others wish to send a message and get a response – now
– Considerations
User’s Presence provides info regarding availability (Yields measure of Probability of message delivery)
– Presence capability can be separated from IM
Functional Separation
– Sequence
User is out and about (having meetings or just travelling)
Availability status gets updated as needed (User control – change to ‘unavailable – in meeting’, Network control – out-of-coverage / busy-in-call)
– Co-worker wants to send you a note
Check of Presence Info lets others see if user is available (If available – provides addressing info (e.g. IM server / account ids))
– IM Server handles message deliveries
Status updates available at any time
Location Info in Presence Use Case
– Premise:
User is travelling per a schedule
Others looking to find out when user will arrive
Alternative model is to know where to go to meet user
– Considerations
User’s Presence Info could have activity indicator (e.g. ‘in a meeting’ or ‘driving’)
– System may have access to location information on user
Issue would be the granularity/resolution
– System may have access to user’s ‘calendar’
Would make a plan available
– Security/authentication aspects of disclosures
– Sequence
User is out and about (having meetings or just travelling (Assume that user activity indication available (For example: ‘unavailable – driving’)
System could correlate location information with activity (Answer questions like – is user at planned meeting?, If travelling, could correlate distance with minimum transit time)
System could maintain progress on plan from calendar (System may be able to determine if user is running late or not, User could revise plan or provide annotated information)
Co-worker wants to know if you are available (System provides current activity, possible links to schedule)
– Family wants to know if user is on way home
Activity indication of ‘driving’ may assist in determination
Current location info could help determine how far from home
– Meet-me example
Service may correlate matching info (Example where Activity Indication – ‘Shopping’ & Location – ‘Mall’, Friend with matching codes could be flagged, Could IM to determine which store or to have lunch)
Service could manage meeting maker (May have appointment scheduled with others, Could check status to see if everybody was in right location)
Message Modality Control Use Case
– Premise:
User has different means to communicate (voice, text…)
User may indicate preferences
Voice number is managed by entity monitoring status
– Considerations
Content format adaptation available (e.g. text-to-speech (synthetic voice) or speech-to-text)
User preferences set desired message format (May change the official communication device address)
Related services subscribe to user status (Cell net could be watcher to provide value-add/quick routing)
– Sequence
User is in a meeting (can’t take a phone call)
Status shows ‘busy – in a meeting’ (Presence status listed as ‘unavailable for voice’, Option for speech-to-text delivery provided if available)
If friend can send text – does so (Works as expected)
If friend has a voice device (Calls into user’s number, Switch sees speech delivery disabled – conversion offered, Switch connects caller to speech-to-text converter, Text is sent to user, If caller stays on circuit, could engage in two-way dialog)
– Premise:
User is travelling and changes plane
Others looking to communicate with the user
Service available to ‘take a message’
– Considerations
Service has access to User’s state
Service could be associated with User info (May be dependent on state or watcher identification)
Service may deliver ‘markup’ contact for reply (Ideal is to enable programmable or responsive operations)
Traveler Changing Planes Use Case
– Sequence
User is on a plane
User (more correctly – device) is not connected to any network (Presence status listed as ‘unavailable’, Service (‘take a message’) shown as available)
Friend wants to pass some info and sees ‘unavailable’ status (Uses ‘take a message’ to save a friendly note)
Co-worker needs some specific info (Uses ‘take a message’ to record a ‘get back to me’ note)
– User arrives at airport
User (more correctly – device) is not connected to any network (Presence status listed as ‘unavailable’, Service (‘take a message’) shown as available) ‘Take a Message’ Service gets update and sends a report (Provides an inbox type message)
User may interact to read the messages (stored by service) (Messages could be selectively managed (read/forward/delete))
Addresses in Notes are associated with status information (Effectively invokes a dynamically generated buddy list, May have been entities that were not part of regular buddy list, Very easy to ‘return the call’ with know availability information)
– User gets on next plane
Status changes again – reverts to unavailable handling
Annex B (informative):
Change history
|
Change history |
|||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
TSG SA# |
SA Doc. |
SA1 Doc |
Spec |
CR |
Rev |
Rel |
Cat |
Subject/Comment |
Old |
New |
Work Item |
|
22.141 |
Produced during Presence Adhoc 18th-19th April, Seattle, Washington, USA |
0.0.0 |
0.1.0 |
Presence |
|||||||
|
22.141 |
Produced during S1 plenary 7th-11th May, Helsinki, Finland |
0.1.0 |
0.2.0 |
Presence |
|||||||
|
22.141 |
Produced for TSG-SA#12 |
0.2.0 |
1.0.0 |
Presence |
|||||||
|
22.141 |
Produced during Presence adhoc 5th-6th June, Sophia Antipolis, France |
1.0.0 |
1.1.0 |
Presence |
|||||||
|
22.141 |
Produced during Presence adhoc 26th-28th June, Dallas, Texas, USA |
1.1.0 |
1.2.0 |
Presence |
|||||||
|
22.141 |
Produced during Presence adhoc 10th -11th July, Lake Tahoe, Nevada, USA |
1.2.0 |
1.3.0 |
Presence |
|||||||
|
22.141 |
Produced during Presence adhoc 10th -11th July, Lake Tahoe, Nevada, USA |
1.3.0 |
2.0.0 |
Presence |
|||||||
|
SP-13 |
SP-010444 |
S1-010841 |
22.141 |
Rel-5 |
Approved at SA #13 |
2.0.0 |
5.0.0 |
Presence |
|||
|
SP-14 |
SP-010677 |
S1-011059 |
22.141 |
001 |
Rel-5 |
C |
Protection against replay attacks |
5.0.0 |
5.1.0 |
PRESNC |
|
|
SP-14 |
SP-010677 |
S1-011210 |
22.141 |
002 |
Rel-5 |
C |
Reserved for Presence |
5.0.0 |
5.1.0 |
PRESNC |
|
|
SP-14 |
SP-010677 |
S1-011211 |
22.141 |
003 |
Rel-5 |
C |
Clarification to Presence access rules |
5.0.0 |
5.1.0 |
PRESNC |
|
|
SP-14 |
SP-010677 |
S1-011212 |
22.141 |
004 |
Rel-5 |
B |
Clarification on charging mechanisms |
5.0.0 |
5.1.0 |
PRESNC |
|
|
SP-14 |
SP-010677 |
S1-011213 |
22.141 |
005 |
Rel-5 |
F |
Clarification of registration and administration procedures |
5.0.0 |
5.1.0 |
PRESNC |
|
|
SP-14 |
SP-010677 |
S1-010960 |
22.141 |
006 |
Rel-5 |
F |
Use of ‘Principal’ within TS 22.141 |
5.0.0 |
5.1.0 |
PRESNC |
|
|
SP-14 |
SP-010677 |
S1-011218 |
22.141 |
008 |
Rel-5 |
F |
Clarification of presence information requirements |
5.0.0 |
5.1.0 |
PRESNC |
|
|
SP-15 |
SP-020056 |
S1-020306 |
22.141 |
009 |
Rel-5 |
D |
A brief introduction to the Presence Service |
5.1.0 |
5.2.0 |
PRESNC |
|
|
SP-15 |
SP-020056 |
S1-020307 |
22.141 |
010 |
Rel-5 |
D |
Correction to the number of roles in the Presence Service |
5.1.0 |
5.2.0 |
PRESNC |
|
|
SP-15 |
SP-020056 |
S1-020430 |
22.141 |
011 |
Rel-5 |
C |
CR 22.141 Rel.5 Selective Notifications |
5.1.0 |
5.2.0 |
PRESNC |
|
|
SP-15 |
SP-020056 |
S1-020602 |
22.141 |
012 |
Rel-5 |
F |
CR to 22.141 – Clarifications on identifier’s hiding |
5.1.0 |
5.2.0 |
PRESNC |
|
|
SP-15 |
SP-020056 |
S1-020619 |
22.141 |
013 |
Rel-5 |
C |
CR to 22.141 on Multiple terminal support in presence service |
5.1.0 |
5.2.0 |
PRESNC |
|
|
SP-15 |
SP-020056 |
S1-020623 |
22.141 |
014 |
Rel-5 |
C |
Access from external applications |
5.1.0 |
5.2.0 |
PRESNC |
|
|
SP-16 |
SP-020267 |
S1-021043 |
22.141 |
Rel-6 |
Updated from Rel-5 to Rel6; Rel5 deleted |
5.2.0 |
6.0.0 |
||||
|
SP-17 |
SP-020560 |
S1-021592 |
22.141 |
015 |
Rel-6 |
F |
Presence TS – Cleaning of requirements |
6.0.0 |
6.1.0 |
PRESNC |
|
|
SP-17 |
SP-020560 |
S1-021781 |
22.141 |
016 |
Rel-6 |
F |
Presence TS – Tidy up of security requirements |
6.0.0 |
6.1.0 |
PRESNC |
|
|
SP-19 |
SP-030025 |
S1-030066 |
22.141 |
017 |
– |
Rel-6 |
C |
Clarification of network status attribute description within Presence Service Stage 1 |
6.1.0 |
6.2.0 |
PRESNC |
|
2004-07-02: Repair corrupt file. |
6.2.0 |
6.2.1 |
|||||||||
|
SP-26 |
SP-040728 |
S1-040993 |
22.141 |
018 |
– |
Rel-6 |
F |
Delete Requirements for IP session function |
6.2.1 |
6.3.0 |
OSA3 |
|
SP-27 |
SP-050059 |
S1-050219 |
22.141 |
019 |
– |
Rel-6 |
F |
Removal of Reference to TS 22.121 |
6.3.0 |
6.4.0 |
TEI |
|
Rel-6 |
2005-07: |
6.4.0 |
6.4.1 |
||||||||
|
SP-30 |
SP-050806 |
– |
22.141 |
0021 |
1 |
Rel-6 |
F |
Correction to Reference in Presence TS |
6.4.1 |
6.5.0 |
PRESNC |
|
SP-30 |
SP-050747 |
S1-051225 |
22.141 |
0022 |
– |
Rel-7 |
F |
Introduction of generic (non-wireless specific) Presence Service |
6.4.1 |
7.0.0 |
FBI |
|
SP-42 |
– |
– |
Rel-8 |
Updated from Rel-7 to Rel-8 |
7.0.0 |
8.0.0 |
|||||
|
SP-46 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-9 by MCC |
8.0.0 |
9.0.0 |
|
|
2011-03 |
– |
– |
– |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
9.0.0 |
10.0.0 |
|
|
2012-09 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-11 by MCC |
10.0.0 |
11.0.0 |
|
|
2014-10 |
– |
– |
– |
– |
– |
– |
– |
Update to Rel-12 version (MCC) |
11.0.0 |
12.0.0 |
|
|
2015-12 |
– |
– |
– |
– |
– |
– |
Updated to Rel-13 by MCC |
12.0.0 |
13.0.0 |
||
|
2017-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-14 by MCC |
13.0.0 |
14.0.0 |
|
|
2019-07 |
– |
– |
– |
– |
– |
– |
– |
Update to Rel-15 version (MCC) |
14.0.0 |
15.0.0 |
|
|
SA#88e |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-16 by MCC |
15.0.0 |
16.0.0 |
|
|
2022-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-17 by MCC |
16.0.0 |
17.0.0 |
|