Implementing Two-sided Revenue Models in IMS: Challenges & Opportunities
Could two-sided business models be the driver that full-blown IMS deployments have lacked?
This guest post was contributed by Mohan Palat, Product Marketing
Manager, Sonus Networks
IMS (IP Multimedia Subsystem), originally designed by 3GPP for wireless networks in 2003 and later adopted by TISPAN for NGN/fixed networks, was developed as an access-agnostic service delivery network on top of the IP packet data network. Its goal was to facilitate the development and deployment of new IP-based services, with a set of common functions (service enablers).
Since it was first developed, IMS has gone through a number of incarnations. Initially, it was seen as the architecture for supporting push-to-talk (PoC) and instant messaging services but failed to create much market traction. The next incarnation of IMS was in the NGN/fixed networks, mostly for VoIP. While NGN has been largely successful, IMS has, again, enjoyed only limited traction in this market. More recently, IMS has focused on 3G/4G networks with LTE and RCS applications and services.
To this day, IMS has never realized its full potential primarily because it does not have a profitable business case, which, in turn, is largely due to the lack of compelling and practical applications that interest consumers. However, new business and revenue models, such as the two-sided revenue model, hold the promise of improving the business environment for IMS.
In a two-sided revenue model, the service provider acts as a facilitating platform for commercial interaction between consumers and application providers. The consumer is charged for consuming the content and the application provider is charged for the privilege of using the operator’s network to deliver the content/service. This revenue model opens up the IMS network to third-party applications and services, allowing service providers to offer a wide range of applications to consumers.
While the iPhone App Store is often the benchmark in mobile networks for this business model, Apple has the advantage of controlling the customer experience. In open and interoperable network environments based on IMS (fixed or mobile), however, enabling a two-sided business model is much more complex. Unlike in the iPhone’s two-sided model, which has a uniform set of charging policies across all applications and is managed by a single vendor, designing a model in an open and interoperable IMS network is a challenge. Specifically, the model has to support multiple charging policies to accommodate different services/applications, and these policies may vary from operator to operator.
IMS supports both on-line and off-line charging. On-line or real-time charging is primarily used to process prepaid subscriber usage. To support a two-sided revenue model, the IMS charging architecture must be extended to include the prepaid system. The subscriber account balance then has to be verified and decremented by the agreed-upon amount for the usage prior to the transaction with the application provider. In off-line charging, a session typically involves several IMS control and media components. A charging ID is used to correlate the charging information generated by these different components, which is done by a charging function in the network. However, incorporating a two-sided revenue model in this charging architecture further increases the complexity.
Another layer of complexity involves support for roaming subscribers. Is there a surcharge for roaming subscribers? In this scenario, there will be an expanded set of parties involved in a transaction – the consumer, the home network operator, the roamed network operator, the IPX or wholesale provider, and the application provider. The IMS two-sided revenue model must be able to accommodate these scenarios.
Additionally, incomplete or partial transactions require special consideration in two-sided revenue models. For example, if a subscriber watches two-thirds of a streamed video from an application provider before the streaming transaction fails due to a transmission error, does the application provider get paid for the partial transaction?
For IMS operators, device compatibility issues, such as IMS client and SIP stack interoperability, have been real concerns in deploying IMS services. Device compatibility and interoperability considerations complicate the deployment of a two-sided revenue model in an open and public IMS network environment, unlike the closed Apple ecosystem. While there are different devices with various capabilities, a specific application may fully work only on one set of devices and work in a limited manner on another set of handsets (example: no video).This complicates the implementation of the two-sided charging mechanism. In addition, there are differences among vendors in how they interpret (and therefore implement) the IMS standards. In fact, some vendors have implemented their own proprietary extensions to the IMS standards.
Many IMS operators are grappling with problems associated with integrating their IMS network with OSS/BSS systems from various vendors, despite the fact that the OSS/BSS diameter interfaces are supposedly mature. This is because many of these interfaces have proprietary extensions and incompatible charging information/records are generated by the IMS network and required by the OSS/BSS. Therefore, operators are forced to make the necessary modifications to ensure full compatibility and interoperability. Moreover, modifying the OSS/BSS to accommodate the two-sided revenue model and verifying interoperability with the IMS network, makes this integration even more complex.
Policy control has also been described as one of the catalysts for IMS deployment. Policy control (QoS) allows IMS operators to offer differentiated services by controlling the behavior of a service based on defined policies. IMS operators can also impose a cap on resource consumption, and deny specific subscribers access to specific services or applications. The two-sided revenue model has to tightly integrate both the charging and policy functions to enable the IMS operator to apply policies to two-sided revenue transactions. For example, the transaction charging will have to reflect if streaming content from an applications provider is offered to two subscribers at different speeds or QoS. A centralized policy server that is integrated with the charging function will enable this capability.
Despite these challenges, several positive developments are moving toward the implementation of a flexible and interoperable two-sided revenue model in IMS networks and this, in turn, will make the deployment of IMS more attractive for operators.
The GSMA RCS OneAPI specifications, which defines a set of IMS/RCS network APIs that allows content and application providers to develop and charge for applications, is an important initiative by the RCS/IMS community in this regard. Many service providers, including wholesale providers, have embraced the OneAPI initiative and are providing the API to third-party application providers. Other positive developments include the availability of telephony application servers with advanced features that interface with third-party application providers and IPX proxies with flexible charging and QoS support.
For IMS, support of third-party applications with flexible charging models is critical to its success. Operators will have to enable flexible revenue models, such as the two-sided revenue model, in order to make it viable to deploy IMS networks, support interoperable third-party applications, and avoid the fate of becoming a mere bitpipe provider.
Want to use this article? Click here for options!
© 2014 Penton Media Inc.
From the Blog
Join the Discussion
Get more out of Connected Planet by visiting our related resources below:
Connected Planet highlights the next generation of service providers, as well as how their customers use services in new ways.Subscribe Now