Presence in Mobile VoIP Networks
Leveraging Hidden Network Assets to Add Value to Operator Service Offerings
BY ALEX SCHNEYDERMAN
Addressing PTT Limitations with Presence
Push-to-Talk service allows users to communicate with their mobile phones in the manner similar to walkie-talkie radios. This application is one of the today’s most promising new services (usually based on VoIP technology) in cellular telephony. The majority of the PTT systems today do not come with presence functionality, which negatively affects the user experience.
For example, the client presence can enhance PTT directly by allowing the user to make call decisions based on presence information presented in the form of availability icons in the PTT client (similar to desktop instant messengers), thus enabling “opportunistic Push-to-Talk.” (In opportunistic communications called-party availability is known prior to calling, reducing user hesitation.) Presence makes opportunistic calling much more likely, since subscribers will be more inclined to make calls if their contacts are shown as available in their presence-enabled Push-to-Talk address book. The network presence can bring even more value to PTT service by allowing the PTT Server to expedite decisions not to complete calls to users who are found not to be available, thus avoiding uncompleted or failed calls.
One of the most recognized problems in current VoIP-based PTT systems is the appreciable delay (a few seconds) due to the “wake-up” of CDMA radios on both the originator’s and recipient’s mobile devices during the initial call setup. In order to reduce this delay, the caller’s device and the PTT servers can allow the caller to begin speaking before the terminating mobile is contacted. The PTT infrastructure buffers the data, and delivers it to the terminating mobile after the terminating mobile device goes through the dormant-to-active transition. Unfortunately, when the terminating mobile is on a voice call or otherwise unreachable (and its presence has not been properly reported to the PTT server), the originator receives a “not available” tone several seconds after they begin speaking. This severely degrades the PTT user experience.
The PoC standards groups attempted to address this problem with Unconfirmed Indication functionality (defined in Open Mobile Alliance (OMA) document “Push-to-Talk over Cellular (PoC) — Architecture V 1.0 draft) in which the PoC server confirms readiness to receive media before it has received confirmation from downstream elements. This solution, however, is error-prone (for instance: the caller receives a confirmation tone before the network has received positive confirmation of the receiver’s reachability). This limitation of Unconfirmed Indication can be easily addressed by network presence detection, which eliminates the error from unconfirmed indication by making real-time accurate network presence information available to PTT infrastructure. Based on this information the unconfirmed indication is offered only when it has a high probability of success allowing to significantly reduce or completely eliminate error rates.
The Presence platform must be able to discover the following information about the subscriber to create an accurate and comprehensive view of a subscriber availability to be useful for PTT service:
- Is the Mobile Station (MS) active and reachable from a cellular network perspective (detected through SS7 presence by obtaining the MS status from the Home Location Registry)?
- Does the MS have an active registration to the PTT service (detected through PTT Location server interrogation)?
- Is the MS engaged in a circuit voice call (in other words in Busy state — detected through SS7 by interrogating or triggering HLR)?
- Does the MS have an active PPP session that supports PTT service (detected through AAA server query)?
It is possible to illustrate a high-level view of interoperation of PTT and Presence Service (Figure 1). The PTT Server is constantly updated with real-time status of PTT users by a presence server. The PTT server may be set up to poll the presence server reactively for called party status whenever the caller initiates PTT call. Alternatively, presence servers can periodically push the MS presence status changes updates to PTT server. To achieve this PTT servers supporting SIMPLE interface can be set up to SUBSCRIBE for MS presence information, in response, the presence server NOTIFIES the PTT server of the MS availability and subsequent presence status changes. The following is the sequence of events in a typical PTT call set up scenario:
- Caller initiates a Push-to-Talk session (client places an INVITE to Dispatcher).
- The Dispatcher sends a query to the Presence Engine in parallel with placing a call to the target subscriber.
- Alternatively Presence Engine maybe set up to constantly update Dispatcher with presence information received from AAA Server or HLR.
- Presence Engine queries the HLR and AAA Server for circuit call state information and sends called party status to the Push-to-Talk Dispatcher.
- Caller is only allowed to start transmitting voice to the Media Controller (where it is buffered) if the called party is both REGISTERED and not on a 2G phone call. In the event that the called party is available, the buffered media is sent on to their mobile device.
Centralized Presence Platform — Requirement for Large-Scale Deployment
A presence service which meets the complex requirements of VoIP applications such as PTT can be cost-effectively deployed in service provider networks by introducing a centralized platform called a presence server. This platform tasked with discovery, aggregation and deployment of presence information can significantly reduce the initial operator investment by providing a shared presence source for all applications, clients and other network entities such as PTT, and call routing servers.
Having such a centralized presence source, enables the operator to implement complex, tiered presence policy structures required by different applications and easily meet the needs of individual users. For example, the users can be provided with functionality allowing them to restrict the others wishing to subscribe to their presence. In the other example the operators can provide the subscribers with tiered presence service allowing them to charge more for different presence accuracy levels.
Ready For Primetime!
During the last two years, presence technology has matured to the point where presence-enhanced applications are ready for primetime deployment. Currently presence solutions are being deployed in various shapes and forms around the world. Carriers’ deployment strategy is now focused on introduction of presence functionality to the network via a staged approach. Initially, carriers will address the existing networks limitations and shortcomings, then add presence to operator service offerings, such as PTT contact lists and VoIP phones address books, and finally, operators will introduce an entirely new class of applications made possible by presence; like presence-based gaming, instant conferencing, intelligent alerting, and others.
Such staged deployment strategy offers service providers relatively low investment risk while still providing sizable benefits in the foreseeable future. Operators embracing this approach do not need to wait for the illusive “killer app” to start adding presence to their existing infrastructures. They instead are focusing on the implementation details of this new exciting technology, which places them ahead of the competition, helps them to better differentiate their offerings, and provides positive short-term return on investment with significant long-term revenue potential.
Page 2 of 2 [Back to Page 1]
Alex Shneyderman is senior product manager at dynamicsoft. For more information, please visit the company online at www.dynamicsoft.com.
If you are interested in purchasing reprints of this article (in either print or HTML format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.
[ Return To The September 2004 Of Contents ]