Network initiated USSD operations
When a local application associated with a HPLMN HLR is to send a USSD request or notification to the MS, the HLR sets up a transaction to the VPLMN VLR where the subscriber is currently registered and sends the operation, i.e., MAP unstructured SS request or unstructured SS notify. The VLR, on receiving the operation, sets up a transaction to the MSC, where the subscriber is currently registered and passes the operation unchanged to it. The MSC, on receiving the request, sets up a transaction with the MS and invokes a USSD request by sending a REGISTER message to the MS. The register message contains the unstructured SS request or unstructured SS notify invoke component. The MS, on receiving the USSD request/notification, analyzes the data-coding scheme and decides whether the USSD operation is MMI mode or application mode.
The actions taken in the MMI mode are:
■ For a USSD request, the MS displays the text provided and waits for the user inputs. If the user keys in the response, the MS sends it to the HLR/application via MSC, using the same transaction. If the user decides to release the transaction, the MS also releases the transaction.
■ For USSD notify, the MS displays the text provided and sends back a response.
The actions taken in the application mode are:
■ For an USSD request, the MS passes the message to the application in the ME, SIM/USIM, or TE and waits for the response. On receiving a response from the application, it passes it to the initiating entity via the MSC, using the same transaction. If the application decides to release the transaction, the MS also releases the transaction.
■ For an USSD notify, the MS passes the message to the application and sends back a response.
Figure 8-5 shows a network-initiated USSD request. The same procedures are followed as in the case of USSD notify.
Figure 8-4 Process unstructured SS request message decode.
Figure 8-5 Network-initiated USSD request.
Unstructured SS request. The MAP unstructured SS request procedure is used between the:
■ gsmSCF and the HLR
■ HLR and the VLR
■ VLR and the MSC
This procedure is used when the invoking entity requires information from the roamer in connection with the USSD service handling.
The unstructured SS-Request message contains the following parameters:
USSD data coding scheme. This parameter contains the alphabets 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 by the network. The contents of a string sent by the MS are interpreted in Table 8-1.
Alerting pattern. This parameter is an indication that can be used by the MSC to alert the user in a specific manner in the case of mobile terminating traffic (switched call or USSD). That indication can be an alerting level or an alerting category.
The responder, 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.
■ Unknown alphabet: This indicates that the receiving entity does not support the alphabet indicated in the USSD operation.
■ Illegal subscriber: The receiving entity indicates that the delivery of the USSD failed because the destination MS failed authentication.
■ Illegal equipment: The receiving entity indicates that the delivery of the USSD failed because the destination MS failed the IMEI check.
■ USSD busy: This indicates that the USSD handler at the receiving entity is busy and cannot handle further requests.
Unstructured SS notify. The MAP unstructured SS notify procedure is used to send a notification to a roamer in connection with the USSD service. It is used between the following network nodes.
■ gsmSCF and the HLR
■ HLR and the VLR
■ VLR and the MSC
The unstructured SS notify 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 by the network. The contents of a string sent by the MS are interpreted as given in Table 8-1.
Alerting Pattern. This parameter is an indication that can be used by the MSC to alert the user in a specific manner in the case of mobile terminating traffic (switched call or USSD). That indication can be an alerting level or an alerting category.
Figure 8-6 shows a notification sent to the roamer, informing of the credit balance, using unstructured SS notify procedure.
The responder, on unsuccessful outcome of the service, returns a user error. The possible error types are as follows.
■ System failure: This indicates that 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.
■ Unknown alphabet: This indicates that the receiving entity does not support the alphabet indicated in the USSD operation.
■ Illegal subscriber: The receiving entity indicates that the delivery of the USSD failed because the destination MS failed authentication.
Figure 8-6 Unstructured SS notify request message decode.
■ Illegal equipment: The receiving entity indicates that the delivery of the USSD failed because the destination MS failed the IMEI check.
■ USSD busy: This indicates that the USSD handler at the receiving entities is busy and cannot handle further requests.
Prepaid roaming—USSD callback scenario
Figure 8-7 shows a typical callback sequence for prepaid roaming and the actions taken by each entity. The implementation of prepaid roaming application is vendor specific, and hence the call sequence shown here may not be valid in all cases.
1. A PLMN A subscriber (MSISDN A), currently roaming in PLMN B, keys in the USSD string (*111* C#) to initiate an outgoing call to subscriber-C, a fixed line subscriber that belongs to network C.
2. The USSD handler at the MS, on recognizing a valid USSD string, sends a register message with an invoke process unstructured SS request to the serving MSC. This message contains the USSD data coding scheme and USSD string.
3. The USSD handler within MSC analyzes the service code (see Table 8-1) and, on realising that the service code is not meant for its own applications, passes the USSD request to the VLR, using the MAP process unstructured SS request procedure.
4. As the service code 111 is reserved for the HPLMN, the VLR invokes the MAP process unstructured SS request procedure toward the HPLMN HLR. If the alphabet used for the message is understood by the HLR, then the message is fed to an application contained locally in the HLR, or to the gsmSCF, or to a secondary HLR where the USSD application is located. If the alphabet is not understood. then the error message unknown alphabet is returned.
5. A USSD acknowledgment is sent by the HLR to the roamer by the same transaction. (Further actions taken by the application are implementation specific and vendor dependent. Steps 6 to 11 as described here are just for explanation purposes.)
6. The application performs precall checks. For example, it checks if the caller is authorized to make such a call and if there is enough credit balance in the caller’s account. If the caller does not qualify, an appropriate notification is sent by using the unstructured SS notify procedure. If the caller qualifies, the application initiates a mobile terminating call to the calling party first. The MAP send routing information (SRI) procedure is invoked toward the HLR to get the routing information necessary to establish the call. The HLR, on receiving the SRI message, invokes the provide roaming number (PRN) procedure toward the serving MSC/VLR to get the MSRN assigned to the roamer.
Figure 8-7 Prepaid roaming call scenario.
7. Once the MSRN is known, the application using the ISUP procedure initiates an outgoing call. (The application server implementation is vendor dependent. As a minimum, it should have call processing capabilities and should be connected to a MSC/STP by CCS7 ISUP links. It should also have the capability to send SMS notification to a roamer via SMSC.)
8. On answer from the roamer, a suitable announcement or tone is fed to the roamer indicating the call progress.
9. The prepaid roaming platform then initiates a second outgoing call toward called party C, using ISUP procedures.
10. On answer from called party C, a circuit-switched call is established between the roamer and the called party.
11. The application server monitors the call. On disconnection from any of the parties, it releases the call and frees up resources. In cases where the credit balance is exhausted during the call, an appropriate notification is sent to the roamer before call disconnection.
