Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Method to Offload Subscrption Server Aggregation to Watchers and Multiple Servers

IP.com Disclosure Number: IPCOM000237726D
Original Publication Date: 2014-Jul-07
Included in the Prior Art Database: 2014-Jul-07
Document File: 4 page(s) / 179K

Publishing Venue


Related People

T, Satyanarayana: INVENTOR [+3]


Invention: We propose following solution to alleviate the burden on the server and make it more scalable. Watcher aggregates presence updates from multiple servers for the same presentity The proposal involves some extensions to standards to facilitate this We propose sending aggregation rules to the watchers where necessary Approach : Watcher does the aggregation from multiple sub There are two set of servers Master Presence Server It is aware of number of sources and respective secondary servers Secondary Presence Servers Set of servers each interacts with different instances of publishers Supports standard sub Watcher can fetch presence document schema, sources and respective list of servers from Master Presence Server by performing sub Watcher can interact with multiple Presence Servers as per standard sub Watcher can aggregate the presence information received in different sub There is nothing that prevents watcher from doing whatever the server does. In fact, the aggregation policy is usually application dependent and the server shouldn?t be doing it in many cases. It?s best left to the publishers and consumers. The watchers can still apply filters to block info that they don?t want by subscribing only to the secondary presence server of interest. The watchers actually receive lesser network traffic compared to the ?server-driven? aggregation approach

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 36% of the total text.

Method to Offload Subscription Server Aggregation to Watchers and Multiple Servers

By Satyanarayana T, Bhavik A. Chauhan

Motorola Solutions, Inc.



This document proposes a novel method of offloading the computation load associated with aggregation at the subscription server, to watcher clients and other presence servers.    It describes the way a watcher can get the list of servers, contact them individually with subscription requests and eventually aggregate the documents received from them. This helps in improving the overall scalability of the system.


Presence in its simple form is nothing but information about the availability of a person, device or service to communicate with each other. In the converged services world, it is common to see heterogeneous presence sources representing the same presentity publishing information. In the traditional presence solution, server gathers presence information from multiple presence sources, aggregates them and then shares the aggregated info with the watchers. Some of the watchers are only interested a subset of the aggregated information, which can be requested through a “filtering” request.

The aggregation function typically happens in two places.

1.    Publisher client aggregates for internal presence sources:

Even at client side, there can be multiple applications publishing. Instead of publishing presence information from each application separately, client can aggregate presence information on the device into a single presence document, and publish to the server.

2.    Presence server aggregates:

As shown in figure 1, using OMA composition rules, presence server aggregates the presence information from various sources into a single presence document aka “Raw Presence Document”

Fig. 1.  Presence Server Aggregates from various Publishers

Even after avoiding multiple publishes from a client (by aggregating internally), presence server still has following issues when performing aggregation.

1.    Cache-Store of large amount of PIDF data from all the sources for each of the clients:

These PIDF docs are stored in the DB. But, for faster access and lower CPU utilization, we need to avoid multiple DB reads and so, store the documents in memory.

This can consume large amounts of memory. Most of this memory needs to be physical memory to avoid page faults to disk which increase CPU consumption. Moreover, if the server is a 32-bit process, the memory can be limited to 4GB.

When aggregation is done inside the server, the composite documents also need to be maintained in the server. This will more than double the memory needs.

2.    Overhead of Aggregation operations:

Parsing, validating and formatting of PIDF is CPU intensive, as it is XML based.

When handling partial PIDF’s (P-PIDF), the processing gets even more complex. In many cases, a P-PIDF may need to be generated from two composite PIDFs, which is complex.


If the presence documents are passed as-is to the watchers, the...