6 Mobile initiated unstructured supplementary service data

03.903GPPTSUnstructured Supplementary Service Data (USSD)

6.1 Handling of mobile initiated USSD

A MS can at any time initiate a USSD request to the network. No prior provision of the service is required, although provisioning of services which make use of USSD may be required. All USSD messages (requests and responses), contain the USSD string, an alphabet indicator and language indicator.

6.2 Functions and information flows

The following text describes the handling of mobile network initiated USSD. Diagrammatic representations are as follows:

Figure 6.1 SDL, request from user at MS;

Figure 6.2 SDL, request from MS at MSC;

Figure 6.3 SDL, request from application at MSC;

Figure 6.4 SDL, request from MSC at VLR;

Figure 6.5 SDL, request from application at VLR;

Figure 6.6 SDL, request from VLR at HLR;

Figure 6.7 Information flow, no further information required;

Figure 6.8 Information flow, further information required;

Figure 6.9 Information flow for failed USSD request.

6.2.1 Handling of USSD request at MS

When the user makes a request which the MS determines is to make use of USSD, the MS shall set up a transaction to the network, send the request to the MSC and await a response. When the MS receives the response, it shall display the information contained to the user.

While awaiting the response, the MS may receive a network initiated USSD request or notification on the same transaction. If this occurs, the MS shall process that operation (see section 1) and continue to await the response to the mobile initiated request.

If, when the MS determines that a user request is to make use of USSD, the MS is already involved in a USSD or a non-call related supplementary service transaction, the MS shall reject the request.

6.2.2 Handling of USSD request at MSC

When an MSC receives a USSD request containing an HPLMN service code, it shall set up a transaction to the VLR and forward the request unchanged. If this forwarding fails, an error shall be returned to the MS. The MSC shall be transparent to any further requests or responses (in either direction) for that transaction, passing them between the MS and VLR without taking any action. When one transaction is released (MS-MSC or MSC-VLR), the MSC shall release the other.

If an HPLMN service code is not included, the MSC shall process the request locally (see section 6.2.5).

If the MSC does not support the alphabet used in a USSD request, it shall set up a transaction to the VLR and forward the request unchanged, in the same way as when a HPLMN service code is received.

6.2.3 Handling of USSD request at VLR

When a VLR receives a USSD request containing an HPLMN service code and the user is not in the HPLMN, it shall set up a transaction to the HLR and forward the request unchanged. If this forwarding fails, an error shall be returned to the MS. The VLR shall be transparent to any further requests or responses (in either direction) for that transaction, passing them between the MSC and HLR without taking any action. When one transaction is released (MSC-VLR or VLR-HLR), the VLR shall release the other.

If an HPLMN service code is not included, or the user is in the HPLMN, the VLR shall process the request locally (see subclause 6.2.5).

If the VLR does not support the alphabet used in a USSD request, it shall set up a transaction to the HLR and forward the request unchanged, in the same way as when a HPLMN service code is received and the user is not in the HPLMN.

6.2.4 Handling of USSD request at HLR

An HLR shall always process a USSD request locally (see subclause 6.2.5).

If the HLR does not support the alphabet used in a USSD request, it shall inform the MS and release the transaction.

6.2.5 Processing the USSD request

When a network entity is to process a USSD request locally, the request shall be handled by an appropriate application. The location, nature and contents of USSD applications is, by definition, service provider and network operator dependent, but may include:

– Setting up or releasing signalling and/or speech channels;

– Passing the request to another network entity (unchanged or changed);

– Passing a different USSD request to another network entity;

and/or

– Requesting further information from the MS (one or more times).

Upon completion of handling the request, the network entity shall respond to the request and release the transaction.

Figure 6.1: Mobile initiated USSD at MS

Figure 6.2 (sheet 1 of 3): Mobile initiated USSD at MSC

Figure 6.2 (sheet 2 of 3): Mobile initiated USSD at MSC

Figure 6.2 (sheet 3 of 3): Mobile initiated USSD at MSC

Figure 6.3: Application initiated USSD at MSC

Figure 6.4 (sheet 1 of 3): Mobile initiated USSD at VLR

Figure 6.4 (sheet 2 of 3): Mobile initiated USSD at VLR

Figure 6.4 (sheet 3 of 3): Mobile initiated USSD at VLR

Figure 6.5: Application initiated USSD at VLR

Figure 6.6: Mobile initiated USSD at HLR

MS MSC VLR HLR
+—–+ +—–+ +—–+ +—–+
| | | | | | | |
|Request handled by MSC | | | | |
| | | | | | | |
| |USSD request | | | | | |
| +————>| | | | | |
| | |OR1:N| | | | |
| |USSD response| | | | | |
| |<————| | | | | |
| | | | | | | |
| | | | | | | |
|Request handled by VLR | | | | |
| | | | | | | |
| |USSD request | | | | | |
| +————>|OR1:Y| | | | |
| | | |USSD request | | | |
| | | +————>| | | |
| | | | |OR2:N| | |
| | | |USSD response| | | |
| |USSD response| |<————| | | |
| |<————| | | | | |
| | | | | | | |
| | | | | | | |
|Request handled by HLR | | | | |
| | | | | | | |
| |USSD request | | | | | |
| +————>|OR1:Y| | | | |
| | | |USSD request | | | |
| | | +————>|OR2:Y| | |
| | | | | |USSD request | |
| | | | | +————>| |
| | | | | | | |
| | | | | |USSD response| |
| | | |USSD response| |<————| |
| |USSD response| |<————| | | |
| |<————| | | | | |
| | | | | | | |

NOTE: OR1: HPLMN service code Y: Yes OR2: HPLMN service code and user not in HPLMN N: No Note that the application at the MSC/VLR may pass the request on to another network entity. This is not shown here.

Figure 6.7: Information flow for mobile initiated USSD Request (No further information requested)

MS MSC VLR HLR
+—–+ +—–+ +—–+ +—–+
| | | | | | | |
| |USSD request | | | | | |
| +————>| | | | | |
| | | |USSD request | | | |
| | | +————>| | | |
| | | | | |USSD request | |
| | | | | +————>| |
| | | | | | | |
| | | | | |USSD request | |
| | | |USSD request | |<————| |
| |USSD request | |<————| | | |
| |<————| | | | | |
| | | | | | | |
| |USSD response| | | | | |
| +————>| | | | | |
| | | |USSD response| | | |
| | | +————>| | | |
| | | | | |USSD response| |
| | | | | +————>| |
| | | | | | | |
: : : : : : : :
: : : : : : : :
: : : : : : : :
| | | | | |USSD request | |
| | | |USSD request | |<————| |
| |USSD request | |<————| | | |
| |<————| | | | | |
| | | | | | | |
| |USSD response| | | | | |
| +————>| | | | | |
| | | |USSD response| | | |
| | | +————>| | | |
| | | | | |USSD response| |
| | | | | +————>| |
| | | | | | | |
| | | | | |USSD response| |
| | | |USSD response| |<————| |
| |USSD response| |<————| | | |
| |<————| | | | | |
| | | | | | | |

NOTE: Note that this call flow only shows one example to illustrate the possible scenarios. See the SDL diagrams for a complete description.

Figure 6.8: Information flow for mobile initiated USSD Request Handled by HLR, further information requested

MS MSC VLR HLR
+—–+ +—–+ +—–+ +—–+
| | | | | | | |
|Error detected at MSC | | | | |
| | | | | | | |
| |USSD request | | | | | |
| +————>| | | | | |
| | | | | | | |
| | Error | | | | | |
| |<————| | | | | |
| | | | | | | |
| | | | | | | |
|Error detected at VLR | | | | |
| | | | | | | |
| |USSD request | | | | | |
| +————>| | | | | |
| | | |USSD request | | | |
| | | +————>| | | |
| | | | | | | |
| | | | Error | | | |
| | Error | |<————| | | |
| |<————| | | | | |
| | | | | | | |
| | | | | | | |
|Error detected at HLR | | | | |
| | | | | | | |
| |USSD request | | | | | |
| +————>| | | | | |
| | | |USSD request | | | |
| | | +————>| | | |
| | | | | |USSD request | |
| | | | | +————>| |
| | | | | | | |
| | | | | | Error | |
| | | | Error | |<————| |
| | Error | |<————| | | |
| |<————| | | | | |
| | | | | | | |
| | | | | | | |
|MS clears transaction before response received | |
| | | | | | | |
| |USSD request | | | | | |
| +————>| | | | | |
| | | |USSD request | | | |
| | | +————>| | | |
| | | | | |USSD request | |
| | | | | +————>| |
| | Release | | | | | |
| +————>| | | | | |
| | | | Release | | | |
| | | +————>| | | |
| | | | | | Release | |
| | | | | +————>| |
| | | | | | | |

NOTE: This call flow only shows a limited number of examples to illustrate the possible scenarios. See the SDL diagrams for a complete description.

Figure 6.9: Information flow for mobile initiated failed USSD Request

6.3 Information stored in the HLR

The HLR shall not store any information specific to the use of USSD, although information may be stored for services which are offered by USSD applications.

6.4 Information stored in the VLR

The VLR shall not store any information specific to the use of USSD, although information may be stored for services which are offered by USSD applications.

6.5 Handover

Handover will have no impact on the operation of this service.

6.6 Cross-phase compatibility

If, when a Phase 2 MS sends a mobile initiated USSD request, any network entity is of Phase 1, the request will be rejected. If it is possible to encode the content of the USSD request using the Phase 1 protocol, the MS shall repeat the request, using the Phase 1 protocol.

A Mobile initiated USSD request from a Phase 1 MS uses the Phase 1 protocol. On receipt of such a request, the application shall also use the Phase 1 protocol when sending the response.

A Phase 2 network shall not send network initiated requests or notifications during a mobile initiated USSD request if the MS or any network entity involved in the operation is of Phase 1.

Annex A (informative):
Change Request History

Status
of
Technical Specification GSM 03.90

Date Version Remarks

No Phase 1 version

October 1993 version 4.0.0 TS approved by SMG#08

January 1994 version 4.0.1 TS frozen for Phase 2 by SMG#09
TS changed to draft prETS 300 549

October 1994 version 4.0.2 TS changed to final draft prETS 300 549

January 1995 version 4.0.3 TS changed to ETS 300 549 First edition

July 1995 version 4.1.0 CR 03.90-A002 (category 2) approved by SMG#15

August 1996 version 4.1.1 TS changed to ETS 300 549 Second edition

December 1996 version 5.0.0 ETS changed to GTS for release ’96

SMG#27 version 6.0.0 Release 1997 version

SMG#29 version 7.0.0 Release 1998 version

Text and flows: WinWord6
Stylesheet: etsiw_70.dot