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 or “IN” application, and the IN model, namely the Basic Call State Model, 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, 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 Amdocs (News - Alert) jNetX, the market leader in manipulating proprietary IN, IMS and Web Services protocols, and its 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 Amdocs jNetX (News - Alert) Service Broker, backed by the experience of Amdocs jNetX's 40 deployments in 30 countries, is the most reliable and 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 Amdocs jNetX Service Broker. The Amdocs jNetX 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 IN prepaid is invoked with this special flag. If the call is allowed free of charge, then the IN prepaid trigger can even be avoided.

The Amdocs jNetX Service Broker consolidates, in real time, the interaction of services that are running within the Amdocs jNetX Service Broker and/or outside of it. 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 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 the Amdocs jNetX 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.