A.2 Detailed information flows
23.1413GPPArchitecture and functional descriptionPresence serviceRelease 17TS
A.2.1 Overview of flows used
The messages used in this clause are representative and are not meant to indicate any particular protocol as this is outside the scope of this document. In this clause the following messages have been used:
SubscribePres: This is a request by a watcher to obtain presence information about a presentity. The message may be used to either request the current presence information or to subscribe to updates of presence information for a particular time period. This flow may also be used to un-subscribe to periodic updates. The request needs to convey the presence related events that that the watcher is be interested in. A presence server may accept or deny such a request.
MsgAck: This is a generic message acknowledgement for the message flows. It may be used to indicate a positive or negative acknowledgement. In the latter case, the message may convey an indication for the rejection.
Query: This message is used by a Presentity presence proxy to request the HSS/HLR to provide the necessary information to locate a presence server that is associated with a presentity.
Resp: This message is the reply by the HSS/HLR to provide the required information to the Query message above.
NotifyPresUp: This message is used to notify a watcher of updates to a presentitiy’s presence information. The watcher would have either requested the current presence information or had previously subscribed to periodic updates. The message may contain the presence information or a pointer to the information.
PresUpdateMsg: This message is used by a Presence user agent, the Network agent, and the External agent to provide the presentity’s presence information to the Presence Server. This message shall be capable of conveying the complete set of presence information associated with a presentity. This message shall also be capable of conveying a subset of the presence information associated with the presentity. to provide updates of a presentity’s presence information to a presence server. This message needs to be able to convey the presence information associated with a presentity. The message may contain the presence information or a pointer to the information. (Note: there are similarities with the NotifyPreseUp message listed above since they both convey presence information. However for simplicity, different message names are used).
A.2.2 Flows demonstrating how watchers subscribe to presence event notification
The clause covers the flows that show how watchers can request presence information about a presentity.
A.2.2.1 IMS Watcher and IMS Presentity in the same or different IM-CN
Figure A.2.2.1-1: IMS Watcher registering for event notification
Figure A.2.2.1-1 shows an IMS watcher subscribing to presence event notification about an IMS based presentity. The presentity may either be in the same IM-CN subsystem as the watcher or may be in a different IM-CN subsystem. The flows for both these cases are the same.
Note-i: The path of the SUBSCRIBE dialog may optionally include additional I-CSCF(THIGs) in networks where network topology hiding is applied.
Note-ii: The flow shows the case that the S-CSCF of the Presentity does not remain in the path of the dialog.
The details of the flows as follows:
1. A watcher agent in a UE wishes to watch a presentity’s presence information, or certain parts of the presentity’s presence information (defined by the filters included in SubscribePres). To initiate a subscription, the UE sends a SubscribePres message request containing the presence related events that it wishes to be notified of, together with an indication of the length of time this periodic subscription should last. The UE sends the SubscribePres information flow to the proxy (subscriber identity, home networks domain name). The SubscribePres may also include an indication of the watcher’s capability to handle partial notifications.
2. The P-CSCF remembers (from the registration process) the next hop CSCF for this UE. In this case the SubscribePres is forwarded to the S-CSCF in the home network. In this case, the P-CSCF and the S-CSCF act as a Watcher Presence Proxy.
3. The S-CSCF is unable to resolve the presence server address of the presentity that the UE is requesting to watch, and as a result forwards the SubscribePres message to the an I-CSCF offering part of the Presentity Presence Proxy functionality. The S-CSCF shall examine the home domain of the presentity associated with the request and if the request is for a presentity outside the operator’s domain, it determines the external I-CSCF. If the request is for a presentity in the same domain, the S-CSCF forwards the request to the local I-CSCF.
4. The I-CSCF examines the presentity identity and the home domain identity and employs the services of a name-address resolution mechanism to determine the HSS address to contact. The I-CSCF shall query the HSS to obtain the address of the S-CSCF associated with the Presentity. It shall query the HSS via a Query message.
5. The Query Resp message from the HSS provides the name of the S-CSCF associated with the presentity.
6. The I-CSCF, using name of the Presence Server shall determine the address of the S-CSCF through a name-address resolution mechanism. The SubscribePres message is forwarded to the S-CSCF.
7. The S-CSCF using any necessary filtering criteria forwards the SubscribePres message to the appropriate Presence Server.
8. At this stage the presence server performs the necessary authorisation checks on the originator to ensure it is allowed to watch the presentity. Once all privacy conditions are met, the presence server issues a MsgAck to the S-CSCF. (In the case where the privacy/authorisation checks fail, then a negative acknowledgement is sent to the watcher).
9. The S-CSCF forwards the to the I-CSCF.
10. The I-CSCF forwards the MsgAck to the originating S-CSCF.
11. The S-CSCF forwards the MsgAck message to the P-CSCF.
12. The P-CSCF forwards the MsgAck to the watcher agent in the UE.
13. As soon as the Presence Server sends a MsgAck to accept the subscription, it sends a NotifyPresUp message with the current full state of the presentity’s tuples that the watcher has subscribed and been authorised to. The NotifyPresUp is sent along the path of the SUBSCRIBE dialog to the S-CSCF allocated to the Watcher. Further notifications sent by the Presence server may either contain the complete set of presence information, or only those tuples that have changed since the last notification if the watcher has indicated the capability to process partial notifications.
NOTE: If charging for updates to presence information per watcher is enabled, then the presentity presence proxy will remain in the SUBSCRIBE dialogue path and the NotifyPresUp is routed through the presentity presence proxy. The presentity presence proxy (S-CSCF) will provide the charging update.
14. The S-CSCF forwards the NotifyPresUp to the P-CSCF.
15. The P-CSCF forwards the NotifyPresUp to the watcher application in the UE.
16. The UE acknowledges the receipt of the NotifyPresUp message with a MsgAck sending this to the P-CSCF.
17. The P-CSCF forwards the MsgAck message to the S-CSCF.
18. The S-CSCF allocated to the presentity forwards the MsgAck to the Presence Server.
A.2.3 Flows demonstrating how presentities update Presence Information
A.2.3.1 Updating presence information by terminals without support of the Pep reference point
For the case of terminals that do not support the Pep reference point presence information can be provided alternative mechanisms such as SMS, WAP etc. The Presence User Agent provides the necessary interworking with the presence server. As previously indicated, the PUA may be located with network entities such as a WAP WML/HTTP server or SMS-C, however this is an implementation issue and outside of the scope of technical report. This particular example is illustrative and shows the case where a user updates presence information through a WAP browser, where the Presence User Agent is located inside the WAP WML/HTTP server and is illustrated in figure A.2.3.1-1 below. It is acknowledged that other possibilities exist.
Figure A.2.3.1-1: Updating presence information via WAP WML/HTTP server
1. The user opens a WAP session by requesting a WAP URL that is dedicated to updates of presence information.
2. Using a WAP browser, the user modifies aspects of ‘user presence information.
3. The WML/HTML server, which in this example hosts the Presence User Agent (although the PUA may be a separate entity, in which case the interface to the PUA will be proprietary), sends a PresUpdateMsg to the Presence Server. Additional functionality may be required to locate the presence server associated by the presentity. In this particular example, it is assumed that the PUA is configured with the appropriate address of the presence server.
4. The Presence Server acknowledges the PresUpdateMag with a MsgAck to the WAP WML/HTTP server.
A.2.3.2 IMS Registration Notification process to the Presence Server within IMS
The following flow describes how the presence server is notified of an IMS registration event by the network elements.
Figure A.2.3.2-1: IMS Registration Notification procedure for the Presence Server
1. UE registration takes place with the S-CSCF as detailed in TS 23.228 [9]. As part of this process, the filtering criteria are downloaded to the S-CSCF from the HSS. The filter criteria contains instructions that the registration be sent to the presence network agent (e.g. registration, de-registration).
2. The S-CSCF sends the registration to the Presence Network Agent via the ISC interface.
3. When the Presence Network Agent receives the notification of the IMS registration event from the S-CSCF, it determines that this registration is an event that the Presence Server is interested in and informs the Presence Sever.
A.2.3.3 CS/PS Notification process of the Presence Server
The following flow describes how the presence server is notified of an event by the network elements for a CS/PS subscriber.
Figure A.2.3.3-1: CS/PS Notification procedure for the Presence Server
1. For network event to be reported on behalf of a CS/PS subscriber, the necessary triggers are armed in the MSC/SGSN. This takes place off-line and is outside the scope of this TS as to how it is achieved.
2. At the occurrence of an event between the HLR and the MSC/SGSN, (e.g. UE detach) a notification message is generated.
3. A MAP notification message (NOTE_MM_EVENT) is sent to the Network Agent via Pc/Pg interface on the occurrence of an event, details of this are outside the scope of this flow. There may be some address resolution needed by the network agent to locate the presence server but details of this is also outside the scope of this flow.
4. The Network Agent informs the Presence Server. The Presence Server notifies all authorised watchers and sends an acknowledgement to the Network Agent.
5. Network Agent sends an MM_Event_Ack to the MSC/SGSN.
A.2.3.4 Updating presence information by terminals with Pep interface support
Figure A.2.3.4-1: Updating presence information via the Pep interface
1. The PUA residing in the UE generates a PressUpdateMsg message which contains the new presence information. The means for the PUA to compose this presence information is outside the scope of this specification.
2. P-CSCF forwards the message to the user’s S-CSCF.
3. S-CSCF forwards message to the correct Presence Server based on ISC filtering rules.
4. Presence Server authorizes the presence update, and checks what information the message contains. The Presence Server then processes the updated presence information according to the client’s request. The Presence Server sends a MsgAck response back to UE.
5. S-CSCF forwards the response back to the P-CSCF
6. P-CSCF forwards the response back to the UE.
A.2.4 Presence Server notifying watcher of updates to presence information
A.2.4.1 IMS based Watcher and presentity in the same or different IM-CN subsystem
Figure A.2.4.1-1: Presence Server updating IMS watcher
Figure A.2.4.1-1 shows how an IMS based watcher is notified of updates to a presentity’s presence information. The flows are applicable to the case where the Watcher and Presentity are in the same or in different IM-CN subsystems.
Note-i: The path of the SUBSCRIBE dialog (i.e. also the NOTIFY transaction) may optionally include additional I-CSCF(THIGs) in networks where network topology hiding is applied.
Note-ii: The flow shows the case that the S-CSCF of the Presentity does not remain in the path of the dialog.
Details of the flows are as follows:
1. The Presence Server determines which authorised watchers are entitled to receive the updates of the presence information for this presentity. For each appropriate watcher, the presence server sends a NotifyPresUp message that contains the full or partial updates to the presence information. This NotifyPresUp is sent along the path of the SUBSCRIBE dialog to the S-CSCF of the Watcher.
2. The S-CSCF forwards the NotifyPresUp message to the P-CSCF of the watcher.
3. The P-CSCF forwards the NotifyPresUp message to the UE.
4. The UE acknowledges the NotifyPresUp message with a MsgAck to the P-CSCF.
5. The P-CSCF forwards the MsgAck message to the S-CSCF.
6. The S-CSCF of the Watcher forwards the MsgAck to the Presence Server.
A.2.5 Presence User Agent subscribing to watcher list and receiving notification of a new watcher subscription
Figure A.2.5-1: Presence User Agent subscribing to watcher list and receiving notification of a new watcher subscription
Figure A.2.5-1 shows a Presence User Agent subscribing to watcher list and receiving notification of a new watcher subscription that is not contained in the current subscription authorisation policies. The details of the flows are as follows:
1) The Presence User Agent initiates a subscription to the Presence Server requesting notification of any new watcher subscriptions.
2) The presence server issues a MsgAck to the Presence User Agent.
3) A watcher wishes to watch the Presentity. To initiate a subscription, the watcher sends a SubscribePres message request containing the presence related events that it wishes to be notified of, together with an indication of the length of time this periodic subscription should last to the Watcher Presence Proxy. The Watcher Presence Proxy sends the SubscribePres information flow to the Presentity Presence Proxy.
4) The SubscribePres is forwarded by the Presentity Presence Proxy to the Presence Server.
5) The Presence Server checks the subscription authorisation policies and determines that this is a new watcher subscription not contained in the current subscription authorisation policies and so sends a notification to inform the Presence User Agent of the request from the new watcher.
6) The presence server issues a MsgAck to inform the watcher that the Presence Server has received the watcher’s request for Presence information. The MsgAck is sent to the Presentity Presence Proxy.
7) The MsgAck is forwarded by the Presentity Presence Proxy to the watcher via the Watcher Presence Proxy.
Steps 8 – 10 depend on the actions of the Principal. The Principal can ignore the notification sent in step 5 or can respond with an Update of the subscription authorisation policies to Accept, Accept with conditions or Deny the request.
8) The Presence User Agent sends an UpdateSubscriptionAuthorisationPolicies to the Presence Server. (If the Presence User Agent decides to accept, block or accept with conditions the Presence Information requested by the watcher an appropriate SubscriptionAccepted, SubscriptionBlocked or SubscriptionAcceptedWithConditions is sent within the UpdateSubscriptionAuthorisationPolicies to the Presence Server).
9) If the UpdateSubscriptionAuthorisationPolicies accepts the subscription then the Presence Server sends a NotifyPresUp message with the current state of the Presence User Agent to the Presentity Presence Proxy. If the UpdateSubscriptionAuthorisationPolicies indicates that the subscription is blocked then steps 9 and 10 are not performed.
10) The Presentity Presence Proxy forwards the NotifyPresUp message to the watcher via the Watcher Presence Proxy.
Annex B (Informative):
Void
Annex C (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2005-12 |
SA#30 |
SP-050665 |
0080 |
1 |
A |
Correction of some references to release 6 replacements |
7.1.0 |
|
2006-09 |
SA#33 |
SP-060582 |
0081 |
1 |
F |
Miscellaneous Corrections to Presence Specification |
7.2.0 |
|
2007-09 |
SA#37 |
SP-070532 |
0083 |
– |
A |
Removal of obsolete reference and editor’s note |
7.3.0 |
|
2008-03 |
SA#39 |
SP-080104 |
0773 |
2 |
B |
Update to the Presence Spec in support of the Common IMS |
8.0.0 |
|
2008-06 |
SA#40 |
SP-080363 |
0084 |
1 |
F |
Correction to Presence (Stage 2) for Common IMS |
8.1.0 |
|
2009-12 |
SA#46 |
– |
– |
– |
– |
Upgrade to Rel-9 version (MCC) |
9.0.0 |
|
2011-03 |
SA#51 |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
10.0.0 |
|
2012-09 |
– |
– |
– |
– |
– |
Update to Rel-11 version (MCC) |
11.0.0 |
|
2014-09 |
SA#65 |
– |
– |
– |
– |
Update to Rel-12 version (MCC) |
12.0.0 |
|
2015-12 |
– |
– |
– |
– |
– |
Update to Rel-13 version (MCC) |
13.0.0 |
|
2017-03 |
– |
– |
– |
– |
– |
Update to Rel-14 version (MCC) |
14.0.0 |
|
2017-06 |
SA#76 |
SP-170360 |
0776 |
– |
A |
IETF ref clean-up |
14.1.0 |
|
2018-06 |
SP-80 |
– |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
2020-07 |
SP-88 |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
SP-95E |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |