Presence means faster, easier, and more ways to communicate with fewer “no-answers”, and provides a presence-based communication for subscribers to contact with users in the contact lists due to combined with different applications and media types
- Know when others’ presence status are able to communicate- Know which media type (e.g. voice call, video call, text, instant message, or multimedia message) prefer to be contacted by- Provide users with tailored content relevant to their presence status (manage & authorize for privacy)- Route calls in the preferred medium not only to individual users – VoIP, Mobile
- Share presence information with other applications, like IM, PTx, contact list, etc.- Centralize to collect, store and manage the presence information from different sources,- Aggregate with other presence information from different networks (Fixed, Mobile
- PNA (Presence Network Agent): collects network-related Presence information from network and transform it into SIP/SIMPLE format. Different PNAs for different radio access networks: like MSC/VLR, SGSN, GGSN, GMLC, HSS and S-CSCF may be required.- PEA (Presence External Agents): collects presence information from external networks, resolves the location of the relevant presence server, depending on the presentity, and pushes presence information into it.- During subscription, the watcher or third party applications need presence information, they can subscribe to the SIP URI represented “the Presentity”. The Presence Server checks the privacy rules defined the Presence XDMS, and sends the authorized information back to the watcher.- During publication, the Presentity or PNA need to update presence information, they can publish the new updated information.
- Presence Information: authorize to share or reject, and specify what will share or send, specify what would like to receive, and also avoid useless notification
- The Presentity subscribes to its own watcher information as defined in RFC 3857 and 3858. At each new subscription, the Presentity will be notified.
- Partial (pidf-diff document - publishes only the differences) or Group presence information update
- Watcher (PUA) sends SIP SUBSCRIBE messages to the PS and to the PNA, and the PNA (PS) send back SIP NOTIFY messages at each modifications of the presence status defined in IETF RFC 3265/3856.
- Presentity sends SIP PUBLISH messages that contains PIDF document defined in IETF RFC 3903 – PIDF allows reducing the size of XML data exchanged and PS will only send the difference between the last NOTIFY message
- The subscriber asks for a specific throttle delay, and then the server according to a maximum value to control the maximum rate of notifications define in [draft-niemi-sipping-event-throttle]
- The PS can merge all notifications and provide one notification per throttle delay (reducing the number of SIP NOTIFY)
- Both PS and Client can support compression-encoding mechanism (like gzip) for the content of messages in the SIP PUBLISH, and will reduce the network load.
- Presence Data Model (RFC4479) which defines the following elements: 1. “Person” is the end-user with characteristic like the mood, the status, etc…, 2. “Device” is the client used by the end-user which has some capabilities, and 3. “Tuple” represents a communication service installed on a device.
- Keep Latest presence information & status updated or subscribed from multiple devices or IDs
- Switch between multiple modes (like Home, Work, etc.) of Presence information and status
- Authorization Rule for Presence: Authorize to allow or block presence information to be sent to watcher (which and when)
- Authorization Level from different roles to administer fields of presence: Administrator, Telecomm Manager, End-User, etc
- Multi-protocol and device access to presence: IMPP, SIP/SIMPLE, XCAP, XMPP (RFC 3920 used by Google-Talk, iChat.) or Web 2.0
- Provide charging capabilities to OFCS (via Rf/Diameter) and OCS (via Ro/Diameter)
- Comply with IETF, 3GPP, and OMA standards.
2). PS - Major Functional Entity:
2.1). Presence Server
The PS supports the following:
- Accepts, authorizes and stores Presence Information published by Presence Sources [RFC3903]
- Composes Presence Information from Presence Sources.
- Authorizes Watchers’ subscriptions and distributes Presence Information [RFC3265] [RFC3856].
- Authorizes Watcher Information Subscribers’ subscriptions and distributes Watcher Information [RFC3265] [RFC3857].
- Regulates the distribution of Presence Information and Watcher Information in the manner as requested by Watchers.
- Stores or retrieves MIME objects to/from the Content Server.
- Fetches documents from the Shared XDMS and the Presence XDMS.
2.2). Presence Source
The Presence Source is an entity that provides Presence Information to a Presence Service. The Presence Source can be located in a user’s terminal or within a network entity. The Presence Source supports the following:
- Publishes Presence Information on behalf of the Presentity according to [RFC3903].
- Stores MIME objects to the Content Server.
- Compresses/decompresses the presence related SIP messages when the Presence Source resides in the terminal.
2.3). Watcher
A Watcher is an entity that requests Presence Information about a Presentity or multiple Presentities from the Presence Service. The Watcher can be located in a user’s terminal or within a network entity. The Watcher supports the following:
- Subscribes to Presentity’s Presence Information [RFC3265] [RFC3856].
- Subscribes to multiple Presentities’ Presence Information [RFC3265] [RFC4662].
- Retrieves MIME objects from the Content Server.
- Requests the PS to regulate the distribution of Presence Information.
- Processes Presence Information.
- Compresses/decompresses the presence related SIP messages when the Watcher resides in the terminal.
2.4). Watcher Information Subscriber
A Watcher Information Subscriber is an entity that requests Watcher Information about a Presentity from the Presence Service. The Watcher information Subscriber can be located in a user’s terminal or within a network entity. The Watcher Information Subscriber supports the following:
- Subscribes to Watcher Information [RFC3265] [RFC3857].
- Requests the PS to regulate the distribution of Watcher Information.
- Compresses/decompresses the presence related SIP messages when the Watcher Information Subscriber resides in the terminal.
2.5). Resource List Server (RLS)
The purpose of the RLS is to provide an access point for list subscriptions. The RLS is the functional entity that accepts and manages subscriptions to Presence Lists, which enables a Watcher application to subscribe to the Presence Information of multiple Presentities using a single subscription transaction. The RLS supports the following:
- Authorizes Watchers’ subscriptions and distributes Presence Information [RFC3265] [RFC3856] [RFC 4662] - When an end-user wants to subscribe to a list of contacts, the Presence UE will subscribe with the SIP URI of the contact list, which will be handled by the RLS.
- Performs back-end subscriptions on behalf of the Watcher [RFC3265] [RFC3856] [RFC4662].
- Regulates the distribution of Presence Information in the manner as requested by Watchers [RFC4660].
- Propagates the Watcher’s request to regulate the distribution of Presence Information in the back-end subscriptions [RFC4660].
- Fetches documents from the Shared XDMS and the RLS XDMS - The RLS will then interrogate the RLS XDMS to define the SIP URIs of all the members of the list, and then request all the presence updates to the presence server.
- The presence information will be sent back to the Presence UE via one unique document.
2.6). Presence XML Document Management Server (PS XDMS)
The Presence XDMS is an XDMS defined in [OMA XDMAD] that supports the following function:
- Manages XML documents (e.g. Presence Authorization Rules) which are specific to the use of a PS.
- Presence XDMS is an XCAP Server and SIP notifier
- Manages Presence Authorization Policies XML documents which are specific to the Presence Enabler,
- Notifies subscribers of changes to such documents.
2.7). Resource List Server XML Document Management Server (RLS XDMS)
The RLS XDMS is an XDMS defined in [OMA XDMAD] that supports the following function:
- Manages XML documents (e.g. Presence Lists), which are specific to the use of an RLS.
- RLS XDMS is an XCAP server and SIP notifier
- Manages mapping between a SIP URI and a list. The list can be either defined into the RLS document or point out into the Shared XDMS.
- Notifies subscribers of changes to such documents.
2.8). Content Server
The Content Server is the functional entity that is capable of managing MIME objects for Presence, allowing the Presence Sources or the PS to store MIME objects within, and support retrieval of those objects by the PS or the Watchers as required for content indirection [RFC4483].
The Content Server relies on external authentication and authorization done for the Presence Sources and Watchers. When realized with 3GPP IMS or 3GPP2 MMD networks, GAA [3GPP TS 33.222] or GBA [3GPP2 S.S0114-0] can be used for that purpose.
2.9). other functional entities as described in XDM and DM.
3). PS Architecture:
| Interface | Between NEs | Protocol Used |
| PRS-1 | Presence Source – SIP/IP Core | SIP |
| PRS-2 | Watcher – SIP/IP Core network | SIP |
| PRS-3 | SIP/IP Core – Presence Server | SIP |
| PRS-4 | SIP/IP Core – Resource List Server | SIP |
| PRS-5 | Presence Server – Shared XDM Server | XCAP |
| PRS-6 | Presence XDM Server – SIP/IP Core | N/A |
| PRS-7 | Aggregation Proxy –Presence XDM Server | XCAP |
| PRS-8 | Presence Server – Presence XDM Server | XCAP |
| PRS-9 | Resource List Server – Shared XDM Server | XCAP |
| PRS-10 | Resource List Server – RLS XDM Server | XCAP |
| PRS-11 | RLS XDM Server – SIP/IP Core | N/A |
| PRS-12 | RLS XDM Server – Aggregation Proxy | XCAP |
| PRS-13 | Presence Source – Content Server | HTTP |
| PRS-14 | Watcher – Content Server | HTTP |
| PRS-15 | Presence Server – Content Server | HTTP |
| PRS-16 | Watcher Information Subscriber – SIP/IP Core | SIP |
沒有留言:
張貼留言