Michael Pitman mikep @crg.ee.uct.ac.za

1. CoE Industry Seminar August 2008 Aggregation Efficacy in IMS Presence-based Resource List Servers Michael Pitman mikep@crg.ee.uct.ac.za Neco Ventura neco@crg.ee.uct.ac.za

2. Presentation – Order of Development • The IMS • The IMS and Presence – Presence Architecture • Role of the Resource List Server • RLS Functions in the IMS • RLS Operational States • Inefficiencies in IMS and IETF Presence • RLS Aggregation Methods • Experimental Verification of RLS Performance • Verification of RLS Aggregation • Conclusion • Questions and Answers

3. The IMS and Presence • Presence is a status indicator conveying the ability or willingness of a party to communicate • Offers an indication of user availability, rather than only the connection availability of PSTN (i.e. a dial tone) • Often implemented in fragmentary, proprietary non-interoperable standards in the internet • IMS Presence is based on RFCs for operation and formatting, but follows the IMS signalling pathways from terminal to core • Resource List Server is a core network proxy, aggregating XML-encoded presence from the Presence Server (PS) to Presence User Agents (PUAs)

4. IMS Presence Architecture

5. Role of the Resource List Server • The RLS is an IMS Core-based Presence Application Server • Maintains Resource Lists of presentities and their watchers • Aggregates the presence information from Presence Servers to subscribing PUAs • Reduces data processing and packet overhead at the PUA • Moves repetitive SIP signalling to presentities to the bandwidth-rich core network, away from the PUA • General operational specifications covered in IETF and 3GPP standards

6. RLS Functions in the IMS - Subscribing • Watcher SUBSCRIBE with a Resource List Server

7. RLS Operational States • Each subscription to RLS exists in one of two operational states – Initialisation and Steady-State • Initialisation: • Device log-in, or initial access to service • Phone/device turned on, or becomes default presence device • Of short duration, but high volume of traffic • All subscribed presence/watcher information is sent rapidly to PUA

8. RLS Operational States • Steady-state: • Stabilisation of traffic volumes, following on from the initialisation state • Normal, long-term operational state for subscriptions • Steady, random distribution of NOTIFY arrivals • NOTIFY messages generated by changes in subscribed presentity or watcher information

9. RLS Operational States Traffic Volume Curve for Subscription Life-time Initialisation Steady-state Traffic Volume Time

10. Inefficiencies in IMS and IETF Presence • IMS uses SIP for signaling – a human-readable application-layer protocol based on the HTTP request-and-response model • High network stack layer allows greater interoperability across devices and architectures • Text-based SIP headers are bulky and inefficient in terms of information encoding efficiency • Presence information is encoded in XML • Hierarchical and fully extensible data encoding format • High readability leads to a low encoding efficiency • Results in high level of data redundancy • Inefficient use of limited access-network bandwidth, for an add-on service

11. Small XML-encoded “Rich” Presentity <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:im="urn:ietf:params:xml:ns:pidf:im" xmlns:myex="http://id.example.com/presence/" entity="pres:someone@example.com"> <tuple id="bs35r9"> <status> <basic>open</basic> <im:im>busy</im:im> <myex:location>home</myex:location> </status> <contact priority="0.8">im:someone@mobilecarrier.net</contact> <note xml:lang="en">Don't Disturb Please!</note> <note xml:lang="fr">Ne derangez pas, s'il vous plait</note> <timestamp>2001-10-27T16:49:29Z</timestamp> </tuple> <tuple id="eg92n8"> <status> <basic>open</basic> </status> <contact priority="1.0">mailto:someone@example.com</contact> </tuple> <note>I'll be in Tokyo next week</note> </presence> [2]

12. RLS Aggregation Methods • Aggregation methods should reduce message frequency and overhead, while ensuring timeous delivery • May be individually suited to a specific subscription operational state • Time, Quantity, MTU or Selective Updating methods available • Time-based: Aggregate after x seconds/minutes • Initialisation: very large amounts of data transmitted, periodically – ineffective and inefficient • Better suited to a steady-state subscription • Quantity-based: Aggregate after x updates • Suitable for both subscription states • Issue of timeliness for steady-state subscriptions

13. RLS Aggregation Methods • MTU-based: Aggregate when the payload + overhead reaches the MTU of the access network • Maximum payload/overhead efficiency, but timeliness questions for steady-state subscriptions • User-preferences can also be accommodated: • Selective Updates: Only specific presentities or presence information changes generate updates sent to the PUA • Can be used conjunction with time-based aggregation • Combinations of methods likely to give best performance under most conditions – particularly if dynamic • Correct choice of parameters for methods imperative • Polling may obtain presence information “once-off”, either through the RLS, or bypassing it.

14. Experimental Verification of RLS Performance • This work is to perform an experimental verification of the known concepts which led to the definition and specification of the RLS in literature • The performance of a RLS under varied operational conditions is not known, and likely to vary considerably: • Large x values in steady-state quantity aggregation can negatively affect timeous delivery • Small x values in steady-state time aggregation result in many updates, diminishing aggregation effectiveness • Large x values in initialisation-state time aggregation can entirely negate the operational benefits of RLS • Empirical testing of developed RLS will provide data and insight into the RLS performance issues raised

15. RLS Aggregation Concept Verification • Simulations were performed to validate the initial concept • Presented is a scenario of time-based aggregation on a stabilised, steady-state RLS subscription. • Aggregation parameter of 5s between PUA NOTIFY updates • Resource list split in two, with each group having a different level of activity: • 15% had 0.01 probability of updating per second • 85% had 0.0001 probability of updating per second • Simulation had duration of 1000s • Simulation repeated, with resource list size increased each iteration, from 1 to 100 presentities

16. RLS Aggregation Concept Verification - Graph

17. In Conclusion • Presence is a basic network service with great potential as an application in the IMS • The data representation of presence information, and SIP signalling for presence is very bandwidth intensive • The RLS moves most presence traffic from the bandwidth-restricted access network to the bandwidth-provisioned IMS core • The effectiveness of RLS aggregation techniques depend on the subscription state, load, and aggregation parameters • The RLS can reduce the presence traffic to the PUA considerably when applied correctly

18. In Closing • Thank you for your time • Questions and Comments?

19. References • [1] G. Camarillo and M. A. Garcia-Martin, The 3G IP Multimedia Sub-system (IMS) - Merging the Internet and the Cellular Worlds, Ch 17, pp. 323–328. John Wiley and Sons, Ltd, 2nd Ed., 2006. • [2] H. Sugano, S. Fujimoto, G.Klyne, A.Bateman, W.Carr and J. Peterson, “RFC 3863, Presence Information Data Format (PIDF),” 2004