Pharos CIG

With PortaBilling as the Online Charging System (OCS), mobile virtual network operators (MVNO) can offer a full range of mobile services to their customers. PortaBilling supports 2.5/3G and 4G mobile networks and uses Diameter (Ro) as the main protocol for online charging. Since the CAMEL protocol is the main protocol used for real-time charging in 2.5 and 3G networks, additional gateway is required to convert the CAMEL requests to Diameter (Ro) requests.

PortaBilling is integrated with one more gateway that converts the CAMEL requests to Diameter (Ro) requests and vice versa – the Pharos CIG (Charging Interworking Gateway). With the Pharos CIG, PortaBilling supports real-time charging for domestic and roaming voice calls, SMS, and USSD.

The Pharos CIG is deployed within a service provider’s network and acts as a mediation component between PortaBilling and a mobile operator’s network. The Pharos CIG communicates with the MSC (Mobile Switching Center) using the CAMEL protocol and then converts the CAMEL to Diameter (Ro) to communicate with PortaBilling, and vice versa.

This is how it works:

Let’s say you are the MVNO in South Africa who provides domestic/roaming voice calls and SMS to subscribers. John Doe is your subscriber. When John Doe makes a call to a destination 27115557122, South Africa, the MSC performs the call authorization in PortaBilling to verify that John Doe has sufficient funds to call this destination. The MSC sends the authorization request to PortaBilling via the Pharos CIG using CAMEL protocol. The Pharos CIG receives the authorization request from the MSC, converts it from CAMEL to Diameter (Ro) and sends this request to PortaBilling. PortaBilling locks in the funds to cover the initial period of the call and replies to the Pharos CIG with a confirmation message using Diameter (Ro). The Pharos CIG receives the reply from PortaBilling, converts it from Diameter to CAMEL, and sends it to the MSC. When the initial period of the call is over, the MSC sends requests to lock in the funds for the subsequent periods. When John Doe finishes the call, the MSC sends a request to PortaBilling to inform it that the call is over. PortaBilling creates an xDR record for this call.

You can find the configuration details and the workflow for roaming voice calls and SMS services in the Online charging for roaming services chapter.

This integration allows service providers to run MVNO in 2.5 and 3G networks and offer a full range of mobile services to their customers using another CAMEL to Diameter gateway.

In the South African market, it is typical to charge for the duration of a USSD session. PortaBilling supports charging for USSD sessions established via Pharos Charging Interworking Gateway (Pharos CIG).

Unstructured Supplementary Service Data (USSD) requests allow mobile phone users to request information or perform various actions by dialing short codes. For example, a user can dial *136# to check the current balance or *136*4# to change the package.

The advantage of the USSD services is that they require neither Internet access nor a smartphone. With USSD requests, MVNOs can provide services that are easy to access from any mobile phone; thus, such services are still popular in African countries, e.g., South Africa.

Usually, USSD requests are free of charge, but MNOs may charge MVNOs for some of them (e.g., USSD requests for accessing banking services). That’s why, to provide the USSD service and recover the costs, a specific configuration is required in PortaBilling to charge end users for USSD requests.

For example, a South African MNO MTN uses the twenty-second interval for USSD sessions charging, meaning that the users are charged 3.61 rands (R) for every 20 seconds of a USSD session. During a session, every 20 seconds PortaBilling receives a new Diameter (Ro) request from the Pharos USSD gateway. This interval is configured in tariff rates in PortaBilling. Every 20 seconds of the session will show up as a separate xDR in PortaBilling.

Let’s consider examples for two types of USSD sessions:

1. Sessions with menu options. For example, John Doe wants to pay the loan, so they need to transfer money from the cheque account to their loan account. He dials *102*3# and a new USSD session starts. John receives a USSD message with a bank menu with various options (“Balance, press 1”, “Payments, press 2”, “To go to the main menu, press 0” etc.). First, John dials 1 to check the available funds on the balance and receives a USSD message with check account details. Then he dials 0 to go back to the main menu and dials 2 to proceed with payment. He selects the loan account, enters the needed amount to transfer, and confirms the operation.

   After that, John presses the “Close” button to terminate the session and receives a short confirmatory SMS. The duration of the session is 57 seconds. From the session initiation, the Pharos USSD gateway has sent to PortaBilling three Diameter (Ro) requests of 20 seconds each, so the total cost of this USSD session is R3.61*3=R10.86.

2. Sessions without menu options. Let’s say John Doe dials *102*444# to change the current package to “Basic,” the cheaper one. John receives a USSD message that his package was successfully changed. He presses the “Close” button (no other actions are available). The service provider charges John Doe R3.61 for this request as if it was a twenty-second session.

Note that the USSD sessions have an inactivity timeout – the period of 30 seconds after which the session is terminated. It means that if the end user forgets to close the session, it will be terminated automatically.

Service providers operating at markets where USSD services are in demand can monetize these services.

To configure charging for USSD sessions, do the following:

1. Go to the Configuration server > BillingEngine > Custom group:
   • for the Custom.IniOptions attribute, add the following string: [Pharos]RoServiceContexts=[the value of the Service-Context-Id AVP that is sent in the Diameter request for USSD]. For example, for an MVNO launching in the MTN network, this string looks as follows: [Pharos]RoServiceContexts=010.655.02.ussd@mtn.co.za;
   • for the Custom.LoadAdapterModules attribute, specify: pharos=Porta::BE::M::Adapter::Pharos.

   

2. Go to PortaBilling:
   • Create a separate service to charge for USSD sessions (select Voice calls as a service type).
   • Add the available USSD short codes (e.g., *101#, *102*3#) to the list of destinations in PortaBilling as custom destinations.
   • Add rates for each short code to the vendor tariff (e.g., Destination – *101#, Rate – $0; Destination – *102*3#, Interval – 20 seconds, Rate – $0.3).
   • Create a customer tariff to charge for USSD sessions. Create a rate for each short code (e.g., Destination – *101#, Rate – $0; Destination – *102*3#, Interval – 20 seconds, Rate – $0.6).
   • Open the mobile service product and add the USSD service on the Services page.
   • Open the Usage charges page for the product and add a record with the following access code: OUTGOING.SI[the number specified in the value of the Service-Identifier AVP in the Diameter request for USSD]. For example, if you configure an MVNO launching in the MTN network, the access code looks as follows: OUTGOING.SI120.Next to the Access code field, select the created customer tariff for USSD charges.

   

• Create a voice calls service policy, enable the Rise MSCC result code attribute for it, and assign this service policy to the product (or an account).

When a user migrates from one mobile operator (A) to another (B), they can take their existing phone number with them (this is called “number porting”). Even though the phone number still looks as if it belongs to operator A, the calls/SMSes to the ported number should be routed to operator B and charged according to the rates applicable to operator B.

In South Africa, the information about ported numbers is stored in the central reference database (CRDB). Before applying rates to calls/SMSes within South Africa, operators first need to check whether a destination number is ported or not by looking it up in CRDB. Typically, MVNO/MVNE receive the number porting information from their MNO which communicates with CRDB.

The mobile operator’s network includes the number porting information (routing number) in the authorization requests sent to PortaBilling via Pharos Charging Interworking Gateway. The latter converts the CAMEL request into Diameter Ro one. When PortaBilling gets a Diameter Ro request to authorize a domestic call, PortaBilling uses the routing number (RN) to identify the operator owning the called number and apply the correct rate. The RN value is provided by the mobile operator’s network both for ported and non-ported phone numbers in authorization requests.

Benefit

• MVNOs can rate calls/SMSes to ported numbers properly.

Let’s consider an example.

Say you are an MVNO in South Africa. Your subscriber, John Doe, makes a call to 27635552222 (2763 is the prefix of the South African mobile operator MTN). The rate for calls to MTN mobile numbers is 0.11 ZAR/min.

The mobile operator’s network looks the dialed number up in the CRDB to check whether MTN or another mobile operator owns the phone number. The mobile operator’s network sends the porting information (routing number) in the authorization request to PortaBilling. The Diameter Ro authorization request received by PortaBilling includes the routing number (RN) “D084”. This is the RN of the mobile operator Cell-C (the phone numbers that belong to Cell-C have the prefix 2766). PortaBilling authorizes John Doe’s call to 27635552222 and applies the 0.12 ZAR/min rate for calls to 2766 (the rate for calls to Cell-C mobile numbers).

For PortaBilling to apply rates based on the received Routing number (RN) value, go to the Configuration server > BillingEngine > Custom group and do the following:

1. For the Custom.IniOptions attribute, add the following strings:
   1. [Pharos]RoServiceContexts=[the value of the Service-Context-Id AVP that is sent in the Diameter Ro request for a specific service]. For example, 010.655.12.32276@3gpp.org. Note that it should be a separate string for each service (with the corresponding Service-Context-Id).
   2. [Pharos]RoCLDNPDIResolved=1 – this option enables the support of the Number-Portability-Routing-Information (AVP 2024).
2. For the Custom.LoadAdapterModules attribute, specify pharos=Porta::BE::M::Adapter::Pharos.

• The RN value is sent in the Diameter Ro request in the Attribute-value pair (AVP) Number-Portability-Routing-Information. If this AVP with the RN value is not present in the Diameter Ro request, PortaBilling applies the rate corresponding to the dialed number.
• The Number-Portability-Routing-Information AVP is not sent when a user calls international destinations or short code numbers.