SIST ETS 300 549 E2:2003

• Abstract:

  ....

• Status: Published
• Publication Date: 30-Nov-2003
• ICS: 33.070.50 - Global System for Mobile Communication (GSM)
• Technical Committee: SS EIT - Technical Board for the electrotechnical, information technology and telecommunications fields
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Dec-2003
• Due Date: 01-Dec-2003
• Completion Date: 01-Dec-2003
• Ref Project: ETSI ETS 300 549 ed.2 (1996-06) - Digital cellular telecommunications system (Phase 2) (GSM); Unstructured Supplementary Service Data (USSD); Stage 2 (GSM 03.90)

SIST ETS 300 549 E2:2003 is the Slovenian adoption of ETS 300 549 Edition 2 from ETSI. It specifies the Stage 2 handling of Unstructured Supplementary Service Data (USSD) in GSM Phase 2, covering how a mobile station and network entities exchange USSD requests, notifications, and responses. The document is aimed at people implementing, integrating, testing, or operating USSD behavior in GSM networks.

What does SIST ETS 300 549 E2:2003 specify?

SIST ETS 300 549 E2:2003 gives the Stage 2 description of USSD for the European digital cellular telecommunications system (Phase 2). In practice, that means it defines how USSD is handled across the mobile station (MS) and the network entities involved in the path, especially the MSC, VLR, and HLR.

The scope says USSD lets an MS user and a PLMN operator-defined application communicate in a way that is transparent to the MS and to intermediate network entities. The document does not define particular applications or how one is selected; instead, it focuses on the handling of USSD itself.

The document is organized into these main parts:

• Scope
• Normative references
• Definitions and abbreviations
• Cross phase compatibility
• Network initiated unstructured supplementary service
• Mobile initiated unstructured supplementary service data
• History

What are the key requirements of SIST ETS 300 549 E2:2003?

Network initiated USSD

Clause 5 describes USSD started by the network. The network, through the MSC, VLR, or HLR, can send a USSD request or notification to the MS at any time, and no prior provision of USSD is required. In practice, this allows operators to push prompts or information to the handset when a related service is available.

Clause 5.2 defines how each network entity handles a network-initiated transaction. The HLR, VLR, or MSC starts a transaction toward the next entity, waits for a response, and normally releases the transaction after the reply arrives. This matters because the standard treats USSD as a controlled transaction, not a free-text message exchange.

Clause 5.2.4 requires transparent forwarding when the VLR or MSC is only relaying the operation. If the subscriber can be contacted, the VLR forwards unchanged to the MSC, and the MSC forwards unchanged to the MS. This means intermediate entities do not reinterpret the request, which preserves application behavior end to end.

At the MS, Clause 5.2.5 requires the phone to reject a new USSD transaction if another USSD transaction or a non-call related supplementary service transaction is already active, or if the MS cannot perform the needed MMI. If the alphabet is unsupported, the MS informs the network. For a request, the MS displays the text and waits for user input; for a notification, it displays the text and sends a response. This is the core user-facing behavior implementers must support.

Mobile initiated USSD

Clause 6 covers USSD started by the user at the MS. The MS can initiate a USSD request at any time, and no prior provisioning of the service is required. The request is sent into the network and the response is shown to the user.

Clause 6.2.1 says the MS must set up a transaction to the network and wait for the reply. While waiting, the MS may also receive a network-initiated USSD operation on the same transaction and must process it before continuing to wait. If the MS is already in a USSD or non-call related supplementary service transaction, it must reject the new request.

Clause 6.2.2 and 6.2.3 define routing based on the HPLMN service code and where the user is registered. If the request contains an HPLMN service code, the MSC may forward it to the VLR, and the VLR may forward it to the HLR if the user is not in the HPLMN. If the code is absent, or if the user is in the HPLMN, the request is handled locally. This routing behavior tells operators where the USSD logic is expected to run.

Clause 6.2.4 says the HLR always processes a mobile initiated request locally. If the HLR does not support the alphabet used in the request, it informs the MS and releases the transaction. This is important for interoperability when different equipment supports different character sets.

Clause 6.2.5 allows local processing to include setting up or releasing signalling and speech channels, passing the request to another entity, generating a different USSD request, or asking the MS for more information one or more times. After processing, the network entity responds and releases the transaction.

Compatibility, stored data, and mobility

Clause 5.6 and Clause 6.6 cover cross phase compatibility. Network initiated USSD is not permitted if the MS or any network entity is phase 1. For mobile initiated USSD, a phase 2 request is rejected if any involved entity is phase 1, and the MS repeats the request using the phase 1 protocol if the content can be encoded that way. This matters for mixed networks and legacy interworking.

Clauses 5.3, 5.4, 6.3, and 6.4 say the HLR and VLR do not store information specific to USSD itself, although they may store data for services that use USSD. Clauses 5.5 and 6.5 state that handover has no impact on the service.

What terms does SIST ETS 300 549 E2:2003 define?

• Unstructured Supplementary Service Data (USSD) - A mechanism for communication between the MS user and an operator-defined application, carried transparently through the network path.
• Application Initiated (AI) - A label used in the document for USSD requests started by an application rather than by the user.
• Mobile Initiated (MI) - A label used for USSD requests started from the MS by the user.
• HPLMN service code - A code in a mobile initiated request that affects whether the MSC or VLR forwards the request to a higher network entity.
• Mobile Station (MS) - The handset side of the exchange, which displays USSD text, accepts user input, and sends responses.
• Man-Machine Interface (MMI) - The user interaction on the MS used to present USSD information and collect the reply.
• Transaction - The temporary signaling context that is set up, forwarded, maintained, and then released while USSD is being handled.
• Alphabet indicator - The field that tells the receiving entity which character set to use for the USSD text.

Who uses SIST ETS 300 549 E2:2003?

SIST ETS 300 549 E2:2003 is used by GSM network operators, core network engineers, handset and network equipment vendors, and test labs. It is especially relevant for people working with MSC, VLR, and HLR behavior, since those entities decide whether to process, forward, or reject a USSD request.

Quality managers and buyers use it to check whether a product or network implementation follows the required USSD transaction flow, handles unsupported alphabets correctly, and behaves properly in mixed phase 1 and phase 2 environments. It is also useful for interoperability testing, since the document gives the expected handling of requests, notifications, forwarding, and release conditions.

What changed in SIST ETS 300 549 E2:2003 from the previous edition?

SIST ETS 300 549 E2:2003 corresponds to ETS 300 549 Edition 2, which in the document history is the second edition of the ETS. The document also states that it corresponds to GSM 03.90, version 4.1.1.

Which standards are used with SIST ETS 300 549 E2:2003?

• GSM 01.04 (ETR 100) - Provides abbreviations and acronyms used across the GSM Phase 2 series.
• GSM 02.30 (ETS 300 511) - Defines the Man-Machine Interface (MMI) of the MS, which the USSD procedures rely on at the handset.
• GSM 02.90 (ETS 300 625) - Gives the Stage 1 description of USSD, so this document can build on the service-level definition.
• GSM 03.38 (ETS 300 628) - Defines alphabets and language-specific information, including the coding used for USSD text.

The document notes that dated references apply as incorporated, while undated references apply to the latest edition.

What does the SIST ETS 300 549 E2:2003 document contain?

The document contains a service architecture description, state and signal flow logic, and message-handling rules for network initiated and mobile initiated USSD. It includes SDL and information-flow figures for successful, multiple, and failed transactions, which are used to implement and test the signaling behavior.

It also contains diagrams showing how requests move between the MS, MSC, VLR, and HLR, and how responses and release actions are handled. For engineers, those figures are the practical guide to transaction control, forwarding, and error handling.

The text covers the MS behavior for user input, notifications, unsupported alphabets, and conflicting transactions, which is directly useful for handset implementation and conformance testing.

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHPID]D±1HVWUXNWXULUDQLSRGDWNLR
GRSROQLOQLVWRULWYL866'±6WRSQMD*60
Digital cellular telecommunications system (Phase 2) (GSM); Unstructured
Supplementary Service Data (USSD); Stage 2 (GSM 03.90)
Ta slovenski standard je istoveten z: ETS 300 549 Edition 2
ICS:
33.070.50 Globalni sistem za mobilno Global System for Mobile
telekomunikacijo (GSM) Communication (GSM)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN ETS 300 549
TELECOMMUNICATION June 1996
STANDARD Second Edition
Source: ETSI TC-SMG Reference: RE/SMG-030390P
ICS: 33.060.30
Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM)
Digital cellular telecommunications system (Phase 2);
Unstructured Supplementary Service Data (USSD) - Stage 2
(GSM 03.90)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1996. All rights reserved.

Page 2
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Contents
Foreword.5
1 Scope .7
2 Normative references .7
3 Definitions and abbreviations.8
4 Cross phase compatibility .8
5 Network initiated unstructured supplementary service.9
5.1 Handling of network initiated USSD.9
5.2 Functions and information flows.9
5.2.1 Invoking unstructured SS operation from the HLR .9
5.2.2 Invoking unstructured SS operation from the VLR . 10
5.2.3 Invoking unstructured SS operation from the MSC . 10
5.2.4 Forwarding USSD operations. 10
5.2.5 Handling of unstructured SS operation at the MS . 11
5.3 Information stored in the HLR. 19
5.4 Information stored in the VLR. 19
5.5 Handover. 19
5.6 Cross-phase compatibility. 19
6 Mobile initiated unstructured supplementary service data. 20
6.1 Handling of mobile initiated USSD. 20
6.2 Functions and information flows. 20
6.2.1 Handling of USSD request at MS. 20
6.2.2 Handling of USSD request at MSC. 20
6.2.3 Handling of USSD request at VLR. 21
6.2.4 Handling of USSD request at HLR. 21
6.2.5 Processing the USSD request . 21
6.3 Information stored in the HLR. 35
6.4 Information stored in the VLR. 35
6.5 Handover. 35
6.6 Cross-phase compatibility. 35
History. 36

Page 4
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Blank page
Page 5
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Foreword
This European Telecommunication Standard (ETS) was produced by the Special Mobile Group (SMG)
Technical Committee (TC) of the European Telecommunications Standards Institute (ETSI).
This ETS describes the unstructured supplementary service operation within the European digital cellular
telecommunications system (Phase 2).
This ETS corresponds to GSM Technical Specification (GSM-TS) GSM 03.90, version 4.1.1.
Reference is made within this ETS to GSM-TSs.
NOTE: TC-SMG has produced documents which give the technical specifications for the
implementation of the European digital cellular telecommunications system. Historically,
these documents have been identified as GSM Technical Specifications (GSM-TSs).
These TSs may have subsequently become I-ETSs (Phase 1), or ETSs (Phase 2),
whilst others may become ETSI Technical Reports (ETRs). GSM-TSs are, for editorial
reasons, still referred to in current GSM ETSs.
Transposition dates
Date of adoption of this ETS (doa): 30 June 1996
Date of latest announcement of this ETS (doa): 30 September 1996
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 March 1997
Date of withdrawal of any conflicting National Standard (dow): 31 March 1997

Page 6
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Blank page
Page 7
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
1 Scope
This European Telecommunication Standard (ETS) gives the stage 2 description of Unstructured
Supplementary Service Data (USSD).
The unstructured supplementary service data (USSD) mechanism allows the MS user and a PLMN
operator defined application to communicate in a way which is transparent to the MS and to intermediate
network entities. The mechanism allows development of PLMN specific supplementary services. The
following diagram shows how handling of USSD is carried out, independently of the applications.
USERUSER
‡
�˝˝˝˝˝�˝˝˝˝˝»  �˝˝˝˝˝˝˝˝˝˝˝»  �˝˝˝˝˝˝˝˝˝˝˝»  �˝˝˝˝˝˝˝˝˝˝˝»
”MS  ‡   ”  ”MSC    ”  ”VLR    ”  ”HLR    ”
” �˜˜˜`˜˜˜¿ ”  ” �˜˜˜˜˜˜˜¿ ”  ” �˜˜˜˜˜˜˜¿ ”  ” �˜˜˜˜˜˜˜¿ ”
” ‡ MMI ‡ ”  ” ‡Applica‡ ”  ” ‡Applica‡ ”  ” ‡Applica‡ ”
” ‡    ‡ ”  ” ‡ tions ‡ ”  ” ‡ tions ‡ ”  ” ‡ tions ‡ ”
” �˜˜˜´˜˜˜� ”  ” �˜˜˜´˜˜˜� ”  ” �˜˜˜´˜˜˜� ”  ” �˜˜˜´˜˜˜� ”
”   ‡   ”  ”   ‡   ”  ”   ‡   ”  ”   ‡   ”
” �˜˜˜`˜˜˜¿ ”  ” �˜˜˜`˜˜˜¿ ”  ” �˜˜˜`˜˜˜¿ ”  ” �˜˜˜`˜˜˜¿ ”
” ‡ USSD ‡ ”  ” ‡ USSD ‡ ”  ” ‡ USSD ‡ ”  ” ‡ USSD ‡ ”
” ‡Handlerˆ˜�˜˜˜�˜·Handlerˆ˜�˜˜˜�˜·Handlerˆ˜�˜˜˜�˜·Handler‡ ”
” �˜˜˜˜˜˜˜� ”  ” �˜˜˜˜˜˜˜� ”  ” �˜˜˜˜˜˜˜� ”  ” �˜˜˜˜˜˜˜� ”
¨˝˝˝˝˝˝˝˝˝˝˝…  ¨˝˝˝˝˝˝˝˝˝˝˝…  ¨˝˝˝˝˝˝˝˝˝˝˝…  ¨˝˝˝˝˝˝˝˝˝˝˝…
Figure 1.1: Handling of USSD
This specification defines the requirements for handling USSD at the MS and network entities. It does not
include specification of particular applications, nor does it specify how a particular application is selected.
Where more than one application exists at a network entity, routing of messages to the correct application
is carried out by the USSD handler. The MMI for USSD is specified in GSM 02.30 and
GSM 02.90. The alphabet indicator and the data coding scheme are defined in GSM 03.38.
USSD may be initiated by the mobile station user, or by the network in the following ways:
- Network initiated USSD (section 1);
- Mobile initiated USSD (section 2).
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply
to this ETS only when incorporated in it by amendment or revision. For undated references, the latest
edition of the publication referred to applies.
[1] GSM 01.04 (ETR 100): "Digital cellular telecommunication system (Phase 2);
Abbreviations and acronyms".
[2] GSM 02.30 (ETS 300 511): "Digital cellular telecommunication system
(Phase 2); Man-Machine Interface (MMI) of the Mobile Station (MS)".
[3] GSM 02.90 (ETS 300 625): "Digital cellular telecommunication system
(Phase 2); Stage 1 description of Unstructured Supplementary Service Data
(USSD)".
[4] GSM 03.38 (ETS 300 628): "Digital cellular telecommunication system
(Phase 2); Alphabets and language specific information".

Page 8
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
3 Definitions and abbreviations
In addition to those below, abbreviations used in this specification are listed in GSM 01.04 [1].
AI Application Initiated
MI Mobile Initiated
USSD Unstructured Supplementary Service Data
4 Cross phase compatibility
The phase 1 series of GSM specifications defined the signalling protocol which may be used, but they did
not specify the operation of USSD as a service.
The main body of this specification assumes that the mobile station and all network entities comply with
this phase of USSD. In order to minimize any possible problems between a phase 1 implementation of
USSD and this phase, sections 5.6 and 6.6 define the additional requirements for when one or more entity
complies with the phase 1 USSD specification for network initiated and mobile initiated USSD respectively.

Page 9
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
5 Network initiated unstructured supplementary service
5.1 Handling of network initiated USSD
The network (MSC, VLR or HLR) can at any time send a USSD operation towards an MS. This operation
may be either a request (asking the MS to provide information) or a notification (requiring no information in
the response from the MS). No prior provision of USSD is required, although provision of services which
make use of USSD may be required. All USSD requests, notifications and responses (except responses to
notifications) contain the USSD string, an alphabet indicator and language indicator.
5.2 Functions and information flows
The following text describes the handling of network initiated USSD. Diagrammatic representations are as
follows:
Figure 5.1 SDL for USSD invocation (HLR, VLR, MSC);
Figure 5.2 SDL for forwarding of USSD operations (VLR, MSC);
Figure 5.3 SDL for MS;
Figure 5.4 Information flow for successful single USSD request;
Figure 5.5 Information flow for successful single USSD notification;
Figure 5.6 Information flow for successful multiple USSD requests;
Figure 5.7 Information flow for failed USSD request.
5.2.1 Invoking unstructured SS operation from the HLR
When an application in the HLR is to send a USSD request or notification to an MS, it shall set up a
transaction to the VLR where the subscriber is currently registered and send the operation to the VLR. It
shall then await a response. The HLR is responsible for controlling the transaction, and shall therefore
normally release the transaction when it receives a response from the VLR. The HLR may also release the
transaction before receiving a response if necessary (e.g. if an application timer expires).
If an application in the HLR needs to send further operations to the same MS as part of the same
application, it may continue to use the same transaction until all operations are completed (see figure 5.6).
If a different transaction is to be used for a subsequent operation, the HLR shall release the first
transaction before starting the next.
If the VLR releases the transaction at any time (e.g. due to user clearing), the HLR shall inform the
application and terminate the USSD operation.
See section 5.2.4 for forwarding of an HLR invoked operation by the VLR and MSC.

Page 10
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
5.2.2 Invoking unstructured SS operation from the VLR
When an application in the VLR is to send a USSD request or notification to an MS, it shall set up a
transaction to the MSC where the subscriber is currently registered and send the operation to the MSC. It
shall then await a response. The VLR is responsible for controlling the transaction, and shall therefore
normally release the transaction when it receives a response from the MSC. The VLR may also release
the transaction before receiving a response if necessary (e.g. if an application timer expires).
If an application in the VLR needs to send further operations to the same MS as part of the same
application, it may continue to use the same transaction until all operations are completed. If a different
transaction is to be used for a subsequent operation, the VLR shall release the first transaction before
starting the next.
See section 5.2.4 for forwarding of a VLR invoked operation by the MSC.
If the MSC releases the transaction at any time (e.g. due to the user clearing), the VLR shall inform the
application and terminate the USSD operation.
5.2.3 Invoking unstructured SS operation from the MSC
When an application in the MSC is to send a USSD request or notification to an MS, it shall set up a
transaction to the MS where the subscriber is currently registered and send the operation to the MS. It
shall then await a response. The MSC is responsible for controlling the transaction, and shall therefore
normally release the transaction when it receives a response from the MS. The MSC may also release the
transaction before receiving a response if necessary (e.g. if an application timer expires).
If an application in the MSC needs to send further operations to the same MS as part of the same
application, it may continue to use the same transaction until all operations are completed. If a different
transaction is to be used for a subsequent operation, the VLR shall release the first transaction before
starting the next.
If the MS releases the transaction at any time (e.g. due to the user clearing), the MSC shall inform the
application and terminate the USSD operation.
NOTE: MSC invoked USSD is only likely to be used for call related operations, where the
application is controlling a call to or from the MS.
5.2.4 Forwarding USSD operations
The VLR may any time receive a USSD operation from the HLR. If the subscriber can be contacted, the
VLR shall set up a transaction to the MSC and forward the operation unchanged. Any further information
exchange between the HLR and MSC shall be transparent to the VLR. When one transaction is released,
the VLR shall release the other.
The MSC may at any time receive an USSD operation from the VLR. If the subscriber can be contacted,
the MSC shall set up a transaction to the MS and forward the operation unchanged. Any further
information exchange between the VLR and MS shall be transparent to the MSC. When one transaction is
released, the MSC shall release the other.

Page 11
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
5.2.5 Handling of unstructured SS operation at the MS
The MS may at any time receive a USSD operation (request or notification) from the MSC.
If the MS receives a USSD transaction while another USSD transaction (network or mobile initiated) or a
non-call related supplementary service transaction is in progress, the MS shall reject the new transaction.
If the MS receives a USSD operation when it is in a state where the MMI required is not possible (e.g.
during dialling) it shall reject the operation.
If the MS does not support the alphabet indicated in the USSD operation, it shall inform the network.
If the MS is in a state where it can handle the operation, it shall process the operation as follows:
- For a USSD request, the MS shall display the text provided and await user input. If the user enters a
response, the MS shall return the response to the MSC, maintaining the transaction. If the user
requests release of the transaction, the MS shall release the transaction. See TS GSM 02.30 for
details of the MMI.
- For a USSD notification, the MS shall display the text provided and send back a response.
After sending the response to a USSD operation, the MS shall wait for the network to release the
transaction. If, while awaiting this release, the MS receives any further USSD operations, it shall process
them in the normal way.
Page 12
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Process USSD_NI1 390_51(1)
INPUTS AND OUTPUTS
Figure 5.1
idle
Source/destination of messages
shown to/from the right is
the application.
Source/destination of messages
shown to/from the left depends
USSD USSD
on the entity being described,
notify request
as follows:
Entity  To/From
HLR   VLR
no no
MS MS
VLR   MSC
reachable reachable
MSC   MS
yes yes
RELEASE USSD USSD  RELEASE
(error) notify request  (error)
NW
idle wait user idle
response
USSD
error  release  release
response
USSD
error  release  release
response
wait
for idle
application
USSD  USSD
release  release
notify  request
USSD USSD
release release
notify request
NW
wait user
idle
response
Figure 5.1: Network initiated USSD invoked at HLR, VLR or MSC

Page 13
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Process USSD_NI2 390_52(1)
Figure 5.2 idle
INPUTS AND OUTPUTS
Source/destination of messages
depends on the entity being
described, as follows:
USSD USSD
notify request
Entity  Left    Right
VLR   MSC   HLR
MSC   MS     VLR
no no
MS MS
reachable reachable
yes yes
RELEASE USSD USSD  RELEASE
(error) notify request  (error)
forwarding
idle idle
wait user
USSD
error  release  release
response
USSD
error  release  release
response
forwarding
idle
wait application
USSD  USSD
release  release
notify  request
USSD USSD
release release
notify request
forwarding
idle
wait user
Figure 5.2: Network initiated USSD forwarding at VLR or MSC

Page 14
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
Process USSD_NI3 390_53(1)
idle Figure 5.3
1 2
USSD  USSD
notify  request
INPUTS AND OUTPUTS
Source/destination of messages
shown to/from the left is
no no
the MS MMI.
alphabet alphabet
supported supported
Source/destination of messages
shown to/from the right is
yes yes the network.
no no
valid valid
state state
yes yes
USSD USSD
error  error
notify request
wait MS wait
USSD
network wait user network
response
action response action
USSD
release  release
response
USSD
release  release
response
wait
network idle
action
USSD  USSD
release  release
notify  request
release  release
1 2 idle
Figure 5.3: Network initiated USSD at MS

Page 15
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
MS         MSC         VLR         HLR
�˜˜˜˜˜¿       �˜˜˜˜˜¿       �˜˜˜˜˜¿       �˜˜˜˜˜¿
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡HLR initiated   ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡USSD request ‡   ‡
‡   ‡       ‡   ‡USSD request ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡
‡   ‡USSD request ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡       ‡   ‡
‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡
‡   ‡       ‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡  Release ‡   ‡
‡   ‡       ‡   ‡  Release ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡
‡   ‡  Release ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡VLR initiated   ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡USSD request ‡   ‡       ‡   ‡
‡   ‡USSD request ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡       ‡   ‡
‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡  Release ‡   ‡       ‡   ‡
‡   ‡  Release ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡MSC initiated   ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD request ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡  Release ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
Figure 5.4: Information flow for USSD request (Single Operation)

Page 16
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
MS         MSC         VLR         HLR
�˜˜˜˜˜¿       �˜˜˜˜˜¿       �˜˜˜˜˜¿       �˜˜˜˜˜¿
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡HLR initiated   ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡USSD notify ‡   ‡
‡   ‡       ‡   ‡USSD notify ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡
‡   ‡USSD notify ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡       ‡   ‡
‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡
‡   ‡       ‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡  Release ‡   ‡
‡   ‡       ‡   ‡  Release ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡
‡   ‡  Release ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡VLR initiated   ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡USSD notify ‡   ‡       ‡   ‡
‡   ‡USSD notify ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡       ‡   ‡
‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡  Release ‡   ‡       ‡   ‡
‡   ‡  Release ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡MSC initiated   ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD notify ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡  Release ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
Figure 5.5: Information flow for USSD notification (Single Operation)

Page 17
ETS 300 549: June 1996 (GSM 03.90 version 4.1.1)
MS         MSC         VLR         HLR
�˜˜˜˜˜¿       �˜˜˜˜˜¿       �˜˜˜˜˜¿       �˜˜˜˜˜¿
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡USSD request ‡   ‡
‡   ‡       ‡   ‡USSD request ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡
‡   ‡USSD request ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡       ‡   ‡
‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡
‡   ‡       ‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
:   :       :   :       :   :       :   :
:   :       :   :       :   :       :   :
:   :       :   :       :   :       :   :
‡   ‡       ‡   ‡       ‡   ‡USSD request ‡   ‡
‡   ‡       ‡   ‡USSD request ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡
‡   ‡USSD request ‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡
‡   ‡<˜˜˜˜˜˜˜˜˜˜˜˜·   ‡       ‡   ‡       ‡   ‡
‡   ‡       ‡   ‡       ‡   ‡       ‡   ‡
‡   ‡USSD response‡   ‡       ‡   ‡       ‡   ‡
‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡       ‡   ‡
‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡USSD response‡   ‡
‡   ‡       ‡   ‡       ‡   ˆ˜˜˜˜˜˜˜˜˜˜˜˜>‡   ‡
‡
...