The prepaid mobile market is evolving all over the world, with prepaid making up a significant and growing number of subscribers. For many operators, prepaid now represents up to 80 percent or more of their subscriber base.
As no credit checks are required, signing a prepaid service is a simple and hassle-free process for new subscribers. For low-income groups like students, prepaid offers new convenience and flexibility in controlling communication expenses. They pay up-front and top up their credit as they use.
Mobile operators are able to expand their subscriber base significantly by offering prepaid services. The possibilities of fraud and bad debts are minimal because of the up-front payment method. However, the churn rate is very high, and gaining the loyalty of prepaid subscribers poses a great challenge for mobile operators.
Extending roaming capabilities for prepaid subscribers to match their postpaid counterparts makes business sense for mobile operators. For prepaid subscribers, an additional verification needs to be done to ensure that an adequate credit balance is available before allowing them to use the services. Moreover, the call needs to be monitored during the conversation period, in real time, to avoid a negative balance.
There are many ways to implement prepaid roaming. Currently, most of the prepaid roaming implementations utilize the capabilities provided by unstructured supplementary service data (USSD) and customized application mobile enhanced logic (CAMEL).
USSD deploys a callback mechanism, as described in the following section. For each outgoing call initiated by a roamer, there will be two call legs—an international call leg back home and a follow-on call. This is surely not an efficient way to handle the call. The offered services are also not transparent, as the user needs to initiate the service by using a special service code. However, implementing prepaid roaming with USSD is rather simple, fast, cheaper, and supported by almost all existing networks, providing a global footprint.
The CAMEL-based solution is technically more advanced and efficient. The user access services transparently, as normal in his home network. There is no additional call leg required. However, the partner networks must also support CAMEL to enable roaming.
The most popular technology that enables roaming for prepaid subscribers uses unstructured supplementary services data (USSD) capability, which is already built into GSM standards. USSD provides session-based messaging between mobile terminals and mobile services and can also be used to enable many other value-added services such as WAP, interactive chat, prepaid balance checks, and voucher top-up.
USSD uses the callback principle to enable prepaid roaming. Aroamer in a visited network requests a call to be set up by keying a special service or access code and the MSISDN number of the destination party. The visited network passes this service request to the roamer’s home network. From this point onward, the HPLMN takes control of call processing. For example, the HPLMN may like to perform precall checks before processing further. It verifies if the subscriber has enough credit balance to pay for the requested service. After verification, the prepaid roaming application in the HPLMN initiates a call to the destination subscriber and then initiates another call to the roamer. Once the call is established between roamer and intended called party, the HPLMN monitors the service usage against the available balance in real time. The HPLMN notifies the roamer if the credit balance runs out and terminates the call.
Figure 8-1 shows a typical sequence of an outgoing call initiated by a roamer in a visited network. In this example, the PLMN 2 uses the service code 111 for prepaid roaming, a roamer (PLMN 2 subscriber) in the visited network (PLMN 1) initiates a call request to a subscriber (e.g., +60133439128), which may belong to an HPLMN, any other PLMN, or a fixed network, by sending the following sequence.
1. The roamer keys in
and presses the <SEND/OK> button to initiate a call to subscriber +60133439128 in another network.
2. The VPLMN MSC/VLR transfers this USSD string to the HPLMN HLR.
Figure 8-1 USSD Call back—call flow.
3. The HPLMN HLR passes this string to the prepaid roaming platform.
4. After the required precall checks, the prepaid roaming platform initiates two outgoing calls (i.e., one to the roamer and one to the requested called party) and connects.
USSD string coding
The length and content of a USSD string is very flexible. USSD utilizes the characters "*," "#," and all the digits. If the user keys in a string following the coding scheme given in Table 8-1, the USSD handlers in the MS, the MSC, the VLR, and the HLR treat it as a USSD request.
The character "*" is used to indicate the beginning of a USSD string. It is also used as a separator between two parameters. The character "#" is used to terminate a USSD string.
The formatting rules to create a USSD string are summarized as follows.
■ An asterisk to indicate beginning
■ A predefined access/service code
■ One or more parameters needed to invoke supplementary service
■ A # to terminate request
For example, a USSD service request is coded as follows.
USSD request handling—general concept
As described in Table 8-1, the treatment of USSD at every node is independent of any application in that particular node. A USSD handler routes the USSD to the correct application based on service code. Figure 8-2 shows the routing of a USSD message to the destination node.
TABLE 8-1 USSD Operations—Interpretation at VPLMN
|
USSD string |
Treatment |
Action at the VPLMN |
Remarks |
|
*1XY*<any number of any characters># where X = 0-4 and Y = 0-9 |
Reserved for the HPLMN |
The VPLMN passes theUSSD message directly to the HPLMN |
String may begin with 1, 2, or 3 digits from the set *, # |
|
*1XY*<any number of any characters># where, X = 5-9 and Y = 0-9 |
Reserved for the VPLMN |
It is up to the VPLMN to decide how to treat it. |
|
|
7(Y) where Y = any number 0-9 |
Reserved for the HPLMN |
The VPLMN passes the USSD message directly to the HPLMN |
A roamer in a visited network can initiate a USSD request for a provisioned service at any time by keying in the USSD string containing the HPLMN service code. The MSC examines the service code and forwards this request to the VLR without taking any action.
When a VLR receives the request forwarded by the MSC with an HPLMN service code, it sets up a connection to the HPLMN HLR and forwards the request unchanged. The HLR, on receiving the USSD request, processes and passes it to an appropriate application, i.e., a prepaid roaming application in this case.
In a similar fashion, the network can send a USSD operation toward an MS anytime. This operation could be a request to get certain information or a notification. For example, if the prepaid roaming application in the HLR is to send a USSD request or notification to the roamer, it sets up a transaction to the VLR where the roamer is currently registered. The VLR, on receiving this request or notification, sets up a transaction to the serving MSC. The serving MSC sends it to the MS and then waits for a response. The MS analyzes the data-coding scheme and decides whether the USSD operation is in the MMI mode or the application mode. For a USSD request with the application mode, the MS passes the message to the corresponding application and sends back the response. For a USSD request with the MMI mode, the MS displays the text provided and waits for the user inputs. If the user enters a response, the MS returns the response to the MSC.
Roamer initiated USSD operation
Figure 8-3 shows a roamer-initiated USSD operation and message flow at the B and D interfaces. When a roamer invokes a USSD request (e.g., a prepaid roamer initiates USSD callback) by keying in the appropriate code (containing the HPLMN service code), the USSD handler within the MS invokes the USSD request by sending a REGISTER message to the network. The REGISTER message contains a process unstructured SS request invoke component. The serving MSC, on receiving a USSD request containing an HPLMN service code, sets up a transaction to the VLR and forwards the request unchanged. The MSC will act in a transparent mode to any further requests/responses for this transaction, passing them between the MS and the VLR without taking any action.
When a VLR receives a USSD request containing an HPLMN service code, it sets up a transaction to the HLR and forwards the request unchanged. The VLR then acts in a transparent mode to any further requests/responses for this transaction. Passing them between the MSC and the HLR without taking any action. When the HLR receives the USSD
Figure 8-2 USSD handling at the GSM entities.
Figure 8-3 Roamer-initiated USSD operation.
The application, as an option, may request further information in order to perform the requested operation or terminate the dialogue. If the application requests more information, it initiates a USSD request (see Section 8.1.4 for network-initiated requests), using the ongoing transaction. If the application decides to terminate the dialogue, the network side sends a release complete message. The MS can also terminate a dialogue by sending a release complete message.
Process unstructured SS request. The MAP process unstructured SS request procedure is used to relay USSD information between the:
■ MSC and the VLR
■ VLR and the HLR
■ HLR and the gsmSCF (the gsmSCF is defined in the next section)
The process unstructured SS request message contains the following parameters:
USSD data coding scheme. This parameter contains the alphabet and the language information used for the unstructured information in a USSD operation. The coding of this parameter is according to the cell broadcast data coding scheme as specified in 3GPP TS 23.038.
Default alphabet: SMS default alphabet
Default language: Language unspecified
USSD string. This parameter contains a string of unstructured information. The string is sent either by the mobile user or the network. The contents of a string sent by the MS are interpreted as given in Table 8-1.
MSISDN. Originating subscriber international number. The MSISDN is an optional parameter.
The receiving entity, on unsuccessful outcome of the service, returns a user error. The possible error types are as follows:
■ System failure: This indicates that the requested task could not be completed because of a problem in another entity.
■ Data missing: This indicates that the context is missing in the received message.
■ Unexpected data value: This error is returned if the receiver is not able to deal with the contents of the USSD string.
■ Call barred: This indicates that the receiving entities cannot process the request because of barring of the initiated service.
■ Unknown alphabet: This indicates that the receiving entity does not support the alphabet indicated in the USSD operation.
Figure 8-4 shows the protocol decodes of a process unstructured SS request message. The USSD string contains a service code, i.e., 138 in this case, and the MSISDN number of the called party.
