Tech-invite  3GPPspace  IETF RFCs  SIP
Quick  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x
Top   in Index   Prev   Next

TS 22.090
USSD —
Unstructured Supplementary Service Data –
Stage 1

3GPP‑Page   ETSI‑search   CONTENT↓
V16.0.0 (PDF)  2020/06  12 p.
V15.0.0  2018/06  12 p.
V14.0.0  2017/03  12 p.
V13.0.0  2015/12  11 p.
V12.0.0  2014/10  12 p.
V11.0.0  2012/09  12 p.
V10.0.0  2011/04  12 p.
V9.0.0  2009/12  12 p.
V8.0.0  2009/01  12 p.
V7.0.0  2006/06  12 p.
V6.0.0  2004/12  12 p.
V5.0.0  2002/07  12 p.
V4.0.0  2001/04  11 p.
V3.1.0  2000/03  12 p.
GSM Rel-98 v7.0.0  1999/06  9 p.
GSM Rel-97 v6.0.0  1998/10  9 p.
GSM Rel-96 v5.1.0  1997/02  11 p.
GSM Phase-2 v4.1.1  1997/09  11 p.
Rapporteur:
Mr. Ignatius, Jan  Nokia Networks

Content for  TS 22.090  Word version:  16.0.0

Here   Top

1  Scope  Word‑p. 4

The present document defines the stage 1 description of Unstructured Supplementary Service Data (USSD) for use in one or a number of Public Land Mobile Networks (PLMNs).

2  References

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]  TR 21.905: "Vocabulary for 3GPP Specifications".
[2]  TS 22.004: "General on supplementary services".
[3]  TS 22.030: "Man Machine Interface (MMI) of the Mobile Station (MS)".
[4]  TS 23.038: "Alphabets and language-specific information".
[5]  TS 24.080: "Mobile radio interface layer 3 supplementary services specification Formats and coding".
Up

3  Abbreviations  Word‑p. 5

For the purposes of the present document, the abbreviations listed in TR 21.905 apply.

4  Description

There are two modes of USSD: MMI-mode and application mode. MMI-mode USSD is for the transparent transport of MMI strings entered by the user to the network and for the transparent transport of text strings from the network that are displayed by the mobile for user information.
Application mode USSD is for the transparent transport of data between the network and the UE. Application mode USSD is intended to be used by applications in the network and their peer applications in the UE.
The communication over the radio interface takes place on the signalling channels using short dialogues with peak data throughput rate capabilities of up to approximately 600 bits/s outside of a call and 1 000 bits/s during a call.
Up

5  USSD operations - MMI mode

5.1  Mobile initiated USSD operations

5.1.1  Initiating action at the User Equipment (UE)

If the user enters an MMI string that, according to TS 22.030, should be treated as USSD, the UE shall send this string to the network using the appropriate operation from TS 24.080.
The mobile initiated operation shall contain an alphabet indicator and language indicator. The alphabet indicator shall indicate the alphabet used in the operation. The selection of values for these indicators is a matter for the user.
The UE may initiate an USSD operation either during a call or out of call.
Up

5.1.2  Action at the network

A network supporting USSD shall examine the alphabet indicator. If the serving network does not recognize the alphabet indicated in the mobile initiated USSD operation, it shall send the operation to the HLR.
On recognition of the alphabet, the network shall examine the contents of the string, and take appropriate action, according to the following rules, depending of the format of the message.
Case a)
1, 2 or 3 digits from the set (*, #) followed by 1X(Y), where X=any number 0 4, Y=any number 0 9, then, optionally "* followed by any number of any characters", and concluding with # SEND:
This case is reserved for HPLMN use. When a serving network receives such a message from a visiting subscriber, it shall pass the USSD message directly to the HPLMN. If it receives it from a home subscriber, it is up to the network to decide whether to treat it locally or to pass it to the HLR.
Case b)
1, 2 or 3 digits from the set (*, #) followed by 1X(Y), where X=any number 5 9, Y=any number 0 9, then, optionally "* followed by any number of any characters", and concluding with # SEND:
This case is reserved for VPLMN use. It is up to the VPLMN to decide how to treat it.
Case c)
7(Y) SEND, where Y=any number 0 9:
This case is reserved for HPLMN use. When a serving network receives such a message from a visiting subscriber, it shall pass the USSD message directly to the HPLMN. If it receives it from a home subscriber, it is up to the network to decide whether to treat it locally or to pass it to the HLR.
Case d)
All other formats:
The visited network examines the message. If it is able, it acts upon it. Failing that, it passes the message to the HLR.
If the HLR does not support the alphabet indicated, it shall inform the UE.
The network shall terminate the mobile initiated operation by responding to the request from the mobile with either an error signal, or a text string indicating the outcome of the operation. The response string uses the characters available in the selected alphabet as defined in TS 23.038. If no indication to the user is required, the response string may be empty.
The response to the mobile initiated USSD operation shall contain alphabet and language indicators. The selection of values for these indicators is a matter for the network operator.
Up

5.1.3  Mobile initiated USSD cross phase compatibility  Word‑p. 6

In situations of incompatibility the mobile initiated USSD operation will be rejected by a non-supporting network and the attempt will fail. In this situation, if it is possible to encode the content of the USSD message in the IA5 alphabet, the UE shall attempt the operation again using the IA5 format without the alphabet and language indicators.
This procedure is not applicable if an operation failure is due to alphabet support problems, services not supported or network failure problems.

5.1.4  Allocation of service codes (to be noted by network operators)

Service codes for use in control of Supplementary Services are standardized by international agreement, so must not be used by PLMNs unless authorized, except for those codes allocated for PLMN use.
If the message is of the format:
1, 2 or 3 digits from the set (*, #), followed by
NN(N), where N=0 9,
optionally followed by "* and any number of any characters",
and terminating in # SEND:
then NN(N) is known as the service code. Only codes specified in TS 22.030 and those defined in cases a) and b) above may be used. All other values are reserved.
Similarly, if the message is of the format:
X(Y) SEND, where X=0 6 or 8 9 and Y=0 9:
the codes X(Y) are standardized. Only codes specified in TS 22.030 subclause 4.5.5 may be used. All other values are reserved.
Up

5.2  Network initiated USSD operation  Word‑p. 7

5.2.1  Initiating actions in the network

At any stage while the UE is registered with a network, the network may send an unstructured string to the UE. This string contains operator determined information that is relevant to the user. If the network is unable to successfully reach the UE, then an error shall be returned to the node that originated the operation.
The network initiated USSD operation shall contain an alphabet indicator and language indicator. The alphabet indicator shall indicate the alphabet used in the operation. The selection of values for these indicators is a matter for the network operator.
Up

5.2.2  Actions at the UE

If the is unable to process the network initiated USSD operation (e.g. the feature is not supported or the user is engaged in another MMI activity) then an error indication shall be returned to the node that originated the operation. If the alphabet indicated by the network is not supported by the UE, the UE shall inform the network.
The network may explicitly indicate to the UE that a response from the user is required. In this case, the next string entered by the user shall be used as the responseand this string is not interpreted according to normal MMI procedures stated in TS 22.030. An MMI command shall be provided to allow the user to terminate the dialogue with a null response. The response string uses the characters available in the selected alphabet as defined in TS 23.038. The response is sent to the node that originated the operation. If the network does not indicate that a response is required, then the normal MMI procedures on the UE continue to apply.
The UE shall include alphabet and language indicators in the response to the network (if any).
Up

5.3  Network aspects of USSD operation

Applications that useUSSD operations may be located in either the HPLMN or a roamed to VPLMN.
Network applications using USSD operations may:
  • use several USSD operations (possibly a mixture of mobile initiated and network initiated) in combination as part of a dialogue with the user. Linkage between separate operations as part of a dialogue is only implemented locally in the network application and does not lead to any special mode of operation in the UE. The network initiated request for a response from the user and the corresponding response is a single operation;
  • act on calls in progress, or place new calls, as part of the service the application provides.
Release of the connection used for an unstructured dialogue is normally the responsibility of the network and may be carried out at the request of the application using the USSD operations. The user may also initiate connection release through an MMI procedure.
Up

6  USSD operations - application mode  Word‑p. 8

6.1  General

USSD supports communication between an application (handler) in the UE and a corresponding application (handler) in the network by enabling transparent transfer of binary data between the network and the UE. The applications may use USSD either during a call or out of call.
Application-level addressing is out of scope of the present document.

6.2  Mobile initiated transfer

6.2.1  Initiating action at the UE

If the UE wishes to send data to the network, it can do so using USSD. It shall be possible for the UE to send data to nodes in the VPLMN and in the HPLMN, i.e. MSC, VLR, HLR, MExE servers, CSEs and proxy servers.

6.2.2  Action in the network

The serving network shall pass the received message to its destination node. If the VPLMN cannot route the message to the destination it shall forward the message to the HPLMN.

6.3  Network initiated transfer

6.3.1  Initiating action in the network

If a node in the network wishes to send data to an UE, it can do so using USSD.
If the network is unable successfully to reach the UE, then an error shall be returned to the node that originated the operation.

6.3.2  Action at the UE

The UE shall pass the message to the ME, to the SIM/USIM or to the TE as indicated in the message.

6.4  External addressing

The USSD dialogue exists inside the PLMN. However, it shall be possible to transport the address of an external node in the USSD message. The address format must be standardised and support at least E.164 and IP addresses.
When addressing of an UE from an external node the address shall be an MSISDN number. The return address shall be present and in the same format the UE uses to address an external node.
The mechanism for communication between the PLMN and the external node is out of scope of the present document.
Up

6.5  Charging aspects

It shall be possible to charge for the use of application mode USSD based on e.g. the destination node.
Charging for the use of an application is out of scope of the present document.

6.6  Compatibility aspects  Word‑p. 9

6.6.1  Mobile initiated transfer

If the network does not support application mode USSD, the mobile initiated operation will be rejected and the attempt will fail. The UE shall not attempt automatic fall back to phase 1 USSD or to MMI mode USSD in case of incompatibility. Application-level recovery is outside the scope of the present document.
If the network is unable to identify the destination node, it shall forward the message to the HLR.

6.6.2  Network initiated transfer

If the UE is unable to process the network initiated USSD operation, then an error indication shall be returned to the node that originated the operation.

6.7  Interaction with other services

The user or the network operator shall be able to prevent the use of application mode USSD during calls. The use of USSD in parallel with a circuit switched call may have a negative impact on the quality of the speech or data transmission.

6.8  Security

Application-level security is out of scope of the present document.

$  Change history  Word‑p. 10

Up   Top