More and more, customers are turning to prepaid as a way to manage their spend on mobile communications. However, prepaid subscribers are unable to benefit from the rich communications services available to the postpaid subscriber.

You’re prepaid, and that’s it.

This has several business consequences for the service provider. Firstly, prepaid-oriented service providers suffer a high churn rate; secondly, service providers are missing an opportunity to grow their ARPU by selling new rich communication services to all their prepaid subscribers.

But let’s step back. Why can’t a prepaid subscriber benefit from rich communication services like a postpaid subscriber?

To understand this, we have to look at the nature of the prepaid application itself. Prepaid is an Intelligent Network (IN) application, and the IN model, namely the Basic Call State Model (BSCM), has one clear limitation: for one call establishment, only one IN application can be invoked. As prepaid is already one IN application, service providers can’t offer additional services to their prepaid customers.

Obviously traditional Network Equipment Providers (NEPs), the main IN vendors, have proposed workarounds to solve this limitation. However these workarounds only work in a single IN vendor environment, forcing service providers to work with a single IN vendor. As most service providers already have IN applications from different vendors in their network, combining these existing IN applications to build new value for their customers is not really possible.

This is where the Service Broker comes in. When a combination of IN applications from different vendors is needed, which is the case when service providers are looking to offer rich communications services to their prepaid subscribers, then the Service Broker is the most cost-effective solution.

How does it work?

When a call is being established, for example between an IN prepaid and an IN-based community application, it’s routed to the Service Broker. The Service Broker first invokes the community application to find out if both calling and called parties belong to the same community. Based on the response a special flag is inserted and the prepaid application is invoked with this special flag. If the call is allowed free of charge, then the IN prepaid trigger can even be avoided.

The Service Broker consolidates, in real time, the interaction of services that are running within the Service Broker and/or outside of it. When external applications or features are involved, the Service Broker takes care of the appropriate protocol conversion. As a consequence, service providers can re-use all their legacy IN applications in an IMS environment and vice versa and easily bridge IN and IMS services together with Web Services / SOA.

For a service provider with a high prepaid penetration, introducing an Service Broker not only allows them to quickly offer new services to their whole prepaid subscribers’ base; but it also enables them to unlock the service layer and avoid any vendor lock-in situation.

The business consequences are that prepaid subscribers have the freedom to select the services they want, making them less likely to churn, leading to ARPU growth.

About Amdocs jNetX (News - Alert) Service Broker

The Amdocs jNetX Service Broker enables end users to decide which set of applications they want to use. As an example, prepaid users are now free to subscribe simultaneously to additional services such as Ring Back Tone, Personal Call Management, Parental control, Ring Back When Free, VPN and so on. The result is increased revenues for service providers, reduced cost and considerably improved time to market.

The Amdocs (News - Alert) jNetX Service Broker breaks the technical barriers that prevent multiple services from multiple vendors to be simultaneously subscribed and delivered to the end user. It enables service interaction between a combination of independent:

--IN services or features (IN Mediation)

--SIP/IMS services or features (SCIM)

--Internet/Web Services

The Amdocs jNetX Service Broker is used to consolidate, in real-time, the interaction of services that are running within the Amdocs jNetX Service Broker and/or outside of it (external applications servers). When external applications or features are involved, the Amdocs jNetX Service Broker takes care of the appropriate protocol conversion. As a consequence, service providers can reuse their legacy IN applications in an IMS environment and vice versa and easily bridge IN and IMS services together with Web Services and/or SOA. Additionally the Amdocs jNetX convergent technology enables:

-- The Amdocs jNetX Service Broker to simultaneously communicate with Online or Offline Charging Systems (e.g. over Diameter Ro and Rf), with User Data Repositories (e.g. over Diameter Sh, Radius and LDAP) or with any other network elements that are required.

-- The Amdocs jNetX Service Broker to simultaneously host any communications applications. Amdocs jNetX offers a large portfolio of commercial-off-the-shelf (COTS) communications applications that provide rich communications services, but at the same time enable services providers to replace their existing legacy IN applications (such as VPN, NTS (News - Alert), etc.) that are well on their way to reaching their respective end of life.

-- Finally, the Amdocs jNetX Service Broker can easily evolve to an Amdocs Prepaid solution or to an Amdocs Convergent Charging solution. The overall goal is to facilitate a smooth replacement of costly and inflexible legacy IN prepaid systems with the new generation of Amdocs Prepaid or Amdocs Convergent Charging systems.

Many service providers that are currently using the Amdocs jNetX Service Broker started by combining IN or SIP services together with their existing and legacy Prepaid IN.

TMCnet publishes expert commentary on various telecommunications, IT, call center, CRM and other technology-related topics. Are you an expert in one of these fields, and interested in having your perspective published on a site that gets several million unique visitors each month? Get in touch.

Edited by Marisa Torrieri