W starych zasobach znalazłem coś takiego. Może Ci się przyda.
GSM GSM 07.05
TECHNICAL January 1998
SPECIFICATION Version 5.5.0
Source: SMG Reference: GTS/SMG-040705QR
ICS: 33.020
Key words: Digital cellular telecommunications system, Global System for
Mobile communications (GSM)
Digital cellular telecommunications system (Phase 2+);
Use of Data Terminal Equipment - Data Circuit terminating;
Equipment (DTE - DCE) interface for
Short Message Service (SMS) and Cell Broadcast Service (CBS)
(GSM 07.05 version 5.5.0)
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:
secretariat@etsi.fr
Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16
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 1998. All rights
reserved.
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.
Contents
TOC \o Foreword GOTOBUTTON _Toc410546365 PAGEREF _Toc410546365
7
Introduction GOTOBUTTON _Toc410546366 PAGEREF _Toc410546366 7
0 Scope GOTOBUTTON _Toc410546367 PAGEREF _Toc410546367 9
0.1 Normative references GOTOBUTTON _Toc410546368 PAGEREF
_Toc410546368 10
0.2 Abbreviations GOTOBUTTON _Toc410546369 PAGEREF _Toc410546369
10
1 Reference configuration GOTOBUTTON _Toc410546370 PAGEREF
_Toc410546370 11
1.1 V.24 Interface Circuits GOTOBUTTON _Toc410546371 PAGEREF
_Toc410546371 11
1.1.1 Circuit definitions for the SMS Block mode GOTOBUTTON
_Toc410546372 PAGEREF _Toc410546372 11
1.1.2 Circuit definitions for the SMS Text and PDU modes GOTOBUTTON
_Toc410546373 PAGEREF _Toc410546373 12
2 SMS Block Mode GOTOBUTTON _Toc410546374 PAGEREF _Toc410546374 12
2.1 Beginning and ending of SMS/CBS Block Mode GOTOBUTTON
_Toc410546375 PAGEREF _Toc410546375 12
2.1.1 Beginning SMS/CBS Block Mode GOTOBUTTON _Toc410546376 PAGEREF
_Toc410546376 12
2.1.2 Returning from SMS/CBS Block Mode To Default Mode GOTOBUTTON
_Toc410546377 PAGEREF _Toc410546377 12
2.2 Protocol description GOTOBUTTON _Toc410546378 PAGEREF
_Toc410546378 13
2.3 Requesting messages already held in the Mobile Termination
GOTOBUTTON _Toc410546379 PAGEREF _Toc410546379 14
2.3.1 Requesting List Of Messages GOTOBUTTON _Toc410546380 PAGEREF
_Toc410546380 14
2.3.2 Requesting Transfer Of Messages GOTOBUTTON _Toc410546381
PAGEREF _Toc410546381 14
2.3.2.1 Requesting Transfer Of A Specific Message GOTOBUTTON
_Toc410546382 PAGEREF _Toc410546382 15
2.3.2.2 Requesting Transfer Of All Messages GOTOBUTTON _Toc410546383
PAGEREF _Toc410546383 15
2.3.3 Requesting Diversion Of Incoming Messages GOTOBUTTON
_Toc410546384 PAGEREF _Toc410546384 15
2.3.3.1 Requesting SMS Messages GOTOBUTTON _Toc410546385 PAGEREF
_Toc410546385 15
2.3.3.2 Requesting CBS Messages GOTOBUTTON _Toc410546386 PAGEREF
_Toc410546386 16
2.3.3.3 Requesting indication of message arrival GOTOBUTTON
_Toc410546387 PAGEREF _Toc410546387 16
2.3.4 Requesting Transfer Into Mobile Termination GOTOBUTTON
_Toc410546388 PAGEREF _Toc410546388 17
2.3.5 Requesting Deletion Of Messages GOTOBUTTON _Toc410546389
PAGEREF _Toc410546389 17
2.4 Message functional definitions and contents GOTOBUTTON
_Toc410546390 PAGEREF _Toc410546390 17
2.4.1 Commands Issued By The Terminal Equipment GOTOBUTTON
_Toc410546391 PAGEREF _Toc410546391 18
2.4.1.1 List Request GOTOBUTTON _Toc410546392 PAGEREF _Toc410546392
18
2.4.1.2 Get Message GOTOBUTTON _Toc410546393 PAGEREF _Toc410546393
19
2.4.1.3 Get First Message GOTOBUTTON _Toc410546394 PAGEREF
_Toc410546394 19
2.4.1.4 Get Next Message GOTOBUTTON _Toc410546395 PAGEREF
_Toc410546395 19
2.4.1.5 Transfer Inc SMS GOTOBUTTON _Toc410546396 PAGEREF
_Toc410546396 19
2.4.1.6 Indicate Inc SMS GOTOBUTTON _Toc410546397 PAGEREF
_Toc410546397 19
2.4.1.7 Transfer Inc CBS GOTOBUTTON _Toc410546398 PAGEREF
_Toc410546398 19
2.4.1.8 Insert SMS GOTOBUTTON _Toc410546399 PAGEREF _Toc410546399
19
2.4.1.9 Delete message GOTOBUTTON _Toc410546400 PAGEREF
_Toc410546400 20
2.4.1.10 Unable to process GOTOBUTTON _Toc410546401 PAGEREF
_Toc410546401 20
2.4.1.11 End SMS Mode GOTOBUTTON _Toc410546402 PAGEREF
_Toc410546402 20
2.4.1.12 Acknowledge Message GOTOBUTTON _Toc410546403 PAGEREF
_Toc410546403 20
2.4.2 Responses/Indications Issued By The MT GOTOBUTTON _Toc410546404
PAGEREF _Toc410546404 20
2.4.2.1 Message List GOTOBUTTON _Toc410546405 PAGEREF _Toc410546405
21
2.4.2.2 Message GOTOBUTTON _Toc410546406 PAGEREF _Toc410546406 21
2.4.2.3 Get Message Failure GOTOBUTTON _Toc410546407 PAGEREF
_Toc410546407 21
2.4.2.4 Inc Message GOTOBUTTON _Toc410546408 PAGEREF _Toc410546408
21
2.4.2.5 Message Arrived GOTOBUTTON _Toc410546409 PAGEREF
_Toc410546409 22
2.4.2.6 Insert SMS Complete GOTOBUTTON _Toc410546410 PAGEREF
_Toc410546410 22
2.4.2.7 Insert SMS Failure GOTOBUTTON _Toc410546411 PAGEREF
_Toc410546411 22
2.4.2.8 Delete Message Complete GOTOBUTTON _Toc410546412 PAGEREF
_Toc410546412 22
2.4.2.9 Delete Message Failure GOTOBUTTON _Toc410546413 PAGEREF
_Toc410546413 22
2.4.2.10 Unable To Process GOTOBUTTON _Toc410546414 PAGEREF
_Toc410546414 22
2.4.2.11 End SMS Mode GOTOBUTTON _Toc410546415 PAGEREF
_Toc410546415 23
2.4.2.12 Request Confirmed GOTOBUTTON _Toc410546416 PAGEREF
_Toc410546416 23
2.5 General message format and information elements coding GOTOBUTTON
_Toc410546417 PAGEREF _Toc410546417 23
2.5.1 Message Type GOTOBUTTON _Toc410546418 PAGEREF _Toc410546418
23
2.5.2 Other Information Elements GOTOBUTTON _Toc410546419 PAGEREF
_Toc410546419 24
2.5.2.1 Short Message Reference GOTOBUTTON _Toc410546420 PAGEREF
_Toc410546420 24
2.5.2.2 SMS Transfer Type GOTOBUTTON _Toc410546421 PAGEREF
_Toc410546421 25
2.5.2.3 Indication Type GOTOBUTTON _Toc410546422 PAGEREF
_Toc410546422 25
2.5.2.4 Insert Type GOTOBUTTON _Toc410546423 PAGEREF _Toc410546423
26
2.5.2.5 Short Message Index GOTOBUTTON _Toc410546424 PAGEREF
_Toc410546424 27
2.5.2.6 Short Message Data GOTOBUTTON _Toc410546425 PAGEREF
_Toc410546425 29
2.5.2.7 Cause GOTOBUTTON _Toc410546426 PAGEREF _Toc410546426 31
2.5.2.8 Index Count GOTOBUTTON _Toc410546427 PAGEREF _Toc410546427
32
2.5.2.9 CBS Transfer Type GOTOBUTTON _Toc410546428 PAGEREF
_Toc410546428 32
2.5.2.10 Page Index GOTOBUTTON _Toc410546429 PAGEREF _Toc410546429
32
2.5.2.11 Last Short Message GOTOBUTTON _Toc410546430 PAGEREF
_Toc410546430 33
2.5.2.12 Confirm Type GOTOBUTTON _Toc410546431 PAGEREF
_Toc410546431 33
2.5.2.13 TP-Failure Cause GOTOBUTTON _Toc410546432 PAGEREF
_Toc410546432 34
2.5.2.14 SM-Deliver-Ack GOTOBUTTON _Toc410546433 PAGEREF
_Toc410546433 34
2.5.2.15 SM-Submit-Ack GOTOBUTTON _Toc410546434 PAGEREF
_Toc410546434 35
3 Text Mode GOTOBUTTON _Toc410546435 PAGEREF _Toc410546435 35
3.1 Parameter Definitions GOTOBUTTON _Toc410546436 PAGEREF
_Toc410546436 35
3.2 General Configuration Commands GOTOBUTTON _Toc410546437 PAGEREF
_Toc410546437 38
3.2.1 Select Message Service +CSMS GOTOBUTTON _Toc410546438 PAGEREF
_Toc410546438 38
3.2.2 Preferred Message Storage +CPMS GOTOBUTTON _Toc410546439
PAGEREF _Toc410546439 39
3.2.3 Message Format +CMGF GOTOBUTTON _Toc410546440 PAGEREF
_Toc410546440 39
3.2.4 Enter SMS Block Mode Protocol +CESP GOTOBUTTON _Toc410546441
PAGEREF _Toc410546441 40
3.2.5 Message Service Failure Result Code +CMS ERROR GOTOBUTTON
_Toc410546442 PAGEREF _Toc410546442 40
3.2.6 Informative Examples GOTOBUTTON _Toc410546443 PAGEREF
_Toc410546443 41
3.3 Message Configuration Commands GOTOBUTTON _Toc410546444 PAGEREF
_Toc410546444 41
3.3.1 Service Centre Address +CSCA GOTOBUTTON _Toc410546445 PAGEREF
_Toc410546445 41
3.3.2 Set Text Mode Parameters +CSMP GOTOBUTTON _Toc410546446
PAGEREF _Toc410546446 41
3.3.3 Show Text Mode Parameters +CSDH GOTOBUTTON _Toc410546447
PAGEREF _Toc410546447 42
3.3.4 Select Cell Broadcast Message Types +CSCB GOTOBUTTON
_Toc410546448 PAGEREF _Toc410546448 42
3.3.5 Save Settings +CSAS GOTOBUTTON _Toc410546449 PAGEREF
_Toc410546449 43
3.3.6 Restore Settings +CRES GOTOBUTTON _Toc410546450 PAGEREF
_Toc410546450 43
3.3.7 Informative Examples GOTOBUTTON _Toc410546451 PAGEREF
_Toc410546451 43
3.4 Message Receiving and Reading Commands GOTOBUTTON _Toc410546452
PAGEREF _Toc410546452 44
3.4.1 New Message Indications to TE +CNMI GOTOBUTTON _Toc410546453
PAGEREF _Toc410546453 44
3.4.2 List Messages +CMGL GOTOBUTTON _Toc410546454 PAGEREF
_Toc410546454 48
3.4.3 Read Message +CMGR GOTOBUTTON _Toc410546455 PAGEREF
_Toc410546455 49
3.4.4 New Message Acknowledgement to ME/TA +CNMA GOTOBUTTON
_Toc410546456 PAGEREF _Toc410546456 49
3.4.5 Informative Examples GOTOBUTTON _Toc410546457 PAGEREF
_Toc410546457 50
3.5 Message Sending and Writing Commands GOTOBUTTON _Toc410546458
PAGEREF _Toc410546458 51
3.5.1 Send Message +CMGS GOTOBUTTON _Toc410546459 PAGEREF
_Toc410546459 51
3.5.2 Send Message from Storage +CMSS GOTOBUTTON _Toc410546460
PAGEREF _Toc410546460 52
3.5.3 Write Message to Memory +CMGW GOTOBUTTON _Toc410546461
PAGEREF _Toc410546461 53
3.5.4 Delete Message +CMGD GOTOBUTTON _Toc410546462 PAGEREF
_Toc410546462 53
3.5.5 Send Command +CMGC GOTOBUTTON _Toc410546463 PAGEREF
_Toc410546463 53
3.5.6 More Messages to Send +CMMS $(TEI R97)$ GOTOBUTTON _Toc410546464
PAGEREF _Toc410546464 54
3.5.7 Informative Examples GOTOBUTTON _Toc410546465 PAGEREF
_Toc410546465 54
4 PDU Mode GOTOBUTTON _Toc410546466 PAGEREF _Toc410546466 55
4.1 List Messages +CMGL GOTOBUTTON _Toc410546467 PAGEREF
_Toc410546467 55
4.2 Read Message +CMGR GOTOBUTTON _Toc410546468 PAGEREF
_Toc410546468 56
4.3 Send Message +CMGS GOTOBUTTON _Toc410546469 PAGEREF
_Toc410546469 56
4.4 Write Message to Memory +CMGW GOTOBUTTON _Toc410546470 PAGEREF
_Toc410546470 57
4.5 Send Command +CMGC GOTOBUTTON _Toc410546471 PAGEREF
_Toc410546471 57
4.6 New Message Acknowledgement to ME/TA +CNMA GOTOBUTTON
_Toc410546472 PAGEREF _Toc410546472 58
4.7 Send Message from Storage +CMSS GOTOBUTTON _Toc410546473
PAGEREF _Toc410546473 59
Annex A (Normative): Character Set Conversions for SMS Text Mode
GOTOBUTTON _Toc410546474 PAGEREF _Toc410546474 60
Annex B (Informative): Example of processing a data block GOTOBUTTON
_Toc410546475 PAGEREF _Toc410546475 63
B.1 Example state diagrams for the block receiver GOTOBUTTON
_Toc410546476 PAGEREF _Toc410546476 63
B.2 Example of coding and decoding a data block GOTOBUTTON
_Toc410546477 PAGEREF _Toc410546477 63
Annex C (Informative): Change History GOTOBUTTON _Toc410546478
PAGEREF _Toc410546478 67
History GOTOBUTTON _Toc410546479 PAGEREF _Toc410546479 68
Blank page
Foreword
This Global System for Mobile communications Technical Specification
(GTS) has been produced by the Special Mobile Group (SMG) of the
European Telecommunications Standards Institute (ETSI).
This GTS outlines the use of data terminal equipment and specifies the
terminal (DTE-DCE) interface for Short Message and Short Message Cell
Broadcast Services within the digital cellular telecommunications
system.
The contents of this GTS are subject to continuing work within SMG and
may change following formal SMG approval. Should SMG modify the contents
of this GTS it will then be republished by ETSI with an identifying
change of release date and an increase in version number as follows:
Version 5.x.y
where:
y the third digit is incremented when editorial only changes have been
incorporated in the specification;
x the second digit is incremented for all other types of changes, i.e.
technical enhancements, corrections, updates, etc.
The specification from which this ETS has been derived was originally
based on CEPT documentation, hence the presentation of this ETS may not
be entirely in accordance with the ETSI/PNE Rules.
Introduction
The present document includes references to features which were
introduced into the GSM Technical specifications after Release 96 of GSM
Phase 2+. The text that is relevant, if the feature is supported, is
marked with designators. GSM 10.01 defines the correspondence between
these features and GSM yearly releases.
The following table lists all features that were introduced after
Release 96 and have impacted this specification:
Feature Designator
Technical enhancement and improvement: New optional command $(TEI R97)$
Enhanced Validity Period Format $(EVPF)$
Blank page
0 Scope
This Global System for Mobile communications Technical Specification
(GTS) defines three interface protocols for control of SMS functions
within a GSM mobile telephone from a remote terminal via an asynchronous
interface.
Clause 2 defines a binary protocol (``Block Mode''). The protocol
includes error protection and is suitable for use where the link may not
be completely reliable. It will be of particular use where control of
remote devices is required. Efficient transfer of binary encoded user
data is possible.
Clause 3 defines a character-based interfaced based on ``AT'' commands
(``Text Mode''). This mode is suitable for unintelligent terminals or
terminal emulators, and for application software built on command
structures like those defined in V.25ter. Some of the commands defined
in clause 3 will also be useful for implementations of clause 2 and/or
clause 4, for example enabling an indication of incoming SMS messages.
Clause 4 defines a character-based interface with hex-encoded binary
transfer of message blocks (``PDU Mode''). This mode is suitable for
software drivers based on AT command structures which do not understand
the content of the message blocks and can only pass them between the MT
and ``upper level'' software resident in the TE.
In all three modes, the terminal is considered to be in control for
SMS/CBS transactions.
This specification considers the mobile termination to be a single
entity. Other GSM Technical Specifications describe the split of
functionality between the mobile equipment and SIM.
The three ``modes'' referred to above, are represented in figure 0.1/GSM
07.05.
The ``Block mode'' is a self contained mode in its own right, and when
entered, control will remain within that mode until the procedures to
exit the mode are executed, after which control is returned to the
V.25ter ``command'' state or ``on-line command'' state.
The ``Text'' and ``PDU'' modes are not in themselves V.25ter states but
are simply sets of commands which will operate in either the V.25ter
``command'' state or ``on-line command'' state. The ``Text'' and ``PDU''
modes are transitory states and after each operation, control is
automatically returned to the V.25ter ``command'' state or ``on-line
command'' state. Whilst in the V.25ter command state, the MS is
available to handle incoming and outgoing calls such as Data or
Facsimile.
Figure 0.1/GSM 07.05: Block, Text and PDU modes
In the ``Block mode'' and ``PDU'' mode a mobile is not permitted to
modify any component of an SMS/CBS message received from the air
interface or an SMS message received from a TE, before passing it on,
except where GSM 03.40 or GSM 03.41 defines a ``component modification
facility'' and where this ``component modification facility'' is
supported by the mobile. In the Text Mode the mobile may be unable to
display characters coded in particular coding schemes. In this case,
the mobile shall behave as described in GSM 03.38 and assume the coding
scheme to be the GSM Default Alphabet.
0.1 Normative references
This GTS 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 GTS 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 350): " Digital cellular telecommunications system
(Phase 2+); Abbreviations and acronyms " .
[2] GSM 03.38 (ETS 300 900): " Digital cellular telecommunications system
(Phase 2+); Alphabets and language-specific information " .
[3] GSM 03.40 (ETS 300 901): " Digital cellular telecommunications system
(Phase 2+); Technical realization of the Short Message Service (SMS)
Point-to-Point (PP) " .
[4] GSM 03.41 (ETS 300 902): " Digital cellular telecommunications system
(Phase 2+); Technical realization of Short Message Service Cell
Broadcast (SMSCB) " .
[5] GSM 04.08 (ETS 300 940): " Digital cellular telecommunications system
(Phase 2+); Mobile radio interface layer 3 specification " .
[6] GSM 04.11 (ETS 300 942): " Digital cellular telecommunications system
(Phase 2+); Point-to-Point (PP) Short Message Service (SMS) support on
mobile radio interface " .
[7] GSM 04.12 (ETS 300 943): " Digital cellular telecommunications system
(Phase 2+); Short Message Service Cell Broadcast (SMSCB) support on the
mobile radio interface " .
[8] GSM 07.01 (ETS 300 913): " Digital cellular telecommunications system
(Phase 2+); General on Terminal Adaptation Functions (TAF) for Mobile
Stations (MS) " .
[9] GSM 07.07 (ETS 300 916): " Digital cellular telecommunications system
(Phase 2+); AT command set for GSM Mobile Equipment (ME) " .
[10] GSM 11.11 (ETS 300 977): " Digital cellular telecommunications
system (Phase 2+); Specification of the Subscriber Identity Module -
Mobile Equipment (SIM - ME) interface " .
[11] CCITT Recommendation V.25ter: ``Serial Asynchronous Automatic
Dialling And Control''
[12] CCITT Recommendation V.24: " List of definitions for interchange
circuits between data terminal equipment (DTE) and data
circuit-terminating equipment " .
[13] CCITT Recommendation E.164: " Numbering plan for the ISDN era " .
[14] CCITT Recommendation E.163: " Numbering plan for the international
telephone service " .
0.2 Abbreviations
Abbreviations used in this specification are listed in GSM 01.04 [1].
1 Reference configuration
MOBILE TERMINATION (MT2)
Figure 1: Reference configuration
The mobile termination consists of the mobile equipment (ME) and the
SIM. Messages may be stored in either, but this specification does not
distinguish between messages stored in the SIM or in the ME. The
management of message storage in the two parts of the mobile termination
is a matter for the mobile termination implementation.
1.1 V.24 Interface Circuits
The operation of the CCITT V.24 blue book interface circuits for SMS is
shown in table 1.1/GSM 07.05.
Table 1.1/GSM 07.05: Use of V.24 interface circuits
V.24 CIRCUIT DESCRIPTION TE to MT MT to TE
CT102 signal ground x x
CT103 TXD x
CT104 RXD
x
CT105 RTS x
CT106 CTS
x
CT107 DSR
x
CT108.2 DTR x
CT109 DCD
x
NOTE: CT105 at the TE is connected to CT133 at the MT
1.1.1 Circuit definitions for the SMS Block mode
CT103
All commands from the TE to the MT are transferred across this circuit.
Inband flow control is not permitted during Block Mode.
CT104
All responses/indications from the MT to the TE are transferred across
this circuit. Inband flow control is not permitted during Block Mode.
CT105
This circuit allows the TE to flow control the MT when in the Block Mode
and at other times if hardware flow control is enabled.
CT106
This circuit allows the MT to flow control the TE when in the Block Mode
and at other times if hardware flow control is enabled.
CT107
This circuit shall be set to the ON condition before entry into the
Block Mode, and shall remain in the ON condition during Block Mode. If
the TE detects that this circuit returns to the OFF condition during the
block mode then the TE shall return CT108.2 to the OFF condition and
exit the Block Mode.
CT108.2
This circuit shall be set in the ON condition before the AT+CESP command
is sent from the TE to begin the Block Mode, and shall be maintained in
the ON condition during the Block Mode. It shall be returned to the OFF
condition after the command 'END SMS MODE' has been accepted and
acknowledged by the MT. If the MT detects that this circuit returns to
the OFF condition during the Block Mode then the MT shall exit the Block
Mode.
CT109
This circuit shall be set to the ON condition before entry into the
Block Mode and remain in the ON condition during the Block Mode. If the
TE detects that this circuit returns to the OFF condition during the
Block Mode then the TE shall return CT108.2 to the OFF condition and
shall exit the Block Mode.
1.1.2 Circuit definitions for the SMS Text and PDU modes
Only circuits CT102, CT103 and CT104 are mandatory for the Text and PDU
modes. The functionality and operation of other circuits shall be in
accordance with V.25ter.
2 SMS Block Mode
2.1 Beginning and ending of SMS/CBS Block Mode
2.1.1 Beginning SMS/CBS Block Mode
As described in GSM 07.01, the DTE/DCE interface is normally associated
with the terminal adaptation function (TAF), if such a function is
available. When no data connection is in progress, and the terminal
equipment wishes to enter SMS/CBS mode, the command 'AT+CESP' shall be
issued by the TE through the DTE/DCE interface requesting that the Block
mode protocol described in this specification is to be used. The syntax
of this command is further described in subclause 3.2.4 later. The
syntax for these commands is derived from V.25ter, i.e. the command is
encoded as an IA5 character string together with delimiters as described
in V.25ter.
Upon receipt of this command, the mobile termination shall respond as
follows:
If the mobile termination supports SMS/CBS block mode commands,
responses and indications as described in this technical specification,
it shall respond with 'OK' (or 0) and enter the SMS/CBS mode.
If the mobile termination does not support SMS/CBS block mode commands,
responses and indications as described in this technical specification,
it shall respond with 'ERROR' (or 4) and remain in the current mode..
Terminal software shall wait a short time (e.g. 5 seconds) for the `OK'
(0) or `ERROR' (4) response. If neither response is received before the
timeout then the terminal software shall assume that the block mode has
been entered. The terminal software may then submit its first block
mode command. If no response is received to this command then the
terminal software shall proceed as described below in subclause 2.2
(i.e. repeat the command 3 times and then exit the block mode).
If the SMS/CBS block mode command is accepted by the mobile termination,
then all further commands, responses and indications shall be as defined
in clause 2 of this technical specification. These SMS/CBS mode
commands, responses and indications use 8-bit encoded data and not IA5
characters.
2.1.2 Returning from SMS/CBS Block Mode To Default Mode
When the terminal equipment wishes to return to default mode from
SMS/CBS mode, it shall issue the command 'END SMS MODE', described in
subclause 2.4.1.11. The mobile termination shall respond with 'OK' (or
0) to indicate that the DTE/DCE interface has returned to default mode.
The TE shall change back to default mode whether or not such a response
is received.
The TE may also indicate that it has exit from the SMS/CBS mode through
the use of CT 108/2 (see subclause 1.1)
If an incoming data call arrives while the DTE/DCE interface is set to
SMS/CBS mode, then the mobile termination may autonomously issue the
'END SMS MODE' indication (subclause 2.4.2.11) and revert to default
mode in order to connect the data call through the TAF.
The MT may exit from SMS/CBS mode autonomously if the power to the MT is
switched off and then on again. In addition, the MT manufacturer may
provide MMI to change the mode back to the default mode. In the latter
case, the MT shall issue the 'END SMS MODE' indication (subclause
2.4.2.11) and exit the SMS/CBS mode immediately.
The MT may also indicate that it has exit from the SMS/CBS mode through
the use of CT 107 and
CT 109 (see subclause 1.1).
A BREAK condition in either direction at the DTE/DCE interface shall
cause the TE and the MT to exit from the SMS/CBS block mode and return
to the default mode.
In the event where the TE or the MT find themselves unable to recover
from a protocol error then either entity may exit the SMS/CBS mode using
any of the mechanisms described above. Confirmation of default mode
operation will be achieved through the use of AT commands and responses.
2.2 Protocol description
The communication path between the MT and the TE across the DTE/DCE
interface should be quite reliable if it uses a short wire link.
However, to ensure that the low error rate does not cause malfunction,
the following error protection scheme is provided.
Each message sent from the MT to the TE or vice-versa consists of a data
block (DATA) and block check sum (BCS, see figure 2.2.1). In the
following description the notation DLE, STX, NUL and ETX refer to
control characters having the values 10 02 00 and 03 hexadecimal
respectively.
& lt; -----------------DATA----------------- & gt; & lt; - BCS - & gt;
DLE STX Message content DLE ETX BCS BCS
10H 02H
10H 03H MSB LSB
Figure 2.2.1/GSM 07.05: Format of DTE/DCE interface messages
The data block consists of a start transmission sequence, set to
00010000 00000010 (10 02 hex), the message content as defined below and
an end transmission sequence, set to 00010000 00000011 (10 03 hex). The
least significant bit of each octet is always transmitted first.
The block check sum is calculated at the transmitter by adding all of
the octets in the message content modulo 65536. Each bit of the 16-bit
result is then inverted, and 1 is added to the answer.
During transmission of the message content and the BCS octets, any
occurrence of the value 10 hex (DLE) shall result in an additional
'stuffing' octet of value 00 hex (NUL) being transmitted immediately
following the octet containing 10 hex. This is to ensure that the start
and end markers are unambiguous. The receiver shall remove stuffing
octets by discarding any octet of value 00 hex (NUL) which immediately
follows an octet of value 10 hex (DLE).
After removal of any stuffing octets, the receiver can check the BCS by
adding all of the octets in the message content and the 16-bit BCS
modulo 65536. The correct result is 0000 hex. If any message is received
with an incorrect BCS, then the message is discarded. No response is
sent over the DTE/DCE interface, but an indication may be provided to
higher layers within the receiving entity.
The transmitter shall only send DLE when it is followed by STX, NUL or
ETX. Therefore, if the receiver sees a DLE followed by anything else
then the receiver shall assume that some data has been lost, and shall
start to search for the start marker. An unexpected end marker at the
receiver shall also result in a search for a start marker. A start
marker shall always be treated as the start of a new block, regardless
of which state the receiver is in.
Examples of state diagrams for a block receiver to implement this
procedure are given in Annex B, together with an example of coding and
decoding a message.
Only one Command/Response transaction shall be permitted at any one time
from any sending or receiving entity. It shall however be possible for a
Command/Response transaction from one entity to be initiated even if
there is a Command/Response transaction in progress from the other
entity.
If an immediate response is expected to a message sent over the DTE/DCE
interface, then the sending entity shall wait 10 seconds. If no response
is received within this time, the sending entity shall repeat the
message. The message shall be repeated a maximum of 3 times, after which
the sending entity shall exit from the SMS/CBS mode and provide an error
indication to the user.
If a message cannot be understood by the receiving entity even though it
has a correct BCS, then it shall return an UNABLE TO PROCESS message
with cause value 'Command not understood'. The receipt of an UNABLE TO
PROCESS message should not in itself initiate re-transmission although
re-transmission may take place due to the timeout mechanism described
earlier since an UNABLE TO PROCESS is deemed to be an invalid response.
The `Cause' may however be referred to a higher layer. An UNABLE TO
PROCESS shall not be sent as the result of an incorrect BCS.
2.3 Requesting messages already held in the Mobile Termination
The TE may request the MT to provide SMS or CBS messages already stored.
The TE will either request all messages, or request a list of messages
and subsequently ask for specific messages.
At the start of the SMS/CBS mode session, the MT shall number all
messages contiguously, starting with message number 1. These " Short
Message References " are only valid for a single SMS/CBS MODE session and
should not be confused with the GSM 03.40 TP-Message-Reference. Each
message retains its Short Message Reference for the duration of the
SMS/CBS mode session. New messages will normally be given the lowest
previously-unused Short Message Reference. However, if all Short Message
References have been used then the MT may reallocate Short Message
References previously allocated to now-deleted messages.
Short Message Reference 0 signifies that there are no messages in the
MT. The value of 0 is used under the following conditions:
- When an INSERT SMS command is used to transfer an SM over the air
interface and not store it in the MT then the MT will return a Short
Message Reference of 0 in the REQUEST CONFIRMED response and the ensuing
INSERT SMS COMPLETE / INSERT SMS FAILURE indications.
- For Class 0 SM's which are not stored in the MT
- For TE specific SM's which are not stored in the MT
If Message number 0 is requested by the TE, the MT will always return an
error cause, but will also include the highest valid Short Message
Reference (see subclause 2.3.2.1 below).
2.3.1 Requesting List Of Messages
The TE may request the MT to provide a list of SMS and CBS messages
currently stored in the mobile termination. This is achieved by the
LIST REQUEST command (subclause 2.4.1.1). The MT divides the messages
stored into groups of 5 (called pages) and transfers the first 5 in a
MESSAGE LIST response (subclause 2.4.2.1) containing message references
allocated by the MT, plus the relevant header information described in
GSM 03.40/04.11 and GSM 03.41/04.12.
If there are no messages stored in the MT, then the MESSAGE LIST
response shall be empty.
The TE may then request further groups of up to 5 messages by repeating
the LIST REQUEST command for pages 2,3, and so on. The MT will indicate
that there are no more pages by responding with an empty MESSAGE LIST
response.
2.3.2 Requesting Transfer Of Messages
The TE may request the transfer of one or more messages by means of the
commands described below. The MT does not delete messages which have
been transferred. Messages can only be deleted by the DELETE MESSAGE
command (subclause 2.4.1.9).
2.3.2.1 Requesting Transfer Of A Specific Message
The TE may request the MT to transfer a specific message by sending the
GET MESSAGE command (subclause 2.4.1.2), including the appropriate
message reference. The MT will provide the full message including header
in a MESSAGE response (subclause 2.4.2.2). If the message reference is
unallocated, then the GET MESSAGE FAILURE response is returned with
cause 'No such message' and the highest valid Message Reference
(subclause 2.4.2.3).
2.3.2.2 Requesting Transfer Of All Messages
The TE may request the MT to transfer all messages by sending the GET
FIRST MESSAGE command (subclause 2.4.1.3), followed by the appropriate
number of GET NEXT MESSAGE commands (subclause 2.4.1.4).
The MT shall be able to transfer all messages one-by-one, starting with
the 'first' and continuing with the 'next'. The precise ordering of the
messages is left to the MT implementation.
If the MT exits from SMS/CBS mode for any reason, then this information
need not be retained.
On receipt of the GET FIRST MESSAGE command, the MT shall set a pointer
to the first message, and transfer this message using the MESSAGE
response as described in subclause 2.3.2.1.
On receipt of the GET NEXT MESSAGE command, the MT shall move the
pointer to the first available message after the last message
transferred (using either GET FIRST MESSAGE, GET MESSAGE or GET NEXT
MESSAGE), and transfer this message using the MESSAGE response as
described in subclause 2.3.2.1.
If the MT receives a GET NEXT MESSAGE command when all messages have
been transferred to the TE, or there are no messages stored in the MT,
then the GET MESSAGE FAILURE response shall be provided with the cause
'No such message' (see subclause 2.4.2.3).
If the TE receives an out of sequence message then it shall attempt to
transfer the missing message using the GET MESSAGE command before
continuing with GET NEXT MESSAGE. If this attempt fails with the cause
'no such message', it means that the message has been deleted, or it has
been lost due to a failure at the MT.
The MT includes a LAST SHORT MESSAGE REFERENCE in the GET MESSAGE
FAILURE response. This is so that the TE can detect whether or not the
last short message was received in error.
If the MT receives a GET NEXT MESSAGE command prior to receiving a GET
FIRST MESSAGE or GET MESSAGE command, then it shall continue as if the
command had been GET FIRST MESSAGE (i.e. provide the 'first' message and
continue with the 'next' on receipt of the subsequent GET NEXT MESSAGE
command).
2.3.3 Requesting Diversion Of Incoming Messages
The TE may request the MT to transfer SMS or CBS messages directly from
the air interface to the DTE/DCE interface, by the following procedures.
If messages are diverted then they are not stored in the MT. If messages
are diverted and there is no communication path to the TE (e.g. because
it has been disconnected), the diversion shall be cancelled.
2.3.3.1 Requesting SMS Messages
The TE may request an indication of arrival of incoming SMS messages, or
the direct transfer of incoming SMS messages.
The TE requests new SMS messages by the TRANSFER INC SMS command
(subclause 2.4.1.5). This command will be sent with parameters
indicating whether all incoming SMS messages are to be transferred, or
only those indicated as being for the TE.
The MT shall confirm receipt of this command with a REQUEST CONFIRMED
message provided there is memory available to store SM's in the ME or
the SIM. If there is no memory available, the MT shall respond with
'unable to process' with a cause value No memory.
The MT shall transfer incoming messages by the INC MESSAGE indication
(subclause 2.4.2.4).
For an INC MESSAGE which contains a Short Message (SMS) info element id,
the TE shall acknowledge receipt of the INC MESSAGE with an ACKNOWLEDGE
MESSAGE (subclause 2.4.1.12). The MT should not send another INC MESSAGE
which contains a Short Message (SMS) info element id to the TE whilst it
is waiting for an ACKNOWLEDGE MESSAGE.
In the event of the MT not receiving an ACKNOWLEDGE MESSAGE within a
time specified by the MT manufacturer the MT shall exit the SMS mode
automatically after 'n' attempts to send the INC MESSAGE (where n is a
number specified by the MT manufacturer). The MT should attempt to store
the unacknowledged SM or Status Report (contained in the INC MESSAGE) in
the MT or on the SIM as appropriate.
The ACKNOWLEDGE MESSAGE sent from the TE to the MT must not delay the MT
sending the RP-ACK defined in GSM 03.40 (to the SC) for longer than the
RP-ACK timeout specified in GSM 04.08.
The TE requests the cessation of incoming message transfer by the same
command, indicating no incoming messages. The transfer of messages will
automatically cease on exit of the SMS/CBS mode. Transfer shall not
recommence until a new request is issued by the TE.
2.3.3.2 Requesting CBS Messages
The TE may request the transfer of all cell broadcast messages directly
from the air interface to the DTE/DCE interface. This is achieved by
the use of the TRANSFER INC CBS message (subclause 2.4.1.7).
The MT shall confirm receipt of this command with a REQUEST CONFIRMED
message.
After receipt of this command, the MT shall transfer all CBS pages as
they arrive on the air interface, using the INC MESSAGE indication
(subclause 2.4.2.4).
While the CBS pages are being transferred, any other indication or
response required to be sent to the TE will take precedence over the CBS
pages. However, the MT shall not interrupt the transfer of a page to
send other information within the SMS/CBS mode (ie. the MT shall wait
until a page boundary).
The transfer of messages will automatically cease on exit of the SMS/CBS
mode. Transfer shall not recommence until a new request is issued by
the TE.
2.3.3.3 Requesting indication of message arrival
If the TE requires an indication of incoming message arrival, the
INDICATE INC SMS command (subclause 2.4.1.6) shall be used.
The MT shall confirm receipt of this command with a REQUEST CONFIRMED
message.
After receipt of this command, the MT shall indicate all incoming
messages in the specified categories (unless they are directly
transferred) with the MESSAGE ARRIVED indication (subclause 2.4.2.5).
This indication shall be of the same format as the MESSAGE LIST response
described in subclause 2.3.1.
The TE shall acknowledge receipt of the MESSAGE ARRIVED with an
ACKNOWLEDGE MESSAGE. (subclause 2.4.1.12). The MT should not send
another MESSAGE ARRIVED to the TE whilst it is waiting for an
ACKNOWLEDGE MESSAGE.
In the event of the MT not receiving an ACKNOWLEDGE MESSAGE within a
time specified by the MT manufacturer the MT shall exit the SMS mode
automatically after `n' attempts to send the MESSAGE ARRIVED (where n is
a number specified by the MT manufacturer). The MT should attempt to
store the unacknowledged SM or Status Report in the MT or on the SIM as
appropriate.
The ACKNOWLEDGE MESSAGE sent from the TE to the MT must not delay the MT
sending the RP-ACK defined in GSM 03.40 (to the SC) for longer than the
RP-ACK timeout specified in the GSM 04.08.
The TE requests the cessation of incoming message indication by the
INDICATE INC SMS command, with the 'no incoming messages' parameter.
2.3.4 Requesting Transfer Into Mobile Termination
The TE may request transfer of SMS messages into the mobile termination.
Cell broadcast messages cannot be transferred in this direction.
The TE shall use the INSERT SMS command (subclause 2.4.1.8) to transfer
the message. This command shall indicate whether the message is to be
stored in the MT, sent over the air interface or both. The command
shall include the full SMS message and header as described in GSM 03.40,
except for the message reference and message type indication (which are
allocated by the MT).
Only one INSERT SMS command may be outstanding at any given instant. An
INSERT SMS is deemed complete when an INSERT SMS COMPLETE or an INSERT
SMS FAILURE indication has been received irrespective of whether an
intermediate REQUEST CONFIRMED has been received.
Upon receipt of an INSERT SMS command, the MT shall act in the
following way:
If the TE requested the MT to store the message, the MT shall attempt to
store the message. If the attempt is successful, the MT shall return an
INSERT SMS COMPLETE indication (subclause 2.4.2.6), including the
message reference allocated by the MT. If the attempt fails (eg. due to
lack of memory), the MT shall return an INSERT SMS FAILURE indication
(subclause 2.4.2.7), providing a cause for the failure.
If the TE requested the MT to send the message, the MT shall respond
immediately with a REQUEST CONFIRMED message, and attempt to send the
message. If the send attempt subsequently succeeds, the MT shall send an
INSERT SMS COMPLETE indication, including the message references
allocated by the MT. If the send attempt subsequently fails, the MT
shall return an INSERT SMS FAILURE indication, providing a cause for the
failure.
If the TE requested the MT to store and send the message, the MT shall
first attempt to store the message. If no storage is available, the MT
shall return an INSERT SMS FAILURE indication (subclause 2.4.2.7) and
shall not attempt to send the message. If storage is available, the MT
shall store the message and then respond with a REQUEST CONFIRMED
message. If the send attempt is successful, the MT shall return an
INSERT SMS COMPLETE indication (subclause 2.4.2.6), including the
message references allocated by the MT. If the transmission of the
message fails, then the MT shall return an INSERT SMS FAILURE indication
(subclause 2.4.2.7). This will show that the send attempt failed and
provide a cause. After that the MT shall delete the stored message.
2.3.5 Requesting Deletion Of Messages
The TE may request deletion of SMS or CBS messages from the store in the
MT. This is achieved by the DELETE MESSAGE command (subclause 2.4.1.9).
The command will include a message reference, as defined by the MT and
provided in the message list.
Upon receipt of this command, the MT shall attempt to delete the
message. If successful, the MT shall return a DELETE MESSAGE COMPLETE
indication (subclause 2.4.2.8). If not successful, the MT shall return a
DELETE MESSAGE FAILURE indication (subclause 2.4.2.9).
On successful deletion of an SM or CBS message the Page Index (see
2.5.2.10) and the Index Count (see 2.5.2.8) shall be re-assigned so that
their values are contiguous (i.e. there are no gaps in either
parameter). The original short message Reference values remain
unchanged.
2.4 Message functional definitions and contents
This subclause provides an overview of the message structure to be used
over the DTE/DCE interface in SMS/CBS block mode. Each message
definition includes a brief description of the use of the message, and a
table showing all the information elements which may be included in the
message. If an entity receives a message containing more information
elements than expected then the receiving entity shall ignore the
additional information elements. For each information element the
following data are provided:
Reference - this indicates where the detailed description of each
element can be found.
Presence:
M Mandatory must always be present
receiver: If not present, consider message erroneous
C Conditional presence depending on e.g.
a) value of other element
b) presence of optional element
receiver: If not present when condition met, consider message
erroneous
O Optional presence is a choice of the sender
receiver: present or not, accept message
Format:
T Type only, fixed length, only IEI
V Value only, fixed length, no IEI included
TV Type and value, fixed length, IEI included
LV Length and value, variable length, no IEI included and Length
indicator included
TLV Type, Length and Value, variable length, IEI and length indicator
included
Length - this indicates the length of the information element in octets.
2.4.1 Commands Issued By The Terminal Equipment
Table 2.4.1/GSM 07.05 summarises the commands which may be issued by the
TE.
Table 2.4.1/GSM 07.05: Commands which may be issued by the TE
Reference
LIST REQUEST 2.4.1.1
GET MESSAGE 2.4.1.2
GET FIRST MESSAGE 2.4.1.3
GET NEXT MESSAGE 2.4.1.4
TRANSFER INC SMS 2.4.1.5
INDICATE INC SMS 2.4.1.6
TRANSFER INC CBS 2.4.1.7
INSERT SMS 2.4.1.8
DELETE MESSAGE 2.4.1.9
UNABLE TO PROCESS 2.4.1.10
END SMS MODE 2.4.1.11
ACKNOWLEDGE MESSAGE 2.4.1.12
2.4.1.1 List Request
This message is sent by the TE to the MT to request a list of messages
stored in the MT.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Page Index 2.5.2.10 M V 1
2.4.1.2 Get Message
This message is sent by the TE to the MT to request transfer of a
specific SMS or CBS message stored in the MT.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Reference 2.5.2.1 M V 1
2.4.1.3 Get First Message
This message is sent by the TE to the MT to request transfer of the
first available SMS or CBS message stored in the MT.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
2.4.1.4 Get Next Message
This message is sent by the TE to the MT to request transfer of the next
available SMS or CBS message stored in the MT.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
2.4.1.5 Transfer Inc SMS
This message is sent by the TE to the MT to request the direct transfer
of incoming messages from the air interface to the TE.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
SMS Transfer Type 2.5.2.2 M V 1
2.4.1.6 Indicate Inc SMS
This message is sent by the TE to the MT to request that the MT
indicates when an incoming message arrives.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Indication Type 2.5.2.3 M V 1
2.4.1.7 Transfer Inc CBS
This message is sent by the TE to the MT to request transfer of all cell
broadcast messages directly from the air interface to the DTE/DCE
interface.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
CBS Transfer Type 2.5.2.9 M V 1
2.4.1.8 Insert SMS
This message is sent by the TE to the MT to request the transfer of an
SMS TPU to the MT memory or across the air interface. The TPDU is
formatted in exactly the same way as described in TS 03.40. Where the
TPDU includes a TP-Message-Reference which is to be incremented by the
MT for every outgoing message, the TP-Message-Reference provided by the
TE will be overwritten by the MT before transmission of the message. The
value provided by the TE is discarded by the MT and has no significance.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Insert Type 2.5.2.4 M V 1
RP-Destination-Address GSM 04.11 M LV 1-12 a)
SMS-TPDU GSM 03.40 M V max 164
a) If no RP-Destination-Address is to be transferred then the length is
set to 0. In this case, the MT inserts the default SC address.
2.4.1.9 Delete message
This message is sent from the TE to the MT to request deletion of a
specific SMS or CBS message held in the MT.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Reference 2.5.2.1 M V 1
2.4.1.10 Unable to process
This response is sent from the TE to the MT to indicate that the MT's
message could not be processed.
Information element Preference Presence Format Length
Message Type 2.5.1 M V 1
Cause 2.5.2.7 M V 1
2.4.1.11 End SMS Mode
This message is sent from the TE to the MT to terminate the SMS/CBS mode
of the DTE/DCE interface.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
2.4.1.12 Acknowledge Message
This message is sent from the TE to the MT to acknowledge receipt of a
INC MESSAGE or MESSAGE ARRIVED which contains a Short Message (SMS) info
element id, (e.g. a Short Message or a Status Report but not a CBS
message.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
SM-Deliver-Ack 2.5.2.14 O TLV 2 to 160
2.4.2 Responses/Indications Issued By The MT
Table 2.4.2/GSM 07.05 summarises the responses/indications which may be
issued by the MT.
Table 2.4.2/GSM 07.05: Responses/Indications which may be issued by the
MT
Reference
MESSAGE LIST 2.4.2.1
MESSAGE 2.4.2.2
GET MESSAGE FAILURE 2.4.2.3
INC MESSAGE 2.4.2.4
MESSAGE ARRIVED 2.4.2.5
INSERT SMS COMPLETE 2.4.2.6
INSERT SMS FAILURE 2.4.2.7
DELETE MESSAGE COMPLETE 2.4.2.8
DELETE MESSAGE FAILURE 2.4.2.9
UNABLE TO PROCESS 2.4.2.10
END SMS MODE 2.4.2.11
REQUEST CONFIRMED 2.4.2.12
2.4.2.1 Message List
This response is sent from the MT to the TE on receipt of a LIST REQUEST
from the TE.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Page Index 2.5.2.10 M V 1
Index Count 2.5.2.8 M V 1
Short Message Index (1) 2.5.2.5 O TLV 8-48
Short Message Index (2) 2.5.2.5 O TLV 8-48
: : : : :
Short Message Index (n) 2.5.2.5 O TLV 8-48
The number of Short Message Indices included in the message may be 0, 1,
2, 3, 4 or 5.
2.4.2.2 Message
This response is sent from the MT to the TE when a short message has
been requested.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Data 2.5.2.6 M TLV 28-181
2.4.2.3 Get Message Failure
This response is sent from the MT to the TE when a request for a short
message cannot be fulfilled.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Last Short Message 2.5.2.11 M V 1
Cause 2.5.2.7 M V 1
2.4.2.4 Inc Message
This indication is sent from the MT to the TE after the MT has been
requested to transfer messages of certain categories immediately upon
receipt.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Data 2.5.2.6 M TLV 28-181
2.4.2.5 Message Arrived
This indication is sent from the MT to the TE after the MT has been
requested to provide an indication of the receipt of certain categories
of incoming message.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Index 2.5.2.5 M TLV 8-48
2.4.2.6 Insert SMS Complete
This response is sent by the MT to the TE to indicate that the TE's
request to insert a message has been completed.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Reference 2.5.2.1 M V 1
TP-Message Reference GSM 03.40 C a) V 1
SM-Submit-Ack 2.5.2.15 O TLV 2 to 160
a) The TP-Message Reference is only included if the message had been
requested to be transferred over the air interface.
2.4.2.7 Insert SMS Failure
This response is sent from the MT to the TE to indicate that the attempt
to insert an SMS message failed.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Cause 2.5.2.7 M V 1-2
TP-Failure Cause 2.5.2.13 O TLV 4
Short Message Reference 2.5.2.1 O TV 2
2.4.2.8 Delete Message Complete
This response is sent from the MT to the TE to indicate that the request
to delete a message from the MT store has been completed.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Reference 2.5.2.1 M V 1
2.4.2.9 Delete Message Failure
This response is sent from the MT to the TE to indicate that the request
to delete a message from the MT store failed.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Short Message Reference 2.5.2.1 M V 1
Cause 2.5.2.7 M V 1
2.4.2.10 Unable To Process
This response is sent from the MT to the TE to indicate that the TE's
request could not be processed.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Cause 2.5.2.7 M V 1
2.4.2.11 End SMS Mode
This indication is sent from the MT to the TE when the MT autonomously
exits from SMS/CBS mode.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Cause 2.5.2.7 M V 1
2.4.2.12 Request Confirmed
This indication is sent from the MT to the TE to indicate that the MT
has received the request from the TE and will perform the requested
function.
Information element Reference Presence Format Length
Message Type 2.5.1 M V 1
Confirm Type 2.5.2.12 M V 1
Short Message Reference 2.5.2.1 O TV 2
2.5 General message format and information elements coding
This subclause describes the content of messages for the SMS/CBS mode of
the DTE/DCE interface. Within the figures in this subclause, the bit
designated " bit 1 " is transmitted first, followed by bits 2,3,4 etc.
Similarly, the octet shown at the top of each figure is sent first.
2.5.1 Message Type
The purpose of the message type is to identify the function of the
message being sent. The message type is coded as shown in figure
2.5.1/GSM 07.05 and table 2.5.1/GSM 07.05.
Bit 8 is reserved for possible future use as an extension bit.
8 7 6 5 4 3 2 1
0
Message Type
octet 1
Figure 2.5.1/GSM 07.05: Message Type
Table 2.5.1/GSM 07.05: Message Types
8 7 6 5 4 3 2 1
0 0 0 - - - - - Commands/ Responses issued by TE
0 0 0 0 0 0 0 0 LIST REQUEST
0 0 0 0 0 0 0 1 GET MESSAGE
0 0 0 0 0 0 1 0 GET FIRST MESSAGE
0 0 0 0 0 0 1 1 GET NEXT MESSAGE
0 0 0 0 0 1 0 0 TRANSFER INC SMS
0 0 0 0 0 1 0 1 INDICATE INC SMS
0 0 0 0 0 1 1 0 TRANSFER INC CBS
0 0 0 0 0 1 1 1 INSERT SMS
0 0 0 0 1 0 0 0 DELETE MESSAGE
0 0 0 0 1 0 0 1 UNABLE TO PROCESS
0 0 0 1 1 1 1 0 END SMS MODE
0 0 0 1 1 1 1 1 ACKNOWLEDGE MESSAGE
0 0 1 - - - - - Responses/Indications issued by MT
0 0 1 0 0 0 0 0 MESSAGE LIST
0 0 1 0 0 0 0 1 MESSAGE
0 0 1 0 0 0 1 0 GET MESSAGE FAILURE
0 0 1 0 0 0 1 1 INC MESSAGE
0 0 1 0 0 1 0 0 MESSAGE ARRIVED
0 0 1 0 0 1 0 1 INSERT SMS COMPLETE
0 0 1 0 0 1 1 0 INSERT SMS FAILURE
0 0 1 0 0 1 1 1 DELETE MESSAGE COMPLETE
0 0 1 0 1 0 0 0 DELETE MESSAGE FAILURE
0 0 1 0 1 0 0 1 UNABLE TO PROCESS
0 0 1 0 1 0 1 0 REQUEST CONFIRMED
0 0 1 1 1 1 1 1 END SMS MODE
All other values are reserved. If a reserved Message Type is received
then the receiving entity shall return ``Unable to Process'' with Cause
``Command not understood''.
2.5.2 Other Information Elements
Other information elements follow the general coding principles
specified in GSM 04.08, and are described in the following subclauses.
2.5.2.1 Short Message Reference
The Short Message Reference uniquely identifies a short message stored
in the MT. It is an 8 bit number and is allocated by the MT.
The Short Message Reference information element is coded as shown in
figure 2.5.2/GSM 07.05 and table 2.5.2/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 octet 1
Short Message Reference info element id
Short Message Reference value octet 2
Figure 2.5.2/GSM 07.05: Short Message Reference information element
Table 2.5.2/GSM 07.05: Short Message Reference information element
Short Message Reference value (octet 2).
In the Short Message Reference value field bit 8 of octet 2 is the most
significant bit and bit 1 of octet 2 is the least significant bit.
Short Message Reference values are allocated by the MT.
2.5.2.2 SMS Transfer Type
The SMS Transfer Type indicates to the MT which SMS messages are
required to be transferred to the TE.
The SMS Transfer Type information element is coded as shown in figure
2.5.3/GSM 07.05 and table 2.5.3/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 1 octet 1
SMS Transfer Type info element ident
0 0 0 0 0 SMS Txfr octet 2
Reserved Type value
Figure 2.5.3/GSM 07.05: SMS Transfer Type information element
Table 2.5.3/GSM 07.05: SMS Transfer Type information element
SMS Txfr Type value (octet 2).
The SMS txfr type is coded as follows:
bit 2 bit 1
0 0 Transfer no SMS messages
0 1 Transfer SMS messages marked as
TE-specific
1 0 Reserved
1 1 Transfer all SMS messages
Bit 3 shows whether to transfer SMS-STATUS-REPORTS
Bit 3
0 Do not transfer SMS-STATUS-REPORTS
1 Transfer SMS-STATUS-REPORTS
A receiving entity shall ignore the setting of bits 8-4. If bit 2 is
set to 1 and bit 1 is set to 0 then the receiving entity shall return
``Unable to Process'' with cause ``Command Not Understood''
2.5.2.3 Indication Type
The Indication Type tells the MT when to notify the TE that an incoming
message has been received.
The Indication Type information element is coded as shown in figure
2.5.4/GSM 07.05 and table 2.5.4/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 0 0 1 0 octet 1
Indication Type info element identifier
0 0 0 0 Indication Type octet 2
Reserved value
Figure 2.5.4/GSM 07.05: Indication Type information element
Table 2.5.4/GSM 07.05: Indication Type information element
Indication Type value (octet 2).
The indication type is coded as follows:
bit 3 bit 2 bit 1
0 0 0 Indicate no messages
0 0 1 Reserved
0 1 0 Indicate all SMS messages
0 1 1 Indicate SMS messages marked as
TE-specific
1 0 0 Indicate all CBS messages
1 0 1 Indicate CBS messages marked as
TE-specific
1 1 0 Indicate all CBS and SMS messages
1 1 1 Indicate SMS and CBS messages marked
as TE-specific
Bit 4 shows whether or not to indicate SMS reports:
bit 4
0 Do not indicate SMS reports
1 Indicate SMS reports
A receiving entity shall ignore the setting of bits 8-5. If bits 3 and
2 are set to 0 and bit 1 is set to 1 then the receiving entity shall
return ``Unable to Process'' with cause ``Command Not Understood''.
2.5.2.4 Insert Type
The Insert Type tells the MT what to do with the short message arriving
from the TE.
The Insert Type information element is coded as shown in figure
2.5.5/GSM 07.05 and table 2.5.5/GSM 07.05
8 7 6 5 4 3 2 1
0 0 0 0 0 0 1 1 octet 1
Insert Type info element identifier
0 0 0 0 0 0 Insert octet 2
Reserved
Type value
Figure 2.5.5/GSM 07.05: Insert Type information element
Table 2.5.5/GSM 07.05: Insert Type information element
Insert Type value (octet 2).
The insert type is coded as follows:
bit 2 bit 1
0 0 Reserved
0 1 Store the short message in the MT
1 0 Send the short message over the air
1 1 Store the short message in the MT and send it over the air
A receiving entity shall ignore the setting of bits 8-3. If bits 2 and
1 are set to 0 then the receiving entity shall return ``Unable to
Process'' with cause ``Command Not Understood''
2.5.2.5 Short Message Index
The Short Message Index provides information about each individual short
message currently stored in the MT. Two types of Short Message index
are provided; one for SMS and one for CBS.
The Short Message Index (SMS) information element is coded as shown in
figure 2.5.6/GSM 07.05 and table 2.5.6/GSM 07.05. A Short Message Index
may be an SMS-SUBMIT, an SMS-DELIVER or an SMS-STATUS-REPORT.
The Short Message Index (CBS) information element is coded as shown in
figure 2.5.7/GSM 07.05 and table 2.5.7/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 0 1 0 0 octet 1
Short Message Index (SMS) info element id
Length of Short Message Index octet 2
Short Message Reference value octet 3
Short Message Status octet 4
Service Centre Address octets
5-n
Short Message Header (SMS) octets
n+1 - n+31
Figure 2.5.6/GSM 07.05: Short Message Index (SMS) information element
n can take a value between 5 and 18 (inclusive)
Table 2.5.6/GSM 07.05: Short Message Index (SMS) information element
Short Message Reference value (octet 3).
The Short Message Reference value is coded as specified in table
2.5.2/GSM 07.05.
Short Message Status (octet 4).
The Short Message Status is coded as follows:
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 Not read/not sent
0 0 0 0 0 0 0 1 Read/Sent
0 0 0 0 0 1 0 0 Not Read
0 0 0 0 0 1 0 1 Read
0 0 0 0 0 1 1 0 Not Sent
0 0 0 0 0 1 1 1 Sent
All other values are reserved.
The receiving entity shall ignore the setting of bits 8-4.
In addition, if bit 3 is set to 0 then a receiving entity shall ignore
the setting of bit 2. Where bit 3 is set to 0, if the message is mobile
originated then bit 1 indicates whether the message has been sent to the
network. If the message is mobile terminated then bit 1 indicates
whether the message has been read.
Service Centre Address (Octets 5-n).
The Service Centre Address is coded as the RP-Origination or
RP-Destination address specified in GSM 04.11. If the short message is
mobile originated, the address will be the RP-Destination address. If
the short message is mobile terminated, the address will be the
RP-Origination address. The address is of variable length, 1-12 octets.
Short Message Header (SMS) (Octets n+1 - n+31).
The Short Message Header (SMS) is coded as a TPDU as described in
GSM 03.40. In the case of SMS-DELIVER or SMS-SUBMIT, the TP-User-Data is
not included, but the TP-User-Data-Length is included. The Short Message
Header is of variable length, 6-31 octets.
8 7 6 5 4 3 2 1
0 0 0 0 0 1 0 1 octet 1
Short Message Index (CBS) info element id
Short Message Reference value octet 2
Short Message Header (CBS) octets
3-8
Figure 2.5.7/GSM 07.05: Short Message Index (CBS) information element
Table 2.5.7/GSM 07.05: Short Message Index (CBS) information element
Short Message Reference value (octet 2).
The Short Message Reference value is coded as specified in table
2.5.2/GSM 07.05.
Short Message Header (CBS) (Octets 3-8).
The Short Message Header (CBS) is coded as described in GSM 03.41,
including SEQUENCE NUMBER, MESSAGE IDENTIFIER, ALPHABET IDENTIFIER and
PAGE PARAMETER, but excluding the characters of the message.
2.5.2.6 Short Message Data
The Short Message Data information element is a copy of a short message
currently stored in the MT. Two types of Short Message Data information
element are provided; one for SMS and one for CBS.
The Short Message Data (SMS) information element is coded as shown in
figure 2.5.8/GSM 07.05 and table 2.5.8/GSM 07.05. Short Message Data may
be an SMS-SUBMIT, an SMS-DELIVER or an SMS-STATUS-REPORT.
The Short Message Data (CBS) information element is coded as shown in
figure 2.5.9/GSM 07.05 and table 2.5.9/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 0 1 1 0 octet 1
Short Message Data (SMS) info element id
Length of Short Message Data octet 2
Short Message Reference value octet 3
Short Message Status octet 4
Service Centre Address octets
5-n
Short Message (SMS) octets
n+1-n+164
Figure 2.5.8/GSM 07.05: Short Message Data (SMS) information element
n can take a value between 5 and 18 (inclusive)
Table 2.5.8/GSM 07.05: Short Message (SMS) information element
Short Message Reference value (octet 3).
The Short Message Reference value is coded as specified in table
2.5.2/GSM 07.05.
Short Message Status (octet 4).
The Short Message Status is coded as follows:
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 Not read/not sent
0 0 0 0 0 0 0 1 Read/Sent
0 0 0 0 0 1 0 0 Not Read
0 0 0 0 0 1 0 1 Read
0 0 0 0 0 1 1 0 Not Sent
0 0 0 0 0 1 1 1 Sent
All other values are reserved.
The receiving entity shall ignore the setting of bits 8-4.
In addition, if bit 3 is set to 0 then a receiving entity shall ignore
the setting of bit 2.
Where bit 3 is set to 0, if the message is mobile originated then bit 1
indicates whether the message has been sent to the network. If the
message is mobile terminated then bit 1 indicates whether the message
has been read.
Service Centre Address (Octets 5-n).
The Service Centre Address is coded as the RP-Origination-Address or
RP-Destination Address specified in GSM 03.40.
If the short message is mobile originated, the address will be the
RP-Destination address. If the short message is mobile terminated, the
address will be the RP-Origination Address. The address is of variable
length, 1-12 octets.
Short Message (SMS) (Octets n+1 - n+164).
The Short Message (SMS) is coded as a TPDU as described in GSM 03.40.
The Short Message is of variable length, 6-164 octets.
8 7 6 5 4 3 2 1
0 0 0 0 0 1 1 1 octet 1
Short Message Data (CBS) info element id
Short Message Reference value octet 2
Short Message (CBS) octets
3-90
Figure 2.5.9/GSM 07.05: Short Message Data (CBS) information element
Table 2.5.9/GSM 07.05: Short Message Data (CBS) information element
Short Message Reference value (octet 2).
The Short Message Reference value is coded as specified in table
2.5.2/GSM 07.05.
Short Message (CBS) (Octets 3-90).
The Short Message (CBS) is coded as described in GSM 03.41, including
SEQUENCE NUMBER, MESSAGE IDENTIFIER, ALPHABET IDENTIFIER, PAGE PARAMETER
and CHARACTERS OF THE MESSAGE.
2.5.2.7 Cause
The Cause information element provides more detail as to why an error
has occurred.
The Cause information element is coded as shown in figure 2.5.10/GSM
07.05 and table 2.5.10/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 1 0 0 0 octet 1
Cause information element identifier
0
octet 2
ext Cause value
04.11 RP-Cause value octet 3
Figure 2.5.10/GSM 07.05: Cause information element
Table 2.5.10/GSM 07.05: Cause information element
Cause value (octet 2).
The cause is coded as follows:
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 No such message
- - no short message exists with the
provided shortmessage reference
0 0 0 0 0 0 0 1 No memory
- - the short message cannot be stored
due to lack of memory
0 0 0 0 0 0 1 0 No air interface
- - submission of the short message
cannot be attempted because the
mobile is out of coverage
0 0 0 0 0 0 1 1 Receiving entity busy
- - the request was not fulfilled because
the Receiving entity is busy on
another task
0 0 0 0 0 1 0 0 Command not understood
- - error in the coding of the command, or
command belongs to higher version of
protocol of protocol than that implemented
0 0 0 0 0 1 0 1 Incoming data call
- - Incoming data call forces MT to exit from
SMS mode
0 0 0 0 0 1 1 0 User-invoked exit
- - User has taken MT out of SMS by MMI
0 0 0 0 0 1 1 1 Other error
- - Any other error not covered here1 0 0 0 0 1 1 1 Message
Transfer failed
- - The SMS transfer to the SC failed and the
04.11 error cause is provided in octet 3
All other values are reserved.
A receiving entity shall treat any reserved codings as ``other error''.
04.11 RP-Cause value (octet 3)
If this element is included then bit 8 of octet 2 is set to '1'. The
error cause included in the RP-Cause over the air interface is directly
mapped into this element. This element is only included if the MT
attempts to send a short message to the network and that send attempt
fails.
2.5.2.8 Index Count
The Index Count identifies the number of short message indices contained
in a MESSAGE LIST response from the MT to the TE. It is an 8 bit
number.
The Index Count information element is coded as shown in figure
2.5.11/GSM 07.05 and
table 2.5.11/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 1 0 0 1 octet 1
Index Count information element ident
Index Count value octet 2
Figure 2.5.11/GSM 07.05: Index Count information element
Table 2.5.11/GSM 07.05: Index Count information element
Index Count value (octet 2).
In the Index Count field bit 8 of octet 2 is the most significant bit
and bit 1 of octet 2 is the least significant bit.
2.5.2.9 CBS Transfer Type
The CBS Transfer Type indicates to the MT which CBS messages are
required to be transferred to the TE.
The CBS Transfer Type information element is coded as shown in figure
2.5.12/GSM 07.05 and
table 2.5.12/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 1 0 1 0 octet 1
CBS Transfer Type info element ident
0 0 0 0 0 0 CBS Txfr octet 2
Reserved Type value
Figure 2.5.12/GSM 07.05: CBS Transfer Type information element
Table 2.5.12/GSM 07.05: CBS Transfer Type information element
CBS Txfr Type value (octet 2).
The CBS txfr type is coded as follows:
bit 2 bit 1
0 0 Transfer no CBS messages
0 1 Transfer CBS messages marked as TE-specific
1 0 Reserved
1 1 Transfer all CBS messages
A receiving entity shall ignore the setting of bits 8-3. If bit 2 is
set to 1 and bit 1 is set to 0 then the receiving entity shall return
``Unable to Process'' with cause ``Command Not Understood''
2.5.2.10 Page Index
The Page Index indicates to the MT which Page of SMS Indices is required
to be transferred. It also indicates to the TE which Page of SMS
Indices is being transferred.
The Page Index information element is coded as shown in figure
2.5.13/GSM 07.05 and
table 2.5.13/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 1 0 1 1 octet 1
Page Index info element ident
0 0 Page Index value octet 2
Reserved
Figure 2.5.13/GSM 07.05: Page Index information element
Table 2.5.13/GSM 07.05: Page Index information element
Page Index value (octet 2).
In the Page Index field bit 6 of octet 2 is the most significant bit and
bit 1 of octet 2 is the least significant bit. The Page Index can have
a value from 1 to 51.
A receiving entity shall ignore the setting of bits 8 and 7. If the
Page Index field has a value of 0 or a value greater than 51 then the
receiving entity shall return ``Unable to Process'' with cause ``Command
Not Understood''
2.5.2.11 Last Short Message
The Last Short Message field indicates to the TE the highest value of
Short Message Reference which points to a valid message stored in the
MT. The value 0 signifies that there are no short messages stored in
the MT.
The Last Short Message information element is coded as shown in figure
2.5.14/GSM 07.05 and table 2.5.14/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 1 1 0 0 octet 1
Last Short Message info element ident
Last Short Message value octet 2
Figure 2.5.14/GSM 07.05: Last Short Message information element
Table 2.5.14/GSM 07.05: Last Short Message information element
Last Short Message value (octet 2).
In the Last Short Message field bit 8 of octet 2 is the most significant
bit and bit 1 of octet 2 is the least significant bit. The Last Short
Message can have a value from 0 to 255.
2.5.2.12 Confirm Type
The Confirm Type field indicates the message to which the REQUEST
CONFIRM is a response.
The Confirm Type information element is coded as shown in figure
2.5.15/GSM 07.05 and table 2.5.15/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 1 1 0 1 octet 1
Confirm Type info element ident
Confirm Type value octet 2
Figure 2.5.15/GSM 07.05: Confirm Type information element
Table 2.5.15/GSM 07.05: Confirm Type information element
Confirm Type value (octet 2).
The Confirm Type is coded as follows:
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 Reserved
0 0 0 0 0 0 0 1 Confirm request to transfer incoming
SMS messages
0 0 0 0 0 0 1 0 Confirm request to transfer incoming
CBS messages
0 0 0 0 0 0 1 1 Confirm request to indicate arrival of
messages in MT
0 0 0 0 0 1 0 0 Confirm request to attempt to send
short message (actual send is confirmed
later: see subclause 3.3)
All other values are reserved. If any reserved value is received then
the receiving entity shall return ``Unable to Process'' with cause value
``Command Not Understood''.
2.5.2.13 TP-Failure Cause
This optional field is present if provided by the Relay Layer. The
TP-Failure Cause is provided from the Service Centre and indicates to
the TE the reason why the delivery of the message was unsuccessful. The
TP-Failure cause information element is coded as shown in figure
2.5.16/GSM 07.05 and
table 2.5.16/GSM 07.05.
8 7 6 5 4 3 2 1
0 0 0 0 1 1 1 0 octet 1
Cause information element identifier
Length of Failure cause field octet 2
Failure cause octets 3-4
Figure 2.5.16/GSM 07.05: TP-Failure Cause information element
Table 2.5.16/GSM 07.05: TP-Failure Cause information element
Failure cause (octet 3-4)
The failure cause contained in this field is directly mapped from the
TP-Failure Cause (TP-FCS) field of the SMS-SUBMIT-REPORT message defined
in GSM 03.40.
2.5.2.14 SM-Deliver-Ack
This optional field is sent from the TE to the MT to convey the
information to be inserted into the SMS-DELIVER-REPORT RP-ACK TPDU sent
by the MT to the SC as defined in GSM 03.40.
8 7 6 5 4 3 2 1
0 0 0 0 1 1 1 1 octet 1
SM-DELIVER-ACK information element identifier
Length of SMS-DELIVER-REPORT RP-ACK Field octet 2
03.40 SMS-DELIVER-REPORT RP-ACK octets 3-166
2.5.2.15 SM-Submit-Ack
This optional field is sent from the MT to the TE to convey the
information to be inserted into the SMS-SUBMIT-REPORT RP-ACK TPDU sent
by the SC to the MT as defined in GSM 03.40.
8 7 6 5 4 3 2 1
0 0 0 1 0 0 0 0 octet 1
SM-SUBMIT-ACK information element identifier
Length of SMS-SUBMIT-REPORT RP-ACK Field octet 2
03.40 SMS-SUBMIT-REPORT RP-ACK octets 3-166
3 Text Mode
3.1 Parameter Definitions
The following parameters are used in the subsequent clauses which
describe all commands. The formats of integer and string types
referenced here are defined in V.25ter. The default values are for
command parameters, not for result code parameters.
Message Storage Parameters
& lt; index & gt; integer type; value in the range of location numbers supported
by the associated memory
& lt; mem1 & gt; string type; memory from which messages are read and deleted
(commands List Messages +CMGL, Read Message +CMGR and Delete Message
+CMGD); defined values (others are manufacturer specific):
" BM " broadcast message storage
" ME " ME message storage
" MT " any of the storages associated with ME
" SM " SIM message storage
" TA " TA message storage
" SR " status report storage
& lt; mem2 & gt; string type; memory to which writing and sending operations are
made (commands Send Message from Storage +CMSS and Write Message to
Memory +CMGW) ); refer & lt; mem1 & gt; for defined values
& lt; mem3 & gt; string type; memory to which received SMs are preferred to be
stored (unless forwarded directly to TE; refer command New Message
Indications +CNMI); refer & lt; mem1 & gt; for defined values; received CBMs are
always stored in " BM " (or some manufacturer specific storage) unless
directly forwarded to TE; received status reports are always stored in
" SR " (or some manufacturer specific storage) unless directly forwarded
to TE
& lt; stat & gt; integer type in PDU mode (default 0), or string type in text mode
(default " REC UNREAD " ); indicates the status of message in memory;
defined values:
0 " REC UNREAD " received unread message (i.e. new message)
1 " REC READ " received read message
2 " STO UNSENT " stored unsent message (only applicable to SMs)
3 " STO SENT " stored sent message (only applicable to SMs)
4 " ALL " all messages (only applicable to +CMGL command)
& lt; total1 & gt; integer type; total number of message locations in & lt; mem1 & gt;
& lt; total2 & gt; integer type; total number of message locations in & lt; mem2 & gt;
& lt; total3 & gt; integer type; total number of message locations in & lt; mem3 & gt;
& lt; used1 & gt; integer type; number of messages currently in & lt; mem1 & gt;
& lt; used2 & gt; integer type; number of messages currently in & lt; mem2 & gt;
& lt; used3 & gt; integer type; number of messages currently in & lt; mem3 & gt;
Message Data Parameters
& lt; ackpdu & gt; GSM 03.40 RP-User-Data element of RP-ACK PDU; format is same as
for & lt; pdu & gt; in case of SMS, but without GSM 04.11 SC address field and
parameter shall be bounded by double quote characters like a normal
string type parameter
& lt; alpha & gt; string type alphanumeric representation of & lt; da & gt; or & lt; oa & gt;
corresponding to the entry found in MT phonebook; implementation of this
feature is manufacturer specific; used character set should be the one
selected with command Select TE Character Set +CSCS (see definition of
this command in TS 07.07)
& lt; cdata & gt; GSM 03.40 TP-Command-Data in text mode responses; ME/TA converts
each 8-bit octet into two IRA character long hexadecimal number (e.g.
octet with integer value 42 is presented to TE as two characters 2A (IRA
50 and 65))
& lt; ct & gt; GSM 03.40 TP-Command-Type in integer format (default 0)
& lt; da & gt; GSM 03.40 TP-Destination-Address Address-Value field in string
format; BCD numbers (or GSM default alphabet characters) are converted
to characters of the currently selected TE character set (refer command
+CSCS in TS 07.07); type of address given by & lt; toda & gt;
& lt; data & gt; In the case of SMS: GSM 03.40 TP-User-Data in text mode
responses; format:
- if & lt; dcs & gt; indicates that GSM 03.38 default alphabet is used and & lt; fo & gt;
indicates that GSM 03.40 TP-User-Data-Header-Indication is not set:
- if TE character set other than " HEX " (refer command Select TE
Character Set +CSCS in TS 07.07): ME/TA converts GSM alphabet into
current TE character set according to rules of Annex A
- if TE character set is " HEX " : ME/TA converts each 7-bit character of
GSM alphabet into two IRA character long hexadecimal number (e.g.
character ( (GSM 23) is presented as 17 (IRA 49 and 55))
- if & lt; dcs & gt; indicates that 8-bit or UCS2 data coding scheme is used, or
& lt; fo & gt; indicates that GSM 03.40 TP-User-Data-Header-Indication is set:
ME/TA converts each 8-bit octet into two IRA character long hexadecimal
number (e.g. octet with integer value 42 is presented to TE as two
characters 2A (IRA 50 and 65))
In the case of CBS: GSM 03.41 CBM Content of Message in text mode
responses; format:
- if & lt; dcs & gt; indicates that GSM 03.38 default alphabet is used:
- if TE character set other than " HEX " (refer command +CSCS in GSM
07.07): ME/TA converts GSM alphabet into current TE character set
according to rules of Annex A
- if TE character set is " HEX " : ME/TA converts each 7-bit character of
GSM alphabet into two IRA character long hexadecimal number
- if & lt; dcs & gt; indicates that 8-bit or UCS2 data coding scheme is used:
ME/TA converts each 8-bit octet into two IRA character long hexadecimal
number
& lt; dcs & gt; depending on the command or result code: GSM 03.38 SMS Data Coding
Scheme (default
0), or Cell Broadcast Data Coding Scheme in integer format
& lt; dt & gt; GSM 03.40 TP-Discharge-Time in time-string format:
``yy/MM/dd,hh:mm:ss(zz'', where characters indicate year (two last
digits), month, day, hour, minutes, seconds and time zone. E.g. 6th of
May 1994, 22:10:00 GMT+2 hours equals to ``94/05/06,22:10:00+08''
& lt; fo & gt; depending on the command or result code: first octet of GSM 03.40
SMS-DELIVER, SMS-SUBMIT (default 17), SMS-STATUS-REPORT, or SMS-COMMAND
(default 2) in integer format
& lt; length & gt; integer type value indicating in the text mode (+CMGF=1) the
length of the message body & lt; data & gt; & gt; (or & lt; cdata & gt; ) in characters; or in
PDU mode (+CMGF=0), the length of the actual TP data unit in octets
(i.e. the RP layer SMSC address octets are not counted in the length)
& lt; mid & gt; GSM 03.41 CBM Message Identifier in integer format
& lt; mn & gt; GSM 03.40 TP-Message-Number in integer format
& lt; mr & gt; GSM 03.40 TP-Message-Reference in integer format
& lt; oa & gt; GSM 03.40 TP-Originating-Address Address-Value field in string
format; BCD numbers (or GSM default alphabet characters) are converted
to characters of the currently selected TE character set (refer command
+CSCS in TS 07.07); type of address given by & lt; tooa & gt;
& lt; page & gt; GSM 03.41 CBM Page Parameter bits 4-7 in integer format
& lt; pages & gt; GSM 03.41 CBM Page Parameter bits 0-3 in integer format
& lt; pdu & gt; In the case of SMS: GSM 04.11 SC address followed by GSM 03.40
TPDU in hexadecimal format: ME/TA converts each octet of TP data unit
into two IRA character long hexadecimal number (e.g. octet with integer
value 42 is presented to TE as two characters 2A (IRA 50 and 65))
In the case of CBS: GSM 03.41 TPDU in hexadecimal format
& lt; pid & gt; GSM 03.40 TP-Protocol-Identifier in integer format (default 0)
& lt; ra & gt; GSM 03.40 TP-Recipient-Address Address-Value field in string
format; BCD numbers (or GSM default alphabet characters) are converted
to characters of the currently selected TE character set (refer command
+CSCS in TS 07.07); type of address given by & lt; tora & gt;
& lt; sca & gt; GSM 04.11 RP SC address Address-Value field in string format; BCD
numbers (or GSM default alphabet characters) are converted to characters
of the currently selected TE character set (refer command +CSCS in TS
07.07); type of address given by & lt; tosca & gt;
& lt; scts & gt; GSM 03.40 TP-Service-Centre-Time-Stamp in time-string format
(refer & lt; dt & gt; )
& lt; sn & gt; GSM 03.41 CBM Serial Number in integer format
& lt; st & gt; GSM 03.40 TP-Status in integer format
& lt; toda & gt; GSM 04.11 TP-Destination-Address Type-of-Address octet in integer
format (when first character of & lt; da & gt; is + (IRA 43) default is 145,
otherwise default is 129)
& lt; tooa & gt; GSM 04.11 TP-Originating-Address Type-of-Address octet in integer
format (default refer & lt; toda & gt; )
& lt; tora & gt; GSM 04.11 TP-Recipient-Address Type-of-Address octet in integer
format (default refer & lt; toda & gt; )
& lt; tosca & gt; GSM 04.11 RP SC address Type-of-Address octet in integer format
(default refer & lt; toda & gt; )
& lt; vp & gt; depending on SMS-SUBMIT & lt; fo & gt; setting: GSM 03.40 TP-Validity-Period
either in integer format (default 167) or in time-string format (refer
& lt; dt & gt; )
& lt; vp & gt; depending on SMS-SUBMIT & lt; fo & gt; setting: GSM 03.40 TP-Validity-Period
either in integer format (default 167), in time-string format (refer
& lt; dt & gt; ), or if $(EVPF)$ is supported, in enhanced format (hexadecimal
coded string with double quotes)
3.2 General Configuration Commands
3.2.1 Select Message Service +CSMS
Parameter Command Syntax
Command Possible response(s)
+CSMS= & lt; service & gt; +CSMS: & lt; mt & gt; , & lt; mo & gt; , & lt; bm & gt;
+CMS ERROR: & lt; err & gt;
+CSMS? +CSMS: & lt; service & gt; , & lt; mt & gt; , & lt; mo & gt; , & lt; bm & gt;
+CSMS=? +CSMS: (list of supported & lt; service & gt; s)
Description
Set command selects messaging service & lt; service & gt; . It returns the types of
messages supported by the ME: & lt; mt & gt; for mobile terminated messages, & lt; mo & gt;
for mobile originated messages and & lt; bm & gt; for broadcast type messages. If
chosen service is not supported by the ME (but is supported by the TA),
final result code +CMS ERROR: & lt; err & gt; shall be returned. See chapter
Message Service Failure Result Code for a list of & lt; err & gt; values.
Also read command returns supported message types along the current
service setting.
Test command returns a list of all services supported by the TA.
Defined Values
& lt; service & gt; :
0 GSM 03.40 and 03.41 (the syntax of SMS AT commands is compatible with
GSM 07.05 Phase 2 version 4.7.0; Phase 2+ features which do not require
new command syntax may be supported (e.g. correct routing of messages
with new Phase 2+ data coding schemes))
1 GSM 03.40 and 03.41 (the syntax of SMS AT commands is compatible with
GSM 07.05 Phase 2+ version; the requirement of & lt; service & gt; setting 1 is
mentioned under corresponding command descriptions)
2...127 reserved
128... manufacturer specific
& lt; mt & gt; , & lt; mo & gt; , & lt; bm & gt; :
0 type not supported
1 type supported
Implementation
Mandatory.
3.2.2 Preferred Message Storage +CPMS
Parameter Command Syntax
Command Possible response(s)
+CPMS= & lt; mem1 & gt; [, & lt; mem2 & gt; [, & lt; mem3 & gt; ]] +CPMS:
& lt; used1 & gt; , & lt; total1 & gt; , & lt; used2 & gt; , & lt; total2 & gt; , & lt; used3 & gt; , & lt; total3 & gt;
+CMS ERROR: & lt; err & gt;
+CPMS? +CPMS: & lt; mem1 & gt; , & lt; used1 & gt; , & lt; total1 & gt; , & lt; mem2 & gt; , & lt; used2 & gt; , & lt; total2 & gt; ,
& lt; mem3 & gt; , & lt; used3 & gt; , & lt; total3 & gt;
+CMS ERROR: & lt; err & gt;
+CPMS=? +CPMS: (list of supported & lt; mem1 & gt; s),(list of supported & lt; mem2 & gt; s),
(list of supported & lt; mem3 & gt; s)
Description
Set command selects memory storages & lt; mem1 & gt; , & lt; mem2 & gt; and & lt; mem3 & gt; to be used
for reading, writing, etc. If chosen storage is not appropriate for the
ME (but is supported by the TA), final result code +CMS ERROR: & lt; err & gt;
shall be returned. See chapter Message Service Failure Result Code for a
list of possible & lt; err & gt; values.
Test command returns lists of memory storages supported by the TA.
Implementation
Mandatory.
3.2.3 Message Format +CMGF
Parameter Command Syntax
Command Possible response(s)
+CMGF=[ & lt; mode & gt; ]
+CMGF? +CMGF: & lt; mode & gt;
+CMGF=? +CMGF: (list of supported & lt; mode & gt; s)
Description
Set command tells the TA, which input and output format of messages to
use. & lt; mode & gt; indicates the format of messages used with send, list, read
and write commands and unsolicited result codes resulting from received
messages. Mode can be either PDU mode (entire TP data units used) or
text mode (headers and body of the messages given as separate
parameters). Text mode uses the value of parameter & lt; chset & gt; specified by
command Select TE Character Set +CSCS to inform the character set to be
used in the message body in the TA-TE interface.
Test command returns supported modes as a compound value.
Defined Values
& lt; mode & gt; :
0 PDU mode (default when implemented)
1 text mode
Implementation
Mandatory also when only one mode implemented.
3.2.4 Enter SMS Block Mode Protocol +CESP
Action Command Syntax
Command Possible response(s)
+CESP
+CESP=?
Description
Execution command sets the TA in SMS block protocol mode. The TA shall
return OK (or 0) to confirm acceptance of the command prior to entering
the block mode (see subclause 2.1.1). The final result code OK (or 0)
shall be returned when the block mode is exited.
NOTE: Commands following +CESP in the AT command line must not be
processed by the TA.
Implementation
Mandatory when block mode implemented.
3.2.5 Message Service Failure Result Code +CMS ERROR
Final result code +CMS ERROR: & lt; err & gt; indicates an error related to mobile
equipment or network. The operation is similar to ERROR result code.
None of the following commands in the same command line is executed.
Neither ERROR nor OK result code shall be returned. ERROR is returned
normally when error is related to syntax or invalid parameters.
Defined Values
& lt; err & gt; values used by common messaging commands:
0...127 GSM 04.11 Annex E-2 values
128...255 GSM 03.40 subclause 9.2.3.22 values
300 ME failure
301 SMS service of ME reserved
302 operation not allowed
303 operation not supported
304 invalid PDU mode parameter
305 invalid text mode parameter
310 SIM not inserted
311 SIM PIN required
312 PH-SIM PIN required
313 SIM failure
314 SIM busy
315 SIM wrong
316 SIM PUK required
317 SIM PIN2 required
318 SIM PUK2 required
320 memory failure
321 invalid memory index
322 memory full
330 SMSC address unknown
331 no network service
332 network timeout
340 no +CNMA acknowledgement expected
500 unknown error
...511 other values in range 256...511 are reserved
512... manufacturer specific
Implementation
Mandatory.
3.2.6 Informative Examples
Setting up a TA supporting GSM SMS:
AT+CSMS=? (inquiry of available services in TA)
+CSMS: (0) (only GSM 07.05 Phase 2 compatible SMS command set
implemented)
OK
AT+CSMS=0;+CPMS=? (set GSM SMS; query available memories)
+CSMS: 1,1,1 (all MT, MO and CBM supported)
+CPMS: ( " BM " , " ME " , " SM " ),( " ME " , " SM " ),( " ME " , " SM " ) (CBM, ME and SIM
memories
OK for reading, ME and SIM memories for writing)
AT+CPMS= " ME " , " ME " , " ME " ;+CMGF=? (set ME memory; query available message
formats)
+CPMS: " ME " ,5,99, " ME " ,5,99, " ME " ,5,99 (five messages in ME, 99 total
space)
+CMGF: (0,1) (both text and PDU mode implemented)
OK
AT+CMGF=1;+CSCS=? (select text mode; query available TE character
sets)
+CSCS: ( " IRA " , " PCCP437 " , " 8859-1 " )
OK
AT+CSCS= " PCCP437 " (select PC code page 437)
OK
3.3 Message Configuration Commands
3.3.1 Service Centre Address +CSCA
Parameter Command Syntax
Command Possible response(s)
+CSCA= & lt; sca & gt; [, & lt; tosca & gt; ]
+CSCA? +CSCA: & lt; sca & gt; , & lt; tosca & gt;
+CSCA=?
Description
Set command updates the SMSC address, through which mobile originated
SMs are transmitted. In text mode, setting is used by send and write
commands. In PDU mode, setting is used by the same commands, but only
when the length of the SMSC address coded into & lt; pdu & gt; parameter equals
zero.
Implementation
Mandatory.
3.3.2 Set Text Mode Parameters +CSMP
Parameter Command Syntax
Command Possible response(s)
+CSMP=[ & lt; fo & gt; [, & lt; vp & gt; [, & lt; pid & gt; [, & lt; dcs & gt; ]]]]
+CSMP? +CSMP: & lt; fo & gt; , & lt; vp & gt; , & lt; pid & gt; , & lt; dcs & gt;
+CSMP=?
Description
Set command is used to select values for additional parameters needed
when SM is sent to the network or placed in a storage when text format
message mode is selected. It is possible to set the validity period
starting from when the SM is received by the SMSC ( & lt; vp & gt; is in range 0...
255) or define the absolute time of the validity period termination
( & lt; vp & gt; is a string). The format of & lt; vp & gt; is given by & lt; fo & gt; . If TA supports
the enhanced validity period format ($(EVPF)$, see GSM 03.40), it shall
be given as a hexadecimal coded string (refer e.g. & lt; pdu & gt; ) with double
quotes.
NOTE: When storing a SMS-DELIVER from the TE to the preferred memory
storage in text mode (refer command Write Message to Memory +CMGW), & lt; vp & gt;
field can be used for & lt; scts & gt; .
Implementation
Mandatory when text mode implemented.
3.3.3 Show Text Mode Parameters +CSDH
Parameter Command Syntax
Command Possible response(s)
+CSDH=[ & lt; show & gt; ]
+CSDH? +CSDH: & lt; show & gt;
+CSDH=? +CSDH: (list of supported & lt; show & gt; s)
Description
Set command controls whether detailed header information is shown in
text mode result codes.
Test command returns supported values as a compound value.
Defined Values
& lt; show & gt; :
0 do not show header values defined in commands +CSCA and +CSMP ( & lt; sca & gt; ,
& lt; tosca & gt; , & lt; fo & gt; , & lt; vp & gt; , & lt; pid & gt; and & lt; dcs & gt; ) nor & lt; length & gt; , & lt; toda & gt; or & lt; tooa & gt; in
+CMT, +CMGL, +CMGR result codes for SMS-DELIVERs and SMS-SUBMITs in text
mode; for SMS-COMMANDs in +CMGR result code, do not show & lt; pid & gt; , & lt; mn & gt; ,
& lt; da & gt; , & lt; toda & gt; , & lt; length & gt; or & lt; cdata & gt;
1 show the values in result codes
Implementation
Mandatory when text mode implemented.
3.3.4 Select Cell Broadcast Message Types +CSCB
Parameter Command Syntax
Command Possible response(s)
+CSCB=[ & lt; mode & gt; [, & lt; mids & gt; [, & lt; dcss & gt; ]]]
+CSCB? +CSCB: & lt; mode & gt; , & lt; mids & gt; , & lt; dcss & gt;
+CSCB=? +CSCB: (list of supported & lt; mode & gt; s)
Description
Set command selects which types of CBMs are to be received by the ME.
Test command returns supported modes as a compound value.
Defined Values
& lt; mode & gt; :
0 message types specified in & lt; mids & gt; and & lt; dcss & gt; are accepted
1 message types specified in & lt; mids & gt; and & lt; dcss & gt; are not accepted
& lt; mids & gt; : string type; all different possible combinations of CBM message
identifiers (refer & lt; mid & gt; ) (default is empty string); e.g.
" 0,1,5,320-478,922 "
& lt; dcss & gt; : string type; all different possible combinations of CBM data
coding schemes (refer & lt; dcs & gt; ) (default is empty string); e.g. " 0-3,5 "
Implementation
Optional.
3.3.5 Save Settings +CSAS
Action Command Syntax
Command Possible response(s)
+CSAS[= & lt; profile & gt; ] +CMS ERROR: & lt; err & gt;
+CSAS=? +CSAS: (list of supported & lt; profile & gt; s)
Description
Execution command saves active message service settings to a
non-volatile memory. A TA can contain several profiles of settings.
Settings specified in commands Service Centre Address +CSCA, Set Message
Parameters +CSMP and Select Cell Broadcast Message Types +CSCB (if
implemented) are saved. Certain settings may not be supported by the
storage (e.g. SIM SMS parameters) and therefore can not be saved. See
chapter Message Service Failure Result Code for & lt; err & gt; values.
Test command shall display the supported profile numbers for reading and
writing of settings.
Defined Values
& lt; profile & gt; :
0...255 manufacturer specific profile number where settings are to be
stored
Implementation
Optional.
3.3.6 Restore Settings +CRES
Action Command Syntax
Command Possible response(s)
+CRES[= & lt; profile & gt; ] +CMS ERROR: & lt; err & gt;
+CRES=? +CRES: (list of supported & lt; profile & gt; s)
Description
Execution command restores message service settings from non-volatile
memory to active memory. A TA can contain several profiles of settings.
Settings specified in commands Service Centre Address +CSCA, Set Message
Parameters +CSMP and Select Cell Broadcast Message Types +CSCB (if
implemented) are restored. Certain settings may not be supported by the
storage (e.g. SIM SMS parameters) and therefore can not be restored. See
chapter Message Service Failure Result Code for & lt; err & gt; values.
Defined Values
& lt; profile & gt; :
0...255 manufacturer specific profile number from where settings are to
be restored
Implementation
Optional.
3.3.7 Informative Examples
Figure seq Figure smspar 1 illustrates an example setup of a TE-TA-ME
system for GSM SMS. Location of volatile and non-volatile parameter
memories, and the operations to change the parameter values are shown.
+CSMP is used to set the text mode header values of SMS-SUBMIT (or
SMS-DELIVER when received message is written from TE to a storage). The
volatile memory may as well be in the ME, or when no volatile memory is
used, +CSMP, +CSCA and +CSCB settings are stored directly to
non-volatile memory of ME.
Figure seq Figure 1 : Message service parameter procedures
In this example, the volatile parameter settings of TA are used to
construct messages in text mode. SMSC address setting is used also in
PDU mode. The next example illustrates a session to restore the message
parameters from the ME to the TA, and to set up the CBM identifiers (and
languages) which are wanted to be received:
AT+CRES (restore settings from non-volatile memory to volatile
memory)
OK
AT+CSMP?;+CSCA? (query SM parameters)
+CSMP: 17,167,0,0 (default values for SMS-SUBMIT)
+CSCA: " +358501234567 " ,145 (SMSC address)
OK
AT+CSDH=1 (show all headers in text mode)
OK
AT+CSCB=1 (all CBMs are accepted)
OK
3.4 Message Receiving and Reading Commands
3.4.1 New Message Indications to TE +CNMI
Parameter Command Syntax
Command Possible response(s)
+CNMI=[ & lt; mode & gt; [, & lt; mt & gt; [, & lt; bm & gt; [, & lt; ds & gt; [,
& lt; bfr & gt; ]]]]] +CMS ERROR: & lt; err & gt;
+CNMI? +CNMI: & lt; mode & gt; , & lt; mt & gt; , & lt; bm & gt; , & lt; ds & gt; , & lt; bfr & gt;
+CNMI=? +CNMI: (list of supported & lt; mode & gt; s),(list of supported
& lt; mt & gt; s),(list of supported & lt; bm & gt; s),(list of supported & lt; ds & gt; s),(list of
supported & lt; bfr & gt; s)
Description
Set command selects the procedure, how receiving of new messages from
the network is indicated to the TE when TE is active, e.g. DTR signal is
ON. If TE is inactive (e.g. DTR signal is OFF), message receiving should
be done as specified in GSM 03.38.
NOTE: When DTR signal is not available or the state of the signal is
ignored (V.25ter command & D0), reliable message transfer can be assured
by using +CNMA acknowledgement procedure.
& lt; mode & gt; controls the processing of unsolicited result codes specified
within this command, & lt; mt & gt; sets the result code indication routing for
SMS-DELIVERs, & lt; bm & gt; for CBMs and & lt; ds & gt; for SMS-STATUS-REPORTs. & lt; bfr & gt;
defines the handling method for buffered result codes when & lt; mode & gt; 1, 2
or 3 is enabled. If ME does not support requested item (although TA
does), final result code +CMS ERROR: & lt; err & gt; is returned. See chapter
Message Service Failure Result Code for a list of & lt; err & gt; values.
Test command gives the settings supported by the TA as compound values.
NOTE: Command Select Message Service +CSMS should be used to detect ME
support of mobile terminated SMs and CBMs, and to define whether a
message routed directly to TE should be acknowledged or not (refer
command +CNMA).
Defined Values
& lt; mode & gt; (refer figure seq Figure unsobu 2 ;
NOTE: The buffering mechanism may as well be located in the ME; the
setting affects only to unsolicited result codes specified within this
command):
0 Buffer unsolicited result codes in the TA. If TA result code buffer is
full, indications can be buffered in some other place or the oldest
indications may be discarded and replaced with the new received
indications.
1 Discard indication and reject new received message unsolicited result
codes when TA-TE link is reserved (e.g. in on-line data mode). Otherwise
forward them directly to the TE.
2 Buffer unsolicited result codes in the TA when TA-TE link is reserved
(e.g. in on-line data mode) and flush them to the TE after reservation.
Otherwise forward them directly to the TE.
3 Forward unsolicited result codes directly to the TE. TA-TE link
specific inband technique used to embed result codes and data when TA is
in on-line data mode.
NOTE: It is possible that ME/TA result code buffer is in volatile
memory. In this case messages may get lost if the power of ME/TA is
switched off before codes are sent to TE. Thus, it is not recommended to
use direct message routing ( & lt; mt & gt; =2 or 3, & lt; bm & gt; =2 or 3, or & lt; ds & gt; =1) with
& lt; mode & gt; value 0 or 2.
Figure seq Figure 2 : & lt; mode & gt; parameter
& lt; mt & gt; (the rules for storing received SMs depend on its data coding
scheme (refer GSM 03.38 [2]), preferred memory storage (+CPMS) setting
and this value; refer table seq Table mtparameter 1 ;
NOTE: If AT command interface is acting as the only display device, the
ME must support storing of class 0 messages and messages in the message
waiting indication group (discard message); refer table seq Table
smsdeliversummary 2 ):
0 No SMS-DELIVER indications are routed to the TE.
1 If SMS-DELIVER is stored into ME/TA, indication of the memory location
is routed to the TE using unsolicited result code:
+CMTI: & lt; mem & gt; , & lt; index & gt;
2 SMS-DELIVERs (except class 2 messages and messages in the message
waiting indication group (store message)) are routed directly to the TE
using unsolicited result code:
+CMT: [ & lt; alpha & gt; ], & lt; length & gt; & lt; CR & gt; & lt; LF & gt; & lt; pdu & gt; (PDU mode enabled)
or
+CMT: & lt; oa & gt; , [ & lt; alpha & gt; ], & lt; scts & gt; [, & lt; tooa & gt; , & lt; fo & gt; , & lt; pid & gt; , & lt; dcs & gt; , & lt; sca & gt; , & lt; tosca & gt; ,
& lt; length & gt; ] & lt; CR & gt; & lt; LF & gt; & lt; data & gt; (text mode enabled; about parameters in italics,
refer command Show Text Mode Parameters +CSDH)
If ME has its own display device then class 0 messages and messages in
the message waiting indication group (discard message) may be copied to
both ME display and to TE. In this case, ME shall send the
acknowledgement to the network (refer table seq Table
smsdeliversummary 2 ).
Class 2 messages and messages in the message waiting indication group
(store message) result in indication as defined in & lt; mt & gt; =1.
3 Class 3 SMS-DELIVERs are routed directly to TE using unsolicited
result codes defined in & lt; mt & gt; =2. Messages of other data coding schemes
result in indication as defined in & lt; mt & gt; =1.
Table seq Table 1 : & lt; mt & gt; parameter
& lt; mt & gt; Receiving procedure for different message data coding schemes
(refer GSM 03.38 [2])
0 no class: as in GSM 03.38, but use & lt; mem3 & gt; as preferred memory
class 0: as in GSM 03.38, but use & lt; mem3 & gt; as preferred memory if message
is tried to be stored
class 1: as in GSM 03.38, but use & lt; mem3 & gt; as preferred memory
class 2: as in GSM 03.38
class 3: as in GSM 03.38, but use & lt; mem3 & gt; as preferred memory
message waiting indication group (discard message): as in GSM 03.38, but
use & lt; mem3 & gt; as preferred memory if message is tried to be stored
message waiting indication group (store message): as in GSM 03.38, but
use & lt; mem3 & gt; as preferred memory
1 as & lt; mt & gt; =0 but send indication if message stored successfully
2 no class: route message to TE
class 0: as in GSM 03.38, but also route message to TE and do not try to
store it in memory
class 1: route message to TE
class 2: as & lt; mt & gt; =1
class 3: route message to TE
message waiting indication group (discard message): as in GSM 03.38, but
also route message to TE and do not try to store it in memory
message waiting indication group (store message): as & lt; mt & gt; =1
3 class 3: route message to TE
others: as & lt; mt & gt; =1
Table seq Table 2 : SMS-DELIVER result code and acknowledgement
summary
& lt; mt & gt; no class or class 1 class 0 or message waiting indication group
(discard) class 2 or message waiting indication group (store) class 3
1 +CMTI [+CMTI1)] +CMTI +CMTI
2 +CMT & +CNMA3) +CMT [ & +CNMA2)] +CMTI +CMT & +CNMA3)
3 +CMTI [+CMTI1)] +CMTI +CMT & +CNMA3)
1) result code is sent when ME does not have other display device than
AT interface
2) acknowledgement command must be sent when +CSMS & lt; service & gt; value
equals 1 and ME does not have other display device than AT interface
3) acknowledgement command must be sent when +CSMS & lt; service & gt; value
equals 1
& lt; bm & gt; (the rules for storing received CBMs depend on its data coding
scheme (refer GSM 03.38 [2]), the setting of Select CBM Types (+CSCB)
and this value; refer table seq Table bmparameter 3 ):
0 No CBM indications are routed to the TE.
1 If CBM is stored into ME/TA, indication of the memory location is
routed to the TE using unsolicited result code:
+CBMI: & lt; mem & gt; , & lt; index & gt;
2 New CBMs are routed directly to the TE using unsolicited result code:
+CBM: & lt; length & gt; & lt; CR & gt; & lt; LF & gt; & lt; pdu & gt; (PDU mode enabled)
or
+CBM: & lt; sn & gt; , & lt; mid & gt; , & lt; dcs & gt; , & lt; page & gt; , & lt; pages & gt; & lt; CR & gt; & lt; LF & gt; & lt; data & gt; (text mode enabled)
If ME supports data coding groups which define special routing also for
messages other than class 3 (e.g. SIM specific messages), ME may choose
not to route messages of such data coding schemes into TE (indication of
a stored CBM may be given as defined in & lt; bm & gt; =1).
3 Class 3 CBMs are routed directly to TE using unsolicited result codes
defined in & lt; bm & gt; =2. If CBM storage is supported, messages of other
classes result in indication as defined in & lt; bm & gt; =1.
Table seq Table 3 : & lt; bm & gt; parameter
& lt; bm & gt; Receiving procedure for different message data coding schemes
(refer GSM 03.38 [2])
0 all schemes: as in GSM 03.38; if CBM storage is supported, store
message to " BM " (or some manufacturer or data coding scheme specific
memory)
1 all schemes: as & lt; bm & gt; =0 but send indication if message stored
successfully
2 all schemes: route message to TE unless ME has detected a special
routing to somewhere else (e.g. to SIM; an indication may be sent if
message stored successfully)
3 class 3: route message to TE
others: as & lt; bm & gt; =1 (if CBM memory storage is supported)
& lt; ds & gt; :
0 No SMS-STATUS-REPORTs are routed to the TE.
1 SMS-STATUS-REPORTs are routed to the TE using unsolicited result code:
+CDS: & lt; length & gt; & lt; CR & gt; & lt; LF & gt; & lt; pdu & gt; (PDU mode enabled)
or
+CDS: & lt; fo & gt; , & lt; mr & gt; ,[ & lt; ra & gt; ],[ & lt; tora & gt; ], & lt; scts & gt; , & lt; dt & gt; , & lt; st & gt; (text mode enabled)
2 If SMS-STATUS-REPORT is stored into ME/TA, indication of the memory
location is routed to the TE using unsolicited result code:
+CDSI: & lt; mem & gt; , & lt; index & gt;
Table seq Table 4 : SMS-STATUS-REPORT result code and acknowledgement
summary
& lt; ds & gt; result codes and commands
1 +CDS & +CNMA1)
2 +CDSI
1) acknowledgement command must be sent when +CSMS & lt; service & gt; value
equals 1
& lt; bfr & gt; :
0 TA buffer of unsolicited result codes defined within this command is
flushed to the TE when & lt; mode & gt; 1...3 is entered (OK response shall be
given before flushing the codes).
1 TA buffer of unsolicited result codes defined within this command is
cleared when & lt; mode & gt; 1...3 is entered.
Implementation
Mandatory when any of the new message indications implemented.
3.4.2 List Messages +CMGL
Action Command Syntax
Command Possible response(s)
+CMGL[= & lt; stat & gt; ] if text mode (+CMGF=1), command successful and
SMS-SUBMITs and/or SMS-DELIVERs:
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; oa/da & gt; ,[ & lt; alpha & gt; ],[ & lt; scts & gt; ][, & lt; tooa/toda & gt; ,
& lt; length & gt; ] & lt; CR & gt; & lt; LF & gt; & lt; data & gt; [ & lt; CR & gt; & lt; LF & gt;
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; da/oa & gt; ,[ & lt; alpha & gt; ],[ & lt; scts & gt; ][, & lt; tooa/toda & gt; ,
& lt; length & gt; ] & lt; CR & gt; & lt; LF & gt; & lt; data & gt; [...]]
if text mode (+CMGF=1), command successful and SMS-STATUS-REPORTs:
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; fo & gt; , & lt; mr & gt; ,[ & lt; ra & gt; ],[ & lt; tora & gt; ], & lt; scts & gt; , & lt; dt & gt; , & lt; st & gt;
[ & lt; CR & gt; & lt; LF & gt;
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; fo & gt; , & lt; mr & gt; ,[ & lt; ra & gt; ],[ & lt; tora & gt; ], & lt; scts & gt; , & lt; dt & gt; , & lt; st & gt;
[...]]
if text mode (+CMGF=1), command successful and SMS-COMMANDs:
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; fo & gt; , & lt; ct & gt; [ & lt; CR & gt; & lt; LF & gt;
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; fo & gt; , & lt; ct & gt; [...]]
if text mode (+CMGF=1), command successful and CBM storage:
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; sn & gt; , & lt; mid & gt; , & lt; page & gt; , & lt; pages & gt;
& lt; CR & gt; & lt; LF & gt; & lt; data & gt; [ & lt; CR & gt; & lt; LF & gt;
+CMGL: & lt; index & gt; , & lt; stat & gt; , & lt; sn & gt; , & lt; mid & gt; , & lt; page & gt; , & lt; pages & gt;
& lt; CR & gt; & lt; LF & gt; & lt; data & gt; [...]]
otherwise:
+CMS ERROR: & lt; err & gt;
+CMGL=? +CMGL: (list of supported & lt; stat & gt; s)
Description
Execution command returns messages with status value & lt; stat & gt; from message
storage & lt; mem1 & gt; to the TE. About text mode parameters in italics, refer
command Show Text Mode Parameters +CSDH. If status of the message is
'received unread', status in the storage changes to 'received read'. If
listing fails, final result code +CMS ERROR: & lt; err & gt; is returned. See
chapter Message Service Failure Result Code for & lt; err & gt; values.
NOTE: If the selected & lt; mem1 & gt; can contain different types of SMs (e.g.
SMS-DELIVERs, SMS-SUBMITs, SMS-STATUS-REPORTs and SMS-COMMANDs), the
response may be a mix of the responses of different SM types. TE
application can recognize the response format by examining the third
response parameter.
Test command shall give a list of all status values supported by the TA.
Implementation
Optional.
3.4.3 Read Message +CMGR
Action Command Syntax
Command Possible response(s)
+CMGR= & lt; index & gt; if text mode (+CMGF=1), command successful and
SMS-DELIVER:
+CMGR: & lt; stat & gt; , & lt; oa & gt; ,[ & lt; alpha & gt; ], & lt; scts & gt; [, & lt; tooa & gt; , & lt; fo & gt; , & lt; pid & gt; , & lt; dcs & gt; ,
& lt; sca & gt; , & lt; tosca & gt; , & lt; length & gt; ] & lt; CR & gt; & lt; LF & gt; & lt; data & gt;
if text mode (+CMGF=1), command successful and SMS-SUBMIT:
+CMGR: & lt; stat & gt; , & lt; da & gt; ,[ & lt; alpha & gt; ][, & lt; toda & gt; , & lt; fo & gt; , & lt; pid & gt; , & lt; dcs & gt; ,[ & lt; vp & gt; ],
& lt; sca & gt; , & lt; tosca & gt; , & lt; length & gt; ] & lt; CR & gt; & lt; LF & gt; & lt; data & gt;
if text mode (+CMGF=1), command successful and SMS-STATUS-REPORT:
+CMGR: & lt; stat & gt; , & lt; fo & gt; , & lt; mr & gt; ,[ & lt; ra & gt; ],[ & lt; tora & gt; ], & lt; scts & gt; , & lt; dt & gt; , & lt; st & gt;
if text mode (+CMGF=1), command successful and SMS-COMMAND:
+CMGR: & lt; stat & gt; , & lt; fo & gt; , & lt; ct & gt; [, & lt; pid & gt; ,[ & lt; mn & gt; ],[ & lt; da & gt; ],[ & lt; toda & gt; ], & lt; length & gt;
& lt; CR & gt; & lt; LF & gt; & lt; cdata & gt; ]
if text mode (+CMGF=1), command successful and CBM storage:
+CMGR: & lt; stat & gt; , & lt; sn & gt; , & lt; mid & gt; , & lt; dcs & gt; , & lt; page & gt; , & lt; pages & gt; & lt; CR & gt; & lt; LF & gt; & lt; data & gt;
otherwise:
+CMS ERROR: & lt; err & gt;
+CMGR=?
Description
Execution command returns message with location value & lt; index & gt; from
message storage & lt; mem1 & gt; to the TE. About text mode parameters in italics,
refer command Show Text Mode Parameters +CSDH. If status of the message
is 'received unread', status in the storage changes to 'received read'.
If reading fails, final result code +CMS ERROR: & lt; err & gt; is returned. See
chapter Message Service Failure Result Code for & lt; err & gt; values.
Implementation
Optional.
3.4.4 New Message Acknowledgement to ME/TA +CNMA
Action Command Syntax
Command Possible response(s)
if text mode (+CMGF=1):
+CNMA +CMS ERROR: & lt; err & gt;
+CNMA=?
Description
Execution command confirms correct reception of a new message
(SMS-DELIVER or SMS-STATUS-REPORT) which is routed directly to the TE
(refer command +CNMI tables seq Table smsdeliversummary 2 and seq
Table smssrsummary 4 ). This acknowledgement command (causing ME to
send RP-ACK to the network) shall be used when +CSMS parameter & lt; service & gt;
equals 1. TA shall not send another +CMT or +CDS result code to TE
before previous one is acknowledged.
If ME does not get acknowledgement within required time (network
timeout), ME should send RP-ERROR to the network. ME/TA shall
automatically disable routing to TE by setting both & lt; mt & gt; and & lt; ds & gt; values
of +CNMI to zero.
If command is executed, but no acknowledgement is expected, or some
other ME related error occurs, final result code +CMS ERROR: & lt; err & gt; is
returned. See chapter Message Service Failure Result Code for a list of
& lt; err & gt; values.
NOTE: In case that a directly routed message must be buffered in ME/TA
(possible when +CNMI parameter & lt; mode & gt; equals 0 or 2) or AT interpreter
remains too long in a state where result codes cannot be sent to TE
(e.g. user is entering a message using +CMGS), acknowledgement (RP-ACK)
must be sent to the network without waiting +CNMA command from TE.
Later, when buffered result codes are flushed to TE, TE must send +CNMA
acknowledgement for each result code. In this way, ME/TA can determine
if message should be placed in non-volatile memory and routing to TE
disabled (+CNMA not received). Refer command +CNMI for more details how
to use & lt; mode & gt; parameter reliably.
Implementation
Mandatory when & lt; service & gt; value 1 of command Select Message Service +CSMS
is supported.
3.4.5 Informative Examples
Message forwarding is done as illustrated in figure seq Figure smsrlr
3 . Optional +CNMA acknowledgement procedure is not presented. In this
example, there is no TA memory for messages and result code buffer is
situated in TA. The routing of message waiting indication group (discard
message) SMS-DELIVERs equal to class 0 messages, and the routing of
message waiting indication group (store message) SMS-DELIVERs equal to
class 2 messages.
Figure seq Figure 3 : Message receiving procedures
Setting new message indications:
AT+CNMI=? (query new message unsolicited result code modes)
+CNMI: (0-2),(0-3),(0-3),(0,1),(0,1)
OK
AT+CNMI=2,1,0,1,0 (send SM and status report indications to TE
OK when TA in command mode, otherwise buffer)
In this example, the TA is set so that it should send an unsolicited
result code +CMTI: & lt; mem & gt; , & lt; index & gt; to the TE when a new SMS-DELIVER is
received from the network and stored successfully to storage & lt; mem & gt; , and
an unsolicited result code +CDS:... when a SMS-STATUS-REPORT is
received. These result codes are routed to the TE when TA is in command
mode, but buffered when in on-line data mode. Now, if new SM is
received, it can be read as follows (text mode with no detailed header
information; GSM default alphabet used in message body):
+CMTI: " ME " ,2 (new message received in index 2)
AT+CMGR=2 (read the message)
+CMGR: " REC UNREAD " , " +358507654321 " , " Mr. Jones " , " 95/07/03,17:38:15+04 "
This is the Mr. Jones testing
OK
In the next example all messages of storage & lt; mem1 & gt; are listed (text mode
with no detailed header information; GSM default alphabet used in
message bodies):
AT+CMGL= " ALL " (read all SMs)
+CMGL: 1, " REC READ " , " +358501234567 " , " Mr. Smith " , " 95/07/03,17:45:03+04 "
This is the body of the message.
+CMGL: 2, " STO UNSENT " , " +358501234567 " , " Mr. Smith " ,
This is the body of the reply.
OK
The next example shows a method to read new CBMs received from the
network (text mode; GSM default alphabet used in message bodies):
AT+CNMI=2,,2,,0 (CBMs will be sent to the TE)
OK
AT+CPMS= " BM " ;+CMGL (select CBM memory for reading; list all unread CBMs)
+CMGL: 1, " REC UNREAD " ,100,40,1,3 (first page of three page weather
information)
Weather in Finland 3rd of July 1995
+CMGL: 2, " REC UNREAD " ,100,40,2,3 (second page of three page weather
information)
Helsinki: cloudy, snow storms, -20 degrees Celsius, wind -14 m/s NE
+CMGL: 3, " REC UNREAD " ,100,40,3,3 (third page of three page weather
information)
Tampere: sunny, 40 degrees Celsius, wind 1 m/s SW
OK
3.5 Message Sending and Writing Commands
3.5.1 Send Message +CMGS
Action Command Syntax
Command Possible response(s)
if text mode (+CMGF=1):
+CMGS= & lt; da & gt; [, & lt; toda & gt; ] & lt; CR & gt;
text is entered & lt; ctrl-Z/ESC & gt; if text mode (+CMGF=1) and sending
successful:
+CMGS: & lt; mr & gt; [, & lt; scts & gt; ]
if sending fails:
+CMS ERROR: & lt; err & gt;
+CMGS=?
Description
Execution command sends message from a TE to the network (SMS-SUBMIT).
Message reference value & lt; mr & gt; is returned to the TE on successful message
delivery. Optionally (when +CSMS & lt; service & gt; value is 1 and network
supports) & lt; scts & gt; is returned. Values can be used to identify message
upon unsolicited delivery status report result code. If sending fails in
a network or an ME error, final result code +CMS ERROR: & lt; err & gt; is
returned. See chapter Message Service Failure Result Code for a list of
& lt; err & gt; values. This command should be abortable.
Description
Execution command sends message from a TE to the network (SMS-SUBMIT).
Message reference value & lt; mr & gt; is returned to the TE on successful message
delivery. Value can be used to identify message upon unsolicited
delivery status report result code. If sending fails in a network or an
ME error, final result code +CMS ERROR: & lt; err & gt; is returned. See chapter
Message Service Failure Result Code for a list of & lt; err & gt; values. This
command should be abortable.
- entered text (GSM 03.40 TP-Data-Unit) is sent to address & lt; da & gt; and all
current settings (refer Set Text Mode Parameters +CSMP and Service
Centre Address +CSCA) are used to construct the actual PDU in ME/TA
- the TA shall send a four character sequence
& lt; CR & gt; & lt; LF & gt; & lt; greater_than & gt; & lt; space & gt; (IRA 13, 10, 62, 32) after command line is
terminated with & lt; CR & gt; ; after that text can be entered from TE to ME/TA
- the DCD signal shall be in ON state while text is entered
- the echoing of entered characters back from the TA is controlled by
V.25ter echo command E
- the entered text should be formatted as follows:
- if & lt; dcs & gt; (set with +CSMP) indicates that GSM 03.38 default alphabet is
used and & lt; fo & gt; indicates that GSM 03.40 TP-User-Data-Header-Indication is
not set:
- if TE character set other than " HEX " (refer command Select TE
Character Set +CSCS in TS 07.07): ME/TA converts the entered text into
GSM alphabet according to rules of Annex A; backspace can be used to
delete last character and carriage returns can be used (previously
mentioned four character sequence shall be sent to the TE after every
carriage return entered by the user)
- if TE character set is " HEX " : the entered text should consist of two
IRA character long hexadecimal numbers which ME/TA converts to 7-bit
characters of GSM alphabet (e.g. 17 (IRA 49 and 55) will be converted to
character ( (GSM 23))
- if & lt; dcs & gt; indicates that 8-bit or UCS2 data coding scheme is used or
& lt; fo & gt; indicates that GSM 03.40 TP-User-Data-Header-Indication is set: the
entered text should consist of two IRA character long hexadecimal
numbers which ME/TA converts into 8-bit octet (e.g. two characters 2A
(IRA 50 and 65) will be converted to an octet with integer value 42)
- sending can be cancelled by giving & lt; ESC & gt; character (IRA 27)
- & lt; ctrl-Z & gt; (IRA 26) must be used to indicate the ending of the message
body
Implementation
Optional.
3.5.2 Send Message from Storage +CMSS
Action Command Syntax
Command Possible response(s)
+CMSS= & lt; index & gt; [, & lt; da & gt; [, & lt; toda & gt; ]] if text mode (+CMGF=1) and sending
successful:
+CMSS: & lt; mr & gt; [, & lt; scts & gt; ]
if sending fails:
+CMS ERROR: & lt; err & gt;
+CMSS=?
Description
Execution command sends message with location value & lt; index & gt; from
preferred message storage & lt; mem2 & gt; to the network (SMS-SUBMIT or
SMS-COMMAND). If new recipient address & lt; da & gt; is given given for
SMS-SUBMIT, it shall be used instead of the one stored with the message.
Reference value & lt; mr & gt; is returned to the TE on successful message
delivery. Optionally (when +CSMS & lt; service & gt; value is 1 and network
supports) & lt; scts & gt; is returned. Values can be used to identify message
upon unsolicited delivery status report result code. If sending fails in
a network or an ME error, final result code +CMS ERROR: & lt; err & gt; is
returned. See chapter Message Service Failure Result Code for a list of
& lt; err & gt; values. This command should be abortable.
Implementation
Optional.
3.5.3 Write Message to Memory +CMGW
Action Command Syntax
Command Possible response(s)
if text mode (+CMGF=1):
+CMGW[= & lt; oa/da & gt; [, & lt; tooa/toda & gt; [, & lt; stat & gt; ]]] & lt; CR & gt;
text is entered & lt; ctrl-Z/ESC & gt; +CMGW: & lt; index & gt;
+CMS ERROR: & lt; err & gt;
+CMGW=?
Description
Execution command stores message (either SMS-DELIVER or SMS-SUBMIT) to
memory storage & lt; mem2 & gt; . Memory location & lt; index & gt; of the stored message is
returned. By default message status will be set to 'stored unsent', but
parameter & lt; stat & gt; allows also other status values to be given. The
entering of text is done similarly as specified in command Send Message
+CMGS. If writing fails, final result code +CMS ERROR: & lt; err & gt; is
returned. See chapter Message Service Failure Result Code for & lt; err & gt;
values.
NOTE: SMS-COMMANDs and SMS-STATUS-REPORTs can not be stored in text
mode.
Implementation
Optional.
3.5.4 Delete Message +CMGD
Action Command Syntax
Command Possible response(s)
+CMGD= & lt; index & gt; +CMS ERROR: & lt; err & gt;
+CMGD=?
Description
Execution command deletes message from preferred message storage & lt; mem1 & gt;
location & lt; index & gt; . If deleting fails, final result code +CMS ERROR: & lt; err & gt;
is returned. See chapter Message Service Failure Result Code for & lt; err & gt;
values.
Implementation
Optional.
3.5.5 Send Command +CMGC
Action Command Syntax
Command Possible response(s)
if text mode (+CMGF=1):
+CMGC= & lt; fo & gt; , & lt; ct & gt; [, & lt; pid & gt; [, & lt; mn & gt; [, & lt; da & gt; [, & lt; toda & gt; ]]]] & lt; CR & gt;
text is entered & lt; ctrl-Z/ESC & gt; if text mode (+CMGF=1) and sending
successful:
+CMGC: & lt; mr & gt; [, & lt; scts & gt; ]
if sending fails:
+CMS ERROR: & lt; err & gt;
+CMGC=?
Description
Execution command sends a command message from a TE to the network
(SMS-COMMAND). The entering of text (GSM 03.40 TP-Command-Data) is done
similarly as specified in command Send Message +CMGS, but the format is
fixed to be a sequence of two IRA character long hexadecimal numbers
which ME/TA converts into 8-bit octets (refer +CMGS). Message reference
value & lt; mr & gt; is returned to the TE on successful message delivery.
Optionally (when +CSMS & lt; service & gt; value is 1 and network supports) & lt; scts & gt;
is returned. Values can be used to identify message upon unsolicited
delivery status report result code. If sending fails in a network or an
ME error, final result code +CMS ERROR: & lt; err & gt; is returned. See chapter
Message Service Failure Result Code for a list of & lt; err & gt; values. This
command should be abortable.
Implementation
Optional.
3.5.6 More Messages to Send +CMMS $(TEI R97)$
Parameter Command Syntax
Command Possible response(s)
+CMMS=[ & lt; n & gt; ]
+CMMS? +CMMS: & lt; n & gt;
+CMMS=? +CMMS: (list of supported & lt; n & gt; s)
Description
Set command controls the continuity of SMS relay protocol link. When
feature is enabled (and supported by network) multiple messages can be
sent much faster as link is kept open.
Test command returns supported values as a compound value.
Defined Values
& lt; n & gt; :
0 disable
1 keep enabled until the time between the response of the latest message
send command (+CMGS, +CMSS, etc.) and the next send command exceeds 1-5
seconds (the exact value is up to ME implementation), then ME shall
close the link and TA switches & lt; n & gt; automatically back to 0
2 enable (if the time between the response of the latest message send
command and the next send command exceeds 1-5 seconds (the exact value
is up to ME implementation), ME shall close the link but TA shall not
switch automatically back to & lt; n & gt; =0)
Implementation
Optional.
3.5.7 Informative Examples
Figure seq Figure smsssw 4 is an example of a TE-TA-ME setup when
messages are sent to network or stored to ME. The volatile memory may as
well be in the ME, or a non-volatile memory may be used instead when
constructing messages.
Figure seq Figure 4 : Message service send and write procedures
An example of sending a default alphabet message in text mode and a
SMS-STATUS-REPORT is wanted:
AT+CNMI? (check that status reports are routed to TE)
+CNMI: 2,1,0,1,0
OK
AT+CSMP=32,167,0,0 (status report wanted; otherwise default settings)
OK
AT+CMGS= " +358501234567 " (start editing a message)
& gt; This the first line. (edit first line and press carriage return)
& gt; This is the last line.^Z (edit second line and send message by
pressing control-Z)
+CMGS: 10 (success: message reference 10 returned from SMSC)
OK
+CDS: 2,10, " +358501234567 " ,145, " 95/07/04/13:12:14+04 " ,
" 95/07/04/13:12:20+04 " ,0 (status report of successful message delivery
received)
Storing an unsent message in memory, sending it from there, and deleting
it:
AT+CPMS? (check memory settings)
+CPMS: " ME " ,4,10, " ME " ,4,10, " ME " ,4,10
OK
AT+CMGW= " 9501231234 " (write message)
& gt; This is the message body^Z
+CMGW: 7 (index number in storage returned)
OK
AT+CMSS=7 (send from storage)
+CMSS: 12 (success: reference value 12 sent from SC)
OK
AT+CMGD=7 (delete message)
OK
4 PDU Mode
The PDU mode uses the same commands and responses as the Text Mode
described in clause 3. However, the following commands and responses
have a different format. In the PDU mode, a complete SMS Message
including all header information is passed as a binary string. This
binary string is composed of hexadecimal IA5 characters as defined in
clause 3 above under ``Message Data Parameters''.
4.1 List Messages +CMGL
Action Command Syntax
Command Possible response(s)
+CMGL[= & lt; stat & gt; ] if PDU mode (+CMGF=0) and command successful:
+CMGL: & lt; index & gt; , & lt; stat & gt; ,[ & lt; alpha & gt; ], & lt; length & gt; & lt; CR & gt; & lt; LF & gt; & lt; pdu & gt;
[ & lt; CR & gt; & lt; LF & gt; +CMGL: & lt; index & gt; , & lt; stat & gt; ,[ & lt; alpha & gt; ], & lt; length & gt; & lt; CR & gt; & lt; LF & gt; & lt; pdu & gt;
[...]]
otherwise:
+CMS ERROR: & lt; err & gt;
+CMGL=? +CMGL: (list of supported & lt; stat & gt; s)
Description
Execution command returns messages with status value & lt; stat & gt; from
preferred message storage & lt; mem1 & gt; to the TE. Entire data units & lt; pdu & gt; are
returned. If status of the message is 'received unread', status in the
storage changes to 'received read'. If listing fails, final result code
+CMS ERROR: & lt; err & gt; is returned. See chapter Message Service Failure
Result Code for & lt; err & gt; values.
Test command shall give a list of all status values supported by the TA.
Implementation
Optional.
4.2 Read Message +CMGR
Action Command Syntax
Command Possible response(s)
+CMGR= & lt; index & gt; if PDU mode (+CMGF=0) and command successful:
+CMGR: & lt; stat & gt; ,[ & lt; alpha & gt; ], & lt; length & gt; & lt; CR & gt; & lt; LF & gt; & lt; pdu & gt;
otherwise:
+CMS ERROR: & lt; err & gt;
+CMGR=?
Description
Execution command returns message with location value & lt; index & gt; from
preferred message storage & lt; mem1 & gt; to the TE. Status of the message and
entire message data unit & lt; pdu & gt; is returned. If status of the message is
'received unread', status in the storage changes to 'received read'. If
reading fails, final result code +CMS ERROR: & lt; err & gt; is returned. See
chapter Message Service Failure Result Code for & lt; err & gt; values.
Implementation
Optional.
4.3 Send Message +CMGS
Action Command Syntax
Command Possible response(s)
if PDU mode (+CMGF=0):
+CMGS= & lt; length & gt; & lt; CR & gt;
PDU is given & lt; ctrl-Z/ESC & gt;
if PDU mode (+CMGF=0) and sending successful:
+CMGS: & lt; mr & gt; [, & lt; ackpdu & gt; ]
if sending fails:
+CMS ERROR: & lt; err & gt;
+CMGS=?
Description
Execution command sends message from a TE to the network (SMS-SUBMIT).
Message reference value & lt; mr & gt; is returned to the TE on successful message
delivery. Optionally (when +CSMS & lt; service & gt; value is 1 and network
supports) & lt; ackpdu & gt; is returned. Values can be used to identify message
upon unsolicited delivery status report result code. If sending fails in
a network or an ME error, final result code +CMS ERROR: & lt; err & gt; is
returned. See chapter Message Service Failure Result Code for a list of
& lt; err & gt; values. This command should be abortable.
- & lt; length & gt; must indicate the number of octets coded in the TP layer data
unit to be given (i.e. SMSC address octets are excluded)
- the TA shall send a four character sequence
& lt; CR & gt; & lt; LF & gt; & lt; greater_than & gt; & lt; space & gt; (IRA 13, 10, 62, 32) after command line is
terminated with & lt; CR & gt; ; after that PDU can be given from TE to ME/TA
- the DCD signal shall be in ON state while PDU is given
- the echoing of given characters back from the TA is controlled by
V.25ter echo command E
- the PDU shall be hexadecimal format (similarly as specified for & lt; pdu & gt; )
and given in one line; ME/TA converts this coding into the actual octets
of PDU
- when the length octet of the SMSC address (given in the PDU) equals
zero, the SMSC address set with command Service Centre Address +CSCA is
used; in this case the SMSC Type-of-Address octet shall not be present
in the PDU, i.e. TPDU starts right after SMSC length octet
- sending can be cancelled by giving & lt; ESC & gt; character (IRA 27)
- & lt; ctrl-Z & gt; (IRA 26) must be used to indicate the ending of PDU
Implementation
Optional.
4.4 Write Message to Memory +CMGW
Action Command Syntax
Command Possible response(s)
if PDU mode (+CMGF=0):
+CMGW= & lt; length & gt; [, & lt; stat & gt; ] & lt; CR & gt; PDU is given & lt; ctrl-Z/ESC & gt; +CMGW: & lt; index & gt;
+CMS ERROR: & lt; err & gt;
+CMGW=?
Description
Execution command stores a message to memory storage & lt; mem2 & gt; . Memory
location & lt; index & gt; of the stored message is returned. By default message
status will be set to 'stored unsent', but parameter & lt; stat & gt; allows also
other status values to be given. (ME/TA manufacturer may choose to use
different default & lt; stat & gt; values for different message types.) The
entering of PDU is done similarly as specified in command Send Message
+CMGS. If writing fails, final result code +CMS ERROR: & lt; err & gt; is
returned. See chapter Message Service Failure Result Code for & lt; err & gt;
values.
Implementation
Optional.
4.5 Send Command +CMGC
Action Command Syntax
Command Possible response(s)
if PDU mode (+CMGF=0):
+CMGC= & lt; length & gt; & lt; CR & gt;
PDU is given & lt; ctrl-Z/ESC & gt;
if PDU mode (+CMGF=0) and sending successful:
+CMGC: & lt; mr & gt; [, & lt; ackpdu & gt; ]
if sending fails:
+CMS ERROR: & lt; err & gt;
+CMGC=?
Description
Execution command sends a command message from a TE to the network
(SMS-COMMAND). The entering of PDU is done similarly as specified in
command Send Message +CMGS. Message reference value & lt; mr & gt; is returned to
the TE on successful message delivery. Optionally (when +CSMS & lt; service & gt;
value is 1 and network supports) & lt; ackpdu & gt; is returned. Values can be
used to identify message upon unsolicited delivery status report result
code. If sending fails in a network or an ME error, final result code
+CMS ERROR: & lt; err & gt; is returned. See chapter Message Service Failure
Result Code for a list of & lt; err & gt; values. This command should be
abortable.
Implementation
Optional.
4.6 New Message Acknowledgement to ME/TA +CNMA
Action Command Syntax
Command Possible response(s)
if PDU mode (+CMGF=0):
+CNMA[= & lt; n & gt; [, & lt; length & gt; [ & lt; CR & gt;
PDU is given & lt; ctrl-Z/ESC & gt; ]]] +CMS ERROR: & lt; err & gt;
+CNMA=? if PDU mode (+CMGF=0):
+CNMA: (list of supported & lt; n & gt; s)
Description
Execution command confirms reception of a new message (SMS-DELIVER or
SMS-STATUS-REPORT) which is routed directly to the TE (refer command
+CNMI tables seq Table smsdeliversummary 2 and seq Table
smssrsummary 4 ). This acknowledgement command shall be used when +CSMS
parameter & lt; service & gt; equals 1. In PDU mode, it is possible to send either
positive (RP-ACK) or negative (RP-ERROR) acknowledgement to the network.
Parameter & lt; n & gt; defines which one will be sent. Optionally (when & lt; length & gt;
is greater than zero) an acknowledgement TPDU (SMS-DELIVER-REPORT for
RP-ACK or RP-ERROR) may be sent to the network. The entering of PDU is
done similarly as specified in command Send Message +CMGS, except that
the format of & lt; ackpdu & gt; is used instead of & lt; pdu & gt; (i.e. SMSC address field
is not present). PDU shall not be bounded by double quotes. TA shall not
send another +CMT or +CDS result code to TE before previous one is
acknowledged.
If ME does not get acknowledgement within required time (network
timeout), ME should send RP-ERROR to the network. ME/TA shall
automatically disable routing to TE by setting both & lt; mt & gt; and & lt; ds & gt; values
of +CNMI to zero.
If command is executed, but no acknowledgement is expected, or some
other ME related error occurs, final result code +CMS ERROR: & lt; err & gt; is
returned. See chapter Message Service Failure Result Code for a list of
& lt; err & gt; values.
NOTE: In case that a directly routed message must be buffered in ME/TA
(possible when +CNMI parameter & lt; mode & gt; equals 0 or 2) or AT interpreter
remains too long in a state where result codes cannot be sent to TE
(e.g. user is entering a message using +CMGS), acknowledgement (RP-ACK)
must be sent to the network without waiting +CNMA command from TE.
Later, when buffered result codes are flushed to TE, TE must send
+CNMA[=0] acknowledgement for each result code. In this way, ME/TA can
determine if message should be placed in non-volatile memory and routing
to TE disabled (+CNMA[=0] not received). Refer command +CNMI for more
details how to use & lt; mode & gt; parameter reliably.
Test command returns a list of supported & lt; n & gt; values. If the only value
supported is 0, the device does not support sending of TPDU.
Defined Values
& lt; n & gt; :
0 command operates similarly as defined for the text mode
1 send RP-ACK (or buffered result code received correctly)
2 send RP-ERROR (if PDU is not given, ME/TA shall send
SMS-DELIVER-REPORT with GSM 03.40 TP-FCS value set to `FF' (unspecified
error cause))
Implementation
Mandatory when & lt; service & gt; value 1 of command Select Message Service +CSMS
is supported.
4.7 Send Message from Storage +CMSS
Action Command Syntax
Command Possible response(s)
+CMSS= & lt; index & gt; [, & lt; da & gt; [, & lt; toda & gt; ]] if PDU mode (+CMGF=0) and sending
successful:
+CMSS: & lt; mr & gt; [, & lt; ackpdu & gt; ]
if sending fails:
+CMS ERROR: & lt; err & gt;
+CMSS=?
Description
Execution command sends message with location value & lt; index & gt; from message
storage & lt; mem2 & gt; to the network (SMS-SUBMIT or SMS-COMMAND). If new
recipient address & lt; da & gt; is given for SMS-SUBMIT, it shall be used instead
of the one stored with the message. Reference value & lt; mr & gt; is returned to
the TE on successful message delivery. Optionally (when +CSMS & lt; service & gt;
value is 1 and network supports) & lt; ackpdu & gt; is returned. Values can be
used to identify message upon unsolicited delivery status report result
code. If sending fails in a network or an ME error, final result code
+CMS ERROR: & lt; err & gt; is returned. See chapter Message Service Failure
Result Code for a list of & lt; err & gt; values. This command should be
abortable.
Implementation
Optional.
Annex A (Normative): Character Set Conversions for SMS Text Mode
The following conversions to and from GSM 03.38 default alphabet are
defined:
TE char set bits/char Commands
PC Code Page 437 8 +CMGF=1;+CSCS= " PCCP437 "
PC Danish/Norwegian 8 +CMGF=1;+CSCS= " PCDN "
ISO 8859 Latin 1 8 +CMGF=1;+CSCS= " 8859-1 "
IRA 7 +CMGF=1;+CSCS= " IRA "
GSM default alphabet 7 +CMGF=1;+CSCS= " GSM "
The tables below show which 7 bit GSM value corresponds to the 7 or 8
bit value of external character set. The TE character set value is
computed by adding column value, 00H through F0H (70H for 7 bits/char),
with the row value (00H through 0FH). All values are in hexadecimal, but
the H suffix is not used. When text mode is implemented, it is mandatory
for a TA to have at least one conversion which include the conversion
table of IRA (e.g. PC Code Page 437 does). Additional conversions can be
defined by manufacturers. It is manufacturer specific if the TE set is
actually converted to GSM set in the TA or in the ME, and if the TE set
is converted to a ME specific set in the TA before converting it to GSM
set when message is sent to the network. It is recommended that
characters which cannot be converted to GSM set are deleted.
Conversion from IRA to GSM:
00 10 20 30 40 50 60 70
00 - - 20 30 00 50 - 70
01 - - 21 31 41 51 61 71
02 - - 22 32 42 52 62 72
03 - - 23 33 43 53 63 73
04 - - 02 34 44 54 64 74
05 - - 25 35 45 55 65 75
06 - - 26 36 46 56 66 76
07 - - 27 37 47 57 67 77
08 - - 28 38 48 58 68 78
09 - - 29 39 49 59 69 79
0A LF - 2A 3A 4A 5A 6A 7A
0B - - 2B 3B 4B - 6B -
0C - - 2C 3C 4C - 6C -
0D CR- - 2D 3D 4D - 6D -
0E - - 2E 3E 4E - 6E -
0F - - 2F 3F 4F 11 6F -
Conversion from PCCP437 (PC-8 Code Page 437) to GSM:
00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0
00 - - 20 30 00 50 - 70 09 1F 6110 - - - - -
01 - - 21 31 41 51 61 71 7E 1D 6911 - - - 1E -
02 - - 22 32 42 52 62 72 05 1C 6F12 - - - 13 -
03 - - 23 33 43 53 63 73 611 6F7 7513 - - - - -
04 - - 02 34 44 54 64 74 7B 7C 7D - - - 18 -
05 - 5F 25 35 45 55 65 75 7F 08 5D - - - - -
06 - - 26 36 46 56 66 76 0F 758 - - - - - -
07 - - 27 37 47 57 67 77 092 06 - - - - - -
08 - - 28 38 48 58 68 78 653 799 60 - - - 12 -
09 - - 29 39 49 59 69 79 654 5C - - - - 19 -
0A LF - 2A 3A 4A 5A 6A 7A 04 5E - - - - 15 -
0B - - 2B 3B 4B - 6B - 695 - - - - - - -
0C - - 2C 3C 4C - 6C - 696 01 - - - - - -
0D CR- - 2D 3D 4D - 6D - 07 03 40 - - - - -
0E - - 2E 3E 4E - 6E - 5B - - - - - - -
0F - - 2F 3F 4F 11 6F - 0E - - - - - - -
1 : â ð a 2 : ç ð Ç 3 : ê ð e 4 : ë ð e 5 : ï ð i
6 : î ð i 7 : ô ð o 8 : û ð u 9 : ÿ ð y 10 : á ð a
11 : í ð i 12 : ó ð o 13 : ú ð u
Conversion from PCDN (PC-8 Danish/ Norwegian) to GSM:
00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0
00 - - 20 30 00 50 - 70 09 1F 6110 - - - - -
01 - - 21 31 41 51 61 71 7E 1D 6911 - - - 1E -
02 - - 22 32 42 52 62 72 05 1C 6F12 - - - 13 -
03 - - 23 33 43 53 63 73 611 6F7 7513 - - - - -
04 - - 02 34 44 54 64 74 7B 7C 7D - - - 18 -
05 - 5F 25 35 45 55 65 75 7F 08 5D - - - - -
06 - - 26 36 46 56 66 76 0F 758 - - - - - -
07 - - 27 37 47 57 67 77 092 06 - - - - - -
08 - - 28 38 48 58 68 78 653 799 60 - - - 12 -
09 - - 29 39 49 59 69 79 654 5C - - - - 19 -
0A LF - 2A 3A 4A 5A 6A 7A 04 5E - - - - 15 -
0B - - 2B 3B 4B - 6B - 695 0C - - - - - -
0C - - 2C 3C 4C - 6C - 696 01 - - - - - -
0D CR - 2D 3D 4D - 6D - 07 0B 40 - - - - -
0E - - 2E 3E 4E - 6E - 5B - - - - - - -
0F - - 2F 3F 4F 11 6F - 0E - - - - - - -
1 : â ð a 2 : ç ð Ç 3 : ê ð e 4 : ë ð e 5 : ï ð i
6 : î ð i 7 : ô ð o 8 : û ð u 9 : ÿ ð y 10 : á ð a
11 : í ð i 12 : ó ð o 13 : ú ð u
Conversion from 8859-1 (ISO 8859 Latin 1) to GSM:
00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0
00 - - 20 30 00 50 - 70 - - - - 411 - 7F -
01 - - 21 31 41 51 61 71 - - 40 - 412 5D 6120 7D
02 - - 22 32 42 52 62 72 - - - - 413 4F12 6121 08
03 - - 23 33 43 53 63 73 - - 01 - 414 4F13 6122 6F29
04 - - 02 34 44 54 64 74 - - 24 - 5B 4F14 7B 6F30
05 - - 25 35 45 55 65 75 - - 03 - 0E 4F15 0F 6F31
06 - - 26 36 46 56 66 76 - - - - 1C 5C 1D 7C
07 - - 27 37 47 57 67 77 - - 5F - 09 - 0923 -
08 - - 28 38 48 58 68 78 - - - - 455 0B 04 0C
09 - - 29 39 49 59 69 79 - - - - 1F 5516 05 06
0A LF - 2A 3A 4A 5A 6A 7A - - - - 456 5517 6524 7532
0B - - 2B 3B 4B - 6B - - - - - 457 5518 6525 7533
0C - - 2C 3C 4C - 6C - - - - - 498 5E 07 7E
0D CR - 2D 3D 4D - 6D - - - - - 499 5919 6926 7934
0E - - 2E 3E 4E - 6E - - - - - 4910 - 6927 -
0F - - 2F 3F 4F 11 6F - - - - 60 4911 1E 6928 7935
1 : À ð A 2 : Á ð A 3 : Â ð A 4 : Ã ð A 5 : È ð E
6 : Ê ð E 7 : Ë ð E 8 : Ì ð I 9 : Í ð I 10 : Î ð I
11 : Ï ð I 12 : Ò ð O 13 : Ó ð O 14 : Ô ð O 15 : Õ ð O
16 : Ù ð U 17 : Ú ð U 18 : Û ð U 19 : Ý ð Y 20 : á ð a
21 : â ð a 22 : ã ð a 23 : ç ð Ç 24 : ê ð e 25 : ë ð e
26 : í ð i 27 : î ð i 28 : ï ð i 29 : ó ð o 30 : ô ð o
31 : õ ð o 32 : ú ð u 33 : û ð u 34 : ý ð y 35 : ÿ ð y
Conversions from GSM default alphabet to above character sets are
otherwise straightforward, but no conversions of the characters listed
below tables are applied.
Annex B (Informative): Example of processing a data block
B.1 Example state diagrams for the block receiver
The state diagrams on the following two pages show how the receiver
component at the block level could work. In this example the received
octets are processed in two stages.
Stage 1 is a low level function which detects the unique start and end
markers, and removes any stuffing octets. The results of this stage are
passed to stage 2. Any unexpected octet value after a DLE will be
indicated as 'abort'.
Stage 2 assembles the message content and the BCS octets, using octets
passed from stage 1 and the 'start' and 'end' indications. A 'start'
will always reset the process to state 1 from any state. An 'abort' will
always cause a return to state 0 where a 'start' will be awaited. When
an 'end' is received in state 1, the following two octets are checked as
the BCS. If the BCS is correct, the message content is passed to another
stage of the receiver for processing of the message content.
B.2 Example of coding and decoding a data block
The last page of this annex shows the coding of an example message at a
transmitter, and the decoding stages at a receiver which has the two
stages of processing as described above.
In this example, the message content and the BCS both contain an octet
with a value of 10 hex. Therefore the message as transmitted over the
interface has additional stuffing octets (00 hex) inserted after these
octets. The receiver first detects the start and end markers, and
removes the stuffing octets. Finally the BCS is checked.
Annex C (Informative): Change History
SMG# TDoc VERS CR REV PHASE CAT WORKITEM SUBJECT NEW_VERS
S20 612/96 5.0.0 A022
2+ B TEI Enhanced SMS routing to TE in AT modes 5.1.0
S20 612/96 5.0.0 A023
2+ B TEI Underscore character in Annex A 5.1.0
S20 612/96 5.0.0 A024
2+ B TEI New +CMS ERROR codes 5.1.0
S20 612/96 5.0.0 A025
2+ B TEI UCS2 in text mode 5.1.0
S20 612/96 5.0.0 A026
2+ B TEI Enhanced SMS storage handling in AT modes 5.1.0
S20 612/96 4.7.0 A027
2 F
IEI value for TP Failure Case (Phase 2) 4.8.0
S20 612/96 5.0.0 A028
2+ A
IEI value for TP Failure Case (Phase 2+) 5.1.0
S20 612/96 5.0.0 A029
2+ D TEI OK response to AT+CESP 5.1.0
S20 612/96 5.0.0 A030
2+ B TEI RP-Ack PDU 5.1.0
s21 060/97 5.1.0 A031
2+ D
CBS editorial modifications in AT modes 5.2.0
s21 060/97 5.1.0 A032
2+ F
Correction of error in SMS Block mode 5.2.0
s21 060/97 5.1.0 A033
2+ D
Further text for PDU mode +CMGS 5.2.0
s22 415/97 5.2.0 A034
2+ F
Editorial corrections 5.3.0
s22 415/97 5.2.0 A035
R97 B TEI R97 More messages to send 5.3.0
s23 97-702 5.3.0 A036
R97 B TEI R97 Enhanced validity period format in text mode 5.4.0
s24 97-922 5.4.0 A037
R96 F
Unnecessary conversion in Annex A 5.5.0
History
Document history
July 1996 Publication of Version 5.0.0
October 1996 Publication of Version 5.1.0
March 1997 Publication of Version 5.2.0
August 1997 Publication of Version 5.3.0
November 1997 Version 5.4.0 not published
January 1998 Publication of Version 5.5.0
ISBN 2-7437-1945-1
Dépôt légal : Janvier 1998
Page PAGE 2
GSM 07.05 version 5.5.0: January 1998
Page PAGE 3
GSM 07.05 version 5.5.0: January 1998
TD & lt; & gt;
GSM 03.38 V7.0.0 (1998-07)
Technical Specification
Digital cellular telecommunications system (Phase 2+);
Alphabets and language-specific information
(GSM 03.38 version 7.0.0 Release 1998)
SMG version only, not for publication
Reference
DEN/SMG-040338Q6 (8c003000.PDF)
Keywords
Digital cellular telecommunications system, Global System for Mobile
communications (GSM)
ETSI Secretariat
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
secretariat@etsi.fr
http://www.etsi.fr
http://www.etsi.org
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 1998.
All rights reserved.
Contents
TOC \o Intellectual Property Rights GOTOBUTTON _Toc425657288
PAGEREF _Toc425657288 4
Foreword GOTOBUTTON _Toc425657289 PAGEREF _Toc425657289 4
1 Scope GOTOBUTTON _Toc425657290 PAGEREF _Toc425657290 5
2 Normative references GOTOBUTTON _Toc425657291 PAGEREF
_Toc425657291 5
3 Abbreviations GOTOBUTTON _Toc425657292 PAGEREF _Toc425657292 6
4 SMS Data Coding Scheme GOTOBUTTON _Toc425657293 PAGEREF
_Toc425657293 6
5 Cell Broadcast Data Coding Scheme GOTOBUTTON _Toc425657294
PAGEREF _Toc425657294 9
6 Individual parameters GOTOBUTTON _Toc425657295 PAGEREF
_Toc425657295 11
6.1 General principles GOTOBUTTON _Toc425657296 PAGEREF
_Toc425657296 11
6.1.1 General notes GOTOBUTTON _Toc425657297 PAGEREF _Toc425657297
11
6.1.2 Character packing GOTOBUTTON _Toc425657298 PAGEREF
_Toc425657298 11
6.1.2.1 SMS Point-to-Point Packing GOTOBUTTON _Toc425657299 PAGEREF
_Toc425657299 11
6.1.2.1.1 Packing of 7-bit characters GOTOBUTTON _Toc425657300
PAGEREF _Toc425657300 11
6.1.2.2 SMS Cell Broadcast Packing GOTOBUTTON _Toc425657301 PAGEREF
_Toc425657301 12
6.1.2.2.1 Packing of 7-bit characters GOTOBUTTON _Toc425657302
PAGEREF _Toc425657302 12
6.1.2.3 USSD packing GOTOBUTTON _Toc425657303 PAGEREF _Toc425657303
13
6.1.2.3.1 Packing of 7 bit characters GOTOBUTTON _Toc425657304
PAGEREF _Toc425657304 13
6.2 Alphabet tables GOTOBUTTON _Toc425657305 PAGEREF _Toc425657305
15
6.2.1 Default alphabet GOTOBUTTON _Toc425657306 PAGEREF
_Toc425657306 15
6.2.1.1 GSM 7bit default alphabet extension table GOTOBUTTON
_Toc425657307 PAGEREF _Toc425657307 17
6.2.2 8 bit data GOTOBUTTON _Toc425657308 PAGEREF _Toc425657308 17
6.2.3 UCS2 GOTOBUTTON _Toc425657309 PAGEREF _Toc425657309 18
Annex A (Informative): Document change history GOTOBUTTON
_Toc425657310 PAGEREF _Toc425657310 19
History GOTOBUTTON _Toc425657311 PAGEREF _Toc425657311 20
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have
been declared to ETSI. The information pertaining to these essential
IPRs, if any, is publicly available for ETSI members and non-members,
and can be found in ETR 314: " Intellectual Property Rights (IPRs);
Essential, or potentially Essential, IPRs notified to ETSI in respect of
ETSI standards " , which is available free of charge from the ETSI
Secretariat. Latest updates are available on the ETSI Web server
(http://www.etsi.fr/ipr or http://www.etsi.org/ipr).
Pursuant to the ETSI Interim IPR Policy, no investigation, including IPR
searches, has been carried out by ETSI. No guarantee can be given as to
the existence of other IPRs not referenced in ETR 314 (or the updates on
the ETSI Web server) which are, or may be, or may become, essential to
the present document.
Foreword
This ETSI Technical Specification (TS) has been produced by the Special
Mobile Group (SMG) of the European Telecommunications Standards
Institute (ETSI).
This TS defines the language-specific requirements for GSM within the
digital cellular telecommunications system (Phase 2+).
The contents of this TS is subject to continuing work within SMG and may
change following formal SMG approval. Should SMG modify the contents of
this TS, it will be re-released with an identifying change of release
date and an increase in version number as follows:
Version 7.x.y
where:
7 indicates Release 1998 of GSM Phase 2+
x the second digit is incremented for all other types of changes, i.e.
technical enhancements, corrections, updates, etc.
y the third digit is incremented when editorial only changes have been
incorporated in the specification.
1 Scope
This TS defines the language-specific requirements for GSM. These are
specific codepoints required by the Short Message Service (SMS)
specifications which in turn are used not only for SMS (GSM 03.40,
03.41) but also for Unstructured Data (GSM 02.90) and may additionally
be used for Man Machine Interface (MMI) (GSM 02.30).
The specification for the Data Circuit terminating Equipment/Data
Terminal Equipment (DCE/DTE) interface (GSM 07.05 [8]) will also use the
codes specified herein for the transfer of SMS data to an external
terminal.
2 Normative references
References may be made to:
a) specific versions of publications (identified by date of publication,
edition number, version number, etc.), in which case, subsequent
revisions to the referenced document do not apply; or
b) all versions up to and including the identified version (identified
by " up to and including " before the version identity); or
c) all versions subsequent to and including the identified version
(identified by " onwards " following the version identity); or
d) publications without mention of a specific version, in which case the
latest version applies.
A non-specific reference to an ETS shall also be taken to refer to later
versions published as an EN with the same number.
[1] GSM 01.04: " Digital cellular telecommunication system (Phase 2+);
Abbreviations and acronyms " .
[2] GSM 02.30: " Digital cellular telecommunication system (Phase 2+);
Man-Machine Interface (MMI) of the Mobile Station (MS) " .
[3] GSM 03.90: " Digital cellular telecommunication system (Phase 2+);
Unstructured supplementary services operation - Stage 2 " .
[4] GSM 03.40: " Digital cellular telecommunication system (Phase 2+);
Technical realization of the Short Message Service (SMS) Point to Point
(PP) " .
[5] GSM 03.41: " Digital cellular telecommunication system (Phase 2+);
Technical realization of Short Message Service Cell Broadcast (SMSCB) " .
[6] GSM 04.11: " Digital cellular telecommunication system (Phase 2+);
Point-to-Point (PP) Short Message Service (SMS) support on mobile radio
interface " .
[7] GSM 04.12: " Digital cellular telecommunication system (Phase 2+);
Short Message Service Cell Broadcast (SMSCB) support on the mobile radio
interface " .
[8] GSM 07.05: " Digital cellular telecommunication system (Phase 2+);
Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE
- DCE) interface for Short Message Service (SMS) and Cell Broadcast
Service (CBS) " .
[10] ISO/IEC10646: " Universal Multiple-Octet Coded Character Set
(UCS)''; UCS2, 16 bit coding.
[11] GSM 04.90: " Digital cellular telecommunication system (Phase 2+);
Unstructured supplementary services operation - Stage 3 " .
[12] ISO 639 ``Code for the representation of names of languages''
[13] GSM 03.42: " Digital cellular telecommunication system (Phase 2+);
Compression algorithm for text messaging services''.
[14] GSM 03.40: " Digital cellular telecommunication system (Phase 2+);
Technical realization of the Short Message Service (SMS) Point to Point
(PP) " .
3 Abbreviations
Abbreviations used in this TS are listed in GSM 01.04.
4 SMS Data Coding Scheme
The TP-Data-Coding-Scheme field, defined in GSM 03.40, indicates the
data coding scheme of the TP-UD field, and may indicate a message class.
Any reserved codings shall be assumed to be the GSM default alphabet
(the same as codepoint 00000000) by a receiving entity. The octet is
used according to a coding group which is indicated in bits 7..4. The
octet is then coded as follows:
Coding Group Bits
7..4 Use of bits 3..0
00xx General Data Coding indication
Bits 5..0 indicate the following :
Bit 5, if set to 0, indicates the text is uncompressed
Bit 5, if set to 1, indicates the text is compressed using the GSM
standard compression algorithm. ( see GSM TS 03.42)
Bit 4, if set to 0, indicates that bits 1 to 0 are reserved and have no
message class meaning
Bit 4, if set to 1, indicates that bits 1 to 0 have a message class
meaning :
Bit 1 Bit 0 Message Class
0 0 Class 0
0 1 Class 1 Default meaning: ME-specific.
1 0 Class 2 SIM specific message
1 1 Class 3 Default meaning: TE specific (see GSM TS 07.05 [8])
Bits 3 and 2 indicate the alphabet being used, as follows :
Bit 3 Bit2 Alphabet:
0 0 Default alphabet
0 1 8 bit data
1 0 UCS2 (16bit) [10]
1 1 Reserved
NOTE: The special case of bits 7..0 being 0000 0000 indicates the
Default Alphabet as in Phase 2
0100..1011 Reserved coding groups
1100 Message Waiting Indication Group: Discard Message
Bits 3..0 are coded exactly the same as Group 1101, however with bits
7..4 set to 1100 the mobile may discard the contents of the message, and
only present the indication to the user.
(continued)
Coding Group Bits
7..4 Use of bits 3..0
1101 Message Waiting Indication Group: Store Message
This Group allows an indication to be provided to the user about the
status of types of message waiting on systems connected to the GSM PLMN.
The mobile may present this indication as an icon on the screen, or
other MMI indication. The mobile may take note of the Origination
Address for messages in this group and group 1100. For each indication
supported, the mobile may provide storage for the Origination Address
which is to control the mobile indicator.
Text included in the user data is coded in the Default Alphabet.
Where a message is received with bits 7..4 set to 1101, the mobile shall
store the text of the SMS message in addition to setting the indication.
Bits 3 indicates Indication Sense:
Bit 3
0 Set Indication Inactive
1 Set Indication Active
Bit 2 is reserved, and set to 0
Bit 1 Bit 0 Indication Type:
0 0 Voicemail Message Waiting
0 1 Fax Message Waiting
1 0 Electronic Mail Message Waiting
1 1 Other Message Waiting*
* Mobile manufacturers may implement the ``Other Message Waiting''
indication as an additional indication without specifying the meaning.
The meaning of this indication is intended to be standardized in the
future, so Operators should not make use of this indication until the
standard for this indication is finalized.
1110 Message Waiting Indication Group: Store Message
The coding of bits 3..0 and functionality of this feature are the same
as for the Message Waiting Indication Group above, (bits 7..4 set to
1101) with the exception that the text included in the user data is
coded in the uncompressed UCS2 alphabet.
1111 Data coding/message class
Bit 3 is reserved, set to 0.
Bit 2 Message coding:
0 Default alphabet
1 8-bit data
Bit 1 Bit 0 Message Class:
0 0 Class 0
0 1 Class 1 default meaning: ME-specific.
1 0 Class 2 SIM-specific message.
1 1 Class 3 default meaning: TE specific (see GSM TS 07.05 [8])
Default alphabet indicates that the TP-UD is coded from the 7-bit
alphabet given in subclause 6.2.1. When this alphabet is used, the
characters of the message are packed in octets as shown in
subclause 6.1.2.1.1, and the message can consist of up to 160
characters. The default alphabet shall be supported by all MSs and SCs
offering the service. If the 7 bit default alphabet extension mechanism
is used then the number of displayable characters will reduce by one for
every instance where the 7 bit default alphabet extension table is
used8-bit data indicates that the TP-UD has user-defined coding, and the
message can consist of up to 140 octets.
UCS2 alphabet indicates that the TP-UD has a UCS2 [10] coded message,
and the message can consist of up to 140 octets, i.e. up to 70 UCS2
characters. The General notes specified in subclause 6.1.1 override any
contrary specification in UCS2, so for example even in UCS2 a & lt; CR & gt;
character will cause the MS to return to the beginning of the current
line and overwrite any existing text with the characters which follow
the & lt; CR & gt; .
When a message is compressed, the TP-UD consists of the default alphabet
or UCS2 alphabet compressed message, and the compressed message itself
can consist of up to 140 octets in total.
When a mobile terminated message is class 0 and the MS has the
capability of displaying short messages, the MS shall display the
message immediately and send an acknowledgement to the SC when the
message has successfully reached the MS irrespective of whether there is
memory available in the SIM or ME. The message shall not be
automatically stored in the SIM or ME.
The ME may make provision through MMI for the user to selectively
prevent the message from being displayed immediately.
If the ME is incapable of displaying short messages or if the immediate
display of the message has been disabled through MMI then the ME shall
treat the short message as though there was no message class, i.e. it
will ignore bits 0 and 1 in the TP-DCS and normal rules for memory
capacity exceeded shall apply.
When a mobile terminated message is Class 1, the MS shall send an
acknowledgement to the SC when the message has successfully reached the
MS and can be stored. The MS shall normally store the message in the ME
by default, if that is possible, but otherwise the message may be stored
elsewhere, e.g. in the SIM. The user may be able to override the default
meaning and select their own routing.
When a mobile terminated message is Class 2 (SIM-specific), a phase 2
(or later) MS shall ensure that the message has been transferred to the
SMS data field in the SIM before sending an acknowledgement to the SC.
The MS shall return a " protocol error, unspecified " error message (see
GSM TS 04.11) if the short message cannot be stored in the SIM and there
is other short message storage available at the MS. If all the short
message storage at the MS is already in use, the MS shall return " memory
capacity exceeded " . $begin$(Secure SMS)$ This behaviour applies in all
cases except for phase 2+ MS supporting SIM Application Toolkit when the
Protocol Identifier (TP-PID) of the mobile terminated message is set to
" SIM Data download " (see GSM 03.40 [14]).$end$(Secure SMS)$.
When a mobile terminated message is Class 3, the MS shall send an
acknowledgement to the SC when the message has successfully reached the
MS and can be stored, irrespectively of whether the MS supports an SMS
interface to a TE, and without waiting for the message to be transferred
to the TE. Thus the acknowledgement to the SC of a TE-specific message
does not imply that the message has reached the TE. Class 3 messages
shall normally be transferred to the TE when the TE requests
" TE-specific " messages (see GSM TS 07.05 [8]). The user may be able to
override the default meaning and select their own routing.
The message class codes may also be used for mobile originated messages,
to provide an indication to the destination SME of how the message was
handled at the MS.
The MS will not interpret reserved or unsupported values but shall store
them as received. The SC may reject messages with a Data Coding Scheme
containing a reserved value or one which is not supported.
5 Cell Broadcast Data Coding Scheme
The Cell Broadcast Data Coding Scheme indicates the intended handling of
the message at the MS, the alphabet/coding, and the language (when
applicable). Any reserved codings shall be assumed to be the GSM default
alphabet (the same as codepoint 00001111) by a receiving entity. The
octet is used according to a coding group which is indicated in bits
7..4. The octet is then coded as follows:
Coding Group
Bits
7..4
Use of bits 3..0
0000 Language using the default alphabet
Bits 3..0 indicate the language:
0000 German
0001 English
0010 Italian
0011 French
0100 Spanish
0101 Dutch
0110 Swedish
0111 Danish
1000 Portuguese
1001 Finnish
1010 Norwegian
1011 Greek
1100 Turkish
1101Hungarian
1110 Polish
1111 Language unspecified
0001 0000 Default alphabet; message preceded by language indication.
The first 3 characters of the message are a two-character
representation of the language encoded according to ISO 639 [12],
followed by a CR character. The CR character is then followed by 90
characters of text. A Pre-Phase 2+ MS will overwrite the start of the
message up to the CR and present only the text.
0001 UCS2; message preceded by language indication
The message starts with a two 7-bit default alphabet character
representation of the language encoded according to ISO 639 [12]. This
is padded to the octet boundary with two bits set to 0 and then followed
by 40 characters of UCS2-encoded message.
An MS not supporting UCS2 coding will present the two character language
identifier followed by improperly interpreted user data.
0010..1111 Reserved for European languages
0010.. 0000 Czech
0001 .. 1111 Reserved for European Languages using the default
alphabet, with unspecified handling at the MS
0011 0000..1111 Reserved for European Languages using the default
alphabet, with unspecified handling at the MS
(continued)
(concluded)
01xx General Data Coding indication
Bits 5..0 indicate the following:
Bit 5, if set to 0, indicates the text is uncompressed
Bit 5, if set to 1, indicates the text is compressed using the GSM
standard compressing algorithm. ( see GSM TS 03.42 )
Bit 4, if set to 0, indicates that bits 1 to 0 are reserved and have no
message class meaning
Bit 4, if set to 1, indicates that bits 1 to 0 have a message class
meaning:
Bit 1 Bit 0 Message Class:
0 0 Class 0
0 1 Class 1 Default meaning: ME-specific.
1 0 Class 2 SIM specific message.
1 1 Class 3 Default meaning: TE-specific (see GSM TS 07.05 [8])
Bits 3 and 2 indicate the alphabet being used, as follows:
Bit 3 Bit 2 Alphabet:
0 0 Default alphabet
0 1 8 bit data
1 0 USC2 (16 bit) [10]
1 1 Reserved
Coding Group
Bits
7..4
Use of bits 3..0
1000..1110 Reserved coding groups
1111 Data coding / message handling
Bit 3 is reserved, set to 0.
Bit 2 Message coding:
0 Default alphabet
1 8 bit data
Bit 1 Bit 0 Message Class:
0 0 No message class.
0 1 Class 1 user defined.
1 0 Class 2 user defined.
1 1 Class 3
default meaning: TE specific
(see GSM TS 07.05 [8])
These codings may also be used for Unstructured SS Data and MMI/display
purposes.
See GSM 04.90 [11] for specific coding values applicable to Unstructured
SS Data for MS originated USSD messages and MS terminated USSD messages.
USSD messages using the default alphabet are coded with the 7-bit
alphabet given in subclause 6.2.1. The message can then consist of up to
182 user characters.
Cell Broadcast messages using the default alphabet are coded with the
7-bit alphabet given in subclause 6.2.1. The message then consists of 93
user characters.
If the 7 bit default alphabet extension mechanism is used then the
number of displayable characters will reduce by one for every instance
where the 7 bit default alphabet extension table is usedCell Broadcast
messages using 8-bit data have user-defined coding, and will be 82
octets in length.
UCS2 alphabet indicates that the message is coded in UCS2 [10]. The
General notes specified in subclause 6.1.1 override any contrary
specification in UCS2, so for example even in UCS2 a & lt; CR & gt; character will
cause the MS to return to the beginning of the current line and
overwrite any existing text with the characters which follow the & lt; CR & gt; .
Messages encoded in UCS2 consist of 41 characters.
Class 1 and Class 2 messages may be routed by the ME to user-defined
destinations, but the user may override any default meaning and select
their own routing.
Class 3 messages will normally be selected for transfer to a TE, in
cases where a ME supports an SMS/CBS interface to a TE, and the TE
requests " TE-specific " cell broadcast messages (see GSM 07.05 [8]). The
user may be able to override the default meaning and select their own
routing.
6 Individual parameters
6.1 General principles
6.1.1 General notes
Except where otherwise indicated, the following shall apply to all
alphabet tables:
1: The characters marked " 1) " are not used but are displayed as a space.
2: The characters of this set, when displayed, should approximate to the
appearance of the relevant characters specified in ISO 1073 and the
relevant national standards.
3: Control characters:
Code Meaning
LF Line feed: Any characters following LF which are to be displayed
shall be presented as the next line of the message, commencing with
the first character position.
CR Carriage return: Any characters following CR which are to be
displayed shall be presented as the current line of the message,
commencing with the first character position.
SP Space character.
4: The display of characters within a message is achieved by taking each
character in turn and placing it in the next available space from left
to right and top to bottom.
6.1.2 Character packing
6.1.2.1 SMS Point-to-Point Packing
6.1.2.1.1 Packing of 7-bit characters
If a character number ( is noted in the following way:
b7 b6 b5 b4 b3 b2 b1
(a (b (c (d (e (f (g
The packing of the 7-bits characters in octets is done by completing the
octets with zeros on the left.
For examples, packing: (
- one character in one octet:
- bits number:
7 6 5 4 3 2 1 0
0 1a 1b 1c 1d 1e 1f 1g
- two characters in two octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
0 0 2a 2b 2c 2d 2e 2f
- three characters in three octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
0 0 0 3a 3b 3c 3d 3e
- seven characters in seven octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
7b 7c 7d 7e 7f 7g 6a 6b
0 0 0 0 0 0 0 7a
- eight characters in seven octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
7b 7c 7d 7e 7f 7g 6a 6b
8a 8b 8c 8d 8e 8f 8g 7a
The bit number zero is always transmitted first.
Therefore, in 140 octets, it is possible to pack (140x8)/7=160
characters.
6.1.2.2 SMS Cell Broadcast Packing
6.1.2.2.1 Packing of 7-bit characters
If a character number ( is noted in the following way:
b7 b6 b5 b4 b3 b2 b1
(a (b (c (d (e (f (g
the packing of the 7-bits characters in octets is done as follows:
bit number
7 6 5 4 3 2 1 0
octet number
1 2g 1a 1b 1c 1d 1e 1f 1g
2 3f 3g 2a 2b 2c 2d 2e 2f
3 4e 4f 4g 3a 3b 3c 3d 3e
4 5d 5e 5f 5g 4a 4b 4c 4d
5 6c 6d 6e 6f 6g 5a 5b 5c
6 7b 7c 7d 7e 7f 7g 6a 6b
7 8a 8b 8c 8d 8e 8f 8g 7a
8 10g 9a 9b 9c 9d 9e 9f 9g
.
.
81 93d 93e 93f 93g 92a 92b 92c 92d
82 0 0 0 0 0 93a 93b 93c
The bit number zero is always transmitted first.
Therefore, in 82 octets, it is possible to pack (82x8)/7 = 93.7, that is
93 characters. The 5 remaining bits are set to zero as stated above.
6.1.2.3 USSD packing
6.1.2.3.1 Packing of 7 bit characters
If a character number ( is noted in the following way:
b7 b6 b5 b4 b3 b2 b1
(a (b (c (d (e (f (g
The packing of the 7-bit characters in octets is done by completing the
octets with zeros on the left.
For example, packing: (
- one character in one octet:
- bits number:
7 6 5 4 3 2 1 0
0 1a 1b 1c 1d 1e 1f 1g
- two characters in two octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
0 0 2a 2b 2c 2d 2e 2f
- three characters in three octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
0 0 0 3a 3b 3c 3d 3e
- six characters in six octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
0 0 0 0 0 0 6a 6b
- seven characters in seven octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
7b 7c 7d 7e 7f 7g 6a 6b
0 0 0 1 1 0 1 7a
The bit number zero is always transmitted first.
- eight characters in seven octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
7b 7c 7d 7e 7f 7g 6a 6b
8a 8b 8c 8d 8e 8f 8g 7a
- nine characters in eight octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
7b 7c 7d 7e 7f 7g 6a 6b
8a 8b 8c 8d 8e 8f 8g 7a
0 9a 9b 9c 9d 9e 9f 9g
- fifteen characters in fourteen octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
7b 7c 7d 7e 7f 7g 6a 6b
8a 8b 8c 8d 8e 8f 8g 7a
10g 9a 9b 9c 9d 9e 9f 9g
11f 11g 10a 10b 10c 10d 10e 10f
12e 12f 12g 11a 11b 11c 11d 11e
13d 13e 13f 13g 12a 12b 12c 12d
14c 14d 14e 14f 14g 13a 13b 13c
15b 15c 15d 15e 15f 15g 14a 14b
0 0 0 1 1 0 1 15a
- sixteen characters in fourteen octets:
- bits number:
7 6 5 4 3 2 1 0
2g 1a 1b 1c 1d 1e 1f 1g
3f 3g 2a 2b 2c 2d 2e 2f
4e 4f 4g 3a 3b 3c 3d 3e
5d 5e 5f 5g 4a 4b 4c 4d
6c 6d 6e 6f 6g 5a 5b 5c
7b 7c 7d 7e 7f 7g 6a 6b
8a 8b 8c 8d 8e 8f 8g 7a
10g 9a 9b 9c 9d 9e 9f 9g
11f 11g 10a 10b 10c 10d 10e 10f
12e 12f 12g 11a 11b 11c 11d 11e
13d 13e 13f 13g 12a 12b 12c 12d
14c 14d 14e 14f 14g 13a 13b 13c
15b 15c 15d 15e 15f 15g 14a 14b
16a 16b 16c 16d 16e 16f 16g 15a
The bit number zero is always transmitted first.
Therefore, in 160 octets, is it possible to pack (160*8)/7 = 182.8, that
is 182 characters. The remaining 6 bits are set to zero as stated above.
Packing of 7 bit characters in USSD strings is done in the same way as
for SMS (subclause 7.1.2.1).The character stream is bit padded to octet
boundary with binary zeroes as shown above.
If the total number of characters to be sent equals (8n-1) where n=1,2,3
etc. then there are 7 spare bits at the end of the message. To avoid the
situation where the receiving entity confuses 7 binary zero pad bits as
the @ character, the carriage return or & lt; CR & gt; character (defined in
subclause 7.1.1) shall be used for padding in this situation, just as
for Cell Broadcast.
If & lt; CR & gt; is intended to be the last character and the message (including
the wanted & lt; CR & gt; ) ends on an octet boundary, then another & lt; CR & gt; must be
added together with a padding bit 0. The receiving entity will perform
the carriage return function twice, but this will not result in
misoperation as the definition of & lt; CR & gt; in subclause 7.1.1 is identical
to the definition of & lt; CR & gt; & lt; CR & gt; .
The receiving entity shall remove the final & lt; CR & gt; character where the
message ends on an octet boundary with & lt; CR & gt; as the last character.
Under certain circumstances, a Pre Phase 2 + MS will perform the
carriage return function after displaying the last USSD character
received.
6.2 Alphabet tables
This section provides tables for all the alphabets to be supported by
SMS. The default alphabet is mandatory. Additional alphabets are
optional. Irrespective of support of an individual alphabet, an MS shall
have the ability to store a short message coded in any alphabet on the
SIM.
6.2.1 Default alphabet
Bits per character: 7
SMS User Data Length meaning: Number of characters
CBS/USSD pad character: CR
Character table:
b7 0 0 0 0 1 1 1 1
b6 0 0 1 1 0 0 1 1
b5 0 1 0 1 0 1 0 1
b4 b3 b2 b1 0 1 2 3 4 5 6 7
0 0 0 0 0 @ SYMBOL 68 \f " Symbol " SP 0 ¡ P ¿ p
0 0 0 1 1 £ _ ! 1 A Q a q
0 0 1 0 2 $ SYMBOL 70 \f " Symbol " " 2 B R b r
0 0 1 1 3 ¥ SYMBOL 71 \f " Symbol " # 3 C S c s
0 1 0 0 4 è SYMBOL 76 \f " Symbol " ¤ 4 D T d t
0 1 0 1 5 é SYMBOL 87 \f " Symbol " % 5 E U e u
0 1 1 0 6 ù SYMBOL 80 \f " Symbol " & 6 F V f v
0 1 1 1 7 ì SYMBOL 89 \f " Symbol " ' 7 G W g w
1 0 0 0 8 ò SYMBOL 83 \f " Symbol " ( 8 H X h x
1 0 0 1 9 Ç SYMBOL 81 \f " Symbol " ) 9 I Y i y
1 0 1 0 10 LF SYMBOL 88 \f " Symbol " * : J Z j z
1 0 1 1 11 Ø 1) + ; K Ä k ä
1 1 0 0 12 ø Æ , & lt; L Ö l ö
1 1 0 1 13 CR æ - = M Ñ m ñ
1 1 1 0 14 Å ß . & gt; N Ü n ü
1 1 1 1 15 å É / ? O § o à
1) This code is an escape to an extension of the 7 bit default alphabet
table. A receiving entity which does not understand the meaning of this
escape mechanism shall display it as a space character.
6.2.1.1 GSM 7bit default alphabet extension table
b7 0 0 0 0 1 1 1 1
b6 0 0 1 1 0 0 1 1
b5 0 1 0 1 0 1 0 1
b4 b3 b2 b1 0 1 2 3 4 5 6 7
0 0 0 0 0
|
0 0 0 1 1
0 0 1 0 2
0 0 1 1 3
0 1 0 0 4
^
0 1 0 1 5
2)
0 1 1 0 6
0 1 1 1 7
1 0 0 0 8
{
1 0 0 1 9
}
1 0 1 0 10
1 0 1 1 11
1)
1 1 0 0 12
[
1 1 0 1 13
~
1 1 1 0 14
]
1 1 1 1 15
\
In the event that an MS receives a code where a symbol is not
represented in the above table then the MS shall display the character
shown in the main default 7 bit alphabet table in section 6.2.1
1 ) This code value is reserved for the extension to another extension
table. On receipt of this code, a receiving entity shall display a space
until another extension table is defined.
2 ) This code represents the EURO currency symbol. The code value is
that used for the character `e'. Therefore a receiving entity which is
incapable of displaying the EURO currency symbol will display the
character `e' instead.
6.2.2 8 bit data
Bits per character: 8
SMS User Data Length meaning: Number of octets
CBS/USSD pad character: CR
Character table: User Specific
6.2.3 UCS2
Bits per character: 16
SMS User Data Length meaning: Number of octets
CBS/USSD pad character: CR
Character table: ISO/IEC10646 [10 ]
Annex A (Informative):
Document change history
SMG# TDoc SPEC VERS NEW_VERS CR REV PHASE CAT WORKITEM SUBJECT
s25 096/98 03.38 5.6.0 6.0.0 A015
R97
SIM toolkit security Class 2 SIM Data download message handling
s26 291/98 03.38 6.0.0 7.0.0 A016
R98
TEI 7 bit default alphabet extensions
History
Document history
July 1998 Not For Publication
PAGE
styleref ZA GSM 03.38 V7.0.0 (1998-07)
PAGE 20
styleref ZGSM GSM 03.38 version 7.0.0 Release 1998
TD & lt; & gt;
GSM 07.07 V7.0.0 (1998-07)
European Standard (Telecommunications series)
Digital cellular telecommunications system (Phase 2+);
AT command set for GSM Mobile Equipment (ME)
(GSM 07.07 version 7.0.0 Release 1998)
SMG version only, not for publication
Reference
DTS/SMG-040707Q7 (8hc03000.PDF)
Keywords
Digital cellular telecommunications system, Global System for Mobile
communications (GSM)
ETSI Secretariat
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
secretariat@etsi.fr
http://www.etsi.fr
http://www.etsi.org
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 1998.
All rights reserved.
Contents
TOC \o Intellectual Property Rights GOTOBUTTON _Toc425648157
PAGEREF _Toc425648157 6
Foreword GOTOBUTTON _Toc425648158 PAGEREF _Toc425648158 6
Introduction GOTOBUTTON _Toc425648159 PAGEREF _Toc425648159 6
1 Scope GOTOBUTTON _Toc425648160 PAGEREF _Toc425648160 7
2 References GOTOBUTTON _Toc425648161 PAGEREF _Toc425648161 7
3 Abbreviations and definitions GOTOBUTTON _Toc425648162 PAGEREF
_Toc425648162 9
3.1 Abbreviations GOTOBUTTON _Toc425648163 PAGEREF _Toc425648163 9
3.2 Definitions GOTOBUTTON _Toc425648164 PAGEREF _Toc425648164 10
4 AT command syntax GOTOBUTTON _Toc425648165 PAGEREF _Toc425648165
10
4.1 Command line GOTOBUTTON _Toc425648166 PAGEREF _Toc425648166 10
4.2 Information responses and result codes GOTOBUTTON _Toc425648167
PAGEREF _Toc425648167 11
4.3 ITU-T V.25ter [14] TE-TA interface commands GOTOBUTTON
_Toc425648168 PAGEREF _Toc425648168 11
5 General commands GOTOBUTTON _Toc425648169 PAGEREF _Toc425648169
12
5.1 Request manufacturer identification +CGMI GOTOBUTTON _Toc425648170
PAGEREF _Toc425648170 12
5.2 Request model identification +CGMM GOTOBUTTON _Toc425648171
PAGEREF _Toc425648171 13
5.3 Request revision identification +CGMR GOTOBUTTON _Toc425648172
PAGEREF _Toc425648172 13
5.4 Request product serial number identification +CGSN GOTOBUTTON
_Toc425648173 PAGEREF _Toc425648173 14
5.5 Select TE character set +CSCS GOTOBUTTON _Toc425648174 PAGEREF
_Toc425648174 14
5.6 Request international mobile subscriber identity +CIMI GOTOBUTTON
_Toc425648175 PAGEREF _Toc425648175 15
5.7 Multiplexing mode +CMUX $(MUX MS-TE)$ GOTOBUTTON _Toc425648176
PAGEREF _Toc425648176 15
5.8 ITU-T V.25ter [14] generic TA control commands GOTOBUTTON
_Toc425648177 PAGEREF _Toc425648177 17
5.9 PCCA STD-101 [17] select wireless network +WS46 GOTOBUTTON
_Toc425648178 PAGEREF _Toc425648178 17
5.10 Informative examples GOTOBUTTON _Toc425648179 PAGEREF
_Toc425648179 18
6 Call control commands and methods GOTOBUTTON _Toc425648180
PAGEREF _Toc425648180 19
6.1 Select type of address +CSTA GOTOBUTTON _Toc425648181 PAGEREF
_Toc425648181 19
6.2 ITU-T V.25ter [14] dial command D GOTOBUTTON _Toc425648182
PAGEREF _Toc425648182 19
6.3 Direct dialling from phonebooks GOTOBUTTON _Toc425648183
PAGEREF _Toc425648183 20
6.4 Call mode +CMOD GOTOBUTTON _Toc425648184 PAGEREF _Toc425648184
21
6.5 Hangup call +CHUP GOTOBUTTON _Toc425648185 PAGEREF
_Toc425648185 21
6.6 Alternating mode call control method GOTOBUTTON _Toc425648186
PAGEREF _Toc425648186 22
6.7 Select bearer service type +CBST GOTOBUTTON _Toc425648187
PAGEREF _Toc425648187 23
6.8 Radio link protocol +CRLP GOTOBUTTON _Toc425648188 PAGEREF
_Toc425648188 25
6.9 Service reporting control +CR GOTOBUTTON _Toc425648189 PAGEREF
_Toc425648189 26
6.10 Extended error report +CEER GOTOBUTTON _Toc425648190 PAGEREF
_Toc425648190 26
6.11 Cellular result codes +CRC GOTOBUTTON _Toc425648191 PAGEREF
_Toc425648191 27
6.12 HSCSD device parameters +CHSD GOTOBUTTON _Toc425648192 PAGEREF
_Toc425648192 28
6.13 HSCSD transparent call configuration +CHST GOTOBUTTON
_Toc425648193 PAGEREF _Toc425648193 28
6.14 HSCSD non-transparent call configuration +CHSN GOTOBUTTON
_Toc425648194 PAGEREF _Toc425648194 29
6.15 HSCSD current call parameters +CHSC GOTOBUTTON _Toc425648195
PAGEREF _Toc425648195 30
6.16 Single numbering scheme +CSNS GOTOBUTTON _Toc425648196 PAGEREF
_Toc425648196 30
6.17 Voice Hangup Control +CVHU $(AT R97)$ GOTOBUTTON _Toc425648197
PAGEREF _Toc425648197 31
6.18 V.120 rate adaption protocol +CV120 GOTOBUTTON _Toc425648198
PAGEREF _Toc425648198 31
6.19 ITU-T V.25ter [14] call control commands GOTOBUTTON _Toc425648199
PAGEREF _Toc425648199 33
6.20 ITU-T V.25ter [14] data compression commands GOTOBUTTON
_Toc425648200 PAGEREF _Toc425648200 33
6.21 Informative examples GOTOBUTTON _Toc425648201 PAGEREF
_Toc425648201 33
7 Network service related commands GOTOBUTTON _Toc425648202 PAGEREF
_Toc425648202 34
7.1 Subscriber number +CNUM GOTOBUTTON _Toc425648203 PAGEREF
_Toc425648203 34
7.2 Network registration +CREG GOTOBUTTON _Toc425648204 PAGEREF
_Toc425648204 35
7.3 Operator selection +COPS GOTOBUTTON _Toc425648205 PAGEREF
_Toc425648205 36
7.4 Facility lock +CLCK GOTOBUTTON _Toc425648206 PAGEREF
_Toc425648206 37
7.5 Change password +CPWD GOTOBUTTON _Toc425648207 PAGEREF
_Toc425648207 39
7.6 Calling line identification presentation +CLIP GOTOBUTTON
_Toc425648208 PAGEREF _Toc425648208 40
7.7 Calling line identification restriction +CLIR GOTOBUTTON
_Toc425648209 PAGEREF _Toc425648209 40
7.8 Connected line identification presentation +COLP GOTOBUTTON
_Toc425648210 PAGEREF _Toc425648210 41
7.9 Closed user group +CCUG GOTOBUTTON _Toc425648211 PAGEREF
_Toc425648211 42
7.10 Call forwarding number and conditions +CCFC GOTOBUTTON
_Toc425648212 PAGEREF _Toc425648212 43
7.11 Call waiting +CCWA GOTOBUTTON _Toc425648213 PAGEREF
_Toc425648213 44
7.12 Call related supplementary services +CHLD GOTOBUTTON
_Toc425648214 PAGEREF _Toc425648214 45
7.13 Call deflection +CTFR GOTOBUTTON _Toc425648215 PAGEREF
_Toc425648215 46
7.14 Unstructured supplementary service data +CUSD GOTOBUTTON
_Toc425648216 PAGEREF _Toc425648216 47
7.15 Advice of Charge +CAOC GOTOBUTTON _Toc425648217 PAGEREF
_Toc425648217 48
7.16 Supplementary service notifications +CSSN GOTOBUTTON
_Toc425648218 PAGEREF _Toc425648218 49
7.17 List current calls +CLCC GOTOBUTTON _Toc425648219 PAGEREF
_Toc425648219 50
7.18 Preferred operator list +CPOL $(AT R97)$ GOTOBUTTON _Toc425648220
PAGEREF _Toc425648220 51
7.19 Read operator names +COPN $(AT R97)$ GOTOBUTTON _Toc425648221
PAGEREF _Toc425648221 52
7.20 Informative examples GOTOBUTTON _Toc425648222 PAGEREF
_Toc425648222 52
8 Mobile Equipment control and status commands GOTOBUTTON
_Toc425648223 PAGEREF _Toc425648223 54
8.1 Phone activity status +CPAS GOTOBUTTON _Toc425648224 PAGEREF
_Toc425648224 55
8.2 Set phone functionality +CFUN GOTOBUTTON _Toc425648225 PAGEREF
_Toc425648225 56
8.3 Enter PIN +CPIN GOTOBUTTON _Toc425648226 PAGEREF _Toc425648226
57
8.4 Battery charge +CBC GOTOBUTTON _Toc425648227 PAGEREF
_Toc425648227 58
8.5 Signal quality +CSQ GOTOBUTTON _Toc425648228 PAGEREF
_Toc425648228 58
8.6 Mobile Equipment control mode +CMEC GOTOBUTTON _Toc425648229
PAGEREF _Toc425648229 59
8.7 Keypad control +CKPD GOTOBUTTON _Toc425648230 PAGEREF
_Toc425648230 60
8.8 Display control +CDIS GOTOBUTTON _Toc425648231 PAGEREF
_Toc425648231 61
8.9 Indicator control +CIND GOTOBUTTON _Toc425648232 PAGEREF
_Toc425648232 62
8.10 Mobile Equipment event reporting +CMER GOTOBUTTON _Toc425648233
PAGEREF _Toc425648233 63
8.11 Select phonebook memory storage +CPBS GOTOBUTTON _Toc425648234
PAGEREF _Toc425648234 64
8.12 Read phonebook entries +CPBR GOTOBUTTON _Toc425648235 PAGEREF
_Toc425648235 65
8.13 Find phonebook entries +CPBF GOTOBUTTON _Toc425648236 PAGEREF
_Toc425648236 66
8.14 Write phonebook entry +CPBW GOTOBUTTON _Toc425648237 PAGEREF
_Toc425648237 67
8.15 Clock +CCLK GOTOBUTTON _Toc425648238 PAGEREF _Toc425648238 67
8.16 Alarm +CALA GOTOBUTTON _Toc425648239 PAGEREF _Toc425648239 68
8.17 Generic SIM access +CSIM GOTOBUTTON _Toc425648240 PAGEREF
_Toc425648240 69
8.18 Restricted SIM access +CRSM GOTOBUTTON _Toc425648241 PAGEREF
_Toc425648241 69
8.19 Secure control command +CSCC GOTOBUTTON _Toc425648242 PAGEREF
_Toc425648242 70
8.20 Alert sound mode +CALM $(AT R97)$ GOTOBUTTON _Toc425648243
PAGEREF _Toc425648243 71
8.21 Ringer sound level +CRSL $(AT R97)$ GOTOBUTTON _Toc425648244
PAGEREF _Toc425648244 72
8.22 Vibrator mode +CVIB $(AT R97)$ GOTOBUTTON _Toc425648245
PAGEREF _Toc425648245 72
8.23 Loudspeaker volume level +CLVL $(AT R97)$ GOTOBUTTON
_Toc425648246 PAGEREF _Toc425648246 73
8.24 Mute control +CMUT $(AT R97)$ GOTOBUTTON _Toc425648247 PAGEREF
_Toc425648247 73
8.25 Accumulated call meter +CACM $(AT R97)$ GOTOBUTTON _Toc425648248
PAGEREF _Toc425648248 73
8.26 Accumulated call meter maximum +CAMM $(AT R97)$ GOTOBUTTON
_Toc425648249 PAGEREF _Toc425648249 74
8.27 Price per unit and currency table +CPUC $(AT R97)$ GOTOBUTTON
_Toc425648250 PAGEREF _Toc425648250 74
8.28 Power class +CPWC GOTOBUTTON _Toc425648251 PAGEREF
_Toc425648251 75
8.29 Informative examples GOTOBUTTON _Toc425648252 PAGEREF
_Toc425648252 76
9 Mobile Equipment errors GOTOBUTTON _Toc425648253 PAGEREF
_Toc425648253 79
9.1 Report Mobile Equipment error +CMEE GOTOBUTTON _Toc425648254
PAGEREF _Toc425648254 79
9.2 Mobile Equipment error result code +CME ERROR GOTOBUTTON
_Toc425648255 PAGEREF _Toc425648255 79
9.3 Informative examples GOTOBUTTON _Toc425648256 PAGEREF
_Toc425648256 81
Annex A (normative): Summary of commands from other standards
GOTOBUTTON _Toc425648257 PAGEREF _Toc425648257 82
Annex B (normative): Summary of result codes GOTOBUTTON _Toc425648258
PAGEREF _Toc425648258 84
Annex C (informative): Commands from TIA IS-101 GOTOBUTTON
_Toc425648259 PAGEREF _Toc425648259 85
C.1 Introduction GOTOBUTTON _Toc425648260 PAGEREF _Toc425648260 85
C.2 Commands GOTOBUTTON _Toc425648261 PAGEREF _Toc425648261 86
C.2.1 Select mode +FCLASS GOTOBUTTON _Toc425648262 PAGEREF
_Toc425648262 86
C.2.2 Buffer threshold setting +VBT GOTOBUTTON _Toc425648263
PAGEREF _Toc425648263 86
C.2.3 Calling number ID presentation +VCID GOTOBUTTON _Toc425648264
PAGEREF _Toc425648264 87
C.2.4 Receive gain selection +VGR GOTOBUTTON _Toc425648265 PAGEREF
_Toc425648265 87
C.2.5 Transmit gain selection +VGT GOTOBUTTON _Toc425648266 PAGEREF
_Toc425648266 87
C.2.6 Initialise voice parameters +VIP GOTOBUTTON _Toc425648267
PAGEREF _Toc425648267 88
C.2.7 Inactivity timer +VIT GOTOBUTTON _Toc425648268 PAGEREF
_Toc425648268 88
C.2.8 Line selection +VLS GOTOBUTTON _Toc425648269 PAGEREF
_Toc425648269 88
C.2.9 Receive data state +VRX GOTOBUTTON _Toc425648270 PAGEREF
_Toc425648270 89
C.2.10 Select compression method +VSM GOTOBUTTON _Toc425648271
PAGEREF _Toc425648271 90
C.2.11 DTMF and tone generation +VTS GOTOBUTTON _Toc425648272
PAGEREF _Toc425648272 90
C.2.12 Tone duration +VTD GOTOBUTTON _Toc425648273 PAGEREF
_Toc425648273 91
C.2.13 Transmit data state +VTX GOTOBUTTON _Toc425648274 PAGEREF
_Toc425648274 91
Annex D (informative): Bibliography GOTOBUTTON _Toc425648275
PAGEREF _Toc425648275 92
Annex E (informative): Mobile originated alternating voice/data call
example GOTOBUTTON _Toc425648276 PAGEREF _Toc425648276 93
Annex F (informative): Mobile terminated voice followed by data call
example GOTOBUTTON _Toc425648277 PAGEREF _Toc425648277 94
Annex G (informative): Voice call example GOTOBUTTON _Toc425648278
PAGEREF _Toc425648278 95
Annex H (informative): Change History GOTOBUTTON _Toc425648279
PAGEREF _Toc425648279 96
History GOTOBUTTON _Toc425648280 PAGEREF _Toc425648280 97
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have
been declared to ETSI. The information pertaining to these essential
IPRs, if any, is publicly available for ETSI members and non-members,
and can be found in ETR 314: " Intellectual Property Rights (IPRs);
Essential, or potentially Essential, IPRs notified to ETSI in respect of
ETSI standards " , which is available free of charge from the ETSI
Secretariat. Latest updates are available on the ETSI Web server
(http://www.etsi.fr/ipr or http://www.etsi.org/ipr).
Pursuant to the ETSI Interim IPR Policy, no investigation, including IPR
searches, has been carried out by ETSI. No guarantee can be given as to
the existence of other IPRs not referenced in ETR 314 (or the updates on
the ETSI Web server) which are, or may be, or may become, essential to
the present document.
Foreword
This ETSI Technical Specification (TS) has been produced by the Special
Mobile Group (SMG) of the European Telecommunications Standards
Institute (ETSI).
This TS specifies the AT command for terminal equipments being used
within the digital cellular telecommunications system.
The contents of this TS is subject to continuing work within SMG and may
change following formal SMG approval. Should SMG modify the contents of
this TS, it will be re-released with an identifying change of release
date and an increase in version number as follows:
Version 7.x.y
where:
7 indicates Release 1998 of GSM Phase 2+
x the second digit is incremented for all other types of changes, i.e.
technical enhancements, corrections, updates, etc.
y the third digit is incremented when editorial only changes have been
incorporated in the specification.
Introduction
The present document includes some references to features which are not
part of the original Phase 2+ release of the GSM Technical
specifications. All subclauses and text which were changed as a result
of these features contain a marker (see table below) relevant to the
particular feature.
The following table lists all new features that were introduced to this
document after version 5.4.0. Changes that were made as corrections to
existing featurers are not listed in this table.
NOTE: following a decision made at ETSI SMG #25 requiring that all
specifications containing a release 98 workitem be release as a version
7.0.0. Consequently, new release 98 features approved at or after ETSI
SMG #25 are found only in the version 7.x.y of the present document.
Feature Designator
Technical enhancement and improvement: New AT-commands $(AT R97)$
Support of Multiplexer according to GSM 07.10 $(MUX MS-TE)$
1 Scope
This Specification specifies a profile of AT commands and recommends
that this profile be used for controlling Mobile Equipment (ME)
functions and GSM network services from a Terminal Equipment (TE)
through Terminal Adaptor (TA). The command prefix +C is reserved for
Digital Cellular in ITU-T Recommendation V.25ter [14]. This TS has also
the syntax details used to construct these extended GSM commands.
Commands from ITU-T Recommendation V.25ter [14] and existing digital
cellular standards (TIA IS-99 [15] and TIA IS-135 [16]) are used
whenever applicable. Some of the new commands are defined such way that
they can be easily applied to ME of networks other than GSM. ITU-T
T.31 [11] and T.32 [12] fax AT commands may be used for GSM fax
transmission from TE. GSM Short Message Service AT commands are defined
in GSM 07.05 [24]. GPRS AT commands are defined in GSM 07.60 [34].This
ETS assumes an abstract architecture comprising a TE (e.g. a computer)
and a ME interfaced by a TA (see figure SEQ Figure figsetup 1 ). The
span of control of the defined commands should allow to handle any
physical implementation that this abstract architecture may lead to:
- TA, ME and TE as three separate entities;
- TA integrated under the ME cover, and the TE implemented as a separate
entity;
- TA integrated under the TE cover, and the ME implemented as a separate
entity;
- TA and ME integrated under the TE cover as a single entity.
The commands described in this ETS may be observed on the link between
the TE and the TA. However, most of the commands retrieve information
about the ME, not about the TA.
Figure SEQ Figure 1 : Setup
Interface between TE and TA is intended to operate over existing serial
(ITU-T Recommendation V.24) cables, infrared link, and all link types
with similar behaviour. For correct operation many of the defined
commands require eight bit data and therefore it is recommended that
TE-TA link is set to eight bits/ byte mode. (For infrared operation
implementation refer informative references IrDA. For embedding AT
commands and data during on-line data state refer TIA-617/ITU-T V.80.)
Interface between TA and ME is dependent on the interface in the ME.
2 References
References may be made to:
a) specific versions of publications (identified by date of publication,
edition number, version number, etc.), in which case, subsequent
revisions to the referenced document do not apply; or
b) all versions up to and including the identified version (identified
by " up to and including " before the version identity); or
c) all versions subsequent to and including the identified version
(identified by " onwards " following the version identity); or
d) publications without mention of a specific version, in which case the
latest version applies.
A non-specific reference to an ETS shall also be taken to refer to later
versions published as an EN with the same number.
[1] GSM 02.02: " Digital cellular telecommunication system (Phase 2+);
Bearer Services (BS) supported by a GSM Public Land Mobile Network
(PLMN) " .
[2] GSM 02.03: " Digital cellular telecommunication system (Phase 2+);
Teleservices supported by a GSM Public Land Mobile Network (PLMN) " .
[3] GSM 02.81: " Digital cellular telecommunication system (Phase 2+);
Line identification supplementary services - Stage 1 " .
[4] GSM 02.82: " Digital cellular telecommunication system (Phase 2+);
Call Forwarding (CF) supplementary services - Stage 1 " .
[5] GSM 02.83: " Digital cellular telecommunication system (Phase 2+);
Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage
1 " .
[6] GSM 02.88: " Digital cellular telecommunication system (Phase 2+);
Call Barring (CB) supplementary services - Stage 1 " .
[7] GSM 03.03: " Digital cellular telecommunication system (Phase 2+);
Numbering, addressing and identification " .
[8] GSM 04.08: " Digital cellular telecommunication system (Phase 2+);
Mobile radio interface layer 3 specification " .
[9] GSM MoU SE.13, GSM MoU Permanent Reference Document SE.13: " GSM
Mobile Network Codes and Names " .
[10] ITU-T Recommendation E.212: " Identification plan for land mobile
stations " .
[11] ITU-T Recommendation T.31: " Asynchronous facsimile DCE control,
service class 1 " .
[12] ITU-T Recommendation T.32: " Asynchronous facsimile DCE control,
service class 2 " .
[13] ITU-T Recommendation T.50: " International Reference Alphabet (IRA)
(Formerly International Alphabet No. 5 or IA5) - Information technology
- 7-bit coded character set for information exchange " .
[14] ITU-T Draft new Recommendation V.25ter: " Serial asynchronous
automatic dialling and control " .
[15] Telecommunications Industry Association TIA IS-99: " Data Services
Option Standard for Wideband Spread Spectrum Digital Cellular System " .
[16] Telecommunications Industry Association TIA IS-135: " 800 MHz
Cellular Systems, TDMA Services, Async Data and Fax " .
[17] Portable Computer and Communications Association PCCA STD-101 Data
Transmission Systems and Equipment: " Serial Asynchronous Automatic
Dialling and Control for Character Mode DCE on Wireless Data Services " .
[18] GSM 04.22: " Digital cellular telecommunication system (Phase 2+);
Radio Link Protocol (RLP) for data and telematic services on the Mobile
Station - Base Station System (MS - BSS) interface and the Base Station
System - Mobile-services Switching Centre (BSS - MSC) interface " .
[19] GSM 02.30: " Digital cellular telecommunication system (Phase 2+);
Man Machine Interface (MMI) of the Mobile Station (MS) " .
[20] GSM 05.08: " Digital cellular telecommunication system (Phase 2+);
Radio subsystem link control " .
[21] GSM 02.85: " Digital cellular telecommunication system (Phase 2+);
Closed User Group (CUG) supplementary services - Stage 1 " .
[22] GSM 02.84: " Digital cellular telecommunication system (Phase 2+);
MultiParty (MPTY) supplementary services - Stage 1 " .
[23] GSM 02.90: " Digital cellular telecommunication system (Phase 2+);
Stage 1 description of Unstructured Supplementary Service Data (USSD) " .
[24] GSM 07.05: " Digital cellular telecommunication system (Phase 2+);
Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE
- DCE) interface for Short Message Service (SMS) and Cell Broadcast
Service (CBS) " .
[25] GSM 03.38: " Digital cellular telecommunication system (Phase 2+);
Alphabet and language specific information " .
[26] GSM 02.24: " Digital cellular telecommunication system (Phase 2+);
Description of Charge Advice Information (CAI) " .
[27] GSM 02.86: " Digital cellular telecommunication system (Phase 2+);
Advice of Charge (AoC) supplementary services - Stage 1 " .
[28] GSM 11.11: " Digital cellular telecommunication system (Phase 2+);
Specification of the Subscriber Identity Module - Mobile Equipment
(SIM-ME) interface " .
[29] GSM 02.34: " Digital cellular telecommunication system (Phase 2+);
High Speed Circuit Switched Data (HSCSD) - Stage 1''.
[30] GSM 02.91: ``Digital cellular telecommunication system (Phase 2+);
Explicit Call Transfer (ECT) supplementary service - Stage 1''.
[31] GSM 02.72: ``Digital cellular telecommunication system (Phase 2+);
Call Deflection (CD) supplementary service - Stage 1''.
[32] ISO/IEC10646: " Universal Multiple-Octet Coded Character Set
(UCS)''; UCS2, 16 bit coding.
[33] GSM 02.22: ``Digital cellular telecommunication system (Phase 2+);
Personalisation of GSM Mobile Equipment (ME) Mobile functionality
specification''.
[34] GSM 07.60: " Digital cellular telecommunication system (Phase 2+);
General requirements on Mobile Stations (MS) supporting General Packet
Radio Bearer Service (GPRS) " .
[35] CCITT Recommendation V.110: " Support of data terminal equipments
(DTEs) with V-Series interfaces by an integrated services digital
network " .
[36] CCITT Recommendation V.120: " Support by an ISDN of data terminal
equipment with V-Series type interfaces with provision for statistical
multiplexing " .
[37] ITU-T Recommendation X.31: " Support of packet mode terminal
equipment by an ISDN " .
[38] GSM 05.05: ``Digital cellular telecommunication system (Phase 2+);
Radio transmission and reception''.
3 Abbreviations and definitions
3.1 Abbreviations
For the purposes of this TS, the following abbreviations apply:
AT ATtention; this two-character abbreviation is always used to start a
command line to be sent from TE to TA
BCD Binary Coded Decimal
ETSI European Telecommunications Standards Institute
HSCSD High Speed Circuit Switched Data
IMEI International Mobile station Equipment Identity
IRA International Reference Alphabet (ITU-T T.50 [13])
IrDA Infrared Data Association
ISO International Standards Organisation
ITU-T International Telecommunication Union - Telecommunications
Standardization Sector
ME Mobile Equipment, e.g. a GSM phone (equal to MS; Mobile Station)
MoU Memorandum of Understanding (GSM operator joint)
PCCA Portable Computer and Communications Association
RDI Restricted Digital Information
RLP Radio Link Protocol
SIM Subscriber Identity Module
TA Terminal Adaptor, e.g. a GSM data card (equal to DCE; Data Circuit
terminating Equipment)
TE Terminal Equipment, e.g. a computer (equal to DTE; Data Terminal
Equipment)
TIA Telecommunications Industry Association
UDI Unrestricted Digital Information
3.2 Definitions
For the purposes of this TS, the following syntactical definitions apply
(refer also clause 4):
& lt; CR & gt; Carriage return character, which value is specified with command
S3.
& lt; LF & gt; Linefeed character, which value is specified with command S4.
& lt; ... & gt; Name enclosed in angle brackets is a syntactical element. Brackets
themselves do not appear in the command line.
[...] Optional subparameter of a command or an optional part of TA
information response is enclosed in square brackets. Brackets themselves
do not appear in the command line. When subparameter is not given in
parameter type commands, new value equals to its previous value. In
action type commands, action should be done on the basis of the
recommended default setting of the subparameter.
underline Underlined defined subparameter value is the recommended
default setting of this subparameter. In parameter type commands, this
value should be used in factory settings which are configured by
V.25ter [14] command & F0. In action type commands, this value should be
used when subparameter is not given.
4 AT command syntax
This clause summarizes general aspects on AT commands and issues related
to them. For further information refer ITU-T Recommendation
V.25ter [14].
4.1 Command line
See figure SEQ Figure figatline 2 for general structure of a command
line. Standardized basic commands are found only in V.25ter [14]. GSM
commands use syntax rules of extended commands. Every extended command
has a test command (trailing =?) to test the existence of the command
and to give information about the type of its subparameters. Parameter
type commands also have a read command (trailing ?) to check the current
values of subparameters. Action type commands do not store the values of
any of their possible subparameters, and therefore do not have a read
command.
Figure SEQ Figure 2 : Basic structure of a command line
If verbose responses are enabled with command V1 and all commands in a
command line has been performed successfully, result code
& lt; CR & gt; & lt; LF & gt; OK & lt; CR & gt; & lt; LF & gt; is sent from the TA to the TE. If numeric responses
are enabled with command V0, result code 0 & lt; CR & gt; is sent instead.
If verbose responses are enabled with command V1 and subparameter values
of a command are not accepted by the TA (or command itself is invalid,
or command cannot be performed for some reason), result code
& lt; CR & gt; & lt; LF & gt; ERROR & lt; CR & gt; & lt; LF & gt; is sent to the TE and no subsequent commands in
the command line are processed. If numeric responses are enabled with
command V0, result code 4 & lt; CR & gt; is sent instead. ERROR (or 4) response may
be replaced by +CME ERROR: & lt; err & gt; (refer clause 9) when command was not
processed due to an error related to ME operation.
4.2 Information responses and result codes
The TA response for the example command line of figure SEQ Figure
figatline 2 could be as shown in figure SEQ Figure figatresponse 3
. Here, verbose response format is enabled with command V1. If numeric
format V0 would have been used, & lt; CR & gt; & lt; LF & gt; headers of information
responses would have been left out and final result code changed to
0 & lt; CR & gt; .
Figure SEQ Figure 3 : Response to a command line
So called intermediate result codes inform about progress of TA
operation (e.g. connection establishment CONNECT), and so called
unsolicited result codes indicate occurrence of an event not directly
associated with issuance of a command from TE (e.g. ring indication
RING).
4.3 ITU-T V.25ter [14] TE-TA interface commands
Table SEQ Table tetaint 1 summarizes V.25ter [14] commands relating
to command line and response formatting, and TA-TE interface operation.
All are applicable to GSM terminals.
Table SEQ Table 1 : V.25ter commands relating to TE-TA interface
Command Section Impl. Use in GSM
S3=[ & lt; value & gt; ] 6.2.1 mand. command line termination character (mandatory
default setting IRA 13)
S4=[ & lt; value & gt; ] 6.2.2 mand. response formatting character (recommended
default IRA 10)
S5=[ & lt; value & gt; ] 6.2.3 mand. command line editing character (recommended
default IRA 8)
E[ & lt; value & gt; ] 6.2.4 mand. command echo (recommended default 1 i.e. TA
echoes commands back)
Q[ & lt; value & gt; ] 6.2.5 mand. result code suppression (recommended default 0
i.e. TA transmits result codes)
V[ & lt; value & gt; ] 6.2.6 mand. TA response format (recommended default 1 i.e.
verbose format)
X[ & lt; value & gt; ] 6.2.7 mand. defines CONNECT result code format; values
manufacturer specific
& C[ & lt; value & gt; ] 6.2.8 mand. determines how ITU-T V.24 circuit 109 (or
equivalent) relates to the detection of received line signal from remote
end (recommended default 1 i.e. 109 operation relates to detection of
received signal)
& D[ & lt; value & gt; ] 6.2.9 mand. determines how TA responds when ITU-T V.24
circuit 108/2 (or equivalent) is changed from ON to OFF condition during
online data state
+IPR=[ & lt; value & gt; ] 6.2.10 opt. fixed TE data rate (recommended default 0
i.e. automatic detection)
+ICF=[ & lt; format & gt; [, & lt; parity & gt; ]] 6.2.11 opt. TE-TA character framing
(recommended default 3,3 i.e. eight data bits, no parity, 1 stop bit)
+IFC=[ & lt; by_te & gt; [, & lt; by_ta & gt; ]] 6.2.12 opt. TE-TA local flow control
(recommended default 2,2 i.e. TE uses ITU-T V.24 circuit 133 (or
equivalent), and TA circuit 106 (or equivalent))
+ILRR=[ & lt; value & gt; ] 6.2.13 opt. determines whether the used local TE-TA data
rate is informed using intermediate result code +ILRR: & lt; rate & gt; before
going online data state after call answering or originating
5 General commands
ITU-T Recommendation V.25ter [14] includes " Generic DCE Control "
commands with the prefix +G. These commands are for the identification
of the TA. Four of those commands are adapted here to be the
identification commands of the ME. Syntax is otherwise similar but the
prefix is +CG. TIA IS-99 [15] uses same commands for base station
identification.
5.1 Request manufacturer identification +CGMI
Table SEQ Table 2 : +CGMI action command syntax
Command Possible response(s)
+CGMI & lt; manufacturer & gt;
+CME ERROR: & lt; err & gt;
+CGMI=?
Description
Execution command causes the TA to return one or more lines of
information text & lt; manufacturer & gt; , determined by the ME manufacturer,
which is intended to permit the user of the TA to identify the
manufacturer of the ME to which it is connected to. Typically, the text
will consist of a single line containing the name of the manufacturer,
but manufacturers may choose to provide more information if desired.
Refer subclause 9.2 for possible & lt; err & gt; values.
Defined values
& lt; manufacturer & gt; : the total number of characters, including line
terminators, in the information text shall not exceed 2048 characters.
Text shall not contain the sequence 0 & lt; CR & gt; or OK & lt; CR & gt;
Implementation
Optional.
5.2 Request model identification +CGMM
Table SEQ Table 3 : +CGMM action command syntax
Command Possible response(s)
+CGMM & lt; model & gt;
+CME ERROR: & lt; err & gt;
+CGMM=?
Description
Execution command causes the TA to return one or more lines of
information text & lt; model & gt; , determined by the ME manufacturer, which is
intended to permit the user of the TA to identify the specific model of
the ME to which it is connected to. Typically, the text will consist of
a single line containing the name of the product, but manufacturers may
choose to provide more information if desired. Refer to subclause 9.2
for possible & lt; err & gt; values.
Defined values
& lt; model & gt; : the total number of characters, including line terminators, in
the information text shall not exceed 2048 characters.
Text shall not contain the sequence 0 & lt; CR & gt; or OK & lt; CR & gt;
Implementation
Optional.
5.3 Request revision identification +CGMR
Table SEQ Table 4 : +CGMR action command syntax
Command Possible response(s)
+CGMR & lt; revision & gt;
+CME ERROR: & lt; err & gt;
+CGMR=?
Description
Execution command causes the TA to return one or more lines of
information text & lt; revision & gt; , determined by the ME manufacturer, which is
intended to permit the user of the TA to identify the version, revision
level or date, or other pertinent information of the ME to which it is
connected to. Typically, the text will consist of a single line
containing the version of the product, but manufacturers may choose to
provide more information if desired. Refer subclause 9.2 for possible
& lt; err & gt; values.
Defined values
& lt; revision & gt; : the total number of characters, including line terminators,
in the information text shall not exceed 2048 characters.
Text shall not contain the sequence 0 & lt; CR & gt; or OK & lt; CR & gt;
Implementation
Optional.
5.4 Request product serial number identification +CGSN
Table SEQ Table 5 : +CGSN action command syntax
Command Possible response(s)
+CGSN & lt; sn & gt;
+CME ERROR: & lt; err & gt;
+CGSN=?
Description
Execution command causes the TA to return one or more lines of
information text & lt; sn & gt; , determined by the ME manufacturer, which is
intended to permit the user of the TA to identify the individual ME to
which it is connected to. Typically, the text will consist of a single
line containing the IMEI (International Mobile station Equipment
Identity; refer GSM 03.03 [7]) number of the ME, but manufacturers may
choose to provide more information if desired. Refer subclause 9.2 for
possible & lt; err & gt; values.
Defined values
& lt; sn & gt; : the total number of characters, including line terminators, in the
information text shall not exceed 2048 characters.
Text shall not contain the sequence 0 & lt; CR & gt; or OK & lt; CR & gt;
Implementation
Optional.
5.5 Select TE character set +CSCS
Table SEQ Table 6 : +CSCS parameter command syntax
Command Possible response(s)
+CSCS=[ & lt; chset & gt; ]
+CSCS? +CSCS: & lt; chset & gt;
+CSCS=? +CSCS: (list of supported & lt; chset & gt; s)
Description
Set command informs TA which character set & lt; chset & gt; is used by the TE. TA
is then able to convert character strings correctly between TE and ME
character sets.
When TA-TE interface is set to 8-bit operation and used TE alphabet is
7-bit, the highest bit shall be set to zero.
NOTE: It is manufacturer specific how the internal alphabet of ME is
converted to/from the TE alphabet.
Read command shows current setting and test command displays conversion
schemes implemented in the TA.
Defined values
& lt; chset & gt; (conversion schemes not listed here can be defined by
manufacturers):
" GSM " GSM default alphabet (GSM 03.38 subclause 6.2.1); this setting
causes easily software flow control (XON/XOFF) problems
" HEX " character strings consist only of hexadecimal numbers from 00 to
FF; e.g. " 032FE6 " equals three 8-bit characters with decimal values 3,
47 and 230; no conversions to the original ME character set shall be
done.
NOTE: If ME is using GSM default alphabet, its characters shall be
padded with 8th bit (zero) before converting them to hexadecimal numbers
(i.e. no SMS-style packing of 7-bit alphabet).
" IRA " international reference alphabet (ITU-T T.50 [13])
" PCCPxxx " PC character set Code Page xxx
" PCDN " PC Danish/Norwegian character set
" UCS2 " 16-bit universal multiple-octet coded character set (ISO/IEC10646
[32]); UCS2 character strings are converted to hexadecimal numbers from
0000 to FFFF; e.g. " 004100620063 " equals three 16-bit characters with
decimal values 65, 98 and 99, $(AT R97)$
" 8859-n " ISO 8859 Latin n (1-6) character set
" 8859-C " ISO 8859 Latin/Cyrillic character set
" 8859-A " ISO 8859 Latin/Arabic character set
" 8859-G " ISO 8859 Latin/Greek character set
" 8859-H " ISO 8859 Latin/Hebrew character set
Implementation
Mandatory when a command using the setting of this command is
implemented.
5.6 Request international mobile subscriber identity +CIMI
Table SEQ Table 7 : +CIMI action command syntax
Command Possible response(s)
+CIMI & lt; IMSI & gt;
+CME ERROR: & lt; err & gt;
+CIMI=?
Description
Execution command causes the TA to return & lt; IMSI & gt; , which is intended to
permit the TE to identify the individual SIM which is attached to ME.
Refer subclause 9.2 for possible & lt; err & gt; values.
Defined values
& lt; IMSI & gt; : International Mobile Subscriber Identity (string without double
quotes)
Implementation
Optional.
5.7 Multiplexing mode +CMUX $(MUX MS-TE)$
Table SEQ Table 8 : +CMUX parameter command syntax
Command Possible response(s)
+CMUX= & lt; mode & gt; [, & lt; subset & gt; [,
& lt; port_speed & gt; [, & lt; N1 & gt; [, & lt; T1 & gt;
[, & lt; N2 & gt; [, & lt; T2 & gt; [, & lt; T3 & gt;
[, & lt; k & gt; ]]]]]]]] +CME ERROR: & lt; err & gt;
+CMUX? +CMUX: & lt; mode & gt; ,[ & lt; subset & gt; ], & lt; port_speed & gt; ,
& lt; N1 & gt; , & lt; T1 & gt; , & lt; N2 & gt; , & lt; T2 & gt; , & lt; T3 & gt; [, & lt; k & gt; ]
+CME ERROR: & lt; err & gt;
+CMUX=? +CMUX: (list of supported & lt; mode & gt; s),(list of supported
& lt; subset & gt; s),(list of supported & lt; port_speed & gt; s),(list of supported
& lt; N1 & gt; s),(list of supported & lt; T1 & gt; s),(list of supported & lt; N2 & gt; s),(list of
supported & lt; T2 & gt; s),(list of supported & lt; T3 & gt; s),(list of supported & lt; k & gt; s)
Description
This command is used to enable/disable the GSM 07.10 multiplexing
protocol control channel. Refer to subclause 9.2 for possible & lt; err & gt;
values. The AT command sets parameters for the Control Channel. If the
parameters are left out, the default value is used.
Read command returns the current mode and the settings.
Test command returns the supported modes and parameters.
It is recommended that the ME/TA/TE should autobaud to the +CMUX command
up to and including an interface speed of 9600 bits/s.
The OK or +CME ERROR: & lt; err & gt; response is returned at the speed of the
+CMUX command prior to entering & lt; mode & gt; .
It is recommended that whenever the multiplexor control channel is
released the ME/TA/TE should assume an interface rate of up to and
including 9600 bits/s for auto bauding purposes irrespective of any
previous higher speed having been selected.
If a +CMUX command is issued whilst in any multiplexor mode then that
+CMUX command shall be ignored and the ME/TA shall return an +CME ERROR:
& lt; err & gt; response.
Defined values
& lt; operation & gt; (multiplexor Transparency Mechanism)
0 Basic option
1 Advanced option
& lt; subset & gt; :
This parameter defines the way in which the multiplexor control channel
is set up. A virtual channel may subsequently be set up differently but
in the absence of any negotiation for the settings of a virtual channel,
the virtual channel shall be set up according to the control channel
& lt; subset & gt; setting.
0 UIH frames used only
1 UI frames used only
2 I frames used only
Default value: 0
& lt; port_speed & gt; (transmission rate):
1 9 600 bit/s
2 19 200 bit/s
3 38 400 bit/s
4 57 600 bit/s
5 115 200 bit/s
6 230 400 bits/s
& lt; N1 & gt; (maximum frame size):
1- 32768
default Value : 31 (64 if Advanced option is used)
& lt; T1 & gt; (acknowledgement timer in units of ten milliseconds):
1-255, where 10 is default (100 ms)
& lt; N2 & gt; (maximum number of re-transmissions):
0-100, where 3 is default
& lt; T2 & gt; (response timer for the multiplexor control channel in units of
ten milliseconds):
2-255, where 30 is default (300 ms)
NOTE: T2 must be longer than T1.
& lt; T3 & gt; (wake up response timer in seconds):
1-255, where 10 is default
& lt; k & gt; (window size, for Advanced operation with Error Recovery options):
1-7, where 2 is default
Implementation
Mandatory, if GSM 07.10 supported in the ME/TA.
5.8 ITU-T V.25ter [14] generic TA control commands
Table SEQ Table 9 : V.25ter generic TA control commands
Command Section Impl. Use in GSM
Z[ & lt; value & gt; ] 6.1.1 mand. TA sets all parameters to their defaults as
specified by a user memory profile or by the manufacturer, and resets TA
& F[ & lt; value & gt; ] 6.1.2 mand. TA sets all parameters to their defaults as
specified by the manufacturer
I[ & lt; value & gt; ] 6.1.3 opt. request manufacturer specific information about
the TA (software cannot use this command to determine the capabilities
of a TA)
+GMI 6.1.4 mand. request TA manufacturer identification (may equal to
+CGMI)
+GMM 6.1.5 mand. request TA model identification (may equal to +CGMM)
+GMR 6.1.6 mand. request TA revision identification (may equal to +CGMR)
+GSN 6.1.7 opt. request TA serial number identification (may equal to
+CGSN)
+GOI 6.1.8 opt. request ISO system global object identification of the
TA (general format defined in ITU-T Recommendation X.208; encoding rules
in ITU-T Recommendation X.209)
+GCAP 6.1.9 mand. request overall capabilities of TA; the response code
for a TA building on this document shall be +CGSM
+GCI= & lt; T.35 & gt; 6.1.10 opt. selects the country of installation for the TA
using ITU-T Recommendation T.35 Annex A country codes
5.9 PCCA STD-101 [17] select wireless network +WS46
PCCA STD-101 [17] includes a command to select the cellular network
(Wireless Data Service; WDS) to operate with the TA. PCCA calls this as
WDS-Side Stack Selection. This command may be used when TA is asked to
indicate the networks in which it can operate.
Table SEQ Table 10 : +WS46 parameter command syntax
Command Possible response(s)
+WS46=[ & lt; n & gt; ]
+WS46? & lt; n & gt;
+WS46=? (list of supported & lt; n & gt; s)
Description
Set command selects to WDS side stack & lt; n & gt; to be used by the TA. Read
command shows current setting and test command displays side stacks
implemented in the TA.
Defined values
& lt; n & gt; :
12 GSM digital cellular
refer PCCA STD-101 [17] for other values
Implementation
Mandatory in PCCA STD-101, but optional for GSM.
5.10 Informative examples
When beginning to build a communication link, a general TE application
controlling a TA needs to determine the TA and the ME to which it is
connected. V.25ter [14] has seven commands for TA identification from
which four are mandatory to be implemented in a TA. An example of this
command sequence requesting manufacturer (+GMI), model (+GMM), revision
(+GMR) and serial number (+GSN) information would be:
AT+GMI
Manufacturer ABC
OK
AT+GMM
GSM Ultimate Data Device
OK
AT+GMR
1.00
OK
AT+GSN
987612345-123
OK
The maximum lengths of the information responses are defined to be 2048
characters, but it is recommended that they are kept as simple as in the
example. The serial number command is defined as optional. Another
optional command is Global Object Identification command (+GOI) which
should return the object identifiers of ITU-T Recommendation X.208 as
numeric strings delimited by periods. The Complete Capabilities List
command (+GCAP) should indicate the major capability areas of the TA.
The support of different areas is presented in the response of +GCAP
command. Each area may be presented by the selection command name of a
specific capability area (e.g. +FCLASS for fax support) or some other
predefined response. For instance, a GSM TA with fax capabilities could
respond as follows:
AT+GCAP
+GCAP: +CGSM,+FCLASS,+W
OK
The first supported area in the response is presented with +CGSM. It is
the response text to show that some or all GSM commands of this ETS are
supported. Second response text (+FCLASS) informs that some fax or voice
capabilities are present, and the third text (+W) about the presence of
wireless commands as specified by PCCA STD-101 [17]. Command +FCLASS=?
(refer e.g. ITU-T T.31 [11] and T.32 [12]) should be used to query the
supported fax capabilities and +WS46=? to query the wireless data
services available:
AT+FCLASS=?;+WS46=?
0,1,2,2.0
(12)
OK
The TA of this example supports GSM data services, and fax service class
1 (TIA-578-A), 2 (manufacturer specific) and 2.0 (ITU-T T.32 [12]/
TIA-592).
This ETS defines commands for ME identification which are similar to
those for TA identification in V.25ter [14], for an example:
AT+CGMI
Mobile Manufacturer XYZ
OK
AT+CGMM
GSM Phone 1234
OK
AT+CGMR
1.00
OK
AT+CGSN
123456121234561
OK
Manufacturer, model and version commands work similarly as for TA,
except that the serial number query returns the International Mobile
Station Equipment Identity (IMEI) number. IMEI is fifteen digits long
and consists of a type approval code, a final assembly code, a serial
number and a spare digit (refer GSM 03.03 [7]). When the TA is
implemented inside ME, the responses for both TA and ME queries will
most likely follow the responses of ME identification.
6 Call control commands and methods
This clause describes the control of GSM calls. Normal data and fax call
control is done as in ITU-T Recommendations V.25ter [14], T.31 [11] and
T.32 [12]. For voice call originating, refer subclause " ITU-T V.25ter
dial command D " .
6.1 Select type of address +CSTA
Table SEQ Table 11 : +CSTA parameter command syntax
Command Possible response(s)
+CSTA=[ & lt; type & gt; ]
+CSTA? +CSTA: & lt; type & gt;
+CSTA=? +CSTA: (list of supported & lt; type & gt; s)
Description
Set command selects the type of number for further dialling commands (D)
according to GSM specifications. Test command returns values supported
by the TA as a compound value.
Defined values
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7); default 145 when dialling string includes
international access code character " + " , otherwise 129
Implementation
Mandatory when other than default value allowed.
6.2 ITU-T V.25ter [14] dial command D
V.25ter [14] dial command D lists characters that may be used in a
dialling string for making a call or controlling supplementary services
in accordance with GSM 02.30 [19]. Their use in GSM is listed in this
subclause, as well as new dial modifiers applicable only to GSM are
introduced. For a ME supporting AT commands only, it is mandatory to
support the control of supplementary services in accordance with GSM
02.30 through the dial command or through the specific supplementary
service commands (+CCFC, +CLCK, etc.), where GSM 02.30 identifies the
supplementary services as mandatory.
V.25ter dialling digits
1 2 3 4 5 6 7 8 9 0 * # + A B C (implementation of these characters is
mandatory for GSM)
D (implementation of this character is optional for GSM, and it is
ignored)
V.25ter modifier characters
, (implementation of this character is mandatory for GSM, but it may be
ignored)
T P (implementation of these characters is mandatory for GSM, but they
are ignored)
! W @ (implementation of these characters is optional for GSM, and they
are ignored)
V.25ter semicolon character
In GSM, when semicolon character is given after dialling digits (or
modifiers), a voice call originated to the given address. TA returns to
command state immediately (or after possible +COLP result code; refer
subclause " Connected line identification presentation +COLP " ). Refer
Annex G for a detailed example.
GSM modifier characters
& gt; (refer subclause " Direct dialling from phonebooks " )
I or i (override the CLIR supplementary service subscription default
value for this call; I = invocation (restrict CLI presentation) and
i = suppression (allow CLI presentation); refer subclause " Calling line
identification restriction +CLIR " )
G or g (control the CUG supplementary service information for this call;
uses index and info values set with command +CCUG; refer subclause
" Closed user group +CCUG " )
6.3 Direct dialling from phonebooks
GSM ME and SIM can contain phonebooks which have a phone number and an
alphanumeric field for each phonebook entry location. The use of
V.25ter [14] dialling command ensures that direct dialling from ME and
SIM phonebook is possible through ordinary communications software which
just gives the phone number field to be filled and then use the D
command to originate the call. Available memories may be queried with
Select Phonebook Storage test command +CPBS=?, and location range for
example with Read Phonebook Entries test command +CPBR=?.
Execute commands
1. D & gt; & lt; str & gt; [I][G][;] originate call to phone number which corresponding
alphanumeric field is & lt; str & gt; (if possible, all available memories should
be searched for the correct entry)
2. D & gt; mem & lt; n & gt; [I][G][;] originate call to phone number in memory mem entry
location & lt; n & gt; (available memories may be queried with Select Phonebook
Storage test command +CPBS=?; mem could be e.g. ME)
3. D & gt; & lt; n & gt; [I][G][;] originate call to phone number in entry location & lt; n & gt;
(it is manufacturer specific which memory storage of ME, SIM and TA is
used; command Select Phonebook Memory Storage +CPBS setting is
recommended to be used)
Semicolon character shall be added when voice call is originated. CLIR
and CUG per call base modifiers may also be present.
Responses
Possible error responses include +CME ERROR: & lt; err & gt; when error is related
to ME functionality. Refer subclause 9.2 for possible error values.
Otherwise TA responses can have values defined by V.25ter [14] and
commands Service Reporting Control +CR and Connected Line Identification
Presentation +COLP. Detailed error report of an unsuccessful originated
call failed in a GSM network error can be obtained with command Extended
Error Report +CEER (if implemented).
Defined values
& lt; str & gt; : string type value, which should equal to an alphanumeric field in
at least one phonebook entry in the searched memories; used character
set should be the one selected with Select TE Character Set +CSCS
& lt; n & gt; : integer type memory location should be in the range of locations
available in the memory used
Implementation
Mandatory when direct dialling is implemented. Also phonebook commands
implementation is required.
6.4 Call mode +CMOD
Table SEQ Table 12 : +CMOD parameter command syntax
Command Possible response(s)
+CMOD=[ & lt; mode & gt; ]
+CMOD? +CMOD: & lt; mode & gt;
+CMOD=? +CMOD: (list of supported & lt; mode & gt; s)
Description
Set command selects the call mode of further dialling commands (D) or
for next answering command (A). Mode can be either single or alternating
(in this ETS, terms " alternating mode " and " alternating call " refer to
all GSM bearer and teleservices that incorporate more than one basic
service (voice, data, fax) within one call). When single mode is
selected the call originating and hangup procedures are similar to
procedures specified in ITU-T Recommendations V.25ter [14], T.31 [11]
and T.32 [12]. In GSM there can be voice followed by data (refer
GSM 02.02 [1]), alternating voice/data (refer GSM 02.02 [1]) and
alternating voice/fax calls (refer GSM 02.03 [2]). Refer next two
subclauses for alternating call control methods.
Test command returns values supported by the TA as a compound value.
NOTE: +CMOD shall be set to zero after a successfully completed
alternating mode call. It shall be set to zero also after a failed
answering. The power-up, factory ( & F) and user resets (Z) shall also set
the value to zero. This reduces the possibility that alternating mode
calls are originated or answered accidentally.
Defined values
& lt; mode & gt; :
0 single mode
1 alternating voice/fax (teleservice 61)
2 alternating voice/data (bearer service 61)
3 voice followed by data (bearer service 81)
also all other values below 128 are reserved by this ETS
Implementation
Mandatory when alternating mode calls are implemented in the TA.
6.5 Hangup call +CHUP
Table SEQ Table 13 : +CHUP action command syntax
Command Possible response(s)
+CHUP
+CHUP=?
Description
Execution command causes the TA to hangup the current GSM call of the
ME.
NOTE: The purpose of this command is not to replace the V.25ter [14]
command H, but to give an assured procedure to terminate an alternating
mode call. Refer next subclause.
Implementation
Mandatory when alternating mode calls implemented in the TA.
6.6 Alternating mode call control method
This subclause describes the procedure to handle alternating mode calls
with AT commands. Procedures are mandatory when alternating mode calls
are implemented in the TA.
NOTE: ATH and drop DTR will not necessarily cause a hangup from voice
mode. If the +CVHU $(AT R97)$ is implemented the behaviour shall be
controlled by its setting.
Voice followed by data call (bearer service 81)
Figure SEQ Figure figvoiceflwddata 4 shows commands to start the
call, to switch from voice to data (In-Call Modification) and to hang up
the call. +CMOD and +FCLASS commands indicate the current settings
before dialling or answering command, not that they shall be given just
before D or A command. Refer subclause " Cellular result codes +CRC " for
possible +CRING result code values. Refer Annex F for a detailed
example.
Figure SEQ Figure 4 : Voice followed by data call
Voice/ data call (bearer service number 61)
Figure SEQ Figure figvoicedata 5 shows the commands to start the call,
to switch between modes (In-Call Modification) and to hang up the call.
+CMOD and +FCLASS commands indicate the current settings before dialling
or answering command, not that they shall be given just before D or A
command. Refer subclause " Cellular result codes +CRC " for possible
+CRING result code values. Refer Annex E for a detailed example.
Figure SEQ Figure 5 : Alternating voice and data call
Voice/ fax call (teleservice number 61)
Figure SEQ Figure figvoicefaxNEW 6 shows the commands to start the
call, to switch between modes (In-Call Modification) and to hang up the
call. +CMOD and +FCLASS commands indicate the current settings before
dialling or answering command, not that they shall be given just before
D or A command. The parameter " x " of +FCLASS command can be 1, 1.0, 2 or
2.0.
NOTE: The transition from fax mode to voice mode is for further study.
Figure SEQ Figure 6 : Alternating voice and fax call
6.7 Select bearer service type +CBST
Table SEQ Table 14 : +CBST parameter command syntax
Command Possible response(s)
+CBST=[ & lt; speed & gt; [, & lt; name & gt; [, & lt; ce & gt; ]]]
+CBST? +CBST: & lt; speed & gt; , & lt; name & gt; , & lt; ce & gt;
+CBST=? +CBST: (list of supported & lt; speed & gt; s),(list of supported
& lt; name & gt; s),(list of supported & lt; ce & gt; s)
Description
Set command selects the bearer service & lt; name & gt; with data rate & lt; speed & gt; ,
and the connection element & lt; ce & gt; to be used when data calls are
originated (refer GSM 02.02 [1]). Values may also be used during mobile
terminated data call setup, especially in case of single numbering
scheme calls (refer +CSNS).
Test command returns values supported by the TA as compound values.
Defined values
NOTE: The default values of the subparameters are manufacturer specific
since they depend on the purpose of the device and data services
provided by it. Not all combinations of these subparameters are
supported by GSM (refer GSM 02.02 [1]).
& lt; speed & gt; :
0 autobauding (automatic selection of the speed; this setting is
possible in case of 3.1 kHz modem and non-transparent service)
1 300 bps (V.21)
2 1200 bps (V.22)
3 1200/75 bps (V.23)
4 2400 bps (V.22bis)
5 2400 bps (V.26ter)
6 4800 bps (V.32)
7 9600 bps (V.32)
12 9600 bps (V.34)
14 14400 bps (V.34)
15 19200 bps (V.34)
16 28800 bps (V.34)
34 1200 bps (V.120)
36 2400 bps (V.120)
38 4800 bps (V.120)
39 9600 bps (V.120)
43 14400 bps (V.120)
47 19200 bps (V.120)
48 28800 bps (V.120)
49 38400 bps (V.120)
50 48000 bps (V.120)
51 56000 bps (V.120)
65 300 bps (V.110)
66 1200 bps (V.110)
68 2400 bps (V.110 or X.31 flag stuffing)
70 4800 bps (V.110 or X.31 flag stuffing)
71 9600 bps (V.110 or X.31 flag stuffing)
75 14400 bps (V.110 or X.31 flag stuffing)
79 19200 bps (V.110 or X.31 flag stuffing)
80 28800 bps (V.110 or X.31 flag stuffing)
81 38400 bps (V.110 or X.31 flag stuffing)
82 48000 bps (V.110 or X.31 flag stuffing)
83 56000 bps (V.110 or X.31 flag stuffing)
115 56000 bps (bit transparent)
116 64000 bps (bit transparent)
also all other values below 128 are reserved by this ETS
& lt; name & gt; :
0 data circuit asynchronous (UDI or 3.1 kHz modem)
1 data circuit synchronous (UDI or 3.1 kHz modem)
2 PAD Access (asynchronous) (UDI)
3 Packet Access (synchronous) (UDI)
4 data circuit asynchronous (RDI)
5 data circuit synchronous (RDI)
6 PAD Access (asynchronous) (RDI)
7 Packet Access (synchronous) (RDI)
also all other values below 128 are reserved by this ETS
& lt; ce & gt; :
0 transparent
1 non-transparent
2 both, transparent preferred
3 both, non-transparent preferred
Implementation
Mandatory when data calls implemented.
6.8 Radio link protocol +CRLP
Table SEQ Table 15 : +CRLP parameter command syntax
Command Possible response(s)
+CRLP=[ & lt; iws & gt; [, & lt; mws & gt; [, & lt; T1 & gt; [, & lt; N2 & gt; [, & lt; ver & gt; [, & lt; T4 & gt; ]]]]]]
+CRLP? +CRLP: & lt; iws & gt; , & lt; mws & gt; , & lt; T1 & gt; , & lt; N2 & gt; [, & lt; ver1 & gt; [, & lt; T4 & gt; ]]
[ & lt; CR & gt; & lt; LF & gt; +CRLP: & lt; iws & gt; , & lt; mws & gt; , & lt; T1 & gt; , & lt; N2 & gt; [, & lt; ver2 & gt; [, & lt; T4 & gt; ]]
[...]]
+CRLP=? +CRLP: (list of supported & lt; iws & gt; s),(list of supported & lt; mws & gt; s),
(list of supported & lt; T1 & gt; s),(list of supported & lt; N2 & gt; s)[, & lt; ver1 & gt;
[,(list of supported & lt; T4 & gt; s)]]
[ & lt; CR & gt; & lt; LF & gt; +CRLP: (list of supported & lt; iws & gt; s),(list of supported
& lt; mws & gt; s),(list of supported & lt; T1 & gt; s),(list of supported & lt; N2 & gt; s)
[, & lt; ver1 & gt; [,(list of supported & lt; T4 & gt; s)]]
[...]]
Description
Radio link protocol (RLP) parameters used when non-transparent data
calls are originated may be altered with set command. Available command
subparameters depend on the RLP versions implemented by the device (e.g.
& lt; ver & gt; may not be available if device supports only versions 0 and 1).
NOTE: If radio link protocol is not used, but some other error
correcting protocol (for transparent data calls), V.25ter [14] Error
Control Selection test command +ES=? may be used to indicate the
presence of the protocol.
Read command returns current settings for each supported RLP version
& lt; verx & gt; . Only RLP parameters applicable to the corresponding & lt; verx & gt; are
returned.
Test command returns values supported by the TA as a compound value. If
ME/TA supports several RLP versions & lt; verx & gt; , the RLP parameter value
ranges for each & lt; verx & gt; are returned in a separate line.
Defined values
& lt; ver & gt; , & lt; verx & gt; : RLP version number in integer format; when version
indication is not present it shall equal 0
NOTE: Versions 0 and 1 share the same parameter set. Read and test
commands shall return only one line for this set (where & lt; verx & gt; is not
present).
& lt; iws & gt; , & lt; mws & gt; , & lt; T1 & gt; , & lt; N2 & gt; , & lt; T4 & gt; : IWF to MS window size, MS to IWF window
size, acknowledgement timer T1, retransmission attempts N2,
re-sequencing period T4 in integer format (default values and value
ranges depend on RLP version; refer GSM 04.22 [18]): T1 and T4 are in
units of 10 ms.
Implementation
Mandatory when RLP implemented.
6.9 Service reporting control +CR
Table SEQ Table 16 : +CR parameter command syntax
Command Possible response(s)
+CR=[ & lt; mode & gt; ]
+CR? +CR: & lt; mode & gt;
+CR=? +CR: (list of supported & lt; mode & gt; s)
Description
Set command controls whether or not intermediate result code +CR: & lt; serv & gt;
is returned from the TA to the TE. If enabled, the intermediate result
code is transmitted at the point during connect negotiation at which the
TA has determined which speed and quality of service will be used,
before any error control or data compression reports are transmitted,
and before any final result code (e.g. CONNECT) is transmitted.
NOTE: This command replaces V.25ter [14] command Modulation Reporting
Control +MR, which is not appropriate for use in the GSM network.
Possible error control (other than radio link protocol) and data
compression reporting can be enabled with V.25ter commands Error Control
Reporting +ER and Data Compression Reporting +DR.
Test command returns values supported by the TA as a compound value.
Defined values
& lt; mode & gt; :
0 disables reporting
1 enables reporting
& lt; serv & gt; :
ASYNC asynchronous transparent
SYNC synchronous transparent
REL ASYNC asynchronous non-transparent
REL SYNC synchronous non-transparent
Implementation
Mandatory when data calls implemented.
6.10 Extended error report +CEER
Table SEQ Table 17 : +CEER action command syntax
Command Possible response(s)
+CEER +CEER: & lt; report & gt;
+CEER=?
Description
Execution command causes the TA to return one or more lines of
information text & lt; report & gt; , determined by the ME manufacturer, which
should offer the user of the TA an extended report of the reason of the
failure in the last unsuccessful call setup (originating or answering)
or in-call modification, or the reason for last call release. Typically,
the text will consist of a single line containing the failure
information given by GSM network in textual format.
Defined values
& lt; report & gt; : the total number of characters, including line terminators, in
the information text shall not exceed 2041 characters.
Text shall not contain the sequence 0 & lt; CR & gt; or OK & lt; CR & gt;
Implementation
Optional.
6.11 Cellular result codes +CRC
Table SEQ Table 18 : +CRC parameter command syntax
Command Possible response(s)
+CRC=[ & lt; mode & gt; ]
+CRC? +CRC: & lt; mode & gt;
+CRC=? +CRC: (list of supported & lt; mode & gt; s)
Description
Set command controls whether or not the extended format of incoming call
indication is used. When enabled, an incoming call is indicated to the
TE with unsolicited result code +CRING: & lt; type & gt; instead of the normal
RING.
Test command returns values supported by the TA as a compound value.
NOTE: Similar command may be found in TIA IS-99 [15] and TIA
IS-135 [16].
Defined values
& lt; mode & gt; :
0 disables extended format
1 enables extended format
& lt; type & gt; :
ASYNC asynchronous transparent
SYNC synchronous transparent
REL ASYNC asynchronous non-transparent
REL SYNC synchronous non-transparent
FAX facsimile (TS 62)
VOICE normal voice (TS 11)
VOICE/XXX voice followed by data (BS 81) (XXX is ASYNC, SYNC, REL ASYNC
or REL SYNC)
ALT VOICE/XXX alternating voice/data, voice first (BS 61)
ALT XXX/VOICE alternating voice/data, data first (BS 61)
ALT VOICE/FAX alternating voice/fax, voice first (TS 61)
ALT FAX/VOICE alternating voice/fax, fax first (TS 61)
GPRS XXX GPRS (XXX is a text string, the variable contents of which are
specified in 07.60)
Implementation
Mandatory when data or fax circuit mode calls implemented.
6.12 HSCSD device parameters +CHSD
Table SEQ Table 19 : +CHSD action command syntax
Command Possible response(s)
+CHSD +CHSD: & lt; mclass & gt; , & lt; maxRx & gt; , & lt; maxTx & gt; , & lt; sum & gt; , & lt; codings & gt;
+CME ERROR: & lt; err & gt;
+CHSD=?
Description
Execution command returns information about HSCSD features (refer GSM
02.34 [29]) supported by the ME/TA. Refer subclause 9.2 for possible
& lt; err & gt; values.
Defined values
& lt; mclass & gt; : integer type; multislot class
& lt; maxRx & gt; : integer type; maximum number of receive timeslots that ME can
use
& lt; maxTx & gt; : integer type; maximum number of transmit timeslots that ME can
use
& lt; sum & gt; : integer type; total number of receive and transmit timeslots that
ME can use at the same time (per TDMA frame). The following applies in a
HSCSD call: 1 ( (receive slots) + (transmit slots) ( & lt; sum & gt;
& lt; codings & gt; is a sum of integers each representing a supported channel
coding (e.g. value 5 indicates that 4.8k and 9.6k channel codings are
supported):
1 4.8k full rate data traffic channel
4 9.6k full rate data traffic channel
8 14.4k full rate data traffic channel
Implementation
Mandatory when HSCSD implemented.
6.13 HSCSD transparent call configuration +CHST
Table SEQ Table 20 : +CHST parameter command syntax
Command Possible response(s)
+CHST=[ & lt; wRx & gt; [, & lt; codings & gt; ]]
+CHST? +CHST: & lt; wRx & gt; , & lt; codings & gt;
+CHST=?
Description
Set command controls parameters for transparent HSCSD calls. Changing
them during a call does not affect the current call.
Defined values
& lt; wRx & gt; : integer type; wanted amount of receive timeslots. Default value 0
indicates that TA shall calculate a proper value from currently selected
fixed network user rate ( & lt; speed & gt; subparameter from +CBST command) and
& lt; codings & gt;
& lt; codings & gt; : a sum of integers each representing a channel coding that is
accepted for transparent HSCSD calls. Default value 0 indicates that all
supported codings are accepted (refer +CHSD command for other values)
Implementation
Mandatory when transparent HSCSD implemented.
6.14 HSCSD non-transparent call configuration +CHSN
Table SEQ Table 21 : +CHSN parameter command syntax
Command Possible response(s)
+CHSN=[ & lt; wAiur & gt; [, & lt; wRx & gt; [, & lt; topRx & gt;
[, & lt; codings & gt; ]]]]
+CHSN? +CHSN: & lt; wAiur & gt; , & lt; wRx & gt; , & lt; topRx & gt; , & lt; codings & gt;
+CHSN=? +CHSN: & lt; maxAiur & gt; , & lt; modify & gt;
Description
Set command controls parameters for non-transparent HSCSD calls.
Changing & lt; topRx & gt; or & lt; codings & gt; value during a call does not affect the
current call. Changing of & lt; wAiur & gt; or & lt; wRx & gt; affects the current call only
if & lt; topRx & gt; was non-zero when call was established.
Defined values
& lt; wAiur & gt; : integer type; wanted air interface user rate. Default value 0
indicates that TA shall calculate a proper value from currently selected
fixed network user rate ( & lt; speed & gt; subparameter from +CBST command),
& lt; codings & gt; , and & lt; wRx & gt; (or & lt; maxRx & gt; from +CHSD command if & lt; wRx & gt; =0). Other
values:
1 9600 bps
2 14400 bps
3 19200 bps
4 28800 bps
5 38400 bps
6 43200 bps
7 57600 bps
& lt; wRx & gt; : integer type; wanted amount of receive timeslots. Default value 0
indicates that TA shall calculate a proper value from currently selected
& lt; wAiur & gt; and & lt; codings & gt;
& lt; topRx & gt; : integer type; top value for & lt; wRx & gt; that user is going to request
during the next established non-transparent HSCSD call. Default value 0
indicates that user is not going to change & lt; wAiur & gt; / & lt; wRx & gt; during the next
call
& lt; codings & gt; : a sum of integers each representing a channel coding that is
accepted for non-transparent HSCSD calls. Default value 0 indicates that
all supported codings are accepted (refer +CHSD command for other
values)
& lt; maxAiur & gt; : integer type; maximum value for & lt; wAiur & gt; (assuming that all
supported channel codings are accepted and maximum number of timeslots
are used)
& lt; modify & gt; :
0 & lt; wAiur & gt; / & lt; wRx & gt; modification during call is not supported by ME/TA
( & lt; topRx & gt; accepts only 0)
1 & lt; wAiur & gt; / & lt; wRx & gt; modification during call is supported by ME/TA
Implementation
Mandatory when non-transparent HSCSD implemented.
6.15 HSCSD current call parameters +CHSC
Table SEQ Table 22 : +CHSC action command syntax
Command Possible response(s)
+CHSC +CHSC: & lt; rx & gt; , & lt; tx & gt; , & lt; aiur & gt; , & lt; coding & gt;
+CHSC=?
Description
Execution command returns information about current HSCSD call. If no
HSCSD call is active, all parameters returned shall equal zero. (It is
manufacturer specific whether non-zero information is returned in case
of an active normal single-slot data call.)
Defined values
& lt; rx & gt; : integer type; number of receive timeslots currently in use
& lt; tx & gt; : integer type; number of transmit timeslots currently in use
& lt; aiur & gt; : integer type; current air interface user rate (in case of
transparent service this equals fixed network user rate) (refer +CHSN
command for possible values)
& lt; coding & gt; : current channel coding (refer +CHSD command for possible
values)
Implementation
Optional.
6.16 Single numbering scheme +CSNS
Table SEQ Table 23 : +CSNS parameter command syntax
Command Possible response(s)
+CSNS=[ & lt; mode & gt; ]
+CSNS? +CSNS: & lt; mode & gt;
+CSNS=? +CSNS: (list of supported & lt; mode & gt; s)
Description
Set command selects the bearer or teleservice to be used when mobile
terminated single numbering scheme call is established. Parameter values
set with +CBST command shall be used when & lt; mode & gt; equals to a data
service. If +CBST parameter is set to a value that is not applicable to
single numbering calls, ME/TA shall map the value to the closest valid
one. E.g. if user has set & lt; speed & gt; =71, & lt; name & gt; =2 and & lt; ce & gt; =1
(non-transparent asynchronous 9600 bps V.110 ISDN connection) for mobile
originated calls, ME/TA shall map the values into non-transparent
asynchronous 9600 bps V.32 modem connection when single numbering scheme
call is answered.
Test command returns values supported by the TA as compound values.
Defined values
& lt; mode & gt; :
0 voice
1 alternating voice/fax, voice first (TS 61)
2 fax (TS 62)
3 alternating voice/data, voice first (BS 61)
4 data
5 alternating voice/fax, fax first (TS 61)
6 alternating voice/data, data first (BS 61)
7 voice followed by data (BS 81)
Implementation
Optional.
6.17 Voice Hangup Control +CVHU $(AT R97)$
Table SEQ Table 24 : +CVHU parameter command syntax
Command Possible response(s)
+CVHU=[ & lt; mode & gt; ]
+CVHU? +CVHU: & lt; mode & gt;
+CVHU=? +CVHU:(list of supported & lt; mode & gt; s)
Description
Set command selects whether ATH or ``drop DTR'' shall cause a voice
connection to be disconnected or not. By voice connection is also meant
alternating mode calls that are currently in voice mode. (See section
6.6).
NOTE: When & lt; mode & gt; = 2, this command must be seen in conjunction with the
the V.25ter [14] command & D. Else & D shall be ignored.
Defined values
& lt; mode & gt; :
0 ``Drop DTR'' ignored but OK response given. ATH disconnects.
1 ``Drop DTR'' and ATH ignored but OK response given.
2 ``Drop DTR'' behaviour according to & D setting. ATH disconnects.
Implementation
Optional
6.18 V.120 rate adaption protocol +CV120
Table SEQ Table 25 : +CV120 parameter command syntax
Command Possible response(s)
+CV120=[ & lt; rah & gt; [, & lt; mfm & gt; [,
& lt; mode & gt; [, & lt; llineg & gt; [,
& lt; assign & gt; [, & lt; negtype & gt; ]]]]]]
+CV120? +CV120: & lt; rah & gt; , & lt; mfm & gt; , & lt; mode & gt; , & lt; llineg & gt; ,
& lt; assign & gt; , & lt; negtype & gt;
+CV120=? +CV120: (list of supported & lt; rah & gt; s),(list of supported
& lt; mfm & gt; s),(list of supported & lt; mode & gt; s),(list of supported & lt; llineg & gt; s),(list
of supported & lt; assign & gt; s),(list of supported & lt; negtype & gt; s)
Description
Set command sets the values of the V.120 protocol parameters (defined in
CCITT V.120) that are carried in the GSM BC and/or LLC information
elements.
Read command returns current settings for the V.120 parameters.
Test command returns values supported by the TA as a compound value.
Defined values
& lt; rah & gt;
0 rate adaption header not included
1 rate adaption header included (mandatory for protocol sensitive
modes).
& lt; mfm & gt;
0 multiple frame establishment not supported, only UI frames allowed
1 multiple frame establishment supported, both I and UI frames allowed.
& lt; mode & gt;
0 bit transparent mode of operation
1 protocol sensitive mode of operation.
& lt; llineg & gt;
0 no negotiation, LLI = 256 only
1 negotiation allowed. Note - & lt; negtype & gt; indicates the connection over
which the negotiation is performed.
& lt; assign & gt;
0 message originator is " default assignee "
1 message originator is " assignor only " .
& lt; negtype & gt;
0 negotiation is done using logical link zero
1 negotiation is done with USER INFORMATION messages on a temporary
signalling connection.
GSM does not support all the possible modes of V.120 operation. However,
in order to accommodate possible future additions, the complete set of
parameters is included in the command.
The permitted values are: 1, 1 or 0, 1, 0, 0, 0.
A recommended set of default values is: 1, 1, 1, 0, 0, 0.
Implementation
Mandatory, if the ME supports V.120 interworking.
6.19 ITU-T V.25ter [14] call control commands
Table SEQ Table 26 : V.25ter call control commands
Command Section Impl. Use in GSM
D[ & lt; dial_ string & gt; ][;] 6.3.1 mand. originates a call
T 6.3.2 mand. ignored (select tone dialling)
P 6.3.3 mand. ignored (select pulse dialling)
A 6.3.5 mand. answer a call
H[ & lt; value & gt; ] 6.3.6 mand. hang-up a single mode call; for alternate mode
call refer subclause " Hangup call +CHUP " (only value equal to zero
needed)
O[ & lt; value & gt; ] 6.3.7 mand. returns TA to online data state from online
command mode (only value equal to zero needed)
S0=[ & lt; value & gt; ] 6.3.8 mand. sets the number of call indications (rings)
before automatically answering the call; value equalling zero disables
automatic answering and is the default
S6=[ & lt; value & gt; ] 6.3.9 mand. ignored (pause before blind dialling)
S7=[ & lt; value & gt; ] 6.3.10 mand. sets number of seconds to wait for completion
of call answering or originating procedure before giving up and
disconnecting
S8=[ & lt; value & gt; ] 6.3.11 mand. sets number of seconds to wait when comma dial
modifier encountered in dial string of D command (default is 2 seconds)
S10=[ & lt; value & gt; ] 6.3.12 mand. sets number of tenths of seconds to wait
before disconnecting after TA has indicated the absence of received line
signal
L[ & lt; value & gt; ] 6.3.13 mand. ignored (monitor speaker loudness)
M[ & lt; value & gt; ] 6.3.14 mand. ignored (monitor speaker mode)
6.20 ITU-T V.25ter [14] data compression commands
Table SEQ Table 27 : V.25ter data compression commands
Command Section Impl. Use in GSM
+DS=[ & lt; dir & gt; [, & lt; neg & gt; [, & lt; P1 & gt; [, & lt; P2 & gt; ]]]] 6.6.1 mand. when V.42bis controls
ITU-T Recommendation V.42bis data compression functions; for
subparameter defaults in GSM refer GSM 04.22 [18]
+DR=[ & lt; value & gt; ] 6.6.2 mand. when V.42bis determines whether the use of
V.42bis is informed using intermediate result code +DR: & lt; type & gt; before
going online data state after call answering or originating
6.21 Informative examples
The alternating mode call handling (voice and fax, or voice and data)
and the data call setup commands are defined such that the dialling
command of V.25ter [14] (D) still always originates a call. The purpose
is to support all current TE applications using the dialling command as
default. Fax calls are controlled following the rules of ITU-T T.31 [11]
and T.32 [12] standards.
An example where a voice call is originated:
ATD+1 812 555673I; (type of address defaults to 145, CLI presentation is
restricted for this call)
OK (call setup was successful)
An example where a voice call is attempted from a phonebook:
ATD & gt; " Doe Joe " G; (enable CUG control for this call)
+CME ERROR: 22 (entry " Doe Joe " is not found)
Also supplementary services may be controlled using dial command
according to GSM 02.30 [19]. An example of call forwarding on no reply
for telephony with the adjustment of the no reply condition timer on 25
seconds:
ATD**61*+1812555673*11*25#
OK (modification was successful)
Two new commands are created for controlling the alternating mode calls.
First one, Call Mode (+CMOD), selects between single and alternating
mode. Because this is a crucial command, it is defined that the value is
set back to zero (single mode) after every successfully originated
alternating mode call. Also on power-up and factory or user resets, the
value is set to zero. The second new command, Hangup Call (+CHUP), is
not a replacement of V.25ter [14] command H, but a command which
reliably disconnects the call in GSM network. This is defined because
the H command is used to switch from fax or data mode to voice mode.
The setting of GSM bearer service (data circuit duplex asynchronous and
synchronous, PAD access circuit asynchronous, or data packet duplex
synchronous), is done with Select Bearer Service Type (+CBST). It
chooses one of the four mentioned bearer services, the data rate of the
service (or actually the modulation when modem IWFs are used), and
enables or disables RLP. Command Radio Link Protocol (+CRLP) is used to
set the RLP parameters in the radio path.
Service Reporting Control command (+CR) is defined similarly as the
reporting of modulation, V.18, error control, and data compression which
are V.25ter [14] features used to show information about the type of the
established connection before the CONNECT intermediate result code. +CR
command has one subparameter which specifies whether the intermediate
result code +CR: & lt; serv & gt; is returned or not. The result code should be
returned before any V.25ter [14] reporting result codes. An example of
setting up an asynchronous 9600 bit/s modem connection with service
reporting:
AT+CBST=7,0,1 (asynchronous modem 9600 bit/s and RLP)
OK
AT+CR=1 (enable reporting)
OK
ATD1234567890
+CR: REL ASYNC
CONNECT 9600
As GSM network offers more information about the reason of the failure
in call originating and answering than normal PSTN, it is useful to add
an extra command to return this information to the TE. This information
should not be returned always after unsuccessful call originating or
answering, because many TE applications look for just the regular NO
CARRIER, BUSY, NO ANSWER and CONNECT messages. Action command Extended
Error Report (+CEER) does not have any subparameters, and it returns the
cause of the latest call setup failure. This information may be the
textual presentation of the GSM network failure code (refer GSM
specification 04.08 [8] Annex H), or some other information defined by
the TA manufacturer.
7 Network service related commands
This clause describes GSM network related commands, which are not
covered in call control clause of this ETS. Commands include GSM
supplementary service handling, MSISDN query, ME and network facility
locking, and network registration information query.
7.1 Subscriber number +CNUM
Table SEQ Table 28 : +CNUM action command syntax
Command Possible response(s)
+CNUM +CNUM: [ & lt; alpha1 & gt; ], & lt; number1 & gt; , & lt; type1 & gt; [, & lt; speed & gt; , & lt; service & gt; [, & lt; itc & gt; ]]
[ & lt; CR & gt; & lt; LF & gt; +CNUM: [ & lt; alpha2 & gt; ], & lt; number2 & gt; , & lt; type2 & gt; [, & lt; speed & gt; , & lt; service & gt; [, & lt; itc & gt; ]
]
[...]]
+CME ERROR: & lt; err & gt;
+CNUM=?
Description
Action command returns the MSISDNs related to the subscriber (this
information can be stored in the SIM or in the ME). If subscriber has
different MSISDN for different services, each MSISDN is returned in a
separate line. Refer subclause 9.2 for possible & lt; err & gt; values.
Defined values
& lt; alphax & gt; : optional alphanumeric string associated with & lt; numberx & gt; ; used
character set should be the one selected with command Select TE
Character Set +CSCS
& lt; numberx & gt; : string type phone number of format specified by & lt; typex & gt;
& lt; typex & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7)
& lt; speed & gt; : as defined in subclause 6.7
& lt; service & gt; (service related to the phone number):
0 asynchronous modem
1 synchronous modem
2 PAD Access (asynchronous)
3 Packet Access (synchronous)
4 voice
5 fax
also all other values below 128 are reserved by this ETS
& lt; itc & gt; (information transfer capability):
0 3.1 kHz
1 UDI
Implementation
Optional.
7.2 Network registration +CREG
Table SEQ Table 29 : +CREG parameter command syntax
Command Possible response(s)
+CREG=[ & lt; n & gt; ]
+CREG? +CREG: & lt; n & gt; , & lt; stat & gt; [, & lt; lac & gt; , & lt; ci & gt; ]
+CME ERROR: & lt; err & gt;
+CREG=? +CREG: (list of supported & lt; n & gt; s)
Description
Set command controls the presentation of an unsolicited result code
+CREG: & lt; stat & gt; when & lt; n & gt; =1 and there is a change in the ME network
registration status, or code +CREG: & lt; stat & gt; [, & lt; lac & gt; , & lt; ci & gt; ] when & lt; n & gt; =2 and
there is a change of the network cell.
Read command returns the status of result code presentation and an
integer & lt; stat & gt; which shows whether the network has currently indicated
the registration of the ME. Location information elements & lt; lac & gt; and & lt; ci & gt;
are returned only when & lt; n & gt; =2 and ME is registered in the network. Refer
subclause 9.2 for possible & lt; err & gt; values.
Defined values
& lt; n & gt; :
0 disable network registration unsolicited result code
1 enable network registration unsolicited result code +CREG: & lt; stat & gt;
2 enable network registration and location information unsolicited
result code +CREG: & lt; stat & gt; [, & lt; lac & gt; , & lt; ci & gt; ]
& lt; stat & gt; :
0 not registered, ME is not currently searching a new operator to
register to
1 registered, home network
2 not registered, but ME is currently searching a new operator to
register to
3 registration denied
4 unknown
5 registered, roaming
& lt; lac & gt; : string type; two byte location area code in hexadecimal format
(e.g. " 00C3 " equals 193 in decimal)
& lt; ci & gt; : string type; two byte cell ID in hexadecimal format
Implementation
Optional.
7.3 Operator selection +COPS
Table SEQ Table 30 : +COPS parameter command syntax
Command Possible response(s)
+COPS=[ & lt; mode & gt; [, & lt; format & gt;
[, & lt; oper & gt; ]]] +CME ERROR: & lt; err & gt;
+COPS? +COPS: & lt; mode & gt; [, & lt; format & gt; , & lt; oper & gt; ]
+CME ERROR: & lt; err & gt;
+COPS=? +COPS: [list of supported ( & lt; stat & gt; ,long alphanumeric & lt; oper & gt;
,short alphanumeric & lt; oper & gt; ,numeric & lt; oper & gt; )s]
[,,(list of supported & lt; mode & gt; s),(list of supported & lt; format & gt; s)]
+CME ERROR: & lt; err & gt;
Description
Set command forces an attempt to select and register the GSM network
operator. & lt; mode & gt; is used to select whether the selection is done
automatically by the ME or is forced by this command to operator & lt; oper & gt;
(it shall be given in format & lt; format & gt; ). If the selected operator is not
available, no other operator shall be selected (except & lt; mode & gt; =4). The
selected operator name format shall apply to further read commands
(+COPS?) also. & lt; mode & gt; =2 forces an attempt to deregister from the
network. The selected mode affects to all further network registration
(e.g. after & lt; mode & gt; =2, ME shall be unregistered until & lt; mode & gt; =0 or 1 is
selected). Refer subclause 9.2 for possible & lt; err & gt; values. This command
should be abortable when registration/deregistration attempt is made.
Read command returns the current mode and the currently selected
operator. If no operator is selected, & lt; format & gt; and & lt; oper & gt; are omitted.
Test command returns a list of quadruplets, each representing an
operator present in the network. Quadruplet consists of an integer
indicating the availability of the operator & lt; stat & gt; , long and short
alphanumeric format of the name of the operator, and numeric format
representation of the operator. Any of the formats may be unavailable
and should then be an empty field. The list of operators shall be in
order: home network, networks referenced in SIM, and other networks.
It is recommended (although optional) that after the operator list TA
returns lists of supported & lt; mode & gt; s and & lt; format & gt; s. These lists shall be
delimited from the operator list by two commas.
Defined values
& lt; mode & gt; :
0 automatic ( & lt; oper & gt; field is ignored)
1 manual ( & lt; oper & gt; field shall be present)
2 deregister from network
3 set only & lt; format & gt; (for read command +COPS?), do not attempt
registration/deregistration ( & lt; oper & gt; field is ignored); this value is not
applicable in read command response
4 manual/automatic ( & lt; oper & gt; field shall be present); if manual selection
fails, automatic mode ( & lt; mode & gt; =0) is entered
& lt; format & gt; :
0 long format alphanumeric & lt; oper & gt;
1 short format alphanumeric & lt; oper & gt;
2 numeric & lt; oper & gt;
& lt; oper & gt; : string type; & lt; format & gt; indicates if the format is alphanumeric or
numeric; long alphanumeric format can be upto 16 characters long and
short format up to 8 characters (refer GSM MoU SE.13 [9]); numeric
format is the GSM Location Area Identification number (refer
GSM 04.08 [8] subclause 10.5.1.3) which consists of a three BCD digit
country code coded as in ITU-T E.212 Annex A [10], plus a two BCD digit
network code, which is administration specific; returned & lt; oper & gt; shall
not be in BCD format, but in IRA characters converted from BCD; hence
the number has structure: (country code digit 3)(country code digit
2)(country code digit 1)(network code digit 2)(network code digit 1)
& lt; stat & gt; :
0 unknown
1 available
2 current
3 forbidden
Implementation
Optional.
7.4 Facility lock +CLCK
Table SEQ Table 31 : +CLCK action command syntax
Command Possible response(s)
+CLCK= & lt; fac & gt; , & lt; mode & gt; [, & lt; passwd & gt; [, & lt; class & gt; ]] +CME ERROR: & lt; err & gt;
when & lt; mode & gt; =2 and command successful:
+CLCK: & lt; status & gt; [, & lt; class1 & gt;
[ & lt; CR & gt; & lt; LF & gt; +CLCK: & lt; status & gt; , & lt; class2 & gt;
[...]]
+CLCK=? +CLCK: (list of supported & lt; fac & gt; s)
+CME ERROR: & lt; err & gt;
Description
Execute command is used to lock, unlock or interrogate a ME or a network
facility & lt; fac & gt; . Password is normally needed to do such actions. When
querying the status of a network service ( & lt; mode & gt; =2) the response line
for `not active' case ( & lt; status & gt; =0) should be returned only if service is
not active for any & lt; class & gt; . Refer subclause 9.2 for possible & lt; err & gt;
values. This command should be abortable when network facilities are set
or interrogated.
Call barring facilities are based on GSM supplementary services (refer
GSM 02.88 [6]). The interaction of these with other commands based on
other GSM supplementary services is described in the GSM standard.
Test command returns facility values supported by the TA as a compound
value.
Defined values
& lt; fac & gt; values reserved by this ETS:
" CS " CNTRL (lock CoNTRoL surface (e.g. phone keyboard))
" PS " PH-SIM (lock PHone to SIM card) (ME asks password when other than
current SIM card inserted; ME may remember certain amount of previously
used cards thus not requiring password when they are inserted)
" PF " lock Phone to the very First inserted SIM card (also referred in
this ETS as PH-FSIM) (ME asks password when other than the first SIM
card is inserted)
" SC " SIM (lock SIM card) (SIM asks password in ME power-up and when this
lock command issued)
" AO " BAOC (Barr All Outgoing Calls) (refer GSM 02.88 [6] clause 1)
" OI " BOIC (Barr Outgoing International Calls) (refer GSM 02.88 [6]
clause 1)
" OX " BOIC-exHC (Barr Outgoing International Calls except to Home
Country) (refer GSM 02.88 [6] clause 1)
" AI " BAIC (Barr All Incoming Calls) (refer GSM 02.88 [6] clause 2)
" IR " BIC-Roam (Barr Incoming Calls when Roaming outside the home
country) (refer GSM 02.88 [6] clause 2)
" NT " barr incoming calls from numbers Not stored to TA memory
" NM " barr incoming calls from numbers Not stored to ME memory
" NS " barr incoming calls from numbers Not stored to SIM memory
" NA " barr incoming calls from numbers Not stored in Any memory
" AB " All Barring services (refer GSM 02.30 [19]) (applicable only for
& lt; mode & gt; =0)
" AG " All outGoing barring services (refer GSM 02.30 [19]) (applicable
only for & lt; mode & gt; =0)
" AC " All inComing barring services (refer GSM 02.30 [19]) (applicable
only for & lt; mode & gt; =0)
" FD " SIM fixed dialling memory feature (if PIN2 authentication has not
been done during the current session, PIN2 is required as & lt; passwd & gt; )
" PN " Network Personalisation (refer GSM 02.22 [33])
" PU " network sUbset Personalisation (refer GSM 02.22 [33])
" PP " service Provider Personalisation (refer GSM 02.22 [33])
" PC " Corporate Personalisation (refer GSM 02.22 [33])
& lt; mode & gt; :
0 unlock
1 lock
2 query status
& lt; status & gt; :
0 not active
1 active
& lt; passwd & gt; : string type; shall be the same as password specified for the
facility from the ME user interface or with command Change Password
+CPWD
& lt; classx & gt; is a sum of integers each representing a class of information
(default 7):
1 voice (telephony)
2 data (refers to all bearer services; with & lt; mode & gt; =2 this may refer only
to some bearer service if TA does not support values 16, 32, 64 and 128)
4 fax (facsimile services)
8 short message service
16 data circuit sync
32 data circuit async
64 dedicated packet access
128 dedicated PAD access
Implementation
The call barring supplementary service control is mandatory for ME
supporting AT commands only and not supporting the control through dial
command D.
7.5 Change password +CPWD
Table SEQ Table 32 : +CPWD action command syntax
Command Possible response(s)
+CPWD= & lt; fac & gt; , & lt; oldpwd & gt; , & lt; newpwd & gt; +CME ERROR: & lt; err & gt;
+CPWD=? +CPWD: list of supported ( & lt; fac & gt; , & lt; pwdlength & gt; )s
+CME ERROR: & lt; err & gt;
Description
Action command sets a new password for the facility lock function
defined by command Facility Lock +CLCK. Refer subclause 9.2 for possible
& lt; err & gt; values.
Test command returns a list of pairs which present the available
facilities and the maximum length of their password.
Defined values
& lt; fac & gt; :
" P2 " SIM PIN2
refer Facility Lock +CLCK for other values
& lt; oldpwd & gt; , & lt; newpwd & gt; : string type; & lt; oldpwd & gt; shall be the same as password
specified for the facility from the ME user interface or with command
Change Password +CPWD and & lt; newpwd & gt; is the new password; maximum length
of password can be determined with & lt; pwdlength & gt;
& lt; pwdlength & gt; : integer type maximum length of the password for the
facility
Implementation
Optional.
7.6 Calling line identification presentation +CLIP
Table SEQ Table 33 : +CLIP parameter command syntax
Command Possible response(s)
+CLIP=[ & lt; n & gt; ]
+CLIP? +CLIP: & lt; n & gt; , & lt; m & gt;
+CLIP=? +CLIP: (list of supported & lt; n & gt; s)
Description
This command refers to the GSM supplementary service CLIP (Calling Line
Identification Presentation) that enables a called subscriber to get the
calling line identity (CLI) of the calling party when receiving a mobile
terminated call. Set command enables or disables the presentation of the
CLI at the TE. It has no effect on the execution of the supplementary
service CLIP in the network.
When the presentation of the CLI at the TE is enabled (and calling
subscriber allows), +CLIP:
& lt; number & gt; , & lt; type & gt; [, & lt; subaddr & gt; , & lt; satype & gt; [, & lt; alpha & gt; ]] response is returned
after every RING (or +CRING: & lt; type & gt; ; refer subclause " Cellular result
codes +CRC " ) result code sent from TA to TE. It is manufacturer specific
if this response is used when normal voice call is answered.
Read command gives the status of & lt; n & gt; , and also triggers an interrogation
of the provision status of the CLIP service according GSM 02.81 [3]
(given in & lt; m & gt; ).Test command returns values supported by the TA as a
compound value.
Defined values
& lt; n & gt; (parameter sets/shows the result code presentation status in the
TA):
0 disable
1 enable
& lt; m & gt; (parameter shows the subscriber CLIP service status in the network):
0 CLIP not provisioned
1 CLIP provisioned
2 unknown (e.g. no network, etc.)
& lt; number & gt; : string type phone number of format specified by & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7)
& lt; subaddr & gt; : string type subaddress of format specified by & lt; satype & gt;
& lt; satype & gt; : type of subaddress octet in integer format (refer
GSM 04.08 [8] subclause 10.5.4.8)
& lt; alpha & gt; : optional string type alphanumeric representation of & lt; number & gt;
corresponding to the entry found in phonebook; used character set should
be the one selected with command Select TE Character Set +CSCS
Implementation
Optional.
7.7 Calling line identification restriction +CLIR
Table SEQ Table 34 : +CLIR parameter command syntax
Command Possible response(s)
+CLIR=[ & lt; n & gt; ]
+CLIR? +CLIR: & lt; n & gt; , & lt; m & gt;
+CLIR=? +CLIR: (list of supported & lt; n & gt; s)
Description
This command refers to CLIR-service according to GSM 02.81 [3] that
allows a calling subscriber to enable or disable the presentation of the
CLI to the called party when originating a call.
Set command overrides the CLIR subscription (default is restricted or
allowed) when temporary mode is provisioned as a default adjustment for
all following outgoing calls. This adjustment can be revoked by using
the opposite command.. If this command is used by a subscriber without
provision of CLIR in permanent mode the network will act according
GSM 02.81 [3].
Read command gives the default adjustment for all outgoing calls (given
in & lt; n & gt; ), and also triggers an interrogation of the provision status of
the CLIR service (given in & lt; m & gt; ). Test command returns values supported
by the TA as a compound value.
NOTE: On a per call base CLIR functionality is explained in subclause
" ITU-T V.25ter [14] dial command " .
Defined values
& lt; n & gt; (parameter sets the adjustment for outgoing calls):
0 presentation indicator is used according to the subscription of the
CLIR service
1 CLIR invocation
2 CLIR suppression
& lt; m & gt; (parameter shows the subscriber CLIR service status in the network):
0 CLIR not provisioned
1 CLIR provisioned in permanent mode
2 unknown (e.g. no network, etc.)
3 CLIR temporary mode presentation restricted
4 CLIR temporary mode presentation allowed
Implementation
Optional.
7.8 Connected line identification presentation +COLP
Table SEQ Table 35 : +COLP parameter command syntax
Command Possible response(s)
+COLP=[ & lt; n & gt; ]
+COLP? +COLP: & lt; n & gt; , & lt; m & gt;
+COLP=? +COLP: (list of supported & lt; n & gt; s)
Description
This command refers to the GSM supplementary service COLP (Connected
Line Identification Presentation) that enables a calling subscriber to
get the connected line identity (COL) of the called party after setting
up a mobile originated call. The command enables or disables the
presentation of the COL at the TE. It has no effect on the execution of
the supplementary service COLR in the network.
When enabled (and called subscriber allows), +COLP:
& lt; number & gt; , & lt; type & gt; [, & lt; subaddr & gt; , & lt; satype & gt; [, & lt; alpha & gt; ]] intermediate result code
is returned from TA to TE before any +CR or V.25ter [14] responses. It
is manufacturer specific if this response is used when normal voice call
is established.
Read command gives the status of & lt; n & gt; , and also triggers an interrogation
of the provision status of the COLP service according GSM 02.81 [3]
(given in & lt; m & gt; ).
Test command returns values supported by the TA as a compound value.
Defined values
& lt; n & gt; (parameter sets/shows the result code presentation status in the
TA):
0 disable
1 enable
& lt; m & gt; (parameter shows the subscriber COLP service status in the network):
0 COLP not provisioned
1 COLP provisioned
2 unknown (e.g. no network, etc.)
& lt; number & gt; , & lt; type & gt; , & lt; subaddr & gt; , & lt; satype & gt; , & lt; alpha & gt; : refer +CLIP
Implementation
Optional.
7.9 Closed user group +CCUG
Table SEQ Table 36 : +CCUG parameter command syntax
Command Possible response(s)
+CCUG=[ & lt; n & gt; [, & lt; index & gt; [, & lt; info & gt; ]]]
+CCUG? +CCUG: & lt; n & gt; , & lt; index & gt; , & lt; info & gt;
+CCUG=?
Description
This command allows control of the Closed User Group supplementary
service (refer GSM 02.85 [21]). Set command enables the served
subscriber to select a CUG index, to suppress the Outgoing Access (OA),
and to suppress the preferential CUG.
Set command with & lt; n & gt; =1 enables to control the CUG information on the air
interface as a default adjustment for all following outgoing calls. The
interaction of this command with other commands based on other GSM
supplementary services is described in the GSM standard.
NOTE: On a per call base CUG functionality is explained in subclause
" ITU-T V.25ter [14] dial command " .
Defined values
& lt; n & gt; :
0 disable CUG temporary mode
1 enable CUG temporary mode
& lt; index & gt; :
0...9 CUG index
10 no index (preferred CUG taken from subscriber data)
& lt; info & gt; :
0 no information
1 suppress OA
2 suppress preferential CUG
3 suppress OA and preferential CUG
Implementation
Optional.
7.10 Call forwarding number and conditions +CCFC
Table SEQ Table 37 : +CCFC action command syntax
Command Possible response(s)
+CCFC= & lt; reason & gt; , & lt; mode & gt;
[, & lt; number & gt; [, & lt; type & gt;
[, & lt; class & gt;
[, & lt; subaddr & gt; [, & lt; satype & gt;
[, & lt; time & gt; ]]]]]] +CME ERROR: & lt; err & gt;
when & lt; mode & gt; =2 and command successful:
+CCFC: & lt; status & gt; , & lt; class1 & gt; [, & lt; number & gt; , & lt; type & gt;
[, & lt; subaddr & gt; , & lt; satype & gt; [, & lt; time & gt; ]]][
& lt; CR & gt; & lt; LF & gt; +CCFC: & lt; status & gt; , & lt; class2 & gt; [, & lt; number & gt; , & lt; type & gt;
[, & lt; subaddr & gt; , & lt; satype & gt; [, & lt; time & gt; ]]]
[...]]
+CCFC=? +CCFC: (list of supported & lt; reason & gt; s)
Description
This command allows control of the call forwarding supplementary service
according to GSM 02.82 [4]. Registration, erasure, activation,
deactivation, and status query are supported. When querying the status
of a network service ( & lt; mode & gt; =2) the response line for `not active' case
( & lt; status & gt; =0) should be returned only if service is not active for any
& lt; class & gt; .
Test command returns reason values supported by the TA as a compound
value.
Defined values
& lt; reason & gt; :
0 unconditional
1 mobile busy
2 no reply
3 not reachable
4 all call forwarding (refer GSM 02.30 [19])
5 all conditional call forwarding (refer GSM 02.30 [19])
& lt; mode & gt; :
0 disable
1 enable
2 query status
3 registration
4 erasure
& lt; number & gt; : string type phone number of forwarding address in format
specified by & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7); default 145 when dialling string includes
international access code character " + " , otherwise 129
& lt; subaddr & gt; : string type subaddress of format specified by & lt; satype & gt;
& lt; satype & gt; : type of subaddress octet in integer format (refer
GSM 04.08 [8] subclause 10.5.4.8); default 128
& lt; classx & gt; is a sum of integers each representing a class of information
(default 7):
1 voice (telephony)
2 data (refers to all bearer services; with & lt; mode & gt; =2 this may refer only
to some bearer service if TA does not support values 16, 32, 64 and 128)
4 fax (facsimile services)
8 short message service
16 data circuit sync
32 data circuit async
64 dedicated packet access
128 dedicated PAD access
& lt; time & gt; :
1...30 when " no reply " is enabled or queried, this gives the time in
seconds to wait before call is forwarded, default value 20
& lt; status & gt; :
0 not active
1 active
Implementation
Mandatory for ME supporting AT commands only and not supporting the
control through dial command D.
7.11 Call waiting +CCWA
Table SEQ Table 38 : +CCWA parameter command syntax
Command Possible response(s)
+CCWA=[ & lt; n & gt; [, & lt; mode & gt; [, & lt; class & gt; ]]] +CME ERROR: & lt; err & gt;
when & lt; mode & gt; =2 and command successful
+CCWA: & lt; status & gt; , & lt; class1 & gt;
[ & lt; CR & gt; & lt; LF & gt; +CCWA: & lt; status & gt; , & lt; class2 & gt;
[...]]
+CCWA? +CCWA: & lt; n & gt;
+CCWA=? +CCWA: (list of supported & lt; n & gt; s)
Description
This command allows control of the Call Waiting supplementary service
according to GSM 02.83 [5]. Activation, deactivation and status query
are supported. When querying the status of a network service ( & lt; mode & gt; =2)
the response line for `not active' case ( & lt; status & gt; =0) should be returned
only if service is not active for any & lt; class & gt; . Parameter & lt; n & gt; is used to
disable/enable the presentation of an unsolicited result code +CCWA:
& lt; number & gt; , & lt; type & gt; , & lt; class & gt; [, & lt; alpha & gt; ] to the TE when call waiting service is
enabled. Command should be abortable when network is interrogated.
The interaction of this command with other commands based on other GSM
supplementary services is described in the GSM standard.
Test command returns values supported by the TA as a compound value.
Defined values
& lt; n & gt; (sets/shows the result code presentation status in the TA):
0 disable
1 enable
& lt; mode & gt; (when & lt; mode & gt; parameter is not given, network is not
interrogated):
0 disable
1 enable
2 query status
& lt; classx & gt; is a sum of integers each representing a class of information
(default 7):
1 voice (telephony)
2 data (refers to all bearer services; with & lt; mode & gt; =2 this may refer only
to some bearer service if TA does not support values 16, 32, 64 and 128)
4 fax (facsimile services)
8 short message service
16 data circuit sync
32 data circuit async
64 dedicated packet access
128 dedicated PAD access
& lt; status & gt; :
0 not active
1 active
& lt; number & gt; : string type phone number of calling address in format
specified by & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7)
& lt; alpha & gt; : optional string type alphanumeric representation of & lt; number & gt;
corresponding to the entry found in phonebook; used character set should
be the one selected with command Select TE Character Set +CSCS
Implementation
Optional.
7.12 Call related supplementary services +CHLD
Table SEQ Table 39 : +CHLD action command syntax
Command Possible response(s)
+CHLD=[ & lt; n & gt; ] +CME ERROR: & lt; err & gt;
+CHLD=? [+CHLD: (list of supported & lt; n & gt; s)]
Description
This command allows the control of the following call related services:
- a call can be temporarily disconnected from the ME but the connection
is retained by the network
- multiparty conversation (conference calls)
- the served subscriber who has two calls (one held and the other either
active or alerting) can connect the other parties and release the served
subscriber's own connection
Calls can be put on hold, recovered, released, added to conversation,
and transferred similarly as defined in GSM 02.30 [19]. Refer
subclause 9.2 for possible & lt; err & gt; values.
This is based on the GSM supplementary services HOLD (Call Hold; refer
GSM 02.83 [5] clause 2), MPTY (MultiParty; refer GSM 02.84 [22]) and ECT
(Explicit Call Transfer; refer GSM 02.91 [29]). The interaction of this
command with other commands based on other GSM supplementary services is
described in the GSM standard.
NOTE: Call Hold, MultiParty and Explicit Call Transfer are only
applicable to teleservice 11.
It is recommended (although optional) that test command returns a list
of operations which are supported. The call number required by some
operations shall be denoted by " x " (e.g. +CHLD: (0,1,1x,2,2x,3)).
Defined values
& lt; n & gt; : integer type; equals to numbers entered before SEND button in
GSM 02.30 [19] subclause 4.5.5.1
NOTE: The " directory number " case shall be handled with dial command D,
and the END case with hangup command H (or +CHUP). The 4*``directory
number'' case is handled with +CTFR command.
Implementation
Optional.
7.13 Call deflection +CTFR
Table SEQ Table 40 : +CTFR action command syntax
Command Possible response(s)
+CTFR= & lt; number & gt; [, & lt; type & gt; [, & lt; subaddr & gt; [, & lt; satype & gt; ]]] +CME ERROR: & lt; err & gt;
+CTFR=?
Description
This refers to a service that causes an incoming alerting call to be
forwarded to a specified number. Action command does this. Refer
subclause 9.2 for possible & lt; err & gt; values.
This is based on the GSM supplementary service CD (Call Deflection;
refer GSM 02.72 [30]). The interaction of this command with other
commands based on other GSM supplementary services is described in the
GSM standard.
NOTE: Call Deflection is only applicable to teleservice 11.
Defined values
& lt; number & gt; : string type phone number of format specified by & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7); default 145 when dialling string includes
international access code character " + " , otherwise 129
& lt; subaddr & gt; : string type subaddress of format specified by & lt; satype & gt;
& lt; satype & gt; : type of subaddress octet in integer format (refer GSM 04.08
[8] subclause 10.5.4.8); default 128
Implementation
Optional.
7.14 Unstructured supplementary service data +CUSD
Table SEQ Table 41 : +CUSD parameter command syntax
Command Possible response(s)
+CUSD=[ & lt; n & gt; [, & lt; str & gt; [, & lt; dcs & gt; ]]] +CME ERROR: & lt; err & gt;
+CUSD? +CUSD: & lt; n & gt;
+CUSD=? +CUSD: (list of supported & lt; n & gt; s)
Description
This command allows control of the Unstuctured Supplementary Service
Data (USSD) according to GSM 02.90 [23]. Both network and mobile
initiated operations are supported. Parameter & lt; n & gt; is used to
disable/enable the presentation of an unsolicited result code (USSD
response from the network, or network initiated operation) +CUSD:
& lt; m & gt; [, & lt; str & gt; , & lt; dcs & gt; ] to the TE. In addition, value & lt; n & gt; =2 is used to cancel
an ongoing USSD session.
When & lt; str & gt; is given, a mobile initiated USSD-string or a response
USSD-string to a network initiated operation is sent to the network. The
response USSD-string from the network is returned in a subsequent
unsolicited +CUSD result code.
NOTE: In case of successful mobile initiated operation, TA implemented
according to a version prior to 6 of this standard, waits the USSD
response from the network and sends it to the TE before the final result
code. This will block the AT command interface for the period of the
operation. Such TA does not support & lt; n & gt; value 2.
The interaction of this command with other commands based on other GSM
supplementary services is described in the GSM standard.
Test command returns values supported by the TA as a compound value.
Defined values
& lt; n & gt; :
0 disable the result code presentation in the TA
1 enable the result code presentation in the TA
2 cancel session (not applicable to read command response)
& lt; str & gt; : string type USSD-string (when & lt; str & gt; parameter is not given,
network is not interrogated):
- if & lt; dcs & gt; indicates that GSM 03.38 [25] default alphabet is used:
- if TE character set other than " HEX " (refer command Select TE
Character Set +CSCS): ME/TA converts GSM alphabet into current TE
character set according to rules of GSM 07.05 [24] Annex A
- if TE character set is " HEX " : ME/TA converts each 7-bit character of
GSM alphabet into two IRA character long hexadecimal number (e.g.
character ( (GSM 23) is presented as 17 (IRA 49 and 55))
- if & lt; dcs & gt; indicates that 8-bit data coding scheme is used: ME/TA
converts each 8-bit octet into two IRA character long hexadecimal number
(e.g. octet with integer value 42 is presented to TE as two characters
2A (IRA 50 and 65))
& lt; dcs & gt; : GSM 03.38 [25] Cell Broadcast Data Coding Scheme in integer
format (default 0)
& lt; m & gt; :
0 no further user action required (network initiated USSD-Notify, or no
further information needed after mobile initiated operation)
1 further user action required (network initiated USSD-Request, or
further information needed after mobile initiated operation)
2 USSD terminated by network
3 other local client has responded
4 operation not supported
5 network time out
Implementation
Optional.
7.15 Advice of Charge +CAOC
Table SEQ Table 42 : +CAOC parameter command syntax
Command Possible response(s)
+CAOC[= & lt; mode & gt; ] [+CAOC: & lt; ccm & gt; ]
+CME ERROR: & lt; err & gt;
+CAOC? +CAOC: & lt; mode & gt;
+CAOC=? [+CAOC: (list of supported & lt; mode & gt; s]
Description
This refers to Advice of Charge supplementary service (GSM 02.24 [26]
and GSM 02.86 [27]) that enables subscriber to get information about the
cost of calls. With & lt; mode & gt; =0, the execute command returns the current
call meter value from the ME.
If $(AT R97)$ is supported, the command also includes the possibility to
enable an unsolicited event reporting of the CCM information. The
unsolicited result code +CCCM: & lt; ccm & gt; is sent when the CCM value changes,
but not more that every 10 seconds. Deactivation of the unsolicited
event reporting is made with the same command.
Refer subclause 9.2 for possible & lt; err & gt; values.
NOTE: Advice of Charge values stored in the SIM (ACM, ACMmax, PUCT) can
be accessed with generic or restricted SIM access command (+CSIM or
+CRSM)). If $(AT R97)$ is supported those values can be more readily
accessed with commands +CACM, +CAMM and +CPUC.
If $(AT R97)$ is supported, the Read command indicates whether the
unsolicited reporting is activated or not. Read command is available
when the unsolicited result code is supported.
It is recommended (although optional) that the test command returns the
supported mode values.
Defined values
& lt; mode & gt; : $(AT R97)$
0 query CCM value
1 deactivate the unsolicited reporting of CCM value
2 activate the unsolicited reporting of CCM value
& lt; ccm & gt; : string type; three bytes of the current call meter value in
hexadecimal format (e.g. " 00001E " indicates decimal value 30); value is
in home units and bytes are similarly coded as ACMmax value in the SIM
Implementation
Optional.
7.16 Supplementary service notifications +CSSN
Table SEQ Table 43 : +CSSN parameter command syntax
Command Possible response(s)
+CSSN=[ & lt; n & gt; [, & lt; m & gt; ]]
+CSSN? +CSSN: & lt; n & gt; , & lt; m & gt;
+CSSN=? +CSSN: (list of supported & lt; n & gt; s),(list of supported & lt; m & gt; s)
Description
This command refers to supplementary service related network initiated
notifications. The set command enables/disables the presentation of
notification result codes from TA to TE.
When & lt; n & gt; =1 and a supplementary service notification is received after a
mobile originated call setup, intermediate result code +CSSI:
& lt; code1 & gt; [, & lt; index & gt; ] is sent to TE before any other MO call setup result
codes presented in this ETS or in V.25ter [14]. When several different
& lt; code1 & gt; s are received from the network, each of them shall have its own
+CSSI result code.
When & lt; m & gt; =1 and a supplementary service notification is received during a
mobile terminated call setup or during a call, or when a forward check
supplementary service notification is received, unsolicited result code
+CSSU: & lt; code2 & gt; [, & lt; index & gt; [, & lt; number & gt; , & lt; type & gt; [, & lt; subaddr & gt; , & lt; satype & gt; ]]] is sent
to TE. In case of MT call setup, result code is sent after every +CLIP
result code (refer command " Calling line identification presentation
+CLIP " ) and when several different & lt; code2 & gt; s are received from the
network, each of them shall have its own +CSSU result code.
Test command returns values supported by the TA as a compound value.
Defined values
& lt; n & gt; (parameter sets/shows the +CSSI result code presentation status in
the TA):
0 disable
1 enable
& lt; m & gt; (parameter sets/shows the +CSSU result code presentation status in
the TA):
0 disable
1 enable
& lt; code1 & gt; (it is manufacturer specific, which of these codes are
supported):
0 unconditional call forwarding is active
1 some of the conditional call forwardings are active
2 call has been forwarded
3 call is waiting
4 this is a CUG call (also & lt; index & gt; present)
5 outgoing calls are barred
6 incoming calls are barred
7 CLIR suppression rejected
8 call has been deflected
& lt; index & gt; : refer " Closed user group +CCUG "
& lt; code2 & gt; (it is manufacturer specific, which of these codes are
supported):
0 this is a forwarded call (MT call setup)
1 this is a CUG call (also & lt; index & gt; present) (MT call setup)
2 call has been put on hold (during a voice call)
3 call has been retrieved (during a voice call)
4 multiparty call entered (during a voice call)
5 call on hold has been released (this is not a SS notification) (during
a voice call)
6 forward check SS message received (can be received whenever)
7 call is being connected (alerting) with the remote party in alerting
state in explicit call transfer operation (during a voice call)
8 call has been connected with the other remote party in explicit call
transfer operation (also number and subaddress parameters may be
present) (during a voice call or MT call setup)
9 this is a deflected call (MT call setup)
& lt; number & gt; : string type phone number of format specified by & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7)
& lt; subaddr & gt; : string type subaddress of format specified by & lt; satype & gt;
& lt; satype & gt; : type of subaddress octet in integer format (refer GSM 04.08
[8] subclause 10.5.4.8)
Implementation
Optional.
7.17 List current calls +CLCC
Table SEQ Table 44 :+CLCC action command syntax
Command Possible response(s)
+CLCC [+CLCC: & lt; id1 & gt; , & lt; dir & gt; , & lt; stat & gt; , & lt; mode & gt; , & lt; mpty & gt; [,
& lt; number & gt; , & lt; type & gt; [, & lt; alpha & gt; ]]
[ & lt; CR & gt; & lt; LF & gt; +CLCC: & lt; id2 & gt; , & lt; dir & gt; , & lt; stat & gt; , & lt; mode & gt; , & lt; mpty & gt; [,
& lt; number & gt; , & lt; type & gt; [, & lt; alpha & gt; ]]
[...]]]
+CME ERROR: & lt; err & gt;
+CLCC=?
Description
Returns list of current calls of ME. If command succeeds but no calls
are available, no information response is sent to TE. Refer subclause
9.2 for possible & lt; err & gt; values.
Defined values
& lt; idx & gt; : integer type; call identification number as described in GSM
02.30 [19] subclause 4.5.5.1; this number can be used in +CHLD command
operations
& lt; dir & gt; :
0 mobile originated (MO) call
1 mobile terminated (MT) call
& lt; stat & gt; (state of the call):
0 active
1 held
2 dialing (MO call)
3 alerting (MO call)
4 incoming (MT call)
5 waiting (MT call)
& lt; mode & gt; (bearer/teleservice):
0 voice
1 data
2 fax
3 voice followed by data, voice mode
4 alternating voice/data, voice mode
5 alternating voice/fax, voice mode
6 voice followed by data, data mode
7 alternating voice/data, data mode
8 alternating voice/fax, fax mode
9 unknown
& lt; mpty & gt; :
0 call is not one of multiparty (conference) call parties
1 call is one of multiparty (conference) call parties
& lt; number & gt; : string type phone number in format specified by & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7)
& lt; alpha & gt; : string type alphanumeric representation of & lt; number & gt;
corresponding to the entry found in phonebook; used character set should
be the one selected with command Select TE Character Set +CSCS
Implementation
Optional. Recommended when +CHLD command is implemented.
7.18 Preferred operator list +CPOL $(AT R97)$
Table SEQ Table 45 :+CPOL parameter command syntax
Command Possible response(s)
+CPOL=[ & lt; index & gt; ][, & lt; format & gt; [, & lt; oper & gt; ]] +CME ERROR: & lt; err & gt;
+CPOL? +CPOL: & lt; index1 & gt; , & lt; format & gt; , & lt; oper1 & gt;
[ & lt; CR & gt; & lt; LF & gt; +CPOL: & lt; index2 & gt; , & lt; format & gt; , & lt; oper2 & gt;
[...]]
+CME ERROR: & lt; err & gt;
+CPOL=? +CPOL: (list of supported & lt; index & gt; s),(list of supported
& lt; format & gt; s)+CME ERROR: & lt; err & gt;
Description
This command is used to edit the SIM preferred list of networks. Execute
command writes an entry in the SIM list of preferred operators
(EFPLMNsel). If & lt; index & gt; is given but & lt; oper & gt; is left out, entry is
deleted. If & lt; oper & gt; is given but & lt; index & gt; is left out, & lt; oper & gt; is put in
the next free location. If only & lt; format & gt; is given, the format of the
& lt; oper & gt; in the read command is changed. Refer subclause 9.2 for possible
& lt; err & gt; values.
NOTE: ME may also update this list automatically when new networks are
selected.
Read command returns all used entries from the SIM list of preferred
operators.
Test command returns the whole index range supported by the SIM.
Defined values
& lt; indexn & gt; : integer type; the order number of operator in the SIM
preferred operator list
& lt; format & gt; :
0 long format alphanumeric & lt; oper & gt;
1 short format alphanumeric & lt; oper & gt;
2 numeric & lt; oper & gt;
& lt; opern & gt; : string type; & lt; format & gt; indicates if the format is alphanumeric
or numeric (see +COPS)
Implementation
Optional.
7.19 Read operator names +COPN $(AT R97)$
Table SEQ Table 46 :+COPN action command syntax
Command Possible response(s)
+COPN +COPN: & lt; numeric1 & gt; , & lt; alpha1 & gt;
[ & lt; CR & gt; & lt; LF & gt; +COPN: & lt; numeric2 & gt; , & lt; alpha2 & gt;
[...]]
+CME ERROR: & lt; err & gt;
+COPN=?
Description
Execute command returns the list of operator names from the ME. Each
operator code & lt; numericn & gt; that has an alphanumeric equivalent & lt; alphan & gt; in
the ME memory shall be returned. Refer subclause 9.2 for possible & lt; err & gt;
values.
Defined values
& lt; numericn & gt; : string type; operator in numeric format (see +COPS)
& lt; alphan & gt; : string type; operator in long alphanumeric format (see +COPS)
Implementation
Optional.
7.20 Informative examples
This subclause includes all the GSM supplementary service related
commands, additional commands to lock ME and SIM capabilities, and
commands to check the network registration status.
An example where MSISDNs of a ME are queried, calls are forwarded to
different numbers when mobile is busy (CFB) or when it does not answer
(CFNRy). The status of CFNRy is read:
AT+CNUM
+CNUM: , " +358501234567 " ,145,,4 (voice number)
OK
AT+CCFC=1,1, " 931123456 " (enable CFB)
OK
AT+CCFC=2,1, " 921654321 " (enable CFNRy)
OK
AT+CCFC=1,2 (query CFNRy)
+CCFC: 1,7, " +35821654321 " ,145,,,20 (forward after 20 seconds)
OK
An example of Call Waiting (+CCWA), Call Related Supplementary Services
(+CHLD), and Connected Line Identification Presentation (+COLP) usage:
AT+CCWA=1,1;+COLP=1 (enable call waiting and COLP result codes)
OK
ATD9311234567; (originate a voice call)
+COLP: " +358311234567 " ,145
OK
...conversation...
+CCWA: " +358317654321 " ,145 (another call is waiting)
AT+CHLD=2 (put first call on hold and answer the second one)
OK
...conversation...
AT+CHLD=1 (release the second (active) call and recover the first
(held) call)
OK
ATH (release the first call)
OK
Call barring supplementary services are combined in one command,
Facility Lock (+CLCK), which is also used to restrict ME and SIM
functionality Some of the facilities require a password when enabled or
disabled. An additional command, Change Password (+CPWD), is defined for
changing the password of different barring and restriction facilities.
An example where locking status of outgoing international calls is
interrogated and then barred, and the password of the SIM card lock
(Personal Identity Number, PIN) is changed:
AT+CLCK= " OI " ,2
+CLCK: 0,7
OK
AT+CLCK= " OI " ,1, " 1234 "
OK
AT+CPWD= " SC " , " 4321 " , " 1234 "
OK
Operator Selection (+COPS) command is used for querying the status of
all GSM operators detected in the area, and switching between operators.
Following example illustrates a network selection sequence in Finland.
Two operators are found, the status of Tele is unknown and Radiolinja is
currently selected. Read command shows that automatic selection mode is
on and that Radiolinja is selected. Then an attempt is made to access
Tele, but it is denied (shown by +CME ERROR).
AT+COPS=?
+COPS: (2, " RADIOLINJA " , " RL " , " 24405 " ),(0, " TELE " , " TELE " , " 24491 " )
OK
AT+COPS?
+COPS: 0,0, " RADIOLINJA "
OK
AT+COPS=1,0, " TELE "
+CME ERROR: 3
When a terminal wanders between countries (i.e. networks), an
application may follow this e.g. with the following scenario:
AT+CREG=1 (enable +CREG: & lt; stat & gt; unsolicited result code)
OK
AT+CREG?
+CREG: 1,1 (ME is registered in home PLMN)
OK
AT+COPS=3,2;+COPS?;+COPS=3,0;+COPS?
+COPS: 0,2, " 24405 " (get the country...
+COPS: 0,0, " RADIOLINJA " ...and operator name)
OK
...user wanders to another PLMN...
+CREG: 2 (deregistered, roaming ongoing)
+CREG: 5 (registered again, not home PLMN)
AT+COPS=3,2;+COPS?;+COPS=3,0;+COPS?
+COPS: 0,2, " 24001 " (get the country...
+COPS: 0,0, " TELIA MOBITEL " ...and operator name)
OK
...user loses connection, no other PLMNs around...
+CREG: 0
8 Mobile Equipment control and status commands
This clause includes commands for ME power, keypad, display and
indicator handling. Also commands for selecting, reading and writing of
phonebooks, and setting real-time clock facilities are specified. Two
commands are specified for accessing SIM database records in a general
way.
Figure REF figecscmd \* MERGEFORMAT 7 illustrates the effect of
these commands. Command Phone Activity Status +CPAS indicates the
current general activity status of the ME. Command Set Phone
Functionality +CFUN is used to set the ME to different power consumption
states. Command Enter PIN +CPIN is used to enter ME passwords which are
needed before any other functionality of the ME can be used (e.g. SIM
PIN, PUK). Commands Generic SIM Access +CSIM and Restricted SIM Access
+CRSM can be used to access all data in SIM. Commands Battery Charge
+CBC and Signal Quality +CSQ are same as in TIA IS-135 [16] and they are
used to query the battery charge of the ME and the current RSSI of the
ME. Command Mobile Equipment Control Mode +CMEC is used to select the
controlling unit of ME keypad, display and indicators. Controlling
commands for the TE are Keypad Emulation +CKPD, Display Control +CDIS
and Indicator Control +CIND. If corresponding event reporting is enabled
with command Mobile Equipment Event Reporting +CMER, +CKEV is the result
code of a keypad event, +CDEV is the result code of a display event, and
+CIEV is the result code of an indicator event. Phonebook commands are
Select Phonebook Memory Storage +CPBS, Read Phonebook Entries +CPBR,
Find Phonebook Entries +CPBF and Write Phonebook Entry +CPBW. Additional
command Clock +CCLK can be used to control the real-time clock of the ME
if available. Command Alarm +CALA sets possible alarm clock facilities
of the ME.
Figure SEQ Figure 7 : Mobile equipment control and status commands
8.1 Phone activity status +CPAS
Table SEQ Table 47 : +CPAS action command syntax
Command Possible response(s)
+CPAS +CPAS: & lt; pas & gt;
+CME ERROR: & lt; err & gt;
+CPAS=? +CPAS: (list of supported & lt; pas & gt; s)
+CME ERROR: & lt; err & gt;
Description
Execution command returns the activity status & lt; pas & gt; of the ME. It can be
used to interrogate the ME before requesting action from the phone.
Refer subclause 9.2 for possible & lt; err & gt; values.
Test command returns values supported by the ME as a compound value.
Defined values
& lt; pas & gt; :
0 ready (ME allows commands from TA/TE)
1 unavailable (ME does not allow commands from TA/TE)
2 unknown (ME is not guaranteed to respond to instructions)
3 ringing (ME is ready for commands from TA/TE, but the ringer is
active)
4 call in progress (ME is ready for commands from TA/TE, but a call is
in progress)
5 asleep (ME is unable to process commands from TA/TE because it is in a
low functionality state)
also all other values below 128 are reserved by this ETS
Implementation
Mandatory when ME can be operated from TE (refer subclause " Mobile
Equipment control mode +CMEC " ).
8.2 Set phone functionality +CFUN
Table SEQ Table 48 : +CFUN parameter command syntax
Command Possible response(s)
+CFUN=[ & lt; fun & gt; [, & lt; rst & gt; ]] +CME ERROR: & lt; err & gt;
+CFUN? +CFUN: & lt; fun & gt;
+CME ERROR: & lt; err & gt;
+CFUN=? +CFUN: (list of supported & lt; fun & gt; s), (list of supported & lt; rst & gt; s)
+CME ERROR: & lt; err & gt;
Description
Set command selects the level of functionality & lt; fun & gt; in the ME. Level
" full functionality " is where the highest level of power is drawn.
" Minimum functionality " is where minimum power is drawn. Level of
functionality between these may also be specified by manufacturers. When
supported by manufacturers, ME resetting with & lt; rst & gt; parameter may be
utilized. Refer subclause 9.2 for possible & lt; err & gt; values.
NOTE: It is manufacturer specific does this command affect network
registration. Command Operator Selection +COPS is used to force
registration/deregistration.
Test command returns values supported by the ME as a compound value.
Defined values
& lt; fun & gt; :
0 minimum functionality
1 full functionality
2 disable phone transmit RF circuits only
3 disable phone receive RF circuits only
4 disable phone both transmit and receive RF circuits
5...127 reserved for manufacturers as intermediate states between full
and minimum functionality
& lt; rst & gt; :
0 do not reset the ME before setting it to & lt; fun & gt; power level
NOTE: This shall be always default when & lt; rst & gt; is not given.
1 reset the ME before setting it to & lt; fun & gt; power level
Implementation
Optional.
8.3 Enter PIN +CPIN
Table SEQ Table 49 : +CPIN parameter command syntax
Command Possible response(s)
+CPIN= & lt; pin & gt; [, & lt; newpin & gt; ] +CME ERROR: & lt; err & gt;
+CPIN? +CPIN: & lt; code & gt;
+CME ERROR: & lt; err & gt;
+CPIN=?
Description
Set command sends to the ME a password which is necessary before it can
be operated (SIM PIN, SIM PUK, PH-SIM PIN, etc.). If the PIN is to be
entered twice, the TA shall automatically repeat the PIN. If no PIN
request is pending, no action is taken towards ME and an error message,
+CME ERROR, is returned to TE. Refer subclause 9.2 for possible & lt; err & gt;
values.
If the PIN required is SIM PUK or SIM PUK2, the second pin is required.
This second pin, & lt; newpin & gt; , is used to replace the old pin in the SIM.
NOTE: Commands which interact with ME that are accepted when ME is
pending SIM PIN, SIM PUK, or PH-SIM are: +CGMI, +CGMM, +CGMR, +CGSN,
D112; (emergency call), +CPAS, +CFUN, +CPIN, +CDIS (read and test
command only), and +CIND (read and test command only).
Read command returns an alphanumeric string indicating whether some
password is required or not.
Defined values
& lt; pin & gt; , & lt; newpin & gt; : string type values
& lt; code & gt; values reserved by this ETS:
READY ME is not pending for any password
SIM PIN ME is waiting SIM PIN to be given
SIM PUK ME is waiting SIM PUK to be given
PH-SIM PIN ME is waiting phone-to-SIM card password to be given
PH-FSIM PIN ME is waiting phone-to-very first SIM card password to be
given
PH-FSIM PUK ME is waiting phone-to-very first SIM card unblocking
password to be given
SIM PIN2 ME is waiting SIM PIN2 to be given (this & lt; code & gt; is recommended
to be returned only when the last executed command resulted in PIN2
authentication failure (i.e. +CME ERROR: 17); if PIN2 is not entered
right after the failure, it is recommended that ME does not block its
operation)
SIM PUK2 ME is waiting SIM PUK2 to be given (this & lt; code & gt; is recommended
to be returned only when the last executed command resulted in PUK2
authentication failure (i.e. +CME ERROR: 18); if PUK2 and new PIN2 are
not entered right after the failure, it is recommended that ME does not
block its operation)
PH-NET PIN ME is waiting network personalisation password to be given
PH-NET PUK ME is waiting network personalisation unblocking password to
be given
PH-NETSUB PIN ME is waiting network subset personalisation password to
be given
PH-NETSUB PUK ME is waiting network subset personalisation unblocking
password to be given
PH-SP PIN ME is waiting service provider personalisation password to be
given
PH-SP PUK ME is waiting service provider personalisation unblocking
password to be given
PH-CORP PIN ME is waiting corporate personalisation password to be given
PH-CORP PUK ME is waiting corporate personalisation unblocking password
to be given
Implementation
Mandatory for ME not supporting the +CKPD command and supporting AT
commands only.
8.4 Battery charge +CBC
Table SEQ Table 50 : +CBC action command syntax
Command Possible response(s)
+CBC +CBC: & lt; bcs & gt; , & lt; bcl & gt;
+CME ERROR: & lt; err & gt;
+CBC=? +CBC: (list of supported & lt; bcs & gt; s),(list of supported & lt; bcl & gt; s)
Description
Execution command returns battery connection status & lt; bcs & gt; and battery
charge level & lt; bcl & gt; of the ME. Refer subclause 9.2 for possible & lt; err & gt;
values.
Test command returns values supported by the TA as compound values.
Defined values
& lt; bcs & gt; :
0 ME is powered by the battery
1 ME has a battery connected, but is not powered by it
2 ME does not have a battery connected
3 Recognized power fault, calls inhibited
& lt; bcl & gt; :
0 battery is exhausted, or ME does not have a battery connected
1...100 battery has 1-100 percent of capacity remaining
Implementation
Optional.
8.5 Signal quality +CSQ
Table SEQ Table 51 : +CSQ action command syntax
Command Possible response(s)
+CSQ +CSQ: & lt; rssi & gt; , & lt; ber & gt;
+CME ERROR: & lt; err & gt;
+CSQ=? +CSQ: (list of supported & lt; rssi & gt; s),(list of supported & lt; ber & gt; s)
Description
Execution command returns received signal strength indication & lt; rssi & gt; and
channel bit error rate & lt; ber & gt; from the ME. Refer subclause 9.2 for
possible & lt; err & gt; values.
Test command returns values supported by the TA as compound values.
Defined values
& lt; rssi & gt; :
0 -113 dBm or less
1 -111 dBm
2...30 -109... -53 dBm
31 -51 dBm or greater
99 not known or not detectable
& lt; ber & gt; (in percent):
0...7 as RXQUAL values in the table in GSM 05.08 [20] subclause 8.2.4
99 not known or not detectable
Implementation
Optional.
8.6 Mobile Equipment control mode +CMEC
Table SEQ Table 52 : +CMEC parameter command syntax
Command Possible response(s)
+CMEC=[ & lt; keyp & gt; [, & lt; disp & gt; [, & lt; ind & gt; ]]] +CME ERROR: & lt; err & gt;
+CMEC? +CMEC: & lt; keyp & gt; , & lt; disp & gt; , & lt; ind & gt;
+CMEC=? +CMEC: (list of supported & lt; keyp & gt; s),(list of supported
& lt; disp & gt; s),(list of supported & lt; ind & gt; s)
Description
Set command selects the equipment, which operates ME keypad, writes to
ME display and sets ME indicators. If operation mode is not allowed by
the ME, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt;
values.
Test command returns the modes supported by the TA as compound values.
Defined values
& lt; keyp & gt; :
0 ME can be operated only through its keypad (execute command of +CKPD
cannot be used)
1 ME can be operated only from TE (with command +CKPD)
2 ME can be operated from both ME keypad and TE
& lt; disp & gt; :
0 only ME can write to its display (command +CDIS can only be used to
read the display)
1 only TE can write to ME display (with command +CDIS)
2 ME display can be written by both ME and TE
& lt; ind & gt; :
0 only ME can set the status of its indicators (command +CIND can only
be used to read the indicators)
1 only TE can set the status of ME indicators (with command +CIND)
2 ME indicators can be set by both ME and TE
Implementation
Mandatory when any of keypad, display or indicator commands is
implemented.
8.7 Keypad control +CKPD
Table SEQ Table 53 : +CKPD action command syntax
Command Possible response(s)
+CKPD= & lt; keys & gt; [, & lt; time & gt; [, & lt; pause & gt; ]] +CME ERROR: & lt; err & gt;
+CKPD=?
Description
Execution command emulates ME keypad by giving each keystroke as a
character in a string & lt; keys & gt; . & lt; time & gt; *0.1 seconds is the time to stroke
each key and & lt; pause & gt; *0.1 seconds is the length of pause between two
strokes. If emulating fails in an ME error, +CME ERROR: & lt; err & gt; is
returned. Refer subclause 9.2 for & lt; err & gt; values. This command should be
accepted (OK returned) before actually starting to press the keys. Thus
unsolicited result codes of key pressings and display events can be
returned (refer subclause " Mobile Equipment event reporting +CMER " ).
Defined values
& lt; keys & gt; : string of characters representing keys as listed in the
following table (based on PCCA STD-101 Annex table I-3). Colon character
(IRA 58) followed by one character can be used to indicate a
manufacturer specific key not listed here. All characters from a
semicolon character (IRA 59) to the next single semicolon character are
treated as alpha entries and are not converted to key equivalents. All
semicolon characters inside alpha entries should be duplicated in the TE
and stripped to one before entering to the ME. Pause character (IRA 87
or 119) can be used to pause between key pressings for a time specified
by & lt; pause & gt; . All IRA values not listed here are reserved.
Table SEQ Table 54 : Character codes
Char IRA (dec) Comment (+ some known key symbols)
# 35 hash (number sign)
% 37 percent sign (P)
* 42 star (*)
0... 9 48... 57 number keys
: 58 escape character for manufacturer specific keys
; 59 escape character for string entering
& lt; 60 left arrow
& gt; 62 right arrow
@ 64 alpha key (a/ABC)
A/a 65/97 channel A (A)
B/b 66/98 channel B (B)
C/c 67/99 clear display (C/CLR)
D/d 68/100 volume down
E/e 69/101 connection end (END)
F/f 70/102 function (FCN)
L/l 76/108 phone lock (LOCK)
M/m 77/109 menu (MENU)
P/p 80/112 power (PWR)
Q/q 81/113 quiet/mute (MUTE)
R/r 82/114 recall last number (R/RCL/MR)
S/s 83/115 connection start (SEND)
T/t 84/116 store/ memory (STO/M/M+)
U/u 85/117 volume up
V/v 86/118 down arrow
W/w 87/119 pause character
X/x 88/120 auxiliary (AUX)
Y/y 89/121 delete last character (C)
[ 91 soft key 1
] 93 soft key 2
^ 94 up arrow
& lt; time & gt; , & lt; pause & gt; :
0...255 0... 25.5 seconds (default values are manufacturer specific, but
should be so long that a normal ME can handle keystrokes correctly)
Implementation
Mandatory for ME not supporting the +CPIN command and supporting AT
commands only.
8.8 Display control +CDIS
Table SEQ Table 55 : +CDIS parameter command syntax
Command Possible response(s)
+CDIS=[ & lt; text & gt; [, & lt; text & gt; [,...]]] +CME ERROR: & lt; err & gt;
+CDIS? +CDIS: & lt; text & gt; [, & lt; text & gt; [,...]]
+CME ERROR: & lt; err & gt;
+CDIS=? +CDIS: & lt; length & gt; [, & lt; length & gt; [,...]]
+CME ERROR: & lt; err & gt;
Description
Set command is used to write the contents of ME text type display
elements. An element can consist of one character or several characters.
The order of element parameters & lt; text & gt; should follow the rule: first is
the element in upper left corner, second is the next element to the
right and so on. The last element is the element in lower right corner.
The number of elements is ME specific. If ME does not allow writing to
its display or ME is not currently reachable, +CME ERROR: & lt; err & gt; is
returned. Refer subclause 9.2 for & lt; err & gt; values. If certain element is
not writable, setting of it should be ignored. If element parameter is
empty field, element shall remain in the previous value.
NOTE: This command cannot be used to write to a display which sum of
element lengths exceed the length of the command line buffer of the TA.
Read command returns the contents of ME display elements. If & lt; text & gt;
field is empty (not empty string), ME does not allow the reading of
corresponding element. If ME is not currently reachable, +CME ERROR:
& lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt; values.
Test command returns maximum length of each display element. If ME does
not offer the length of elements, & lt; length & gt; fields should be empty. If ME
is not currently reachable, +CME ERROR: & lt; err & gt; is returned. Refer
subclause 9.2 for & lt; err & gt; values.
NOTE: ME manufacturer should offer the order and maximum length of
elements.
Defined values
& lt; text & gt; : string type parameter using character set specified by command
Select TE Character Set +CSCS
& lt; length & gt; : integer type parameter giving the maximum length of
corresponding & lt; text & gt; parameter
Implementation
Optional.
8.9 Indicator control +CIND
Table SEQ Table 56 : +CIND parameter command syntax
Command Possible response(s)
+CIND=[ & lt; ind & gt; [, & lt; ind & gt; [,...]]] +CME ERROR: & lt; err & gt;
+CIND? +CIND: & lt; ind & gt; [, & lt; ind & gt; [,...]]
+CME ERROR: & lt; err & gt;
+CIND=? +CIND: ( & lt; descr & gt; ,(list of supported & lt; ind & gt; s)) [,( & lt; descr & gt; ,(list of
supported & lt; ind & gt; s))[,...]]
+CME ERROR: & lt; err & gt;
Description
Set command is used to set the values of ME indicators. & lt; ind & gt; value 0
means that the indicator is off (or in state which can be identified as
" off " -state), 1 means that indicator is on (or in a state which is more
substantial than " off " -state), 2 is more substantial than 1, and so on.
If the indicator is a simple on/off style element, it has values 0 and
1. The number of elements is ME specific. If ME does not allow setting
of indicators or ME is not currently reachable, +CME ERROR: & lt; err & gt; is
returned. Refer subclause 9.2 for & lt; err & gt; values. If certain indicator is
not writable, setting of it should be ignored. If parameter is empty
field, indicator shall remain in the previous value.
Read command returns the status of ME indicators. If ME is not currently
reachable, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt;
values.
Test command returns pairs, where string value & lt; descr & gt; is a maximum 16
character description of the indicator and compound value is the allowed
values for the indicator. If ME is not currently reachable, +CME ERROR:
& lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt; values.
NOTE: ME manufacturer should offer the description of supported
indicators not listed here and their value ranges and default values.
Defined values
& lt; ind & gt; : integer type value, which shall be in range of corresponding
& lt; descr & gt;
& lt; descr & gt; values reserved by this ETS and their & lt; ind & gt; ranges:
" battchg " battery charge level (0-5)
" signal " signal quality (0-5)
" service " service availability (0-1)
" sounder " sounder activity (0-1)
" message " message received (0-1)
" call " call in progress (0-1)
" vox " transmit activated by voice activity (0-1)
" roam " roaming indicator (0-1)
" smsfull " a short message memory storage in the MT has become full (1),
or memory locations are available (0); i.e. the range is (0-1)
Implementation
Optional.
8.10 Mobile Equipment event reporting +CMER
Table SEQ Table 57 : +CMER parameter command syntax
Command Possible response(s)
+CMER=[ & lt; mode & gt; [, & lt; keyp & gt; [, & lt; disp & gt; [, & lt; ind & gt; [, & lt; bfr & gt; ]]]]] +CME ERROR: & lt; err & gt;
+CMER? +CMER: & lt; mode & gt; , & lt; keyp & gt; , & lt; disp & gt; , & lt; ind & gt; , & lt; bfr & gt;
+CMER=? +CMER: (list of supported & lt; mode & gt; s),(list of supported
& lt; keyp & gt; s),(list of supported & lt; disp & gt; s),(list of supported & lt; ind & gt; s),(list of
supported & lt; bfr & gt; s)
Description
Set command enables or disables sending of unsolicited result codes from
TA to TE in the case of key pressings, display changes, and indicator
state changes. & lt; mode & gt; controls the processing of unsolicited result
codes specified within this command. & lt; bfr & gt; controls the effect on
buffered codes when & lt; mode & gt; 1, 2 or 3 is entered. If setting is not
supported by the ME, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2
for & lt; err & gt; values.
Test command returns the modes supported by the TA as compound values.
Defined values
& lt; mode & gt; :
0 buffer unsolicited result codes in the TA; if TA result code buffer is
full, codes can be buffered in some other place or the oldest ones can
be discarded
1 discard unsolicited result codes when TA-TE link is reserved (e.g. in
on-line data mode); otherwise forward them directly to the TE
2 buffer unsolicited result codes in the TA when TA-TE link is reserved
(e.g. in on-line data mode) and flush them to the TE after reservation;
otherwise forward them directly to the TE
3 forward unsolicited result codes directly to the TE; TA-TE link
specific inband technique used to embed result codes and data when TA is
in on-line data mode
& lt; keyp & gt; :
0 no keypad event reporting
1 keypad event reporting using result code +CKEV: & lt; key & gt; , & lt; press & gt; . & lt; key & gt;
indicates the key (refer IRA values defined in table in subclause
" Keypad control +CKPD " ) and & lt; press & gt; if the key is pressed or released (1
for pressing and 0 for releasing). Only those key pressings, which are
not caused by +CKPD shall be indicated by the TA to the TE.
NOTE: When this mode is enabled, corresponding result codes of all keys
currently pressed should be flushed to the TA regardless of & lt; bfr & gt;
setting.
2 keypad event reporting using result code +CKEV: & lt; key & gt; , & lt; press & gt; . All key
pressings shall be directed from TA to TE.
NOTE: When this mode is enabled, corresponding result codes of all keys
currently pressed should be flushed to the TA regardless of & lt; bfr & gt;
setting.
& lt; disp & gt; :
0 no display event reporting
1 display event reporting using result code +CDEV: & lt; elem & gt; , & lt; text & gt; . & lt; elem & gt;
indicates the element order number (as specified for +CDIS) and & lt; text & gt;
is the new value of text element. Only those display events, which are
not caused by +CDIS shall be indicated by the TA to the TE. Character
set used in & lt; text & gt; is as specified by command Select TE Character Set
+CSCS
2 display event reporting using result code +CDEV: & lt; elem & gt; , & lt; text & gt; . All
display events shall be directed from TA to TE. Character set used in
& lt; text & gt; is as specified by command Select TE Character Set +CSCS
& lt; ind & gt; :
0 no indicator event reporting
1 indicator event reporting using result code +CIEV: & lt; ind & gt; , & lt; value & gt; .
& lt; ind & gt; indicates the indicator order number (as specified for +CIND) and
& lt; value & gt; is the new value of indicator. Only those indicator events,
which are not caused by +CIND shall be indicated by the TA to the TE
2 indicator event reporting using result code +CIEV: & lt; ind & gt; , & lt; value & gt; . All
indicator events shall be directed from TA to TE
& lt; bfr & gt; :
0 TA buffer of unsolicited result codes defined within this command is
cleared when & lt; mode & gt; 1...3 is entered
1 TA buffer of unsolicited result codes defined within this command is
flushed to the TE when & lt; mode & gt; 1...3 is entered (OK response shall be
given before flushing the codes)
Implementation
Mandatory when any of the keypad, display, or indicator result codes is
implemented.
8.11 Select phonebook memory storage +CPBS
Table SEQ Table 58 : +CPBS parameter command syntax
Command Possible response(s)
+CPBS= & lt; storage & gt; +CME ERROR: & lt; err & gt;
+CPBS? +CPBS: & lt; storage & gt; [, & lt; used & gt; , & lt; total & gt; ]
+CME ERROR: & lt; err & gt;
+CPBS=? +CPBS: (list of supported & lt; storage & gt; s)
Description
Set command selects phonebook memory storage & lt; storage & gt; , which is used by
other phonebook commands. If setting fails in an ME error, +CME ERROR:
& lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt; values.
Read command returns currently selected memory, and when supported by
manufacturer, number of used locations and total number of locations in
the memory.
Test command returns supported storages as compound value.
Defined values
& lt; storage & gt; values reserved by this ETS:
" DC " ME dialled calls list (+CPBW may not be applicable for this
storage) $(AT R97)$
" EN " SIM (or ME) emergency number (+CPBW is not be applicable for this
storage) $(AT R97)$
" FD " SIM fixdialling-phonebook
" LD " SIM last-dialling-phonebook
" MC " ME missed (unanswered received) calls list (+CPBW may not be
applicable for this storage)
" ME " ME phonebook
" MT " combined ME and SIM phonebook
" ON " SIM (or ME) own numbers (MSISDNs) list (reading of this storage may
be available through +CNUM also) $(AT R97)$
" RC " ME received calls list (+CPBW may not be applicable for this
storage) $(AT R97)$
" SM " SIM phonebook
" TA " TA phonebook
& lt; used & gt; : integer type value indicating the number of used locations in
selected memory
& lt; total & gt; : integer type value indicating the total number of locations in
selected memory
Implementation
Mandatory when phonebook read, find or write command, or direct dialling
(refer subclause " Direct dialling from phonebooks " ) is implemented.
8.12 Read phonebook entries +CPBR
Table 54: +CPBR action command syntax
Command Possible response(s)
+CPBR= & lt; index1 & gt;
[, & lt; index2 & gt; ] [+CPBR: & lt; index1 & gt; , & lt; number & gt; , & lt; type & gt; , & lt; text & gt; [[...]
& lt; CR & gt; & lt; LF & gt; +CPBR: & lt; index2 & gt; , & lt; number & gt; , & lt; type & gt; , & lt; text & gt; ]]
+CME ERROR: & lt; err & gt;
+CPBR=? +CPBR: (list of supported & lt; index & gt; s),[ & lt; nlength & gt; ],[ & lt; tlength & gt; ]
+CME ERROR: & lt; err & gt;
Description
Execution command returns phonebook entries in location number range
& lt; index1 & gt; ... & lt; index2 & gt; from the current phonebook memory storage selected
with +CPBS. If & lt; index2 & gt; is left out, only location & lt; index1 & gt; is returned.
Entry fields returned are location number & lt; indexn & gt; , phone number stored
there & lt; number & gt; (of format & lt; type & gt; ) and text & lt; text & gt; associated with the
number. If all queried locations are empty (but available), no
information text lines may be returnedIf listing fails in an ME error,
+CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt; values.
Test command returns location range supported by the current storage as
a compound value and the maximum lengths of & lt; number & gt; and & lt; text & gt; fields.
In case of SIM storage, the lengths may not be available. If ME is not
currently reachable, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2
for & lt; err & gt; values.
Defined values
& lt; index1 & gt; , & lt; index2 & gt; , & lt; index & gt; : integer type values in the range of
location numbers of phonebook memory
& lt; number & gt; : string type phone number of format & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7)
& lt; text & gt; : string type field of maximum length & lt; tlength & gt; ; character set as
specified by command Select TE Character Set +CSCS
& lt; nlength & gt; : integer type value indicating the maximum length of field
& lt; number & gt;
& lt; tlength & gt; : integer type value indicating the maximum length of field
& lt; text & gt;
Implementation
Optional.
8.13 Find phonebook entries +CPBF
Table 55: +CPBF action command syntax
Command Possible response(s)
+CPBF= & lt; findtext & gt; [+CPBF: & lt; index1 & gt; , & lt; number & gt; , & lt; type & gt; , & lt; text & gt; [[...]
& lt; CR & gt; & lt; LF & gt; +CBPF: & lt; index2 & gt; , & lt; number & gt; , & lt; type & gt; , & lt; text & gt; ]]
+CME ERROR: & lt; err & gt;
+CPBF=? +CPBF: [ & lt; nlength & gt; ],[ & lt; tlength & gt; ]
+CME ERROR: & lt; err & gt;
Description
Execution command returns phonebook entries (from the current phonebook
memory storage selected with +CPBS) which alphanumeric field start with
string & lt; findtext & gt; . Entry fields returned are location number & lt; indexn & gt; ,
phone number stored there & lt; number & gt; (of format & lt; type & gt; ) and text & lt; text & gt;
associated with the number. If listing fails in an ME error, +CME ERROR:
& lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt; values.
Test command returns the maximum lengths of & lt; number & gt; and & lt; text & gt; fields.
In case of SIM storage, the lengths may not be available. If ME is not
currently reachable, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2
for & lt; err & gt; values.
Defined values
& lt; index1 & gt; , & lt; index2 & gt; : integer type values in the range of location numbers
of phonebook memory
& lt; number & gt; : string type phone number of format & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7)
& lt; findtext & gt; , & lt; text & gt; : string type field of maximum length & lt; tlength & gt; ;
character set as specified by command Select TE Character Set +CSCS
& lt; nlength & gt; : integer type value indicating the maximum length of field
& lt; number & gt;
& lt; tlength & gt; : integer type value indicating the maximum length of field
& lt; text & gt;
Implementation
Optional.
8.14 Write phonebook entry +CPBW
Table 56: +CPBW action command syntax
Command Possible response(s)
+CPBW=[ & lt; index & gt; ][, & lt; number & gt;
[, & lt; type & gt; [, & lt; text & gt; ]]] +CME ERROR: & lt; err & gt;
+CPBW=? +CPBW: (list of supported & lt; index & gt; s),[ & lt; nlength & gt; ],
(list of supported & lt; type & gt; s),[ & lt; tlength & gt; ]
+CME ERROR: & lt; err & gt;
Description
Execution command writes phonebook entry in location number & lt; index & gt; in
the current phonebook memory storage selected with +CPBS. Entry fields
written are phone number & lt; number & gt; (in the format & lt; type & gt; ) and text & lt; text & gt;
associated with the number. If those fields are omitted, phonebook entry
is deleted. If & lt; index & gt; is left out, but & lt; number & gt; is given, entry is
written to the first free location in the phonebook (the implementation
of this feature is manufacturer specific). If writing fails in an ME
error, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt;
values.
Test command returns location range supported by the current storage as
a compound value, the maximum length of & lt; number & gt; field, supported number
formats of the storage, and the maximum length of & lt; text & gt; field. In case
of SIM storage, the lengths may not be available. If ME is not currently
reachable, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt;
values. If storage does not offer format information, the format list
should be empty parenthesis
Defined values
& lt; index & gt; : integer type values in the range of location numbers of
phonebook memory
& lt; number & gt; : string type phone number of format & lt; type & gt;
& lt; type & gt; : type of address octet in integer format (refer GSM 04.08 [8]
subclause 10.5.4.7) ; default 145 when dialling string includes
international access code character " + " , otherwise 129
& lt; text & gt; : string type field of maximum length & lt; tlength & gt; ; character set as
specified by command Select TE Character Set +CSCS
& lt; nlength & gt; : integer type value indicating the maximum length of field
& lt; number & gt;
& lt; tlength & gt; : integer type value indicating the maximum length of field
& lt; text & gt;
Implementation
Optional.
8.15 Clock +CCLK
Table SEQ Table 59 : +CCLK parameter command syntax
Command Possible response(s)
+CCLK= & lt; time & gt; +CME ERROR: & lt; err & gt;
+CCLK? +CCLK: & lt; time & gt;
+CME ERROR: & lt; err & gt;
+CCLK=?
Description
Set command sets the real-time clock of the ME. If setting fails in an
ME error, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt;
values.
Read command returns the current setting of the clock.
Defined values
& lt; time & gt; : string type value; format is " yy/MM/dd,hh:mm:ss(zz " , where
characters indicate year (two last digits), month, day, hour, minutes,
seconds and time zone (indicates the difference, expressed in quarters
of an hour, between the local time and GMT; range -47...+48). E.g. 6th
of May 1994, 22:10:00 GMT+2 hours equals to " 94/05/06,22:10:00+08 "
NOTE: If ME does not support time zone information then the three last
characters of & lt; time & gt; are not returned by +CCLK?.
Implementation
Optional.
8.16 Alarm +CALA
Table 58: +CALA parameter command syntax
Command Possible response(s)
+CALA= & lt; time & gt; [, & lt; n & gt; [, & lt; type & gt;
[, & lt; text & gt; ]]] +CME ERROR: & lt; err & gt;
+CALA? [+CALA: & lt; time & gt; , & lt; n1 & gt; , & lt; type & gt; ,[ & lt; text & gt; ]
[ & lt; CR & gt; & lt; LF & gt; +CALA: & lt; time & gt; , & lt; n2 & gt; , & lt; type & gt; ,[ & lt; text & gt; ]
[...]]]
+CME ERROR: & lt; err & gt;
+CALA=? +CALA: (list of supported & lt; n & gt; s),(list of supported
& lt; type & gt; s), & lt; tlength & gt;
+CME ERROR: & lt; err & gt;
Description
Set command sets an alarm time in the ME. There can be an array of
different types of alarms, and each alarm may cause different text to be
displayed in the ME display. If setting fails in an ME error, +CME
ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt; values.
Read command returns the list of current active alarm settings in the
ME.
Test command returns supported array index values, alarm types, and
maximum length of the text to be displayed.
Defined values
& lt; time & gt; : refer +CCLK
& lt; n & gt; , & lt; n1 & gt; , & lt; n2 & gt; : integer type value indicating the index of the alarm;
default is manufacturer specific
& lt; type & gt; : integer type value indicating the type of the alarm (e.g. sound,
volume, LED); values and default are manufacturer specific
& lt; text & gt; : string type value indicating the text to be displayed when alarm
time is reached; maximum length & lt; tlength & gt;
& lt; tlength & gt; : integer type value indicating the maximum length of & lt; text & gt;
Implementation
Optional.
8.17 Generic SIM access +CSIM
Table SEQ Table 60 : +CSIM action command syntax
Command Possible response(s)
+CSIM= & lt; length & gt; , & lt; command & gt; +CSIM: & lt; length & gt; , & lt; response & gt;
+CME ERROR: & lt; err & gt;
+CSIM=?
Description
Set command transmits to the ME the & lt; command & gt; it then shall send as it
is to the SIM. In the same manner the SIM & lt; response & gt; shall be sent back
by the ME to the TA as it is. Refer subclause 9.2 for & lt; err & gt; values.
This command allows a direct control of the SIM by an distant
application on the TE. The TE shall then take care of processing SIM
information within the frame specified by GSM.
NOTE: Compared to Restricted SIM Access command +CRSM, the definition of
+CSIM allows TE to take more control over the SIM-ME interface. The
locking and unlocking of the interface may be done by a special
& lt; command & gt; value or automatically by TA/ME (by interpreting & lt; command & gt;
parameter). In case that TE application does not use the unlock command
(or does not send a & lt; command & gt; causing automatic unlock) in a certain
timeout value, ME may release the locking.
Defined values
& lt; length & gt; : integer type; length of the characters that are sent to TE in
& lt; command & gt; or & lt; response & gt; (two times the actual length of the command or
response)
& lt; command & gt; : command passed on by the ME to the SIM in the format as
described in GSM 11.11 [28] (hexadecimal character format; refer +CSCS)
& lt; response & gt; : response to the command passed on by the SIM to the ME in
the format as described in GSM 11.11 [28] (hexadecimal character format;
refer +CSCS)
Implementation
Optional.
8.18 Restricted SIM access +CRSM
Table SEQ Table 61 : +CRSM action command syntax
Command Possible response(s)
+CRSM= & lt; command & gt; [, & lt; fileid & gt;
[, & lt; P1 & gt; , & lt; P2 & gt; , & lt; P3 & gt; [, & lt; data & gt; ]]] +CRSM: & lt; sw1 & gt; , & lt; sw2 & gt; [, & lt; response & gt; ]
+CME ERROR: & lt; err & gt;
+CRSM=?
Description
By using this command instead of Generic SIM Access +CSIM TE application
has easier but more limited access to the SIM database. Set command
transmits to the ME the SIM & lt; command & gt; and its required parameters. ME
handles internally all SIM-ME interface locking and file selection
routines. As response to the command, ME sends the actual SIM
information parameters and response data. ME error result code +CME
ERROR may be returned when the command cannot be passed to the SIM, but
failure in the execution of the command in the SIM is reported in & lt; sw1 & gt;
and & lt; sw2 & gt; parameters. Refer to subclause 9.2 for & lt; err & gt; values.
Coordination of command requests to SIM and the ones issued by GSM
application inside the ME is implementation dependent. However the TE
should be aware of the precedence of the GSM application commands to the
TE commands.
Defined values
& lt; command & gt; (command passed on by the ME to the SIM; refer
GSM 11.11 [28]):
176 READ BINARY
178 READ RECORD
192 GET RESPONSE
214 UPDATE BINARY
220 UPDATE RECORD
242 STATUS
all other values are reserved
NOTE: The ME internally executes all commands necessary for selecting
the desired file, before performing the actual command.
& lt; fileid & gt; : integer type; this is the identifier of a elementary datafile
on SIM. Mandatory for every command except STATUS
NOTE: The range of valid file identifiers depends on the actual SIM and
is defined in GSM 11.11 [28]. Optional files may not be present at all.
& lt; P1 & gt; , & lt; P2 & gt; , & lt; P3 & gt; : integer type; parameters passed on by the ME to the
SIM. These parameters are mandatory for every command, except GET
RESPONSE and STATUS. The values are described in GSM 11.11 [28]
& lt; data & gt; : information which shall be written to the SIM (hexadecimal
character format; refer +CSCS)
& lt; sw1 & gt; , & lt; sw2 & gt; : integer type; information from the SIM about the execution
of the actual command. These parameters are delivered to the TE in both
cases, on successful or failed execution of the command
& lt; response & gt; : response of a successful completion of the command
previously issued (hexadecimal character format; refer +CSCS). STATUS
and GET RESPONSE return data, which gives information about the current
elementary datafield. This information includes the type of file and its
size (refer GSM 11.11 [28]). After READ BINARY or READ RECORD command
the requested data will be returned. & lt; response & gt; is not returned after a
successful UPDATE BINARY or UPDATE RECORD command
Implementation
Optional.
8.19 Secure control command +CSCC
Table SEQ Table 62 : +CSCC parameter command syntax
Command Possible response(s)
+CSCC= & lt; mode & gt; [, & lt; cmd_set & gt; [, & lt; token & gt; ]] +CSCC: & lt; challenge & gt;
+CME ERROR: & lt; err & gt;
+CSCC? +CSCC: & lt; mode & gt; , & lt; cmd_set1 & gt;
[ & lt; CR & gt; & lt; LF & gt; +CSCC: & lt; mode & gt; , & lt; cmd_set2 & gt;
[...]]
+CME ERROR: & lt; err & gt;
+CSCC=? +CSCC: (list of supported & lt; mode & gt; s),(list of supported
& lt; cmd_set & gt; s)
Description
This command is used to enable/disable access to commands protected by
security mechanism. This enables/disables access to command sets
designated as ``secure'' such as programming of ME. Refer subclause 9.2
for possible & lt; err & gt; values.
The TE asks for a & lt; challenge & gt; with & lt; mode & gt; =1 and one specific command set
( & lt; cmd_set & gt; ), the ME replies with the & lt; challenge & gt; , which should be
inserted into the identification algorithm in both entities (TE and ME).
The algorithm output & lt; token & gt; is sent to the ME with & lt; mode & gt; =2 to enable
the specified command set. & lt; mode & gt; =3 is used to disable the command set.
The read command returns the status ( & lt; mode & gt; 2 or 3) of each supported
command set.
Defined values
& lt; mode & gt; :
1 request challenge token to enable access to specified command set
2 enable access to specified command set ( & lt; token & gt; required)
3 disable access to specified command set
& lt; cmd_set & gt; , & lt; cmd_set1 & gt; , & lt; cmd_set2 & gt; :
0 MS code re-programming command set.
other values below 128 are reserved by this ETS
& lt; token & gt; : string type; a variable length bit string represented with IRA
characters 0 - 9 and A - F, each character representing a nibble; e.g.
bit string ``0110 1100 1001 1010'' is represented by the IRA string
``6C9A''. The length of the required bit string varies depending on the
value of & lt; cmd_set & gt; .
& lt; challenge & gt; : same format as token
Implementation
Optional.
8.20 Alert sound mode +CALM $(AT R97)$
Table SEQ Table 63 : +CALM parameter command syntax
Command Possible response(s)
+CALM= & lt; mode & gt; +CME ERROR: & lt; err & gt;
+CALM? +CALM: & lt; mode & gt;
+CME ERROR: & lt; err & gt;
+CALM=? +CALM: (list of supported & lt; mode & gt; s)
+CME ERROR: & lt; err & gt;
Description
This command is used to select the general alert sound mode of the ME.
Refer subclause 9.2 for possible & lt; err & gt; values.
Test command returns supported values as compound value.
Defined values
& lt; mode & gt; :
0 normal mode
1 silent mode (all sounds from ME are prevented)
2... manufacturer specific
Implementation
Optional.
8.21 Ringer sound level +CRSL $(AT R97)$
Table SEQ Table 64 : +CRSL parameter command syntax
Command Possible response(s)
+CRSL= & lt; level & gt; +CME ERROR: & lt; err & gt;
+CRSL? +CRSL: & lt; level & gt;
+CME ERROR: & lt; err & gt;
+CRSL=? +CRSL: (list of supported & lt; level & gt; s)
+CME ERROR: & lt; err & gt;
Description
This command is used to select the incoming call ringer sound level of
the ME. Refer subclause 9.2 for possible & lt; err & gt; values.
Test command returns supported values as compound value.
Defined values
& lt; level & gt; : integer type value with manufacturer specific range (smallest
value represents the lowest sound level)
Implementation
Optional.
8.22 Vibrator mode +CVIB $(AT R97)$
Table SEQ Table 65 : +CVIB parameter command syntax
Command Possible response(s)
+CVIB= & lt; mode & gt; +CME ERROR: & lt; err & gt;
+CVIB? +CVIB: & lt; mode & gt;
+CME ERROR: & lt; err & gt;
+CVIB=? +CVIB: (list of supported & lt; mode & gt; s)
+CME ERROR: & lt; err & gt;
Description
This command is used to enable and disable the vibrator alert feature of
the ME. It is manufacturer specific how this interacts with +CALM
command. Refer subclause 9.2 for possible & lt; err & gt; values.
Test command returns supported values as compound value.
Defined values
& lt; mode & gt; :
0 disable
1 enable
...15 reserved by this ETS
16... manufacturer specific
Implementation
Optional.
8.23 Loudspeaker volume level +CLVL $(AT R97)$
Table SEQ Table 66 : +CLVL parameter command syntax
Command Possible response(s)
+CLVL= & lt; level & gt; +CME ERROR: & lt; err & gt;
+CLVL? +CLVL: & lt; level & gt;
+CME ERROR: & lt; err & gt;
+CLVL=? +CLVL: (list of supported & lt; level & gt; s)
+CME ERROR: & lt; err & gt;
Description
This command is used to select the volume of the internal loudspeaker of
the ME. Refer subclause 9.2 for possible & lt; err & gt; values.
Test command returns supported values as compound value.
Defined values
& lt; level & gt; : integer type value with manufacturer specific range (smallest
value represents the lowest sound level)
Implementation
Optional.
8.24 Mute control +CMUT $(AT R97)$
Table SEQ Table 67 : +CMUT parameter command syntax
Command Possible response(s)
+CMUT= & lt; n & gt; +CME ERROR: & lt; err & gt;
+CMUT? +CMUT: & lt; n & gt;
+CME ERROR: & lt; err & gt;
+CMUT=? +CMUT: (list of supported & lt; n & gt; s)
Description
This command is used to enable and disable the uplink voice muting
during a voice call. Refer subclause 9.2 for possible & lt; err & gt; values.
Test command returns supported values as compound value.
Defined values
& lt; n & gt; :
0 mute off
1 mute on
Implementation
Optional.
8.25 Accumulated call meter +CACM $(AT R97)$
Table SEQ Table 68 : +CACM parameter command syntax
Command Possible response(s)
+CACM=[ & lt; passwd & gt; ] +CME ERROR: & lt; err & gt;
+CACM? +CACM: & lt; acm & gt;
+CME ERROR: & lt; err & gt;
+CACM=?
Description
Set command resets the Advice of Charge related accumulated call meter
value in SIM file EFACM. ACM contains the total number of home units for
both the current and preceding calls. SIM PIN2 is usually required to
reset the value. If setting fails in an ME error, +CME ERROR: & lt; err & gt; is
returned. Refer subclause 9.2 for & lt; err & gt; values.
Read command returns the current value of ACM.
Defined values
& lt; passwd & gt; : string type; SIM PIN2
& lt; acm & gt; : string type; accumulated call meter value similarly coded as
& lt; ccm & gt; under +CAOC
Implementation
Optional.
8.26 Accumulated call meter maximum +CAMM $(AT R97)$
Table SEQ Table 69 : +CAMM parameter command syntax
Command Possible response(s)
+CAMM=[ & lt; acmmax & gt; [, & lt; passwd & gt; ]] +CME ERROR: & lt; err & gt;
+CAMM? +CAMM: & lt; acmmax & gt;
+CME ERROR: & lt; err & gt;
+CAMM=?
Description
Set command sets the Advice of Charge related accumulated call meter
maximum value in SIM file EFACMmax. ACMmax contains the maximum number
of home units allowed to be consumed by the subscriber. When ACM (refer
+CACM) reaches ACMmax calls are prohibited (see also GSM 02.24 [26]).
SIM PIN2 is usually required to set the value. If setting fails in an ME
error, +CME ERROR: & lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt;
values.
Read command returns the current value of ACMmax.
Defined values
& lt; acmmax & gt; : string type; accumulated call meter maximum value similarly
coded as & lt; ccm & gt; under +CAOC; value zero disables ACMmax feature
& lt; passwd & gt; : string type; SIM PIN2
Implementation
Optional.
8.27 Price per unit and currency table +CPUC $(AT R97)$
Table SEQ Table 70 : +CPUC parameter command syntax
Command Possible response(s)
+CPUC= & lt; currency & gt; , & lt; ppu & gt; [, & lt; passwd & gt; ] +CME ERROR: & lt; err & gt;
+CPUC? +CPUC: & lt; currency & gt; , & lt; ppu & gt;
+CME ERROR: & lt; err & gt;
+CPUC=?
Description
Set command sets the parameters of Advice of Charge related price per
unit and currency table in SIM file EFPUCT. PUCT information can be used
to convert the home units (as used in +CAOC, +CACM and +CAMM) into
currency units. SIM PIN2 is usually required to set the parameters. If
setting fails in an ME error, +CME ERROR: & lt; err & gt; is returned. Refer
subclause 9.2 for & lt; err & gt; values.
Read command returns the current parameters of PUCT.
Defined values
& lt; currency & gt; : string type; three-character currency code (e.g. ``GBP'',
``DEM''); character set as specified by command Select TE Character Set
+CSCS
& lt; ppu & gt; : string type; price per unit; dot is used as a decimal separator
(e.g. ``2.66'')
& lt; passwd & gt; : string type; SIM PIN2
Implementation
Optional.
8.28 Power class +CPWC
Table SEQ Table 71 : +CPWC parameter command syntax
Command Possible response(s)
+CPWC=[ & lt; class & gt; [, & lt; band & gt; ]] +CME ERROR: & lt; err & gt;
+CPWC? +CPWC: & lt; curr_class & gt; , & lt; curr_band & gt; ,
& lt; def_class1 & gt; , & lt; band1 & gt; [,
& lt; def_class2 & gt; , & lt; band2 & gt; [...]]
+CME ERROR: & lt; err & gt;
+CPWC=? +CPWC: list of supported ( & lt; band & gt; ,(list of & lt; class & gt; s)) pairs
+CME ERROR: & lt; err & gt;
Description
This command is used to set the preferred ME power class for each GSM
frequency band supported. The interaction of this setting with the
selected bearer service (+CBST and HSCSD commands) is manufacturer
specific (for example, selecting a multislot operation might reduce the
power class automatically). If setting fails in an ME error, +CME ERROR:
& lt; err & gt; is returned. Refer subclause 9.2 for & lt; err & gt; values.
Read command returns the current output power class and frequency band,
and the default class setting for each supported frequency band (as
defined by ME manufacturer). For example, +CPWC: 5,0,4,0,1,1 in case of
a dual-band ME set currently to GSM900 power class 5, the default being
class 4, and the default for GSM1800 being class 1.
Test command returns supported bands and their power classes. For
example, +CPWC: (0,(0,4,5)),(1,(0-2)) in case of a dual-band handheld
ME.
Defined values
& lt; class & gt; , & lt; curr_class & gt; , & lt; def_classn & gt; :
0 default (not applicable to & lt; curr_class & gt; or & lt; def_classn & gt; )
1... MS output power class as in GSM 05.05 [38]
& lt; band & gt; , & lt; curr_band & gt; , & lt; bandn & gt; :
0 GSM900
1 GSM1800
2 reserved for GSM1900
Implementation
Optional.
8.29 Informative examples
Phone Activity Status (+CPAS) is a general command used to detect the
presence of the ME, if there is an incoming call, or if there is a call
in progress. This command should be used before trying to operate the ME
from the TE. Note that the activity status may change at any time after
the execution of +CPAS, and hence the returned value may be obsolete.
Detachment of the ME from the TA is indicated with a special final
result code that indicates all errors related to the operation of the
ME. Result code is +CME ERROR: & lt; err & gt; , where & lt; err & gt; is an integer or
verbose value giving useful information about the reason for the command
failure (refer subclause " Mobile Equipment error result code +CME
ERROR " ).
Set Phone Functionality (+CFUN) can be used to reset the ME or set the
power consumption level of the ME by disabling certain parts of the ME
(e.g. the transmit and receive RF circuits). Mobile Equipment Control
Mode (+CMEC) is a command which manages access sharing between the ME
and the TE to operate the user interface of the ME. It has three
subparameters which describe the access to keypad, display and
indicators. Each subparameter has values for restricting the operation
of the corresponding user interface part only to the ME or only to the
TE, or to give the access for both of them.
Keypad Control command (+CKPD) is used to operate the keypad of the ME.
Here lies the problem of different keypad types between manufacturers,
and also between their ME models. The keypresses are sent to the ME as a
string type subparameter of this command. Each character in that string
represents a key which will be logically pressed. A special character
(colon) followed by any character can be used by manufacturers (or TE
application programmers) to represent a key which is not defined in this
profile. An escape character (semicolon) for direct string entering is
also defined. All text between single semicolon characters is treated as
an alphanumeric entry and is not converted to keypressings. All
semicolon characters inside the text shall be duplicated in the TE and
stripped back to one before entering them to the ME. Command has also
optional second and third parameters which can be used to alter the time
to strike each key, and the pause to wait between keystrokes (in tenths
of a second). A special pause character (W or w) may be added in the
string type subparameter for an extra pause of the same length as given
by the third subparameter. In the following example alphanumeric mode is
entered and a person predefined in the ME phonebook, " Ilkka " , is called;
each key is struck for half a second and pauses between strokes are a
tenth of a second:
AT+CKPD= " @:Ilkka:S " ,5,1
OK
Display Control command (+CDIS) is used both for writing to the display
text fields and for reading the current status of the fields. Mobile
equipment usually have a character set of their own, so the TA shall be
able to do a conversion between the TE and the ME character sets. TE can
have several character sets and the TA must be informed of the character
set in use before starting to write or read the display. Character set
is set with general command Select TE Character Set +CSCS. The +CDIS=?
query command is a way to get information about the length of the
fields. In the following example an ME is first queried about the
supported conversions and the lengths of the fields. The response shows
there are three ten character long and two six character long fields.
Then the TE character set is set to be IRA and the current status of the
display is read. The last command writes the text " Hello, I'm writing to
display " in the three fields, and keeps the contents of the two other
fields same (the last two commas could also be left out).
AT+CSCS=?;+CDIS=?
+CSCS: ( " IRA " , " PCCP850 " , " 8859-1 " )
+CDIS: 10,10,10,6,6
OK
AT+CSCS= " IRA "
OK
AT+CDIS?
+CDIS: " RADIOLINJA " , " " , " " , " Menu " , " Memory "
OK
AT+CDIS= " IRA " , " Hello, I'm " , " writing to " , " display " ,,
OK
The writing is possible only when it is permitted by the Mobile
Equipment Control Mode command (and by the manufacturer). If a certain
field is not writable (but is readable), writing to it should be
ignored. The order of the text fields should be determined by
manufacturers and follow the rule: first field is in the upper left
corner, second in the next field to the right, and so on, until to the
last field in the lower right corner.
Indicators can be handled with Indicator Control command (+CIND). Its
query command returns a short description (abbreviation) of the purpose
of the indicators and the supported values for each indicator. The
setting and reading is done similarly as with Display Control command.
In the following example the indicators of a phone are queried, their
current value is read, and the value of message indicator is tried to
set (but it is forbidden):.
AT+CIND=?
+CIND: ( " memory " ,(0-2)),( " call " ,(0,1)),( " data " ,(0,1)),( " roam " ,(0,1)),
( " alpha " ,(0,1)),( " message " ,(0,1)),( " index1 " ,(0-11)),( " index2 " ,(0-11)),
( " index3 " ,(0-11)),( " signal " ,(0-5)),( " service " ,(0,1)),( " sel1 " ,(0,1)),
( " sel2 " ,(0,1)),( " sel3 " ,(0,1)),( " battchg " ,(0-5))
OK
AT+CIND?
+CIND: 1,0,0,0,0,1,0,0,0,3,1,0,0,0,5
OK
AT+CIND=,,,,,0
+CME ERROR: 10
The subparameter order in the command is defined by the query command
order, not by the actual display order. The zero value of an indicator
means that it is off (or in state which can be identified as
" off " -state), value one means that the indicator is on (or in a state
which is more substantial than " off " -state), value two is more
substantial than one, and so on.
To this point, only operating through the TE is covered. But when ME can
be operated also through its keypad, or there are changes in the status
of the display elements, the information about these actions shall be
given to the TE also. This can be solved only with unsolicited result
codes which return keypad, display text and indicator events. Each event
group has a result code of its own: +CKEV returns the key code and if
the key pressed (1) or released (0), +CDEV returns the display text
field running number (as specified by command +CDIS) and the new status
of the field, and +CIEV returns the running number of the indicator
(refer +CIND) and the new value of it. In the following example number
key 1 is pressed, updated on the display, released, and signal strength
changes its state to five:
+CKEV: 49,1
+CDEV: 1, " 1 "
+CKEV: 49,0
+CIND: 10,5
Mobile Equipment Event Reporting command (+CMER) has been specified for
the purpose of controlling the sending of these unsolicited result codes
to the TE. Four ways are provided to handle the buffering of the result
codes (see figure SEQ Figure unsobu 8 ). The first is to buffer them
always. The second possibility is to discard them when in on-line data
mode and otherwise forward them directly to the TE. The third
possibility is to buffer them in data mode and otherwise forward them to
the TE. The last possibility is to send them always to the TE (some
inband technique - e.g. V.80 - shall be used in data mode to send the
result codes within the data). This is the first subparameter of +CMER
command. Next three subparameters are used to enable or disable each of
the keypad, text field and indicator result codes. Sending codes can be
enabled either so that only events generated from the ME user interface
are returned, or so that also events caused by Keypad, Display and
Indicator Control commands are returned. The fifth subparameter controls
the flushing of the buffer when the value of the first subparameter is
changed to a value from one to three.
Figure SEQ Figure 8 : Mobile equipment event reporting
An example of complete setup of the TA where TE takes the control of
keypad, but does not want to write to display nor control the indicators
(in the start ME is powered off):
AT+CMEE=2;+CREG=1 (use verbose & lt; err & gt; values; report registration)
OK
AT+CPAS (query ME status)
+CPAS: 5 (ME is asleep)
OK
AT+CFUN=1 (set ME to full functionality state)
+CME ERROR: SIM PIN required (SIM requests PIN)
AT+CPIN= " 1234 "
+CME ERROR: incorrect password (user entered wrong PIN)
AT+CPIN= " 4321 "
OK (correct PIN)
AT+COPS=0,0 (ask for automatic operator selection and registration)
OK
+CREG: 1 (registered in the network)
AT+COPS?
+COPS: 0,0, " RADIOLINJA " (get the operator name)
OK
AT+CMEC=1,0,0 (take over the keypad, leave display to ME)
OK
AT+CDIS=?;+CIND=? (query display text and indicator formats)
+CDIS: 10,10,10,6,6
+CIND: ( " memory " ,(0-2)),( " call " ,(0,1)),( " data " ,(0,1)),( " roam " ,(0,1)),
( " alpha " ,(0,1)),( " message " ,(0,1)),( " index1 " ,(0-11)),( " index2 " ,(0-11)),
( " index3 " ,(0-11)),( " signal " ,(0-5)),( " service " ,(0,1)),( " sel1 " ,(0,1)),
( " sel2 " ,(0,1)),( " sel3 " ,(0,1)),( " battchg " ,(0-5))
OK
AT+CSCS= " IRA " (set TE character set for display text results)
OK
AT+CMER=1,0,2,2,0 (return display text and indicator result codes
when
OK in command state, in data mode discard them)
AT+CDIS?;+CIND? (read current state of display texts and indicators)
+CDIS: " " , " " , " 12345 " , " Menu " , " Memory " (user had pressed number
buttons before
+CIND: 1,0,0,0,0,1,0,0,0,3,1,0,0,0,5 TE took control with +CMEC)
OK
AT+CKPD= " C " ,20 (clear main display text '12345' by holding the
OK 'clear' button down two seconds)
+CDEV: 3, " 1234 " (first only one character deleted)
+CDEV: 3, " " (while holding continues, whole display is cleared)
+CDEV: 1, " RADIOLINJA " (operator name comes to the display)
The start of the previous example could go as follows when ME has
already been powered on but is waiting for the PIN:
AT+CMEE=2;+CREG=1 (use verbose & lt; err & gt; values; report registration)
OK
AT+CPAS (query ME status)
+CPAS: 0 (ME is ready to receive commands)
OK
AT+CPIN? (is ME asking passwords?)
+CPIN: SIM PIN (yes, SIM PIN required)
AT+CPIN= " 4321 "
OK (correct PIN)
One of the most regular operations done through the ME user interface is
phonebook control. To lessen the workload of the TE, some direct
commands for phonebook reading and writing are practical. Command Select
Phonebook Memory Storage +CPBS query version returns supported phonebook
memories, read version returns current settings, and set version selects
the memory. For GSM, the normal storages are SIM, ME and TA.
Read Phonebook Entries (+CPBR) can be used to read either one or many
phonebook locations at the same time. A regular phonebook entry consists
of three elements: memory index number, the phone number and its
alphanumeric equivalent given by the user. Query version of this returns
supported index values of the selected memory, and the maximum lengths
of the number and alphanumeric elements. The query version of the Write
Phonebook Entry command (+CPBW) is similar, but the action version sets
or clears an entry in the phonebook. Find Phonebook Entries (+CPBF) may
be used to search alphanumeric entries starting with specific string. An
example where the whole phonebook of the ME is read, index number four
is cleared, and number three is written:
AT+CPBS=?
+CPBS: ( " ME " , " SM " ) (ME and SIM have phonebooks)
OK
AT+CPBS= " ME " (select ME memory)
OK
AT+CPBR=? (read index range and element lengths)
+CPBR: (1-99),30,30
OK
AT+CPBR=1,99 (read all entries but only the ones set are returned)
+CPBR: 1, " 931123456 " ,129, " Ilkka "
+CPBR: 2, " 9501234567 " ,129, " "
+CPBR: 4, " 901234567 " ,129, " Hesari "
OK
AT+CPBW=4;+CPBW=3, " 921123456 " ,, " TS " (clear index 4 and write index 3)
OK
9 Mobile Equipment errors
9.1 Report Mobile Equipment error +CMEE
Table SEQ Table 72 : +CMEE parameter command syntax
Command Possible response(s)
+CMEE=[ & lt; n & gt; ]
+CMEE? +CMEE: & lt; n & gt;
+CMEE=? +CMEE: (list of supported & lt; n & gt; s)
Description
Set command disables or enables the use of result code +CME ERROR: & lt; err & gt;
as an indication of an error relating to the functionality of the ME.
When enabled, ME related errors cause +CME ERROR: & lt; err & gt; final result
code instead of the regular ERROR final result code. ERROR is returned
normally when error is related to syntax, invalid parameters, or TA
functionality.
Test command returns values supported by the TA as a compound value.
Defined values
& lt; n & gt; :
0 disable +CME ERROR: & lt; err & gt; result code and use ERROR instead
1 enable +CME ERROR: & lt; err & gt; result code and use numeric & lt; err & gt; values
(refer next subclause)
2 enable +CME ERROR: & lt; err & gt; result code and use verbose & lt; err & gt; values
(refer next subclause)
Implementation
Mandatory for & lt; n & gt; values 0 and 1.
9.2 Mobile Equipment error result code +CME ERROR
The operation of +CME ERROR: & lt; err & gt; result code is similar to the regular
ERROR result code: if +CME ERROR: & lt; err & gt; is the result code for any of
the commands in a command line, none of the following commands in the
same command line is executed (neither ERROR nor OK result code shall be
returned as a result of a completed command line execution). The format
of & lt; err & gt; can be either numeric or verbose. This is set with command
+CMEE (refer previous subclause).
NOTE: ITU-T V.25ter [14] command V does not affect the format of this
result code.
& lt; err & gt; values (numeric format followed by verbose format):
0 phone failure
1 no connection to phone
2 phone-adaptor link reserved
3 operation not allowed
4 operation not supported
5 PH-SIM PIN required
6 PH-FSIM PIN required
7 PH-FSIM PUK required
10 SIM not inserted
11 SIM PIN required
12 SIM PUK required
13 SIM failure
14 SIM busy
15 SIM wrong
16 incorrect password
17 SIM PIN2 required
18 SIM PUK2 required
20 memory full
21 invalid index
22 not found
23 memory failure
24 text string too long
25 invalid characters in text string
26 dial string too long
27 invalid characters in dial string
30 no network service
31 network timeout
32 network not allowed - emergency calls only
40 network personalisation PIN required
41 network personalisation PUK required
42 network subset personalisation PIN required
43 network subset personalisation PUK required
44 service provider personalisation PIN required
45 service provider personalisation PUK required
46 corporate personalisation PIN required
47 corporate personalisation PUK required
100 unknown
101 - 150 reserved for use by GPRS (values are specified in 07.60)
also all other values below 256 are reserved by this ETS
Implementation
Mandatory for numeric format codes applicable to implemented command
set.
9.3 Informative examples
An example of TA responses with all three +CMEE values when ME
manufacturer identification is requested but ME is not connected to the
TA:
AT+CMEE=0 (+CME ERROR shall not be used)
OK
AT+CGMI
ERROR
AT+CMEE=1 (use numeric & lt; err & gt; )
OK
AT+CGMI
+CME ERROR: 1
AT+CMEE=2 (use verbose & lt; err & gt; )
OK
AT+CGMI
+CME ERROR: no connection to phone
Annex A (normative):
Summary of commands from other standards
Summary of ITU-T Recommendation V.25ter [14] commands applicable to GSM:
Table A. SEQ TableAnn1 1 : V.25ter commands applicable to GSM
Name V.25ter section Description Subclauses in this ETS
& C 6.2.8 Circuit 109 (Received line signal detector) Behaviour 4.3.
& D 6.2.9 Circuit 108 (Data terminal ready) Behaviour 4.3.
& F 6.1.2 Set to Factory-defined Configuration 5.8./ 3.
+DR 6.6.2 Data Compression Reporting 6.20.
+DS 6.6.1 Data Compression 6.20.
+GCAP 6.1.9 Request Complete Capabilities List 5.8.
+GCI 6.1.10 Country of Installation 5.8.
+GMI 6.14 Request Manufacturer Identification 5.8./ 5.1.
+GMM 6.1.5 Request Model Identification 5.8./ 5.2.
+GMR 6.1.6 Request Revision Identification 5.8./ 5.3.
+GOI 6.1.8 Request Global Object Identification 5.8.
+GSN 6.1.7 Request Product Serial Number Identification 5.8./ 5.4.
+ICF 6.2.11 DTE-DCE Character Framing 4.3.
+IFC 6.2.12 DTE-DCE Local Flow Control 4.3.
+ILRR 6.2.13 DTE-DCE Local Rate Reporting 4.3.
+IPR 6.2.10 Fixed DTE Rate 4.3.
A 6.3.5 Answer 6.19./ 6.6.
D 6.3.1 Dial 6.1.-6.4./ 6.6.
E 6.2.4 Command Echo 4.3.
H 6.3.6 Hook Control 6.19./ 6.5./ 6.6.
I 6.1.3 Request Identification Information 5.8.
L 6.3.13 Monitor Speaker Loudness 6.19.
M 6.3.14 Monitor Speaker Mode 6.19.
O 6.3.7 Return to Online Data State 6.19.
P 6.3.3 Select Pulse Dialling 6.19.
Q 6.2.5 Result Code Suppression 4.3.
S0 6.3.8 Automatic Answer 6.19.
S10 6.3.12 Automatic Disconnect Delay 6.19.
S3 6.2.1 Command Line Termination Character 4.3.
S4 6.2.2 Response Formatting Character 4.3.
S5 6.2.3 Command Line Editing Character 4.3.
S6 6.3.9 Pause Before Blind Dialling 6.19.
S7 6.3.10 Connection Completion Timeout 6.19.
S8 6.3.11 Comma Dial Modifier Time 6.19.
T 6.3.2 Select Tone Dialling 6.19.
V 6.2.6 DCE Response Format 4.3./ 3./ 4.1./ 4.2.
X 6.2.7 Result Code Selection and Call Progress Monitoring Control 4.3.
Z 6.1.1 Reset To Default Configuration 5.8.
The use of ITU-T Recommendation V.42 error control protocol is not
specified for GSM, but if a manufacturer chooses to implement it over
transparent data service, +E prefixed commands of V.25ter [14] shall be
used.
ITU-T T.31 [11] and T.32 [12] may be used as facsimile TA-TE protocols
without deletions or additions to the command set.
TIA IS-99 [15] commands referenced in this ETS:
Table A. SEQ TableAnn1 2 : TIA IS-99 commands in this ETS
Command IS-99 section Description Subclause in this ETS
+CBC 5.6.5 Battery Charge 8.4.
+CGMI 5.6.10 Request Manufacturer Identification 5.1.
+CGMM 5.6.10 Request Model Identification 5.2.
+CGMR 5.6.10 Request Revision Identification 5.3.
+CGSN 5.6.10 Request Product Serial Number Identification 5.4.
+CRC 5.6.7 Cellular Result Codes 6.11.
TIA IS-135 [16] commands referenced in this ETS:
Table A. SEQ TableAnn1 3 : TIA IS-135 commands in this ETS
Command IS-135 section Description Subclause in this ETS
+CBC 4.1.24 Battery Charge 8.4.
+CRC 4.1.29 Cellular Result Codes 6.11.
+CSQ 4.1.31 Signal Quality 8.5.
PCCA STD-101[17] commands referenced in this ETS:
Table A. SEQ TableAnn1 4 : PCCA STD-101 commands in this ETS
Command STD-101 section Description Subclause in this ETS
+WS46 5.2.4.6 WDS-side Stack Selection 5.9.
Annex B (normative):
Summary of result codes
V.25ter [14] result codes which can be used in GSM and codes defined in
this ETS:
Table B. SEQ TableAnn2 1 : Result codes
Verbose result code
(V.25ter command V1 set) Numeric
(V0 set) Type Description
+CCCM: & lt; ccm & gt; as verbose unsolicited refer subclause 7.15. $(AT R97)$
+CCWA: & lt; number & gt; , & lt; type & gt; , & lt; class & gt; [, & lt; alpha & gt; ]
as verbose unsolicited refer subclause 7.11.
+CDEV: & lt; elem & gt; , & lt; text & gt; as verbose unsolicited refer subclause 8.10.
+CIEV: & lt; ind & gt; , & lt; value & gt; as verbose unsolicited refer subclause 8.10.
+CKEV: & lt; key & gt; , & lt; press & gt; as verbose unsolicited refer subclause 8.10.
+CLIP: & lt; number & gt;
, & lt; type & gt; [, & lt; subaddr & gt; , & lt; satype & gt; [, & lt; alpha & gt; ]] as verbose unsolicited refer
subclause 7.6.
+CME ERROR: & lt; err & gt; as verbose final refer subclause 9.2.
+COLP: & lt; number & gt;
, & lt; type & gt; [, & lt; subaddr & gt; , & lt; satype & gt; [, & lt; alpha & gt; ]] as verbose intermediate refer
subclause 7.8.
+CR: & lt; type & gt; as verbose intermediate refer subclause 6.8.
+CREG: & lt; stat & gt; [, & lt; lac & gt;
, & lt; ci & gt; ] as verbose unsolicited refer subclause 7.2.
+CRING: & lt; type & gt; as verbose unsolicited refer subclause 6.11.
+CSSI: & lt; code1 & gt;
[, & lt; index & gt; ] as verbose intermediate refer subclause 7.16
+CSSU: & lt; code2 & gt;
[, & lt; index & gt; [, & lt; number & gt; ,
& lt; type & gt; [, & lt; subaddr & gt; ,
& lt; satype & gt; ]]] as verbose unsolicited refer subclause 7.16
+CUSD: & lt; m & gt; [, & lt; str & gt; , & lt; dcs & gt; ] as verbose unsolicited refer subclause 7.14
+DR: & lt; type & gt; as verbose intermediate refer subclause 6.13.
+ILRR: & lt; rate & gt; as verbose intermediate refer subclause 4.3.
BUSY 6 final busy signal detected
CONNECT 1 intermediate connection has been established
CONNECT & lt; text & gt; manufacturer specific intermediate as CONNECT but
manufacturer specific & lt; text & gt; gives additional information (e.g.
connection data rate)
ERROR 4 final command not accepted
NO ANSWER 7 final connection completion timeout
NO CARRIER 3 final connection terminated
NO DIALTONE 5 final no dialtone detected
OK 0 final acknowledges execution of a command line
RING 2 unsolicited incoming call signal from network
Annex C (informative):
Commands from TIA IS-101
C.1 Introduction
The " Voice Control Interim Standard for Asynchronous DCE " , TIA IS-101,
contains some commands that are useful when passing audio " data " (that
is, data which represents audio information) between the computer and
the TA.
Some of the following subsections describe commands from IS-101 which
are central to this TA application. However, with the exception of
necessary extensions, these descriptions are not intended to replace the
definitions found in IS-101. Other novel commands from the interim
standard are not included because they are peripheral to TA operation.
NOTE: IS-101 also uses V.25ter [14] AT commands, but these are not
mentioned here.
The standard specifies the following modes:
- command mode, where there is no transfer of audio " data " between the
TA and the computer. In command mode, the computer is neither sending
audio data to the TA nor receiving audio data from the TA.
- transmit mode, where audio " data " is being transferred from the
computer to the TA. No audio " data " is transferred from the TA to the
computer in this state. A transition back to command mode occurs when an
embedded command indicates " end of play " or " flush data " , or an
inactivity timer times out.
- receive mode, where audio " data " is being transferred from the TA to
the computer. No audio " data " is transferred from the computer to the TA
in this state. A transition back to command mode occurs when any command
is sent from the computer, or an inactivity timer times out. During the
receive mode, the TA embeds result codes into the audio " data " . These
result codes indicate pertanent events such as " silence detected " , " busy
detected " , and so on.
Strictly, the standard specifies another mode (translation), but this is
not directly of interest here.
NOTE: The TA " knows " the type of an incoming call (whether it is voice,
data, fax, whatever), and certain POTS events cannot occur. Hence some
standard result codes for indication of events and discrimination of
call type are unnecessary.
There are three possible levels of service:
- a TA supporting level A performs the following operations and detects
the following events: audio transmit, audio receive, DTMF detection,
DTMF generation and single tone generation. The following indications
are supported:
Event Description Handset state
3 ring idle
4 DTMF received idle
5 receive buffer overrun receive
6 unsolicited fax request idle
8 phone on/off hook idle
9 presumed hangup receive
10 presumed end of message receive
18 ringback idle
19 busy idle
23 playback buffer underrun transmit
25 fax or data request acknowledged idle
- a TA supporting level B performs the operations and events of level A,
and also supports DTMF detection while in the transmit state.
- a TA supporting level C performs the operations and events of level B,
and also supports double DTMF tone generation.
Since DTMF detection and generation cannot be guaranteed over current
digital networks, it follows that none of the three levels of service
can be supported.
C.2 Commands
C.2.1 Select mode +FCLASS
This command puts the TA into a particular mode of operation (data, fax,
voice etc.). This causes the TA to process information in a manner
suitable for that type of information (rather than for other types of
information). The values and meanings of parameter & lt; n & gt; are specified in
the following table.
& lt; n & gt; Mode
0 data
1 fax class 1 (TIA-578-A)
1.0 fax class 1 (ITU-T T.31 [11])
2 fax (manufacturer specific)
2.0 fax class 2 (ITU-T T.32 [12] and TIA-592)
3...7 reserved for other fax modes
8 voice
9...15 reserved for other voice modes
16..79 reserved
80 VoiceView (Radish)
81..255 reserved
Table C. SEQ TableAnn3 1 : +FCLASS
Command Return
+FCLASS= & lt; n & gt;
+FCLASS? & lt; n & gt;
+FCLASS=? (list of supported & lt; n & gt; s)
Voice mode is of particular interest here, and has an additional result
code +VCON. Specifically, +VCON indicates that the TA is entering the
voice command mode and there is a voice connection to at least one audio
input or output. This presupposes that some mechanism has previously
initiated a connection to that audio I/O.
C.2.2 Buffer threshold setting +VBT
This refers to integers & lt; lo & gt; and & lt; hi & gt; that indicate levels within the TA
transmit buffer at which flow control is asserted and deasserted. The
buffer is used for averaging out the irregular timing of data from the
computer, so that the data becomes synchronous and may be sent to some
audio device.
Table C. SEQ TableAnn3 2 : +VBT
Command Return
+VBT= & lt; lo & gt; , & lt; hi & gt;
+VBT? & lt; lo & gt; , & lt; hi & gt;
+VBT=? (list of supported & lt; lo & gt; s),(list of supported & lt; hi & gt; s),(buffer size)
C.2.3 Calling number ID presentation +VCID
The command refers to an integer that allows a called party to enable or
disable ( & lt; n & gt; =0) the reporting of the ID of calling parties, and
specifies the method of presentation of the ID. This is basically the
same as GSM supplementary service CLIP (Calling Line Identification
Presentation). The presentation may be either formatted ( & lt; n & gt; =1) or
unformatted ( & lt; n & gt; =2):
- Formatted presentation : data items are reported in the form of
& lt; tag & gt; = & lt; value & gt; pairs.
& lt; tag & gt; & lt; value & gt;
DATE MMDD (month, day)
TIME HHMM (hour, minute)
NMBR calling number or P or O (P = number is private, O = number is
unavailable)
NAME subscription listing name
MESG data from other (unknown) tags
- Unformatted presentation : here the data is presented in ASCII hex as
printable numbers.
Table C. SEQ TableAnn3 3 : +VCID
Command Return
+VCID= & lt; n & gt;
+VCID? & lt; n & gt;
+VCID=? (0-2)
C.2.4 Receive gain selection +VGR
This refers to the amplification by the TA of audio samples sent from
the TA to the computer. The command operates on an integer & lt; n & gt; , range
0...255. Values larger than 128 indicate a larger gain than nominal.
Values less than 128 indicate a smaller gain than nominal. The entire
range of 0...255 does not have to be provided. A value of zero implies
the use of automatic gain control by the TA.
Table C. SEQ TableAnn3 4 : +VGR
Command Return
+VGR= & lt; n & gt;
+VGR? & lt; n & gt;
+VGR=? (list of supported & lt; n & gt; s)
C.2.5 Transmit gain selection +VGT
This refers to the amplification by the TA of audio samples sent from
the computer to the TA. The command operates on an integer & lt; n & gt; , range
0...255. Values larger than 128 indicate a larger gain than nominal.
Values less than 128 indicate a smaller gain than nominal. The entire
range of 0...255 does not have to be provided. A value of zero implies
the uses of automatic gain control by the TA.
Table C. SEQ TableAnn3 5 : +VGT
Command Return
+VGT= & lt; n & gt;
+VGT? & lt; n & gt;
+VGT=? (list of supported & lt; n & gt; s)
C.2.6 Initialise voice parameters +VIP
This recalls manufacturer determined settings & lt; n & gt; of voice parameters.
The command is write only. The effect of the command is manufacturer
specific.
Table C. SEQ TableAnn3 6 : +VIP
Command Return
+VIP= & lt; n & gt;
+VIP=? (list of supported & lt; n & gt; s)
C.2.7 Inactivity timer +VIT
This refers to the value of the inactivity timer in the TA. It is used
to monitor activity on the connection between the computer and the TA
when the computer is in " transmit " mode and sending audio data to the
TA. When the connection has been inactive for the time set by this
command, the TA leaves " transmit " mode and reverts to command mode. An
integer & lt; n & gt; different than zero implies a time of & lt; n & gt; /10 seconds. A
value of zero disables the timer.
Table C. SEQ TableAnn3 7 : +VIT
Command Return
+VIT= & lt; n & gt;
+VIT? & lt; n & gt;
+VIT=? (list of supported & lt; n & gt; s)
C.2.8 Line selection +VLS
This determines the selection of sources and destinations of audio
samples. An integer is used to label a particular combination of sources
and destinations. The integer is defined in an entry in IS-101 which
assumes as a model a TA, a local phone and a phone line. Two additional
" manufacturer specific " configurations (16,17) are defined.
- label=0: this is the idle state - the phone is not connected to the
radio network and no audio paths are used.
- label=1: the phone is connected to the radio network and no audio
paths involving the internal microphone or internal loudspeaker are
selected. This allows the computer to transmit audio data over the radio
transmitter by selecting " transmit mode " :
Table C. SEQ TableAnn3 8 : +VLS label 1a
loudspeaker computer i/p transmit stage
microphone -- & gt;
computer o/p -- & gt;
*
receiver stage -- & gt;
This also allows the computer to receive audio data from the radio
receiver by selecting " receive mode " :
Table C. SEQ TableAnn3 9 : +VLS label 1b
loudspeaker computer i/p transmit stage
microphone -- & gt;
computer o/p -- & gt;
receiver stage -- & gt;
*
- label=4: the phone is not connected to the radio network but there is
an audio path to the internal speaker. This allows the computer to play
sound by selecting " transmit mode " .
Table C. SEQ TableAnn3 10 : +VLS label 4
loudspeaker computer i/p transmit stage
microphone -- & gt;
computer o/p -- & gt; *
receiver stage -- & gt;
- label=6: the phone is not connected to the radio network but there is
an audio path to the internal microphone. This allows the computer to
record sound by selecting " receive mode " .
Table C. SEQ TableAnn3 11 : +VLS label 6
loudspeaker computer i/p transmit stage
microphone -- & gt;
*
computer o/p -- & gt;
receiver stage -- & gt;
- label=7: the phone is connected to the radio network. The internal
microphone is connected to the radio transmitter. The radio receiver is
connected to the internal loudspeaker. This allows the computer to
enable normal phone operation (a human holding a conversation) by
selecting command mode.
Table C. SEQ TableAnn3 12 : +VLS label 7
loudspeaker computer i/p transmit stage
microphone -- & gt;
*
computer o/p -- & gt;
receiver stage -- & gt; *
Table C. SEQ TableAnn3 13 : +VLS
Command Return
+VLS= & lt; n & gt; +VCON
+VLS? & lt; n & gt;
+VLS=? complex; refer IS-101
+VCON is returned if an audio path is established or if a connection is
made to the radio network.
Manufacturer specific extension (reserved as such by IS-101)
- label=16: the phone is connected to the radio network. There is a path
to the internal microphone, which is also connected to the radio
transmitter. There is a path to the radio receiver, which is also
connected to the internal loudspeaker. This allows the computer to
record the sum of transmitted and received audio by selecting " receive
mode " .
Table C. SEQ TableAnn3 14 : +VLS label 16
loudspeaker computer i/p transmit stage
microphone -- & gt;
* *
computer o/p -- & gt;
receiver stage -- & gt; * *
- label=17: the phone is connected to the radio system and there is a
path to the internal loudspeaker and to the radio transmitter. This
allows the computer to simultaneously play sound and send audio over the
radio by selecting " transmit mode " .
Table C. SEQ TableAnn3 15 : +VLS label 17
loudspeaker computer i/p transmit stage
microphone -- & gt;
computer o/p -- & gt; *
*
receiver stage -- & gt;
C.2.9 Receive data state +VRX
This action command causes the TA to get audio data from a source
determined by the +VLS command, and send it to the computer. Once the
datastream has started, any result codes will be embedded in the data
and shielded using the normal & lt; DLE & gt; methods. The receive process is
terminated when the computer sends any command to the TA, or by time-out
of the inactivity timer. The command is write only.
Table C. SEQ TableAnn3 16 : +VRX
Command Return
+VRX CONNECT
C.2.10 Select compression method +VSM
This selects the voice compression method & lt; n1 & gt; , the voice sampling rate
& lt; n2 & gt; , the silence compression sensitivity & lt; n3 & gt; , and a parameter related
to silence expansion & lt; n4 & gt; . There are several choices of compression
method. IS-101 does not specify methods, but here is a list of some
usual compression methods:
Name Communications system
GSM/full-rate GSM
GSM/half-rate GSM
ADPCM/G.721 DECT, CT2
ADPCM/G.723 DECT, CT2
ADPCM/G.726 DECT, CT2
ADPCM/G.727 DECT, CT2
SIGNED PCM POTS
Table C. SEQ TableAnn3 17 : +VSM
Command Return
+VSM= & lt; n1 & gt; , & lt; n2 & gt; , & lt; n3 & gt; , & lt; n4 & gt;
+VSM? & lt; n1 & gt; , & lt; n2 & gt; , & lt; n3 & gt; , & lt; n4 & gt;
+VSM=? complex; refer IS-101
NOTE: A value of & lt; n3 & gt; =0 implies no silence compression sensitivity. A
value of & lt; n4 & gt; =0 implies no silence expansion.
C.2.11 DTMF and tone generation +VTS
This command allows the transmission of DTMF tones and arbitrary
tones (see note). These tones may be used (for example) when announcing
the start of a recording period. The command is write only. In this
profile of commands, this command does not operate in data or fax modes
of operation (+FCLASS=0,1,2-7).
NOTE: D is used only for dialling.
The string parameter of the command consists of combinations of the
following separated by commas:
1. & lt; DTMF & gt; . A single ASCII character in the set 0-9, #,*,A-D. This is
interpreted as a single ACSII character whose duration is set by the
+VTD command.
NOTE: In GSM this operates only in voice mode.
2. [ & lt; tone1 & gt; , & lt; tone2 & gt; , & lt; duration & gt; ]. This is interpreted as a dual tone of
frequencies & lt; tone1 & gt; and & lt; tone2 & gt; , lasting for a time & lt; duration & gt; (in 10 ms
multiples).
NOTE: This does not operate in GSM.
3. { & lt; DTMF & gt; , & lt; duration & gt; }. This is interpreted as a DTMF tone of different
duration from that mandated by the +VTD command.
NOTE: In GSM this operates only in voice mode.
Table C. SEQ TableAnn3 18 : +VTS
Command Return
+VTS=as above
+VTS=? (list of supported & lt; tone1 & gt; s),(list of supported & lt; tone2 & gt; s) ,(list
of supported & lt; duration & gt; s)
C.2.12 Tone duration +VTD
This refers to an integer & lt; n & gt; that defines the length of tones emitted
as a result of the +VTS command. This does not affect the D command. A
value different than zero causes a tone of duration & lt; n & gt; /10 seconds. The
value zero causes a " manufacturer specific " value.
Table C. SEQ TableAnn3 19 : +VTD
Command Return
+VTD= & lt; n & gt;
+VTD? & lt; n & gt;
+VTD=? (list of supported & lt; n & gt; s)
NOTE: In GSM the value of tone duration is preset and cannot be altered.
C.2.13 Transmit data state +VTX
This action command causes the TA to receive audio data from the
computer and send it to a destination determined by the +VLS command.
Once the audio datastream has started, commands to the TA shall be
embedded in the data stream, and shielded using the normal & lt; DLE & gt;
methods. The transmit process is terminated by the use of embedded
commands or by the time-out of an inactivity timer. It is recommended
that the TA has a buffer to allow the TA to convert potentially bursty
data from the computer into synchronous data for " transmission " . The
command is write only.
Table C. SEQ TableAnn3 20 : +VTX
Command Return
+VTX CONNECT
Annex D (informative):
Bibliography
Informative references:
1) IrDA Serial Infrared Physical Layer Specification
IrDA Serial Infrared MAC and Link Protocol
IrDA Serial Infrared Link Access Protocol
2) PCCA STD-101 Annex I: Data Transmission Systems and Equipment -
Serial Asynchronous Automatic Dialling and Control for Character Mode
DCE on Wireless Data Services - Annex I: Command Extensions for Analog
Cellular Data Modems
3) TIA IS-101 Facsimile Digital Interfaces - Voice Control Interim
Standard for Asynchronous DCE
4) TIA-578-A Facsimile Digital Interfaces - Asynchronous Facsimile DCE
Control Standard, Service Class 1
5) TIA-592 Facsimile Digital Interfaces - Asynchronous Facsimile DCE
Control Standard, Service Class 2
6) TIA-617 Data Transmission Systems and Equipment - In-Band DCE Control
7) ITU-T Recommendation V.80: In-band DCE control and synchronous data
modes for asynchronous DTE
Annex E (informative):
Mobile originated alternating voice/data call example
Figure E.1 illustrates the possible transitions in MO BS 61 call.
Responses and result codes generated by TA are in bold face. In this
example, data part of the call is asynchronous non-transparent 9600 bps
service.
Figure E.1: MO BS 61 call
Annex F (informative):
Mobile terminated voice followed by data call example
Figure F.1 illustrates the possible transitions in MT BS 81 call.
Responses and result codes generated by TA are in bold face. In this
example, data part of the call is asynchronous non-transparent 9600 bps
service.
Figure F.1: MT BS 81 call
Annex G (informative):
Voice call example
Figure G.1 illustrates the possible transitions in both MT and MO TS 11
calls. Responses and result codes generated by TA are in bold face.
Figure G.1: TS 11 calls
Annex H (informative):
Change History
SMG# TDoc CR REV PHASE CAT SUBJECT WORKITEM NEW
_VERS
S20 612/96 A021
2+ B Restricted SIM access command TEI 5.1.0
S20 612/96 A022
2+ C Per call CLI restriction correction TEI 5.1.0
S20 612/96 A023
2+ B +COPS=? enhancement TEI 5.1.0
S20 612/96 A024
2+ B +CHLD=? enhancement TEI 5.1.0
s21 060/97 A025
2+ B Current call list
5.2.0
s21 060/97 A026
2+ B ECT and CD support ECT, CD 5.2.0
s21 060/97 A027
2+ B Extended Error codes
5.2.0
s21 056/97 A028
2+ B HSCSD support HSCSD 5.2.0
s21 060/97 A029
2+ B New AT IMSI command
5.2.0
s21 060/97 A030
2+ B New AT Security command
5.2.0
s21 060/97 A031
2+ B Single numbering scheme
5.2.0
s22 415/97 A032
R97 B IrDA Telecom spec requirements
5.3.0
s22 415/97 A033
2+ F Facility lock enhancements
5.3.0
s22 415/97 A034
2+ F Editorial corrections
5.3.0
s22 536/97 A035
R97 B Modification of AT+CAOC
5.3.0
s23 97-699 A036
R96 F Deletion of codepoint for V.32bis (electronic only) 14.4 kbit/s
5.4.0
s23 97-701 A037
R96 B TCH/F14.4 channel coding in HSCSD commands 14.4 kbit/s 5.4.0
s23 97-702 A038
R97 B ME ringer, loudspeaker and microphone control
5.4.0
s23 97-702 A039
R96 F V.120 Interworking V.120/RDI 5.4.0
s23 97-702 A040
R97 B Advice of charge information from SIM
5.4.0
s23 97-706 A041
R97 D Amendment in the scope Reference to 07.07 GPRS GPRS 5.4.0
s23 97-702 A042
R97 B ATH and drop DTR for voice mode
5.4.0
s23 97-702 A043
R97 B Preferred network list
5.4.0
s24 97-922 A044
R96 D Update of alternating call figures 07.07 5.5.0
s24 97-922 A045
R96 F V.120/RDI correction V.120/RDI 5.5.0
s24 97-922 A047
R96 A AT+CPIN or AT+CKPD must be mandatory in some cases (phase 2+)
07.07 5.5.0
s24 97-1031 A048
R97 B MUX 07.10 AT commands MUX MS-TE 5.5.0
s25 98-0100 A049
R97 F AT command for MUX MS-TE alignment with 07.10
6.0.0
s25 98-0100 A050
R96 A Supplementary Service control phase 2+
5.6.0
s26 98-0292 A052
R97 F GSM AT command support for GPRS GPRS 6.1.0
s26 98-0293 A053
R97 F USSD command improvement TEI 6.1.0
s26 98-0293 A055
R98 B ME power class control TEI 7.0.0
History
Document history
July 1998 Not For Publication
PAGE
styleref ZA GSM 07.07 V7.0.0 (1998-07)
PAGE 97
styleref ZGSM GSM 07.07 version 7.0.0 Release 1998
connection failure
NO CARRIER
AT+CEER
+CEER: failure cause
OK
call setup started
OK
(no indication on successful call setup)
AT+COLP=0
OK
ATD12345;
MO without COLP
success
+COLP: +35812345,145
OK
AT+COLP=1
OK
ATD12345;
MO with COLP
general failure
ERROR
(remote ring or other network generated tones)
OK
NO CARRIER
connection failure
NO CARRIER
AT+CEER
+CEER: failure cause
OK
remote busy
BUSY
general failure
ERROR
VOICE call active
AT+CHUP
(or ATH
or drop DTR)
remote
hangup
connection failure
NO CARRIER
AT+CEER
+CEER: failure cause
OK
success
OK
MT
AT+CLIP=1; +CRC=1
OK
+CRING: VOICE
+CLIP: +35812345,145
ATA
AT+CHUP
(or ATH
or drop DTR)
DATA
(V.24 circuit
109 ON)
success
OK
in-call modification success
+CR: REL ASYNC
+DR: NONE
+ILRR: 19200
CONNECT 9600
VOICE
ATD (or ATA)
in-call modification failure
ERROR
AT+CEER
+CEER: failure cause
OK
+CR: REL ASYNC
+DR: NONE
+ILRR: 19200
CONNECT 9600
remote initiated
in-call modification
successful
remote
hangup
remote
hangup
OFF-LINE
TA sets +CMOD=0
ATH
(or AT+CHUP
or drop DTR)
OK
OK
NO CARRIER
NO CARRIER
AT+CLIP=1; +CR=1; +DR=1; +ILRR=1; +CRC=1
OK
+CRING: VOICE/REL ASYNC
+CLIP: +35812345,145
AT+CMOD=3; +FCLASS=0; A
OFF-LINE
connection failure
NO CARRIER
AT+CEER
+CEER: failure cause
OK
general failure
ERROR
AT+CHUP
(or ATH
or drop DTR )
remote initiated
in-call modification
successful
OK
in-call modification failure
ERROR
AT+CEER
+CEER: failure cause
OK
RLP negotiation failure
+COLP: +35812345,145
+CR: REL ASYNC
NO CARRIER
in-call modification success
OK
ATH (or drop DTR)
remote
hangup
remote
hangup
AT+CHUP
NO CARRIER
OK
OK
NO CARRIER
+CR: REL ASYNC
+DR: NONE
+ILRR: 19200
CONNECT 9600
remote initiated
in-call modification
successful
VOICE
ATD (or ATA)
DATA
(V.24 circuit
109 ON)
in-call modification success
+CR: REL ASYNC
+DR: NONE
+ILRR: 19200
CONNECT 9600
in-call modification failure
ERROR
AT+CEER
+CEER: failure cause
OK
connection failure
NO CARRIER
AT+CEER
+CEER: failure cause
OK
other possible failure codes
BUSY/NO ANSWER/ERROR
success
+COLP: +35812345,145
+CR: REL ASYNC
+DR: NONE
+ILRR: 19200
CONNECT 9600
success
+COLP: +35812345,145
OK
ATD12345;
ATD12345
OFF-LINE
AT+CBST=7,0,1
OK
AT+COLP=1; +CR=1; +DR=1; +ILRR=1
OK
AT+CMOD=2; +FCLASS=0
OK
OFF-LINE
TA sets +CMOD=0
TD & lt; & gt;
Draft EN (GSM 03.40) V6.0.0 (1998-03)
European Standard (Telecommunications series)
Digital cellular telecommunications system (Phase 2+);
Technical realization of the Short Message Service (SMS);
Point-to-Point (PP)
(GSM 03.40 version 6.0.0)
Approved by SMG as SMG version only, not for publication
Reference
DEN/SMG-040340Q6 (8cc03000.PDF)
Keywords
Digital cellular telecommunications system, Global System for Mobile
communications (GSM)
ETSI Secretariat
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
secretariat@etsi.fr
http://www.etsi.fr
http://www.etsi.org
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 1998.
All rights reserved.
Contents
TOC \o Intellectual Property Rights GOTOBUTTON _Toc416054123
PAGEREF _Toc416054123 6
Foreword GOTOBUTTON _Toc416054124 PAGEREF _Toc416054124 6
Introduction GOTOBUTTON _Toc416054125 PAGEREF _Toc416054125 6
1 Scope GOTOBUTTON _Toc416054126 PAGEREF _Toc416054126 8
2 Normative references GOTOBUTTON _Toc416054127 PAGEREF
_Toc416054127 8
2.1 Definitions and abbreviations GOTOBUTTON _Toc416054128 PAGEREF
_Toc416054128 9
2.1.1 Definitions GOTOBUTTON _Toc416054129 PAGEREF _Toc416054129
10
2.2.2 Abbreviations GOTOBUTTON _Toc416054130 PAGEREF _Toc416054130
11
3 Services and service elements GOTOBUTTON _Toc416054131 PAGEREF
_Toc416054131 12
3.1 Basic services GOTOBUTTON _Toc416054132 PAGEREF _Toc416054132
12
3.2 Short Message Service elements GOTOBUTTON _Toc416054133 PAGEREF
_Toc416054133 13
3.2.1 Validity-Period GOTOBUTTON _Toc416054134 PAGEREF
_Toc416054134 13
3.2.2 Service-Centre-Time-Stamp GOTOBUTTON _Toc416054135 PAGEREF
_Toc416054135 13
3.2.3 Protocol-Identifier GOTOBUTTON _Toc416054136 PAGEREF
_Toc416054136 13
3.2.4 More-Messages-to-Send GOTOBUTTON _Toc416054137 PAGEREF
_Toc416054137 14
3.2.5 Delivery of Priority and non-Priority Messages GOTOBUTTON
_Toc416054138 PAGEREF _Toc416054138 14
3.2.6 Messages-Waiting GOTOBUTTON _Toc416054139 PAGEREF
_Toc416054139 14
3.2.7 Alert-SC GOTOBUTTON _Toc416054140 PAGEREF _Toc416054140 17
3.2.8 Options concerning MNRG, MNRF, MNRR, MCEF and MWD GOTOBUTTON
_Toc416054141 PAGEREF _Toc416054141 17
3.2.9 Status report capabilities GOTOBUTTON _Toc416054142 PAGEREF
_Toc416054142 18
3.2.10 Reply Path GOTOBUTTON _Toc416054143 PAGEREF _Toc416054143
18
3.3 Unsuccessful short message TPDU transfer SC - & gt; MS GOTOBUTTON
_Toc416054144 PAGEREF _Toc416054144 18
3.3.1 Errors occurring during transfer of TPDU to MS GOTOBUTTON
_Toc416054145 PAGEREF _Toc416054145 19
3.3.2 Errors occurring after TPDU arrives at MS GOTOBUTTON
_Toc416054146 PAGEREF _Toc416054146 19
3.4 Unsuccessful short message TPDU transfer MS - & gt; SC GOTOBUTTON
_Toc416054147 PAGEREF _Toc416054147 21
3.4.1 Errors occurring during transfer of TPDU to SC GOTOBUTTON
_Toc416054148 PAGEREF _Toc416054148 21
3.4.2 Errors occurring after TPDU arrives at SC GOTOBUTTON
_Toc416054149 PAGEREF _Toc416054149 21
3.5 Use of Supplementary Services in combination with the Short Message
Service GOTOBUTTON _Toc416054150 PAGEREF _Toc416054150 21
3.6 Applicability of Operator Determined Barring to the Short Message
Service GOTOBUTTON _Toc416054151 PAGEREF _Toc416054151 21
3.7 Multiple short message transfer GOTOBUTTON _Toc416054152
PAGEREF _Toc416054152 22
3.8 SMS and Internet Electronic Mail interworking GOTOBUTTON
_Toc416054153 PAGEREF _Toc416054153 22
3.8.1 Basic Format GOTOBUTTON _Toc416054154 PAGEREF _Toc416054154
22
3.8.2 Optional Fields GOTOBUTTON _Toc416054155 PAGEREF
_Toc416054155 23
3.8.2.1 Subject GOTOBUTTON _Toc416054156 PAGEREF _Toc416054156 23
3.8.2.2 Real Name GOTOBUTTON _Toc416054157 PAGEREF _Toc416054157
23
3.8.2.3 Optional Control Flag GOTOBUTTON _Toc416054158 PAGEREF
_Toc416054158 23
3.8.3 Text concatenation GOTOBUTTON _Toc416054159 PAGEREF
_Toc416054159 23
3.8.4 Alternative characters for Internet email addresses in MO SMS.
GOTOBUTTON _Toc416054160 PAGEREF _Toc416054160 24
4 Network architecture GOTOBUTTON _Toc416054161 PAGEREF
_Toc416054161 25
4.1 Basic network structure GOTOBUTTON _Toc416054162 PAGEREF
_Toc416054162 25
4.2 Transfer on link 3 GOTOBUTTON _Toc416054163 PAGEREF
_Toc416054163 26
5 Service Centre and PLMN interconnection GOTOBUTTON _Toc416054164
PAGEREF _Toc416054164 26
5.1 Service centre connection GOTOBUTTON _Toc416054165 PAGEREF
_Toc416054165 26
5.2 Routing requirements GOTOBUTTON _Toc416054166 PAGEREF
_Toc416054166 26
5.2.1 Mobile terminated short message GOTOBUTTON _Toc416054167
PAGEREF _Toc416054167 26
5.2.2 Mobile originated short message GOTOBUTTON _Toc416054168
PAGEREF _Toc416054168 26
6 Service Centre functionality GOTOBUTTON _Toc416054169 PAGEREF
_Toc416054169 26
6.1 Service Centre capabilities GOTOBUTTON _Toc416054170 PAGEREF
_Toc416054170 27
6.2 SC functional requirements GOTOBUTTON _Toc416054171 PAGEREF
_Toc416054171 27
7 MS functionality GOTOBUTTON _Toc416054172 PAGEREF _Toc416054172
27
7.1 MS capabilities GOTOBUTTON _Toc416054173 PAGEREF _Toc416054173
27
7.2 MS configuration GOTOBUTTON _Toc416054174 PAGEREF _Toc416054174
28
8 Node functionality GOTOBUTTON _Toc416054175 PAGEREF _Toc416054175
28
8.1 Node functionality related to SM MT GOTOBUTTON _Toc416054176
PAGEREF _Toc416054176 28
8.1.1 Functionality of the SMS-GMSC GOTOBUTTON _Toc416054177
PAGEREF _Toc416054177 28
8.1.2 Functionality of the MSC GOTOBUTTON _Toc416054178 PAGEREF
_Toc416054178 30
8.1.3 Functionality of the SGSN GOTOBUTTON _Toc416054179 PAGEREF
_Toc416054179 31
8.2 Node functionality related to SM MO GOTOBUTTON _Toc416054180
PAGEREF _Toc416054180 31
8.2.1 Functionality of the MSC GOTOBUTTON _Toc416054181 PAGEREF
_Toc416054181 31
8.2.2 Functionality of the SMS-IWMSC GOTOBUTTON _Toc416054182
PAGEREF _Toc416054182 32
8.2.3 Functionality of the SGSN GOTOBUTTON _Toc416054183 PAGEREF
_Toc416054183 32
8.3 SMS-IWMSC functionality related to alerting GOTOBUTTON
_Toc416054184 PAGEREF _Toc416054184 33
9 Protocols and protocol architecture GOTOBUTTON _Toc416054185
PAGEREF _Toc416054185 33
9.1 Protocol element features GOTOBUTTON _Toc416054186 PAGEREF
_Toc416054186 33
9.1.1 Octet and Bit transmission order GOTOBUTTON _Toc416054187
PAGEREF _Toc416054187 33
9.1.2 Numeric and alphanumeric representation GOTOBUTTON _Toc416054188
PAGEREF _Toc416054188 33
9.1.2.1 Integer representation GOTOBUTTON _Toc416054189 PAGEREF
_Toc416054189 34
9.1.2.2 Octet representation GOTOBUTTON _Toc416054190 PAGEREF
_Toc416054190 34
9.1.2.3 Semi-octet representation GOTOBUTTON _Toc416054191 PAGEREF
_Toc416054191 34
9.1.2.4 Alphanumeric representation GOTOBUTTON _Toc416054192
PAGEREF _Toc416054192 35
9.1.2.5 Address fields GOTOBUTTON _Toc416054193 PAGEREF
_Toc416054193 35
9.2 Service provided by the SM-TL GOTOBUTTON _Toc416054194 PAGEREF
_Toc416054194 37
9.2.1 General GOTOBUTTON _Toc416054195 PAGEREF _Toc416054195 37
9.2.2 PDU Type repertoire at SM-TL GOTOBUTTON _Toc416054196 PAGEREF
_Toc416054196 37
9.2.2.1 SMS-DELIVER type GOTOBUTTON _Toc416054197 PAGEREF
_Toc416054197 37
9.2.2.1a SMS-DELIVER-REPORT type GOTOBUTTON _Toc416054198 PAGEREF
_Toc416054198 39
9.2.2.2 SMS-SUBMIT type GOTOBUTTON _Toc416054199 PAGEREF
_Toc416054199 41
9.2.2.2a SMS-SUBMIT-REPORT type GOTOBUTTON _Toc416054200 PAGEREF
_Toc416054200 42
9.2.2.3 SMS-STATUS-REPORT type GOTOBUTTON _Toc416054201 PAGEREF
_Toc416054201 44
9.2.2.4 SMS-COMMAND type GOTOBUTTON _Toc416054202 PAGEREF
_Toc416054202 46
9.2.3 Definition of the TPDU parameters GOTOBUTTON _Toc416054203
PAGEREF _Toc416054203 47
9.2.3.1 TP-Message-Type-Indicator (TP-MTI) GOTOBUTTON _Toc416054204
PAGEREF _Toc416054204 47
9.2.3.2 TP-More-Messages-to-Send (TP-MMS) GOTOBUTTON _Toc416054205
PAGEREF _Toc416054205 47
9.2.3.3 TP-Validity-Period-Format (TP-VPF) GOTOBUTTON _Toc416054206
PAGEREF _Toc416054206 48
9.2.3.4 TP-Status-Report-Indication (TP-SRI) GOTOBUTTON _Toc416054207
PAGEREF _Toc416054207 48
9.2.3.5 TP-Status-Report-Request (TP-SRR) GOTOBUTTON _Toc416054208
PAGEREF _Toc416054208 48
9.2.3.6 TP-Message-Reference (TP-MR) GOTOBUTTON _Toc416054209
PAGEREF _Toc416054209 48
9.2.3.7 TP-Originating-Address (TP-OA) GOTOBUTTON _Toc416054210
PAGEREF _Toc416054210 49
9.2.3.8 TP-Destination-Address (TP-DA) GOTOBUTTON _Toc416054211
PAGEREF _Toc416054211 49
9.2.3.9 TP-Protocol-Identifier (TP-PID) GOTOBUTTON _Toc416054212
PAGEREF _Toc416054212 49
9.2.3.10 TP-Data-Coding-Scheme (TP-DCS) GOTOBUTTON _Toc416054213
PAGEREF _Toc416054213 51
9.2.3.11 TP-Service-Centre-Time-Stamp (TP-SCTS) GOTOBUTTON
_Toc416054214 PAGEREF _Toc416054214 51
9.2.3.12 TP-Validity-Period (TP-VP) GOTOBUTTON _Toc416054215
PAGEREF _Toc416054215 51
9.2.3.12.1 TP-VP (Relative format) GOTOBUTTON _Toc416054216 PAGEREF
_Toc416054216 51
9.2.3.12.2 TP-VP (Absolute format ) GOTOBUTTON _Toc416054217
PAGEREF _Toc416054217 51
9.2.3.12.3 TP-VP ( Enhanced format ) GOTOBUTTON _Toc416054218
PAGEREF _Toc416054218 52
9.2.3.13 TP-Discharge-Time (TP-DT) GOTOBUTTON _Toc416054219 PAGEREF
_Toc416054219 52
9.2.3.14 TP-Recipient-Address (TP-RA) GOTOBUTTON _Toc416054220
PAGEREF _Toc416054220 53
9.2.3.15 TP-Status (TP-ST) GOTOBUTTON _Toc416054221 PAGEREF
_Toc416054221 53
9.2.3.16 TP-User-Data-Length (TP-UDL) GOTOBUTTON _Toc416054222
PAGEREF _Toc416054222 54
9.2.3.17 TP-Reply-Path (TP-RP) GOTOBUTTON _Toc416054223 PAGEREF
_Toc416054223 54
9.2.3.18 TP-Message-Number (TP-MN) GOTOBUTTON _Toc416054224 PAGEREF
_Toc416054224 54
9.2.3.19 TP-Command-Type (TP-CT) GOTOBUTTON _Toc416054225 PAGEREF
_Toc416054225 54
9.2.3.20 TP-Command-Data-Length (TP-CDL) GOTOBUTTON _Toc416054226
PAGEREF _Toc416054226 55
9.2.3.21 TP-Command-Data (TP-CD) GOTOBUTTON _Toc416054227 PAGEREF
_Toc416054227 55
9.2.3.22 TP-Failure-Cause (TP-FCS) GOTOBUTTON _Toc416054228 PAGEREF
_Toc416054228 55
9.2.3.23 TP-User-Data-Header-Indicator (TP-UDHI) GOTOBUTTON
_Toc416054229 PAGEREF _Toc416054229 57
9.2.3.24 TP-User Data (TP-UD) GOTOBUTTON _Toc416054230 PAGEREF
_Toc416054230 57
9.2.3.24.1 Concatenated Short Messages GOTOBUTTON _Toc416054231
PAGEREF _Toc416054231 60
9.2.3.24.2 Special SMS Message Indication GOTOBUTTON _Toc416054232
PAGEREF _Toc416054232 61
9.2.3.24.3 Application Port Addressing 8 bit address GOTOBUTTON
_Toc416054233 PAGEREF _Toc416054233 63
9.2.3.24.4 Application Port Addressing 16 bit address GOTOBUTTON
_Toc416054234 PAGEREF _Toc416054234 63
9.2.3.24.5 SMSC Control Parameters GOTOBUTTON _Toc416054235
PAGEREF _Toc416054235 64
9.2.3.24.6 UDH Source Indicator GOTOBUTTON _Toc416054236 PAGEREF
_Toc416054236 64
9.2.3.25 TP-Reject-Duplicates (TP-RD) GOTOBUTTON _Toc416054237
PAGEREF _Toc416054237 65
9.2.3.26 TP-Status-Report-Qualifier (TP-SRQ) GOTOBUTTON _Toc416054238
PAGEREF _Toc416054238 65
9.2.3.27 TP-Parameter-Indicator (TP-PI) GOTOBUTTON _Toc416054239
PAGEREF _Toc416054239 65
9.3 Service provided by the SM-RL GOTOBUTTON _Toc416054240 PAGEREF
_Toc416054240 66
9.3.1 General GOTOBUTTON _Toc416054241 PAGEREF _Toc416054241 66
9.3.2 Protocol element repertoire at SM-RL GOTOBUTTON _Toc416054242
PAGEREF _Toc416054242 66
9.3.2.1 RP-MO-DATA GOTOBUTTON _Toc416054243 PAGEREF _Toc416054243
66
9.3.2.2 RP-MT-DATA GOTOBUTTON _Toc416054244 PAGEREF _Toc416054244
67
9.3.2.3 RP-ACK GOTOBUTTON _Toc416054245 PAGEREF _Toc416054245 67
9.3.2.4 RP-ERROR GOTOBUTTON _Toc416054246 PAGEREF _Toc416054246 67
9.3.2.5 RP-ALERT-SC GOTOBUTTON _Toc416054247 PAGEREF _Toc416054247
68
9.3.2.6 RP-SM-MEMORY-AVAILABLE GOTOBUTTON _Toc416054248 PAGEREF
_Toc416054248 68
10 Fundamental procedures within the point-to-point SMS GOTOBUTTON
_Toc416054249 PAGEREF _Toc416054249 68
10.1 Short message mobile terminated GOTOBUTTON _Toc416054250
PAGEREF _Toc416054250 69
10.2 Short message mobile originated GOTOBUTTON _Toc416054251
PAGEREF _Toc416054251 80
10.3 Alert transfer GOTOBUTTON _Toc416054252 PAGEREF _Toc416054252
85
11 Mapping of error causes between RP layers GOTOBUTTON _Toc416054253
PAGEREF _Toc416054253 87
11.1 Mobile Terminated short message transfer GOTOBUTTON _Toc416054254
PAGEREF _Toc416054254 87
11.2 Memory available notification GOTOBUTTON _Toc416054255 PAGEREF
_Toc416054255 88
11.3 Mobile Originated short message transfer GOTOBUTTON _Toc416054256
PAGEREF _Toc416054256 88
Annex A (informative): Protocol stacks for interconnecting SCs and MSCs
GOTOBUTTON _Toc416054257 PAGEREF _Toc416054257 90
Annex B (informative): Information now contained in GSM 03.38
GOTOBUTTON _Toc416054258 PAGEREF _Toc416054258 91
Annex C (informative): Short message information flow GOTOBUTTON
_Toc416054259 PAGEREF _Toc416054259 92
Annex D (informative): Mobile Station reply procedures GOTOBUTTON
_Toc416054260 PAGEREF _Toc416054260 109
D.1 Introduction GOTOBUTTON _Toc416054261 PAGEREF _Toc416054261
109
D.2 The scope of applicability GOTOBUTTON _Toc416054262 PAGEREF
_Toc416054262 109
D.3 Terminology GOTOBUTTON _Toc416054263 PAGEREF _Toc416054263 109
D.4 The reply path requesting procedure GOTOBUTTON _Toc416054264
PAGEREF _Toc416054264 109
D.5 The reception of an original MT SM GOTOBUTTON _Toc416054265
PAGEREF _Toc416054265 110
D.6 The submission of the reply MO SM GOTOBUTTON _Toc416054266
PAGEREF _Toc416054266 110
D.7 Usage of SCs for replying GOTOBUTTON _Toc416054267 PAGEREF
_Toc416054267 110
D.8 Replying possibilities for Phase 1 mobile stations GOTOBUTTON
_Toc416054268 PAGEREF _Toc416054268 111
D.9 The resulting service for originating SMEs GOTOBUTTON
_Toc416054269 PAGEREF _Toc416054269 111
Annex E (informative): Change History GOTOBUTTON _Toc416054270
PAGEREF _Toc416054270 112
History GOTOBUTTON _Toc416054271 PAGEREF _Toc416054271 113
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have
been declared to ETSI. The information pertaining to these essential
IPRs, if any, is publicly available for ETSI members and non-members,
and can be found in ETR 314: " Intellectual Property Rights (IPRs);
Essential, or potentially Essential, IPRs notified to ETSI in respect of
ETSI standards " , which is available free of charge from the ETSI
Secretariat. Latest updates are available on the ETSI Web server
(http://www.etsi.fr/ipr or http://www.etsi.org/ipr).
Pursuant to the ETSI Interim IPR Policy, no investigation, including IPR
searches, has been carried out by ETSI. No guarantee can be given as to
the existence of other IPRs not referenced in ETR 314 (or the updates on
the ETSI Web server) which are, or may be, or may become, essential to
the present document.
Foreword
This Draft European Telecommunications Standard (EN) has been produced
by the Special Mobile Group (SMG) of the European Telecommunications
Standards Institute (ETSI).
This EN describes the point-to-point Short Message Service (SMS) of the
digital cellular telecommunications system (Phase 2/Phase 2+).
The contents of this EN is subject to continuing work within SMG and may
change following formal SMG approval. Should SMG modify the contents of
this EN, it will be resubmitted for OAP by ETSI with an identifying
change of release date and an increase in version number as follows:
Version 6.x.y
where:
6 indicates GSM Release 1997 of Phase 2+
y the third digit is incremented when editorial only changes have been
incorporated in the specification;
x the second digit is incremented for all other types of changes, i.e.
technical enhancements, corrections, updates, etc.
The specification from which this EN has been derived was originally
based on CEPT documentation, hence the presentation of this EN may not
be entirely in accordance with the ETSI/PNE rules.
Introduction
The Point-to-Point Short Message Service (SMS) provides a means of
sending messages of limited size to and from GSM mobiles. The provision
of SMS makes use of a Service Centre, which acts as a store and forward
centre for short messages. Thus a GSM PLMN needs to support the transfer
of short messages between Service Centres and mobiles.
Two different point-to-point services have been defined: mobile
originated and mobile terminated. Mobile originated messages will be
transported from an MS to a Service Centre. These may be destined for
other mobile users, or for subscribers on a fixed network. Mobile
terminated messages will be transported from a Service Centre to an MS.
These may be input to the Service Centre by other mobile users (via a
mobile originated short message) or by a variety of other sources, e.g.
speech, telex, or facsimile.
The present document includes references to features which were
introduced into the GSM Technical specifications after Release 96 of GSM
Phase 2+. GSM 10.01 defines the correspondence between these features
and GSM yearly releases.
The following table lists all features that were introduced after
Release 96 and have impacted this specification:
Feature Designator
Optional SMSC Control Parameters - Selective Status Report not used
Optional Source Indicator in the User Data Header not used
Optional Status Report PDU Enhancement not used
Optional UDH in all PDUs containing user data. not used
Optional SMS Secured Messaging not used
Optional Transmission of the SME Originating Address between the SMSC
and the SMS-GMSC not used
GPRS not used
Mobile phone management not used
1 Scope
This European Telecommunications Standard (EN) describes the
point-to-point Short Message Service (SMS) of the GSM PLMN system. It
defines:
- the services and service elements;
- the network architecture;
- the Service Centre functionality;
- the MSC functionality (with regard to the SMS);
- the SGSN functionality (with regard to the SMS);
- the routing requirements;
- the protocols and protocol layering;
for the Teleservices 21 and 22, as specified in the GSM 02.03
(ETS 300 905).
The use of radio resources for the transfer of short messages between
the MS and the MSC or the SGSN is described in GSM 04.11 (ETS 300 942)
" Point-to-Point Short Message Service Support on Mobile Radio
Interface " , and is dealt with in that specification.
The network aspects of Short Message Service provision are outside the
scope of this specification (i.e. the provision of network connectivity
between the PLMN subsystems). There is no technical restriction within
this specification for the transfer of short messages between different
PLMN's. Any such restriction is likely to be subject to commercial
arrangements and PLMN operators must make their own provision for
interworking or for preventing interworking with other PLMN's as they
see fit.
The required and assumed network service offered to the higher layers is
defined in this specification.
The Cell Broadcast Short Message Service (Teleservice 23) is a separate
service, and is described in GSM 03.41 (ETS 300 902) " Technical
Realization of the Short Message Service - Cell Broadcast " .
2 Normative references
This ETS incorporates by dated and undated references, 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 350): " Digital cellular telecommunication system
(Phase 2+); Abbreviations and acronyms " .
[2] GSM 02.03 (ETS 300 905): " Digital cellular telecommunication system
(Phase 2+); Teleservices supported by a GSM Public Land Mobile Network
(PLMN) " .
[3] GSM 02.04 (ETS 300 918): " Digital cellular telecommunication system
(Phase 2+); General on supplementary services " .
[4] GSM 02.41: " Digital cellular telecommunication system (Phase 2+);
Operator determined barring " .
[5] GSM 03.02: " Digital cellular telecommunication system (Phase 2+);
Network architecture " .
[6] GSM 03.08: " Digital cellular telecommunication system (Phase 2+);
Organization of subscriber data " .
[7] GSM 03.11 (ETS 300 928): " Digital cellular telecommunication system;
Technical realization of supplementary services " .
[8] GSM 03.15: " Digital cellular telecommunication system (Phase 2+);
Technical realization of operator determined barring " .
[9] GSM 03.38 (ETS 300 900): " Digital cellular telecommunication system
(Phase 2+); Alphabets and language-specific information " .
[10] GSM 03.41 (ETS 300 902): " Digital cellular telecommunication system
(Phase 2+); Technical realization of Short Message Service Cell
Broadcast (SMSCB) " .
[11] GSM 03.47 (ETR 354): " Digital cellular telecommunication system;
Example protocol stacks for interconnecting Service Centre(s) (SC) and
Mobile-services Switching Centre(s) (MSC) " .
[12] GSM 04.08 (ETS 300 557): " Digital cellular telecommunication system
(Phase 2); Mobile radio interface layer 3 specification " .
[13] GSM 04.11 (ETS 300 942): " Digital cellular telecommunication system
(Phase 2+); Point-to-Point (PP) Short Message Service (SMS) support on
mobile radio interface " .
[14] GSM 07.05: " Digital cellular telecommunication system (Phase 2+);
Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE
- DCE) interface for Short Message Service (SMS) and Cell Broadcast
Service (CBS) " .
[15] GSM 09.02 (ETS 300 974): " Digital cellular telecommunication system
(Phase 2+); Mobile Application Part (MAP) specification " .
[16] GSM 11.11 (ETS 300 977): " Digital cellular telecommunication system
(Phase 2+); Specification of the Subscriber Identity Module - Mobile
Equipment (SIM - ME) interface " .
[17] CCITT Recommendation E.164 (Blue Book): " Numbering plan for the
ISDN era " .
[18] CCITT Recommendation E.163 (Blue Book): " Numbering plan for the
international telephone service " .
[19] CCITT Recommendation Q.771: " Specifications of Signalling System
No.7; Functional description of transaction capabilities " .
[20] CCITT Recommendation T.100 (Blue Book): " International information
exchange for interactive videotex " .
[21] CCITT Recommendation T.101 (Blue Book): " International interworking
for videotex services " .
[22] CCITT Recommendation X.121 (Blue Book): " International numbering
plan for public data networks " .
[23] CCITT Recommendation X.400 (Blue Book): " Message handling system
and service overview " .
[24] ISO/IEC10646, " Universal Multiple-Octet Coded Character Set (USC);
UCS2, 16 bit coding " .
[25] GSM 02.22: " Digital cellular telecommunication system (Phase 2+);
Personalization of GSM Mobile Equipment (ME); Mobile functionality
specification " .
[26] GSM 03.42: " Digital cellular telecommunication system (Phase 2+);
Compression Algorithm for Text Messaging Services''
[27] GSM 03.60: " Digital cellular telecommunications system (Phase 2+);
General Packet Radio Service (GPRS); Service description; Stage 2 " .
[28] GSM 03.48: " SIM Toolkit Secure Messaging (Phase 2+) " .
2.1 Definitions and abbreviations
NOTE: Use of hyphens and full stops:
Care is needed when reading this specification as names containing
words separated by hyphens have different meaning than when separated
with full stops. E.g. TS-Status-Report-Request is a parameter within a
TS-Submit primitive, whilst TS-Status-Report. Request is a primitive in
its own right.
2.1.1 Definitions
active MS: A switched-on mobile station with a SIM module attached.
alert-SC: Service element provided by a GSM PLMN to inform an SC which
has previously initiated unsuccessful short message delivery attempt(s)
to a specific MS, that the MS is now recognized by the PLMN to have
recovered operation.
status report: SC informing the originating MS of the outcome of a short
message submitted to an SME.
Gateway MSC For Short Message Service (SMS-GMSC): A function of an MSC
capable of receiving a short message from an SC, interrogating an HLR
for routing information and SMS info, and delivering the short message
to the VMSC or the SGSN of the recipient MS.
Interworking MSC For Short Message Service (SMS-IWMSC): A function of an
MSC capable of receiving a short message from within the PLMN and
submitting it to the recipient SC.
Messages-Waiting (MW): Service element that makes a PLMN store
information (Messages-Waiting-Indication), listing those SCs that have
made unsuccessful short message delivery attempts to MSs in that PLMN.
Messages-Waiting-Indication (MWI): Data to be stored in the HLR and VLR
with which an MS is associated, indicating that there is one or more
messages waiting in a set of SCs to be delivered to the MS (due to
unsuccessful delivery attempt(s)).
Messages-Waiting-Data (MWD): A part of the MWI to be stored in the HLR.
MWD consists of an address list of the SCs which have messages waiting
to be delivered to the MS.
Mobile-services Switching Centre (MSC): The Mobile-services Switching
Centre is an exchange which performs switching functions for mobile
stations located in a geographical area designated as the MSC area.
Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF): A part of the MWI
to be stored in the HLR. MCEF is a Boolean parameter indicating if the
address list of MWD contains one or more entries because an attempt to
deliver a short message to an MS has failed with a cause of MS Memory
Capacity Exceeded.
Mobile-Station-Not-Reachable-Flag (MNRF): The part of the MWI to be
stored in the VLR and the HLR. MNRF is a Boolean parameter indicating if
the address list of MWD contains one or more entries because an attempt
to deliver a short message to an MS has failed with a cause of Absent
Subscriber.
Mobile-station-Not-Reachable-for-GPRS (MNRG): The part of the MWI to be
stored in the SGSN and the HLR. MNRG is a Boolean parameter indicating
if the address list of MWD contains one or more entries because an
attempt to deliver a short message to an MS has failed with a cause of
Absent Subscriber.
Mobile-Station-Not-Reachable-Reason (MNRR): The part of the MWI in the
HLR which stores the reason for an MS being absent when an attempt to
deliver a short message to an MS fails at the MSC with a cause of Absent
Subscriber.More-Messages-To-Send (MMS): Information element offering an
MS receiving a short message from an SC the information whether there
are still more messages waiting to be sent from that SC to the MS. The
TP-MMS element (conveyed in the Transfer layer) is copied into the
RP-MMS element (conveyed in the Relay layer). It is possible with
Phase 2 and later versions of MAP (GSM TS 09.02) for the RP-MMS element
to keep an SM transaction open between the GMSC and the MS in the case
where there are more-messages-to-send. Earlier versions of MAP will
support the transport of the TP-MMS element.
priority: Service element enabling the SC or SME to request a short
message delivery attempt to an MS irrespective of whether or not the MS
has been identified as temporarily absent.
protocol-identifier: Information element by which the originator of a
short message (either an SC or an MS) may refer to a higher layer
protocol.
reply path procedure: A mechanism which allows an SME to request that an
SC should be permitted to handle a reply sent in response to a message
previously sent from that SME to another SME. This may happen even
though the SC may be unknown to the SME which received the initial
message.
report: Response from either the network or the recipient upon a short
message being sent from either an SC or an MS. A report may be a
delivery report, which confirms the delivery of the short message to the
recipient, or it may be a failure report, which informs the originator
that the short message was never delivered and the reason why.
When issued by the Service Centre, the delivery report confirms the
reception of the Short Message by the SC, and not the delivery of the
Short Message to the SME.
When issued by the Mobile Station, the delivery report confirms the
reception of the Short Message by the Mobile Station, and not the
delivery of the Short Message to the user.
replace short message type: A range of values in the Protocol Identifier
which allows an indication to be sent with a short message (MT or MO)
that the short message is of a particular type allowing the receiving MS
or the SC to replace an existing message of the same type held in the
SC, the ME or on the SIM, provided it comes:
- in MT cases: from the same SC and originating address;
- in MO cases: from the same MS.
Service Centre (SC): Function responsible for the relaying and
store-and-forwarding of a short message between an SME and an MS. The SC
is not a part of the GSM PLMN, however MSC and SC may be integrated.
Serving GPRS Support Node (SGSN): The Serving GPRS Support Node is an
exchange which performs packet switching functions for mobile stations
located in a geographical area designated as the SGSN area.
short message: Information that may be conveyed by means of the Short
Message Service described in this specification.
Short Message Entity (SME): An entity which may send or receive Short
Messages. The SME may be located in a fixed network, an MS, or an SC.
SMS-STATUS-REPORT: Short message transfer protocol data unit informing
the receiving MS of the status of a mobile originated short message
previously submitted by the MS, i.e. whether the SC was able to forward
the message or not, or whether the message was stored in the SC for
later delivery.
SMS-COMMAND: Short message transfer protocol data unit which enables an
MS to invoke an operation at the SC. An MS may then, for example, delete
a short message, cancel a Status Report Request, enquire about the
status of a short message or request another function to be performed by
the SC.
The type of operation is indicated by the TP-Command-Type and the
particular SM to operate on is indicated by the TP-Message-Number and
the TP-Destination-Address. Receipt of an SMS-COMMAND is confirmed by an
RP-ACK or RP-ERROR. In the case of certain SMS-COMMANDs, an
SMS-STATUS-REPORT may be sent, where the outcome of the SMS-COMMAND is
passed in its TP-Status field.
SMS-DELIVER: Short message transfer protocol data unit containing user
data (the short message), being sent from an SC to an MS.
SMS-SUBMIT: Short message transfer protocol data unit containing user
data (the short message), being sent from an MS to an SC.
Service-Centre-Time-Stamp (SCTS): Information element offering the
recipient of a short message the information of when the message arrived
at the SM-TL entity of the SC. The time of arrival comprises the year,
month, day, hour, minute, second and time zone.
Validity-Period (VP): Information element enabling the originator MS to
indicate the time period during which the originator considers the short
message to be valid.
2.2.2 Abbreviations
For the purposes of this EN, the following abbreviations apply
ACSE Association Control Service Element
E.163 CCITT Rec. E.163 (Blue Book)
E.164 CCITT Rec. E.164 (Blue Book)
SM MT Short Message Mobile Terminated Point-to-Point
SM MO Short Message Mobile Originated Point-to-Point
SM-AL Short Message Application Layer
SM-TL Short Message Transfer Layer
SM-RL Short Message Relay Layer
SM-LL Short Message Lower Layers
SM-TP Short Message Transfer Layer Protocol
SM-RP Short Message Relay Layer Protocol
SM-TS Short Message Transfer Service
SM-RS Short Message Relay Service
T.100 CCITT Rec. T.100 (Blue Book)
T.101 CCITT Rec. T.101 (Blue Book)
TPDU Transfer protocol data unit
X.121 CCITT Rec. X.121 (Blue Book)
X.400 CCITT Rec. X.400 (Blue Book)
In addition to those above, definitions used in this EN are listed in
GSM 01.04.
3 Services and service elements
The SMS provides a means to transfer short messages between a GSM MS and
an SME via an SC. The SC serves as an interworking and relaying function
of the message transfer between the MS and the SME.
This specification describes only the short message point-to-point
services between the MS and SC. It may, however, refer to possible
higher layer applications.
3.1 Basic services
The short message point-to-point services comprise two basic services:
SM MT (Short Message Mobile Terminated Point-to-Point);
SM MO (Short Message Mobile Originated Point-to-Point).
SM MT denotes the capability of the GSM system to transfer a short
message submitted from the SC to one MS, and to provide information
about the delivery of the short message either by a delivery report or a
failure report with a specific mechanism for later delivery; see
figure 03.40/1.
SM MO denotes the capability of the GSM system to transfer a short
message submitted by the MS to one SME via an SC, and to provide
information about the delivery of the short message either by a delivery
report or a failure report. The message must include the address of that
SME to which the SC shall eventually attempt to relay the short message;
see figure 03.40/2.
The text messages to be transferred by means of the SM MT or SM MO
contain up to 140 octets.
Short message delivery
Report
Figure 03.40/1: The Short Message Service mobile terminated,
point-to-point
Short message submission
Report
Figure 03.40/2: The Short Message Service mobile originated,
point-to-point
An active MS shall be able to receive a short message TPDU (SMS-DELIVER)
at any time, independently of whether or not there is a speech or data
call in progress. A report will always be returned to the SC; either
confirming that the MS has received the short message, or informing the
SC that it was impossible to deliver the short message TPDU to the MS,
including the reason why.
An active MS shall be able to submit a short message TPDU (SMS-SUBMIT)
at any time, independently of whether or not there is a speech or data
call in progress. A report will always be returned to the MS; either
confirming that the SC has received the short message TPDU, or informing
the MS that it was impossible to deliver the short message TPDU to the
SC, including the reason why.
NOTE: When the transmission or reception of a short message coincide
with a change of state in the MS, i.e. from busy to idle or from idle to
busy, or during a handover, the short message transfer might be aborted.
It is also possible for two short messages to be received in sequence
having the same originating address and identification, i.e. message
reference number (MO) or SC Timestamp (MT). Such a situation may be due
to errors at the RP or CP layers (e.g. during inter MSC handover) where
it may be a duplicated message or otherwise it may be a valid new
message.
The receiving entity should therefore make provision to check other
parameters contained in the short message to decide whether the second
short message is to be discarded.
3.2 Short Message Service elements
The SMS comprises 7 elements particular to the submission and reception
of messages:
Validity-Period;
Service-Centre-Time-Stamp;
Protocol-Identifier;
More-Messages-to-Send;
Priority;
Messages-Waiting;
Alert-SC.
3.2.1 Validity-Period
The Validity-Period is the information element which gives an MS
submitting an SMS-SUBMIT to the SC the possibility to include a specific
time period value in the short message (TP-Validity-Period field, see
section 9). The TP-Validity-Period parameter value indicates the time
period for which the short message is valid, i.e. for how long the SC
shall guarantee its existence in the SC memory before delivery to the
recipient has been carried out.
3.2.2 Service-Centre-Time-Stamp
The Service-Centre-Time-Stamp is the information element by which the SC
informs the recipient MS about the time of arrival of the short message
at the SM-TL entity of the SC. The time value is included in every
SMS-DELIVER (TP-Service-Centre-Time-Stamp field, see section 9) being
delivered to the MS.
3.2.3 Protocol-Identifier toc \o
The Protocol-Identifier is the information element by which the SM-TL
either refers to the higher layer protocol being used, or indicates
interworking with a certain type of telematic device.
The Protocol-Identifier information element makes use of a particular
field in the message types SMS-SUBMIT, SMS-SUBMIT-REPORT for RP-ACK,
SMS-DELIVER DELIVER, SMS-DELIVER-REPORT for RP-ACK, SMS_STATUS_REPORT
and SMS-COMMAND TP-Protocol-Identifier (TP-PID).
3.2.4 More-Messages-to-Send
The More-Messages-to-Send is the information element by which the SC
informs the MS that there is one or more messages waiting in that SC to
be delivered to the MS. The More-Messages-to-Send information element
makes use of a Boolean parameter in the message SMS-DELIVER,
TP-More-Messages-to-Send (TP-MMS).
3.2.5 Delivery of Priority and non-Priority Messages
Priority is the information element provided by an SC or SME to indicate
to the PLMN whether or not a message is a priority message.
Delivery of a non-priority message will not be attempted if the MS has
been identified as temporarily absent (see section 3.2.6).
Delivery of a non-priority message will be attempted if the MS has not
been identified as temporarily absent irrespective of whether the MS has
been identified as having no free memory capacity (see section 3.2.6).
Delivery of a priority message will be attempted irrespective of whether
or not the MS has been identified as temporarily absent, or having no
free memory capacity.
3.2.6 Messages-Waiting
The Messages-Waiting is the service element that enables the PLMN to
provide the HLR, SGSN and VLR with which the recipient MS is associated
with the information that there is a message in the originating SC
waiting to be delivered to the MS. The service element is only used in
case of previous unsuccessful delivery attempt(s) due to temporarily
absent mobile or MS memory capacity exceeded. This information, denoted
the Messages-Waiting-Indication (MWI), consists of Messages-Waiting-Data
(MWD), ), the Mobile-station-Not-Reachable-for-GPRS (MNRG), the
Mobile-Station-Not-Reachable-Flag (MNRF), the
Mobile-Not-Reachable-Reason (MNRR) and the
Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF) located in the HLR;
the Mobile-station-Not Reachable-for-GPRS (MNRG) located in the SGSN,
and the Mobile-Station-Not-Reachable-Flag (MNRF) located in the VLR.
figure 03.40/3 shows an example.
Figure 03.40/3: Example of how information on one MS can be put in
relation to SC(s)
in order to fulfil the requirement of Alert-SC mechanism
The MWD shall contain a list of addresses (SC-Addr) of SCs which have
made previous unsuccessful delivery attempts of a message (see
section 5). In order to be able to send alert messages to every SC which
has made unsuccessful delivery attempts to an MS, the HLR shall store
the MSIsdn-Alert (see section 3.2.7) together with references to the SC
addresses. The requirements placed upon the HLR are specified in
GSM 03.08. The description of how the HLR is provided with SC and MS
address information is given in GSM 09.02.
The Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF) within the HLR
is a Boolean parameter with the value TRUE an attempt to deliver a short
message to an MS has failed with a cause of MS Memory Capacity Exceeded,
and with the value FALSE otherwise.
The Mobile-station-Not Reachable-for-GPRS (MNRG) within the HLR and the
SGSN is a Boolean parameter with the value TRUE when an attempt to
deliver a short message to an MS has failed with a cause of Absent
Subscriber, and with the value FALSE otherwise (except as described in
note 1 below).
The Mobile-Station-Not-Reachable-Flag (MNRF) within the HLR and the VLR
is a Boolean parameter with the value TRUE when the list MWD contains
one or more list elements because an attempt to deliver a short message
to an MS has failed with a cause of Absent Subscriber, and with the
value FALSE otherwise.
The Mobile-Station-Not-Reachable-Reason (MNRR) within the HLR stores the
reason for the MS being absent when an attempt to deliver a short
message to an MS fails at the MSC, SGSN or both with the cause Absent
Subscriber. The HLR updates the MNRR with the reason for absence when an
absent subscriber diagnostic information is received from the GMSC and
the MNRF, MNRG or both are set. The HLR clears the MNRR when the MNRF
and MNRG are cleared. If the MNRF is set due to a failure at the MSC
with cause Absent Subscriber and information pertaining to the absence
of the MS is not available from the GMSC, the MNRR will remain in a
cleared state. Also, if the MNRG is set due to a failure at the SGSN
with cause Absent Subscriber and information pertaining to the absence
of the MS is not available from the GMSC, the MNRR will remain in a
cleared state. The MNRR shall either be in a cleared state or contain
one of the following reasons:
No Paging Response via the MSC;
No Paging Response via the SGSN;
IMSI Detached;
GPRS Detached.
NOTE 1: The MNRG can also be set in the HLR and in the SGSN after an
unsuccessful attempt to invoke the network requested PDP-Context
Activation procedure. In this case, no SC address is stored in MWD list
(see TS GSM 03.60).
NOTE 2: When a short message delivery attempt fails at the HLR due to
Roaming being Restricted, the MS being deregistered in HLR or the MS
being Purged the absent subscriber diagnostic reason is returned to the
SC, however the reason is not stored in the MNRR.
The MWD, MCEF, MNRR, MNRG and MNRF are updated in the following way:
1a) When a mobile terminated short message delivery fails due to the MS
being temporarily absent (i.e. either IMSI DETACH flag is set or there
is no response from the MS to a paging request via the MSC), the SC
address is inserted into the MWD list (if it is not already present),
the MNRF is set (if it is not already set) and the MNRR via the MSC is
updated (if the information is available), as described in section 10.
1b) When a mobile terminated short message delivery fails due to the MS
being temporarily absent (i.e. either GPRS DETACH flag is set or there
is no response from the MS to a paging request via the SGSN), the SC
address is inserted into the MWD list (if it is not already present),
the MNRG is set (if it is not already set) and the MNRR via the SGSN is
updated (if the information is available), as described in clause 10.
1c) When a mobile terminated short message delivery fails due to the MS
memory capacity via the MSC being exceeded, the SC address is inserted
into the MWD list (if it is not already present) ,the MCEF is set (if it
is not already set), the MNRF is cleared and the MNRR via the MSC is
updated as described in clause 10.
1d) When a mobile terminated short message delivery fails due to the MS
memory capacity via the SGSN being exceeded, the SC address is inserted
into the MWD list (if it is not already present), the MCEF is set (if it
is not already set), the MNRG is cleared and the MNRR via the SGSN is
updated as described in clause 10.
1e) If the MSIsdn used by the SC to address the recipient MS for
alerting purposes is different from the MSIsdn-Alert of the MS (see
section 3.2.7), the HLR returns the MSIsdn-Alert to the SC within the
failure report, see " 1c Failure report " in figures 03.40/15 and /16.
2a) When either the HLR or VLR detects that the MS (with a non-empty MWD
and the MCEF clear in the HLR and the MNRF set in the VLR) has recovered
operation (e.g. has responded to a paging request over MSC), the HLR
directly or on request of the VLR will invoke operations to alert the
SCs within the MWD (see section 3.2.7 and section 10). Once the Alert SC
operations have been invoked, the MNRF and MNRR via the MSC are cleared.
After each SC is alerted by the HLR, the address for that SC is deleted
from the MWD. If the MCEF is set in the HLR, the HLR clears the MNRF and
MNRR via the MSC, but does not invoke operations to alert the SCs within
the MWD and data are not cleared from the MWD.
2b) When either the HLR or SGSN detects that the MS (with a non-empty
MWD and the MCEF clear in the HLR and the MNRG set in the SGSN) has
recovered operation (e.g. has responded to a paging request via the
SGSN), the HLR directly or on request of the SGSN will invoke operations
to alert the SCs within the MWD (see subclause 3.2.7 and clause 10).
Once the Alert SC operations have been invoked, the MNRG and MNRR via
the SGSN are cleared. After each SC is alerted by the HLR, the address
for that SC is deleted from the MWD. If the MCEF is set in the HLR, the
HLR clears the MNRG and MNRR via the SGSN, but does not invoke
operations to alert the SCs within the MWD and data are not cleared from
the MWD.
2c) When the HLR receives (via the MSC and the VLR) a notification that
the MS (with a non-empty MWD and the MCEF set in the HLR) has memory
capacity available to receive one or more short messages, the HLR will
invoke operations to alert the SCs within the MWD (see section 3.2.7 and
section 10). Once the Alert SC operations have been invoked, the MNRF is
cleared in the VLR and the MCEF, MNRF and MNRR via the MSC are cleared
in the HLR. After each SC is alerted by the HLR, the address for that SC
is deleted from the MWD.
2d) When the HLR receives (via the SGSN) a notification that the MS
(with a non-empty MWD and the MCEF set in the HLR) has memory capacity
available to receive one or more short messages, the HLR will invoke
operations to alert the SCs within the MWD (see subclause 3.2.7 and
clause 10). Once the Alert SC operations have been invoked, the MNRG is
cleared in the SGSN and the MCEF, MNRG and MNRR via the SGSN are cleared
in the HLR. After each SC is alerted by the HLR, the address for that SC
is deleted from the MWD.
2e) When the HLR receives from the SMS-GMSC a notification that a short
message has been successfully delivered from an SC to an MS via the MSC
for which the MCEF is set and the MWD are not empty, the HLR will invoke
operations to alert other SCs within the MWD (see subclause 3.2.7 and
clause 10). Once the Alert SC operations have been invoked, the MCEF,
MNRF and MNRR via the MSC are cleared in the HLR. After each SC is
alerted by the HLR, the address for that SC is deleted from the MWD. The
SC which successfully delivered the message is also deleted from the
MWD, if present.
2f) When the HLR receives from the SMS-GMSC a notification that a short
message has been successfully delivered from an SC to an MS via the SGSN
for which the MCEF is set and the MWD are not empty, the HLR will invoke
operations to alert other SCs within the MWD (see subclause 3.2.7 and
clause 10). Once the Alert SC operations have been invoked, the MCEF,
MNRG and MNRR via the SGSN are cleared in the HLR. After each SC is
alerted by the HLR, the address for that SC is deleted from the MWD. The
SC which successfully delivered the message is also deleted from the
MWD, if present.
2g) When the HLR receives (via the MSC and the VLR, or the SGSN) a
notification that the MS has memory capacity available to receive one or
more short messages but the MCEF is not set and the MWD are empty, the
HLR acknowledges the notification but does not alert any service centre.
NOTE 1: The HLR can be in a situation where the MWD list is empty but
where either MNRF or MNRG (with the related MNRR) is still set. This
enables the HLR to return the correct address (MSC or SGSN address) at
the next Send Routing Information Request from the SMS-GMSC.
NOTE 2: If the SMS delivery failed on first attempt via the MSC or the
SGSN (see cases 1a for IMSI Detach and 1b for GPRS Detach), and is
successful on the second attempt (see cases 2e and 2f), the SC address
shall not be inserted into the MWD list
3.2.7 Alert-SC
The Alert-SC is the service element, which may be provided by some GSM
PLMNs, to inform the SC that an MS
1) to which a delivery attempt has failed because the MS is not
reachable or because the MS memory capacity was exceeded;
and
2) which is now recognized by the PLMN:
a) to have resumed operation (e.g. to have responded to a paging
request); or
b) to have memory newly available (which implies that the mobile is
reachable).
is again ready to receive one or more short messages. The SC may - on
reception of an Alert-SC - initiate the delivery attempt procedure for
the queued messages destined for this MS.
To each MS there may be allocated several MSIsdns. When the HLR is to
alert an SC that an MS is again attainable it will use a specific MSIsdn
value for this purpose; in this specification called MSIsdn-Alert.
NOTE: Repeated delivery attempts from the SC may be of two types:
i) A repeated delivery attempt because the SC has been informed that the
MS is active and available to receive short messages.
ii) An autonomous repeated delivery attempt by the SC.
The application of these two options is defined by the providers of the
SC and the network.
3.2.8 Options concerning MNRG, MNRF, MNRR, MCEF and MWD
Setting the Mobile-Station-Not-Reachable-Flag (MNRF) in the VLR is
mandatory. Setting the Mobile-station-Not-Reachable-for-GPRS (MNRG) in
the SGSN is mandatory. It is mandatory for the VLR or the SGSN to send
the " MS Reachable " message (see clause 10) to the HLR when the MS has
been detected as becoming active and then to clear MNRF in the VLR or
the MNRG in SGSN.
The Messages-Waiting-Data (MWD), the Mobile-Station-Not-Reachable-Flag
(MNRF), the Mobile-station-Not-Reachable-for-GPRS (MNRG), the
Mobile-Station-Not-Reachable-Reason (MNRR) and the
Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF)) within the HLR are
optional, but if one is implemented all must be implemented (except MNRG
if the HLR does not support GPRS). This is linked to the transmission of
the " Alert SC " message.
The following describes what happens when a delivery fails.
Case 1: MWD, MNRF, MNRG, MNRR and MCEF are implemented in the HLR
In the case of a delivery failure (to an MS) with cause Absent
Subscriber, the SMS-GMSC requests the HLR to add, if needed, a new entry
in the MWD with cause Absent Subscriber. This new entry contains the SC
address. The HLR sets its copy of the MNRF, MNRG or both and updates
the MNRR (if the information is available). The SC is notified of the
failure, the reason for the MS being absent and also of the MWD setting
in the HLR within the Report message (see clause 10).
In the case of a delivery failure (to an MS) with cause Mobile Station
Memory Capacity Exceeded via the SGSN or the MSC, the SMS-GMSC requests
the HLR to add, if needed, a new entry in the MWD with cause Mobile
Station Memory Capacity Exceeded. This new entry contains the SC
address. The HLR sets the MCEF and reset MNRF or MNRG. The SC is
notified of the failure and also of the MWD setting in the HLR within
the Report message (see clause 10).
If the HLR indicates that it is able to store the SC address, then the
SC will receive an Alert SC message when the MS becomes active.
If the HLR indicates that it is unable to store the SC address (e.g.
because MWD is full), then the only way to ensure delivery is for the SC
to try to retransmit the message periodically.
When the HLR receives the MS Reachable message, if the MCEF is clear it
sends an Alert SC message to the concerned SC, updates MWD and clears
MNRF (if the MS is reachable via the MSC) or MNRG (if the MS is
reachable via the SGSN).
When the HLR receives the MS Memory Capacity Available message, it
sends an Alert SC message to the concerned SC, updates MWD, clears the
MCEF and clears MNRF (if the MS is reachable via the MSC) or MNRG (if
the MS is reachable via the SGSN).
Case 2: MWD, MNRF, MNRG, MNRR and MCEF are not implemented in the HLR
In the case of a delivery failure, the SC is notified that the HLR is
unable to store its address in the MWD. In case of a delivery failure
(to a MS) with cause Absent Subscriber, the SC is notified of the reason
for the MS being absent (if the information is available). The SC must
retransmit the short message periodically in order to ensure delivery.
The HLR discards the MS Reachable message received from the VLR or
SGSN without any failure or error report.
The HLR discards the MS Memory Capacity Available message received from
the MS via the MSC and the VLR or SGSN without any failure or error
report.
3.2.9 Status report capabilities
The SMS also offers to the SC the capabilities of informing the MS of
the status of a previously sent mobile originated short message. The
status of the message can be:
- Successfully delivered to the SME;
- The SC was not able to forward the message to the SME. The reason can
be an error of permanent or temporary nature. Permanent errors can be
e.g. validity period expired, invalid SME address. Errors of temporary
nature can be e.g. SC-SME connection being down, SME temporarily
unavailable.
This is achieved by the SC returning a status report TPDU
(SMS-STATUS-REPORT) to the originating MS when the SC has concluded the
status of the short message. The status report may be initiated by a
status report request within the mobile originated short message. The
status report TPDU is treated as an SMS-DELIVER TPDU by the SC when it
comes to delivery procedures e.g. the alerting mechanism.
The SC may also return to a non-MS SME the status of a mobile terminated
short message. This is however outside the scope of this specification.
The status report capabilities of the SMS are optional, i.e. the choice
of whether to offer status report or not is left to the SC operator.
3.2.10 Reply Path
Reply Path specified in this specification provides a way of both
requesting and indicating a service centre's commitment to deliver a
reply from the replying MS to the originating SME.
Annex D deals with MS procedures, which in general are outside the scope
of GSM specifications. However, for advanced use of the SMS, including
both application level protocols and human responses, it is of vital
importance to guarantee that a reply-supporting MS is able to reply on
every SM, to every SME capable of receiving such reply short messages.
3.3 Unsuccessful short message TPDU transfer SC - & gt; MS
Unsuccessful message transfer SC - & gt; MS may be caused by a variety of
different errors. The description of the occurrence of the different
errors and how to handle and transfer the error indications is given in
GSM 04.08, GSM 04.11 and GSM 09.02.
The different error indications which the SMS-GMSC shall be capable of
returning to the SC following an unsuccessful short message TPDU
transfer SC - & gt; MS, are given in table 03.40/1. In some cases, additional
diagnostic information may be provided.
3.3.1 Errors occurring during transfer of TPDU to MS
These errors are generally due to barring or unsupported service in the
PLMN or MS. An error indication is returned to the SC from the SMS-GMSC,
but further diagnostic information from the MS will not be available.
3.3.2 Errors occurring after TPDU arrives at MS
These errors may occur due to the MS not supporting optional short
message service features, or in connection with a short message
application. An error indication shall be returned to the SC from the
SMS-GMSC. Additionally, a TPDU (SMS-DELIVER-REPORT) containing
diagnostic information may be conveyed from the MS to the originating
SC, transparently through the PLMN, by means defined in GSM 04.11 and
GSM 09.02. The sending of the diagnostic information is optional at the
MS, but when it is sent, the PLMN shall convey the information to the
SC, and the SC shall support reception of the information.
Table 03.40/1: Error indications related to mobile terminated short
message transfer which may be transferred to the originating SC.
Error indication S1) Meaning
Unknown subscriber P The PLMN rejects the short message TPDU because
there is not allocated an IMSI or a directory number for the mobile
subscriber in the HLR (see GSM 09.02).
Teleservice not provisioned P The PLMN rejects the short message TPDU
because the recipient MS has no SMS subscription (see GSM 09.02).
Call barred T The PLMN rejects the short message TPDU due to barring of
the MS (see GSM 09.02, description of the Barring supplementary service,
GSM 02.04 and 03.11), description of Call barred due to Unauthorised
Message Originator, GSM 09.02, and description of Operator Determined
Barring, GSM 02.41 and 03.15).
Facility not supported T The VPLMN rejects the short message TPDU due to
no provision of the SMS in the VPLMN (see GSM 09.02).
Absent subscriber T The PLMN rejects the short message TPDU because
- there was no paging response via the SGSN, MSC or both, (see
GSM 04.08 & GMS 09.02)
- the IMSI GPRS or both records are marked detached (see GSM 09.02),
- the MS is subject to roaming restrictions (see " Roaming not allowed " ,
GSM 09.02).
- deregistered in the HLR. The HLR does not have an MSC, SGSN or both
numbers stored for the target MS, (see GSM 09.02)
- Unidentified subscriber (see GSM 09.02)
- MS purged, (see GMS 09.02)
(The reasons for absence are assigned interger values in table 03.40/1a.
The appropriate integer value is sent with the absent subscriber error
indication as defined in GSM 09.02)
MS busy for MT SMS T The PLMN rejects the short message TPDU because of
congestion encountered at the visited MSC or the SGSN. Possible reasons
include any of the following events in progress:
- short message delivery from another SC;
- IMSI or GPRS detach
- Location Update or Inter SGSN Routing Area Update;
- paging;
- emergency call;
- call setup.
SMS lower layers capabilities not provisioned T The PLMN
rejects the short message TPDU due to MS not being able to support the
Short Message Service.
The short message transfer attempt is rejected either due to information
contained in the class-mark, or the MSC not being able to establish
connection at SAPI = 3 (see GSM 04.08 and GSM 09.02).
Error in MS T The PLMN rejects the short message TPDU due to an error
occurring within the MS at reception of a short message, e.g. lack of
free memory capacity or protocol error.
Illegal Subscriber P The PLMN rejects the short message TPDU because the
MS failed authentication
Illegal Equipment P The PLMN rejects the short message TPDU because the
IMEI of the MS was black-listed in the EIR
System failure T The PLMN rejects the short message TPDU due to network
or protocol failure others than those listed above (see GSM 09.02)
Memory Capacity Exceeded T The MS rejects the short message since it has
no memory capacity available to store the message
1) : Status (Permanent or Temporary)
The relation between the two sets of error indications is given in the
table 03.40/1. Each error is classified as either " Temporary " or
" Permanent " . This classification gives an indication of whether or not
it is probable that the MS becomes attainable within a reasonable
period, and so provides the recommended action to be taken by the SC,
i.e. either to store the message for later transfer, or to discard it.
Table 03.40/1a: Assignment of values to reasons for absence ( values
must be in the range of 0 to 255, see GSM 09.02)
Values Reason for absence
0 - no paging response via the MSC
1 - IMSI detached
2 - roaming restriction
3 - deregistered in the HLR for non GPRS
4 - MS purged for non GPRS
5 - no paging response via the SGSN
6 - GPRS detached
7 - deregistered in the HLR for GPRS
8 - MS purged for GPRS
9 - Unidentified subscriber via the MSC
10 - Unidentified subscriber via the SGSN
All ´non GPRS´ reasons (except for roaming restriction) can be combined
with all ´GPRS´ reasons and vice-versa
All other integer values are reserved.
3.4 Unsuccessful short message TPDU transfer MS - & gt; SC
The error indications related to mobile originated short message
transfer which may be transferred to the originating MS are given in
GSM 04.11. In some cases, additional diagnostic information may be
provided.
3.4.1 Errors occurring during transfer of TPDU to SC
These errors are generally due to barring or unsupported service in the
PLMN. An error indication is returned to the MS from the MSC or the
SGSN, but further diagnostic information from the SC will not be
available.
3.4.2 Errors occurring after TPDU arrives at SC
These errors may occur due to the SC not supporting optional short
message service features, or in connection with a short message
application. An error indication shall be returned to the MS from the
MSC or from the SGSN. Additionally, a TPDU (SMS-SUBMIT-REPORT)
containing diagnostic information may be conveyed from the SC to the
originating MS, transparently through the PLMN, as defined in GSM 09.02
and GSM 04.11. The sending of the diagnostic information is optional at
the SC, but when it is sent, the PLMN shall convey the information to
the MS, and the MS shall support reception of the information.
Note: The SMS-SUBMIT-REPORT is part of the negative acknowledgement to
the mobile originated short message, and is not part of the status
report capabilities described in section 3.2.9.
3.5 Use of Supplementary Services in combination with the Short Message
Service
Only a sub-set of the Supplementary Services defined in GSM 02.04 and
03.11 may be used in combination with the Short Message Service. This
sub-set comprises the following Supplementary Services:
All the 5 Barring services
3.6 Applicability of Operator Determined Barring to the Short Message
Service
The network feature Operator Determined Barring (see GSM 02.41) applies
to the Short Message Service.
If a short message fails due to operator determined barring then an
appropriate error cause is returned to the originator.
3.7 Multiple short message transfer
To avoid the need for a mobile to be paged, authenticated etc. for each
message waiting in the Service Centre, the SC may indicate to the
SMS-GMSC that there are more messages to send. When this indication is
given, MAP procedures are invoked such that this indication is passed to
the VMSC, and the VMSC does not release the MS until all short messages
waiting in the SC have been transferred.
3.8 SMS and Internet Electronic Mail interworking
The interworking between Internet electronic mail and SMS is offered in
both directions which enables new and old mobiles to send/receive
Internet electronic mails via SMS. The interworking is according to the
following procedures:
- An SMS message which is required to interwork with Internet email may
have its TP-PID value set for Internet electronic mail;
- Either single or concatenated SMS can be used to transport the email;
- Concatenation may be achieved by the TPUDH mechanism or text-based
means described below;
- Email cc fields are not supported;
- Where multiple fields are present, additional spaces may be inserted
by the sender to improve presentation of the message. Spaces may not be
inserted into the actual email address (e.g. user@domain1.domain2).
3.8.1 Basic Format
The basic format for transferring email in either direction consists of
the following:
MT SMS:
[ & lt; from-address & gt; & lt; space & gt; ] & lt; message & gt;
MO SMS:
[ & lt; to-address & gt; & lt; space & gt; ] & lt; message & gt;
where [] denote optional fields and & lt; & gt; delimit fields.
The to-address or from address may take the form
user@domain1.domain2
or
User Name & lt; user@domain1.domain2 & gt;
In the latter case the angle brackets & lt; & gt; are part of the address and are
actually transmitted.
Depending on the nature of the gateway, the destination/origination
address is either derived from the content of the SMS TP-OA or TP-DA
field, or the TP-OA/TP-DA field contains a generic gateway address and
the to/from address is added at the beginning as shown above.
Multiple addresses may be identified in MO messages by separating each
address by a comma like this:
address1,address2,address3 & lt; space & gt; & lt; message & gt;
It is optional for the receiving gateway to support this. If the
receiving gateway does not support multiple messages then it shall
reject the original message by returning an appropriate error in a text
message.
3.8.2 Optional Fields
The following further optional fields are supported. An email & lt; - & gt; SMS
gateway may insert additional spaces in the MT message for presentation
to the user, and must accept additional spaces in the MO message from
the user.
3.8.2.1 Subject
The subject is placed between the address and the message, delimited by
round brackets () or preceded by ##, for example:
[ & lt; to-address & gt; ]( & lt; subject & gt; ) & lt; message & gt;
or
[ & lt; to-address & gt; ]## & lt; subject & gt; # & lt; message & gt;
An MO message may contain either format. An MT message may contain
either format. Developers must ensure that both forms are supported for
full compatibility.
3.8.2.2 Real Name
The Real Name field contains the real name of the sender and is used
only in MO messages. The SC or email gateway will generate an email
message according to standard email procedures containing Real Name
& lt; user@domain1.domain2 & gt; (the angle brackets being part of the address and
hence transmitted). If a subject is to be included with the Real Name
then only the ## prefix is used.
The syntax is:
[ & lt; to-address & gt; ]# & lt; real-name & gt; [## & lt; subject & gt; ]# & lt; message & gt;
3.8.2.3 Optional Control Flag
An optional control flag may be added to the start of the message in MO
messages only. This consists of a single character & lt; CF & gt; following a #
symbol as follows:
[# & lt; CF & gt; #][ & lt; to-address & gt; ] & lt; space & gt; & lt; message & gt;
This may also be used in combination with the above fields. It is
intended for use where a particular SC or email gateway specific
function is required to be invoked. For example, the control flag #A#
might add a particular (pre-stored) signature to the end of the message
or #R# might change the from-address to a pre-stored value or #5# might
add the text " Please phone me at the office " . All of these functions
are open for definition by Service Centre or email gateway operators.
3.8.3 Text concatenation
If the GSM binary concatenation protocol is not supported by the
transmitting or receiving entity, the following textual concatenation
mechanism may be used. The first message is ended with a + sign, and
each subsequent message start and end with + signs until the final
message which starts with a + sign but does not end with a + sign.
& lt; message1 & gt; +
+ & lt; message2 & gt; +
+ & lt; message3 & gt;
Any header fields placed on the front of an MO or MT message are not
added to the second and subsequent messages.
This provides a simple mechanism which is completely backward
compatible. There is no indication of the number of messages and should
a message be lost by the system or arrive out of sequence then the
original message cannot be reconstructed. Therefore, wherever possible
the GSM binary concatenation mechanism specified in subclause 9.2.3.24.1
should be used instead.
3.8.4 Alternative characters for Internet email addresses in MO SMS.
It is difficult or impossible to generate some characters on a mobile
phone and so the following alternatives may be used:
@ may be replaced by *
_ (underscore) may be replaced by $
3.9 SMS COMPRESSION
Short Messages may be compressed in accordance with the compression
algorithm described in GSM 03.42.
Compression and Decompression may take place between SME's or between an
SME and the SC.
The compression only applies to the TP-User-Data part of the TPDU and
excludes any TP-User-Data-Header which may be present. The Compression
Header ( see GSM TS 03.42 ) ust commence at the first octet of the
TP-User-Data field immediately following any TP-User-Data-Header field
which may be present.
The TP-UDL value must be set in accordance with that value defined for
the compressed TP-User-Data case in 9.2.3.16.
The TP-DCS parameter indicates whether or not a short message is
compressed. If the TP-DCS parameter indicates that the short message is
compressed then the alphabet encoding values ( bits 2 and 3 in GSM TS
03.38 ) must be ignored by the receiving entity.
In the case where a short message after compression is greater than 140
octets (including the Compression Header and Footer ( see GSM TS 03.42 )
and any TP-User-Data-Header which may be present ) then the sending
entity must concatenate the short message in the normal way as described
in 9.2.3.24.1 if it wishes to continue to send the short message. Only
the first segment of the concatenated short message must contain the
Compression Header defined in GSM TS 03.42. All segments other than the
final segment must be 140 octets in length. Only the final segment
contains the Compression Footer ( see GSM TS 03.42 ).
For mobile terminated compressed messages, where the MMI or the Message
Class indicated in the TP-DCS requires the message to be stored in the
MS then the MS shall store the compressed message as received. In the
case where the MS is capable of decompression then the MS may display
the decompressed message. Such an MS may optionally store the message
in decompressed form subject to the MS being configured to do this via
MMI. However, prior to storing the message in decompressed form, the MS
may have to create a concatenated SM and carry out component
modification on the TP-UDL and TP-DCS values to indicate the correct
length values and that the message is no longer compressed. Transfer of
messages direct from the radio interface or those stored in the MS to a
TE is according to the procedure defined in GSM TS 07.05 and is
independent of whether the message is compressed or uncompressed.
For mobile originated compressed messages, an MS capable of compression
may compress a short message generated within the MS itself prior to
sending it to the radio interface. An MS capable of compression may
optionally compress an uncompressed message received from a TE subject
to the MS being configured to do this via MMI. In such a case the MS
would have to carry out component modification on the TP-UDL and TP-DCS
values to indicate the correct length values and that the message is
compressed. A TE may send a message ( compressed or uncompressed ) to
the MS using the procedures defined in GSM TS 07.05. The MS will store
the compressed message as received and/or transfer it directly to the
radio interface.
4 Network architecture
4.1 Basic network structure
The exchange of messages between an MS and an SME involves the entities
shown in figure 03.40/4.
The basic network structure of the SMS is depicted in figure 03.40/5.
*) : SMS-GMSC when the short message is transferred from the SC to the
MS, SMS-IWMSC when the short message is transferred from the MS to the
SC. The SC may be integrated with the SMS-GMSC/SMS-IWMSC.
**): SGSN is used in place of the MSC in case of SMS transfer over GPRS
Figure 03.40/4: Entities involved in the provision of SM MT and SM MO:
SC, SMS-GMSC/SMS-IWMSC, SGSN, MSC and MS
The links of figure 03.40/5 support the short message transfer in the
following way:
- message transfer on link 1 is described in section 5;
- the operations performed on links 2 and 4 is described in GSM 09.02;
- message transfer on link 3 is described in section 4.2;
- message transfer on link 5 is supported by protocol described in
GSM 04.11.
*): This interface is not used in case of SMS transfer via the SGSN
Figure 03.40/5: The main network structure serving as a basis for the
short message transfer
4.2 Transfer on link 3
The link 3 is used to support communications between MSC, SMS-GMSC and
SMS-IWMSC, or between SGSN, SMS-GMSC and SMS-IWMSC. Two cases can be
distinguished according to whether or not the MSC, SMS-GMSC, SMS-IWMSC
and SGSN are located in the same PLMN.
In the first case, the link definition is left to the operators. For
example, this link may use:
- PSPDN or
- CCITT SS no 7 (according to GSM 09.02).
In the second case, CCITT SS no 7 shall be used over link 3 according to
GSM 09.02, unless otherwise bilaterally agreed.
5 Service Centre and PLMN interconnection
This specification deals with the SC only with regard to the interchange
of messages between SC and MS. Only the requirements put upon the SC by
the SMS functionality are specified in this specification.
5.1 Service centre connection
One SC may be connected to several PLMNs, and may be connected to
several MSCs (SMS-GMSCs or SMS-IWMSCs) within one and the same PLMN.
The SC is addressed from the mobile by an E.164 number in the numbering
plan of the PLMN to which the SC is connected. This E.164 number shall
uniquely identify the SC to that PLMN.
There may be an intermediate network between the PLMN and the SC; in
this case the PLMN must autonomously make a connection to the SC using
the SC address in this intermediate network.
No mandatory protocol between the SC and the MSC below the transfer
layer is specified by GSM; this is a matter for agreement between SC and
PLMN operators. However, annex A provides an example protocol stack
which could be used.
5.2 Routing requirements
5.2.1 Mobile terminated short message
The SC sends the short message to the SMS-GMSC. The SMS-GMSC
interrogates the HLR to retrieve routing information necessary to
forward the short message, and then sends the message to the relevant
MSC or SGSN, transiting other networks if necessary. The MSC or SGSN
then sends the short message to the MS.
5.2.2 Mobile originated short message
The MS sends the short message to the MSC or the SGSN. The MS will
always address the required SC by an E.164 address. The visited PLMN
will route the message to the appropriate SMS-IWMSC in the SC's PLMN,
transiting other networks if necessary.
6 Service Centre functionality
In this specification, only the SC functionality related to the short
message point-to-point service between the SC and the MS is specified.
6.1 Service Centre capabilities
The SC should be capable of
- submitting a short message to an MS, retaining the responsibility of
the message until
1) the report has been received; or
2) the Validity-Period expires.
- receiving a report from the PLMN;
- receiving a short message from an MS;
- returning a report to the PLMN for a previously received short
message.
6.2 SC functional requirements
The detailed functionality of the SC is outside the scope of this
specification, and is for the SC operator to define. However, the
following functional requirements are mandatory for all SCs in order to
support the SM-TP (see section 9) towards the PLMN:
1) To identify each SMS-DELIVER sent to an MS in a unique way, a time
stamp value is included in the field TP-Service-Centre-Time-Stamp,
TP-SCTS, of the SMS-DELIVER. The time stamp gives the time when the
message arrived at the SC with the accuracy of a second. If two or more
messages to the same MS arrive at the SC within one second, the SC shall
modify the time stamp of those messages in such a way that
a) all messages to the MS contain different time stamps;
b) the modification of the time stamps is kept to a minimum.
2) The SC is only allowed to have one outstanding SMS-DELIVER (i.e. a
message for which a report has not been received) to a specific MS at a
given time.
3) The SC shall be able to initiate overwriting of short messages
previously received by the SC if requested by the same originating
address (MS or any other source) by use of the same message type.
7 MS functionality
In this specification, only the MS functionality related to the short
message point-to-point service between the SC and the MS is specified.
7.1 MS capabilities
The MS, when equipped for SMS, should be capable of
- submitting a short message TPDU to an SC, retaining the responsibility
of the message until:
1) the report arrives from the network; or
2) a timer expires.
- receiving a short message TPDU from an SC;
- returning a delivery report to the network for a previously received
short message;
- receiving a report from the network;
- notifying the network when it has memory capacity available to receive
one or more short messages when it has previously rejected a short
message because its memory capacity was exceeded;
- notifying the SC when a short message is intended to replace a short
message the MS has previously submitted to the same destination address.
It is recommended that an MS supporting both replying and automatic SC
selection (as specified in section D.2 of annex D) follows procedures
specified in annex D when replying to MT short messages with MO short
messages.
It is recommended that an MS supporting a capability for requesting a
reply path follows procedures specified in annex D.
7.2 MS configuration
The reference configuration is assumed as in figure 03.40/6, i.e. only
the case where the terminal is integrated in the MS is considered.
Figure 03.40/6: Reference configuration of the MS which apply to the SMS
NOTE: It is foreseen that a terminal interface may be offered, e.g. for
higher layer protocols, memory capacity reasons or to be able to type in
mobile originated messages. This terminal interface is regarded as an
implementation option, although, where offered, it must be based upon an
R- or S-reference point. GSM 07.05 provides an example based on the R
reference point.
8 Node functionality
The overall requirements to the MSC, SMS-GMSC, SMS-IWMSC and SGSN with
respect to handling of the Short Message Service point-to-point is to
cater for the routing and necessary intermediate buffering of the short
messages.
8.1 Node functionality related to SM MT
8.1.1 Functionality of the SMS-GMSC
When receiving a short message TPDU from the SC, the SMS-GMSC is
responsible for the following operations:
- reception of the short message TPDU;
- inspection of the parameters.
NOTE: The SMS-GMSC may be identical to the MSC.
if parameters are incorrect:
- returning the appropriate error information to the SC in a failure
report (see sections 9 and 10);
if errors are not found within parameters:
- interrogating the HLR ( " sendRoutingInfoForShortMsg " , see section 10);
retrieving routing information or possible error information;
if HLR is returning error information:
- returning the appropriate error information to the SC in a failure
report (see sections 9 and 10);
if no errors are indicated by the HLR:
- transferring the short message TPDU to the MSC or SGSN using the
routing information obtained from the HLR ( " forwardShortMessage " , see
section 10).
NOTE: In case where two addresses (SGSN and MSC) are received from HLR,
the SMS-GMSC may choose (operator dependant) via which nodes (SGSN or
MSC) the SMS is first to be sent. The SMS delivery via the SGSN is
normally more radio resource efficient than the SMS delivery via the
MSC.
if one address (SGSN or MSC) is received from HLR:
- When receiving the report associated with the short message from the
MSC or SGSN (positive or negative outcome of " forwardShortMessage " , see
section 10), the SMS-GMSC is responsible for the following operations:
if the report indicates successful delivery:
- notifying the HLR of the successful delivery via the MSC or the SGSN,
which will cause the HLR to alert any service centres whose addresses
are stored in the MWD for the MS;
- creating and sending the successful report to the SC;
if the report is a failure report indicating " absent subscriber " via the
MSC or the SGSN (see section 3.3):
- requesting the HLR to insert the address of the originating SC into
the MWD (if implemented) with cause Absent Subscriber
(``SM_DeliveryReportStatus'', see clauses 9 and 10);
- informing the HLR of the reason for the MS being absent via the MSC or
the SGSN (if this information is available);
- establishing, where necessary, a link with the addressed SC (see
section 5);
- creating and sending the negative report to the SC which should
include the reason for the MS being absent (if this information is
available) so that the SC may adjust any retry algorithm appropriately
(see sections 9 and 10);
if the report is a failure report indicating " MS memory capacity
exceeded " via the MSC or the SGSN (see section 3.3):
- requesting the HLR to insert the address of the originating SC into
the MWD (if implemented) with cause MS Memory Capacity Exceeded via the
MSC or the SGSN (``SM_DeliveryReportStatus'' , see clauses 9 and 10);
- establishing, where necessary, a link with the addressed SC (see
section 5);
- creating and sending the report to the SC (see sections 9 and 10).
if two addresses (SGSN and MSC) are received from HLR:
- When receiving the first report associated with the short message from
the MSC or SGSN (positive or negative outcome of " forwardShortMessage " ,
see clause 10), the SMS-GMSC is responsible for the following
operations:
if the first report indicates successful delivery:
- notifying the HLR of the successful delivery via the MSC or the SGSN,
which will cause the HLR to alert any service centres whose addresses
are stored in the MWD for the MS;
- creating and sending the successful report to the SC;
if the first report is a failure report indicating
- Unidentified subscriber
- Facility not supported
- Absent subscriber with indication: GPRS or IMSI Detach
- System failure
- Unexpected data value
- Data missing
- GPRS connection suspended (see TS GSM 09.02) :
- transferring the short message TPDU to the second path using the
routing information obtained from HLR.
if the second report indicates successful delivery:
- notifying the HLR of the successful delivery of the second transfer
via the MSC or SGSN, which will cause the HLR to alert any service
centres whose addresses are stored in the MWD for the MS;
- notifying the HLR of the unsuccessful delivery at first transfer only
with cause ``absent subscriber'';
- notifying the HLR of the reason for the MS being absent via the MSC or
the SGSN (if this information is available);
- establishing, when necessary, a link with the addressed SC (see clause
5);
- creating and sending the successful report to the SC;
if the second report is a failure report:
- requesting the HLR to insert the address of the originating SC into
the MWD (if implemented) only if at least one of the first or second
report failed due to ``MS Memory Capacity Exceeded'' or ``Absent
Subscriber'' (``SM_DeliveryReportStatus'', see clauses 9 and 10);
- notifying the HLR only with the causes ``Absent Subscriber'', ``Memory
Capacity Exceeded'' via the MSC or the SGSN, or both;
- notifying the HLR of the reason for the MS being absent via the MSC,
SGSN or both (if this information is available);
- establishing, where necessary, a link with the addressed SC (see
clause 5);
- creating and sending the negative report to the SC with errors from
first and second path (see clauses 9 and 10);
8.1.2 Functionality of the MSC
When receiving a short message TPDU from the SMS-GMSC
( " forwardShortMessage " , see section 10), the MSC is responsible for the
following operations:
- reception of the short message TPDU;
- retrieving information from the VLR ( " sendInfoFor-MT-SMS " , see
section 10); location area address and, when appropriate, error
information;
if errors are indicated by the VLR:
- returning the appropriate error information to the SMS-GMSC in a
failure report (negative outcome of " forwardShortMessage " see
sections 10 and 11);
if no errors are indicated by the VLR:
- transferring the short message to the MS (see GSM 04.11).
When receiving a confirmation that the message is received by the MS
(see GSM 04.11):
- relaying the delivery confirmation to the SMS-GMSC in a delivery
report (positive outcome of " forwardShortMessage " , see sections 10 and
11).
When receiving a failure report of the short message transfer to the MS
(see GSM 04.11):
- returning the appropriate error information to the SMS-GMSC in a
failure report (negative outcome of " forwardShortMessage " , see
section 10).
When receiving a notification from the MS that it has memory available
to receive one or more short messages (see GSM 04.11):
- relaying the notification to the VLR ( " mSMemoryCapacityAvailable " , see
section 10);
if errors are indicated by the VLR:
- returning the appropriate error information to the MS in a failure
report (negative outcome of " ReadyForSM " , see sections 10 and 11).
8.1.3 Functionality of the SGSN
When receiving a short message TPDU from the SMS-GMSC
( " forwardShortMessage " , see clause 10), the SGSN is responsible for the
following operations:
- reception of the short message TPDU;
if errors are detected by the SGSN:
- returning the appropriate error information to the SMS-GMSC in a
failure report (negative outcome of " forwardShortMessage " see clauses 10
and 11);
if no errors are detected by the SGSN:
- transferring the short message to the MS (see GSM 04.11).
When receiving a confirmation that the message is received by the MS
(see GSM 04.11):
- relaying the delivery confirmation to the SMS-GMSC in a delivery
report (positive outcome of " forwardShortMessage " , see clauses 10 and
11).
When receiving a failure report of the short message transfer to the MS
(see GSM 04.11):
- returning the appropriate error information to the SMS-GMSC in a
failure report (negative outcome of " forwardShortMessage " , see
clause 10).
When receiving a notification from the MS that it has memory available
to receive one or more short messages (see GSM 04.11):
if errors are detected by the SGSN:
- returning the appropriate error information to the MS in a failure
report (negative outcome of " ReadyForSM " , see clauses 10 and 11).
if no errors are detected by the SGSN:
- notifying the HLR of memory available in the MS via the SGSN with
" ReadyForSM " (see clauses 10 and 11).
When the MS is becoming reachable again (see GSM 04.08):
- notifying the HLR of MS being reachable via the SGSN (and via the MSC
if any) with " ReadyForSM " (see clauses 10).
8.2 Node functionality related to SM MO
8.2.1 Functionality of the MSC
When receiving a short message TPDU from the MS, the MSC is responsible
for the following operations:
- reception of the short message TPDU (see GSM 04.11);
- retrieving information from the VLR ( " sendInfoForMO-SMS " , see
section 10); the MSISDN of the MS and, when appropriate, error
information. The retrieval of information from the VLR is followed by
the VLR investigating the MNRF (to be used in the alerting procedure,
see section 10)
if errors are indicated by the VLR:
- returning the appropriate error information to the MS in a failure
report (negative outcome of " sendInfoForMO-SMS " see sections 10 and 11);
if no errors are indicated by the VLR:
- inspection of the RP-DA parameter;
if parameters are incorrect:
- returning the appropriate error information to the MS in a failure
report (see GSM 04.11);
if no parameter errors are found:
NOTE: The SMS-IWMSC may be identical to the MSC.
- transferring the short message TPDU to the SMS-IWMSC
( " forwardShortMessage " , see section 10).
When receiving the report of the short message from the SMS-IWMSC
(positive or negative outcome of the " forwardShortMessage " , see
section 10), the MSC is responsible for the following operations:
- relaying the report to the MS (see GSM 04.11).
8.2.2 Functionality of the SMS-IWMSC
When receiving a short message TPDU from the MSC or SGSN
( " forwardShortMessage " , see section 10), the SMS-IWMSC is responsible
for the following operations:
- reception of the short message TPDU;
- establishing, where necessary, a link with the addressed SC (see
section 5);
- transferring the short message TPDU to the SC (if the address is
valid).
If a report associated with the short message is received from the SC,
the SMS-IWMSC is responsible for the following operations:
- relaying of the report to the MSC or SGSN (positive or negative
outcome of " forwardShortMessage " , see clause 10).
If a report associated with the short message is not received from the
SC before a timer expires or if the SC address is invalid, the SMS-IWMSC
is responsible for the following operations:
- returning the appropriate error information to the MSC or SGSN in a
failure report (negative outcome of " forwardShortMessage " , see
section 10).
The value of the timer is dependent on the protocol between the SC and
the SMS-IWMSC.
8.2.3 Functionality of the SGSN
When receiving a short message TPDU from the MS, the SGSN is responsible
for the following operations:
- reception of the short message TPDU (see GSM 04.11);
- inspection of the RP-DA parameter;
if parameters are incorrect:
- returning the appropriate error information to the MS in a failure
report (see GSM 04.11);
if no parameter errors are found:
- transferring the short message TPDU to the SMS-IWMSC
( " forwardShortMessage " , see clause 10).
When receiving the report of the short message from the SMS-IWMSC
(positive or negative outcome of the " forwardShortMessage " , see
clause 10), the SGSN is responsible for the following operations:
- relaying the report to the MS (see GSM 04.11).
8.3 SMS-IWMSC functionality related to alerting
When receiving an alert from the HLR ( " alertServiceCentre " , see
section 10), the SMS-IWMSC is responsible for the following operations:
- inspect the SC address;
- generate an RP-Alert-SC (see section 9);
- transferring the RP-Alert-SC to the SC.
NOTE: If the SC address is not valid, then no further action will be
taken.
9 Protocols and protocol architecture
The protocol layers of the SMS are structured as shown in
figure 03.40/7.
Figure 03.40/7: Protocol layer overview for the Short Message Service
point-to-point
This specification specifies the protocol at the SM-TL, the service
offered by the SM-TL at the MS and the SC, and the service offered by
the SM-RL at the SC.
9.1 Protocol element features
9.1.1 Octet and Bit transmission order
The octets are transmitted according to their individual numbering; the
octet with the lowest number being transmitted first. The bits within
each octet are transmitted according to their individual numbering also;
the bits with the lowest internal number being transmitted first.
9.1.2 Numeric and alphanumeric representation
For parameters within the TPDUs, there are four ways of numeric
representation: Integer representation, octet, semi-octet and
alphanumeric representation.
9.1.2.1 Integer representation
Wherever the bits from a number of octets, complete or in fractions, are
to represent an integer, the interpretation will be according to the
following:
1) Between octets: The octets with the lowest octet numbers will contain
the most significant bits.
2) Within an octet: The bits with the highest bit numbers will be the
most significant.
Below is given an example of octet and bit representation and
transmission order of an integer represented field.
Let the 2 rightmost bits of octet no 5, the complete octet no 6 and 7,
and the 3 leftmost bits of octet no 8 represent an integer, as shown in
figure 03.40/8.
*) : Bits not representing the integer.
Figure 03.40/8: 21 bits from the octets 5, 6, 7, and 8 in a short
message () will represent an integer as shown in (), and will be
transmitted in an order as shown in ()
9.1.2.2 Octet representation
A field which is octet represented, will always consist of a number of
complete octets. Each octet within the field represents one decimal
digit. The octets with the lowest octet numbers will contain the most
significant decimal digits.
9.1.2.3 Semi-octet representation
A field which is semi-octet represented, will consist of a number of
complete octets and - possibly - one half octet. Each half octet within
the field represents one decimal digit. The octets with the lowest octet
numbers will contain the most significant decimal digits. Within one
octet, the half octet containing the bits with bit numbers 0 to 3, will
represent the most significant digit.
In the case where a semi-octet represented field comprises an odd number
of digits, the bits with bit numbers 4 to 7 within the last octet are
fill bits and shall always be set to " 1111 " .
If a mobile receives an address field containing non-integer information
in the semi-octets other than " 1111 " (e.g. 1110) it shall display the
semi-octet as the representation given in GSM 04.08 under " called BCD
number " , viz 1010= " * " , 1011= " # " , 1100= " a " , 1101= " b " , 1110= " c " . In the
event of a discrepancy between the values quoted here and the values
specified in GSM 04.08 then GSM 04.08 shall take precedence. If a mobile
receives " 1111 " in a position prior to the last semi-octet then
processing shall commence with the next semi-octet and the intervening
semi-octet will be ignored.
Within each semi octet, the bits with the highest bit numbers will be
the most significant.
Below is given an example:
Octet no:
9.1.2.4 Alphanumeric representation
A field which uses alphanumeric representation will consist of a number
of 7-bit characters represented as the default alphabet defined in
GSM 03.38.
9.1.2.5 Address fields
Address fields used by SM-RL are specified in GSM 04.11 and 09.02.
Each address field of the SM-TL consists of the following sub-fields: An
Address-Length field of one octet, a Type-of-Address field of one octet,
and one Address-Value field of variable length; as shown below:
The Address-Length field is an integer representation of the number of
useful semi-octets within the Address-Value field, i.e. excludes any
semi octet containing only fill bits.
The Type-of-Address field format is as follows:
Type-of-number:
Bits 6 5 4
0 0 0 Unknown 1)
0 0 1 International number 2)
0 1 0 National number 3)
0 1 1 Network specific number 4)
1 0 0 Subscriber number 5)
1 0 1 Alphanumeric, (coded according to GSM TS 03.38 7-bit default
alphabet)
1 1 0 Abbreviated number
1 1 1 Reserved for extension
The MS will interpret reserved values as " Unknown " but will store them
exactly as received.
The SC may reject messages with a type of number containing a reserved
value or one which is not supported.
1) " Unknown " is used when the user or network has no a priori
information about the numbering plan. In this case, the Address-Value
field is organized according to the network dialling plan, e.g. prefix
or escape digits might be present.
2) The international format shall be accepted also when the message is
destined to a recipient in the same country as the MSC or as the SGSN.
3) Prefix or escape digits shall not be included.
4) " Network specific number " is used to indicate administration/service
number specific to the serving network, e.g. used to access an operator.
5) " Subscriber number " is used when a specific short number
representation is stored in one or more SCs as part of a higher layer
application. (Note that " Subscriber number " shall only be used in
connection with the proper PID referring to this application).
Numbering-plan-identification (applies for Type-of-number = 000,001,010)
Bits 3 2 1 0
0 0 0 0 Unknown
0 0 0 1 ISDN/telephone numbering plan (E.164/E.163)
0 0 1 1 Data numbering plan (X.121)
0 1 0 0 Telex numbering plan
1 0 0 0 National numbering plan
1 0 0 1 Private numbering plan
1 0 1 0 ERMES numbering plan (ETSI DE/PS 3 01-3)
1 1 1 1 Reserved for extension
All other values are reserved.
For Type-of-number = 101 bits 3,2,1,0 are reserved and shall be
transmitted as 0000. Note that for addressing any of the entities SC,
MSC, SGSN or MS, Numbering-plan-identification = 0001 will always be
used. However, for addressing the SME, any specified
Numbering-plan-identification value may be used.
The MS will interpret reserved values as " Unknown " but will store them
exactly as received.
The SC may reject messages with a type of number containing a reserved
value or one which is not supported.
Within the Address-Value field, either a semi-octet or an alphanumeric1)
representation applies.
The maximum length of the full address field (Address-Length,
Type-of-Address and Address-Value) is 12 octets.
1) Applies only to addressing at the SM-TL.
9.2 Service provided by the SM-TL
9.2.1 General
The Short Message Transfer Layer (SM-TL) provides a service to the Short
Message Application Layer (SM-AL). This service enables the SM-AL to
transfer short messages to its peer entity, receive short messages from
its peer entity and receive reports about earlier requests for short
messages to be transferred.
In order to keep track of messages and reports about those messages,
primitives between the SM-AL and SM-TL contain a Short Message
Identifier (SMI), which is a reference number for the message associated
with the primitive. This Short Message Identifier is mapped to and from
the Short Message Identifier used between the SM-TL and the Short
Message Relay Layer (SM-RL). The Short Message Identifier is not carried
between entities and therefore a given message may have different SMIs
at the MS and SC sides (see section 9.3.1 below).
The SM-TL communicates with its peer entity by the protocol described in
the following sections.
9.2.2 PDU Type repertoire at SM-TL
The SM-TL comprises the following six PDUs:
SMS-DELIVER, conveying a short message from the SC to the MS;
SMS-DELIVER-REPORT, conveying
a) a failure cause (if necessary);
b) information as part of a positive or negative acknowledgement to an
SMS-DELIVER or SMS-STATUS-REPORT
SMS-SUBMIT, conveying a short message from the MS to the SC;
SMS-SUBMIT-REPORT, conveying
a) a failure cause (if necessary);
b) information as part of a positive or negative acknowledgement to an
SMS-SUBMIT or SMS-COMMAND
SMS-STATUS-REPORT, conveying a status report from the SC to the MS;
SMS-COMMAND, conveying a command from the MS to the SC.
9.2.2.1 SMS-DELIVER type
Basic elements of the SMS-DELIVER type:
Abbr. Reference P1) R2) Description
TP-MTI TP-Message-Type-Indicator M 2b Parameter describing the message
type.
TP-MMS TP-More-Messages-to-Send M b Parameter indicating whether or not
there are more messages to send
TP-RP TP-Reply-Path M b Parameter indicating that Reply Path exists.
TP-UDHI TP-User-Data-Header-Indicator O b Parameter indicating that the
TP-UD field contains a Header
TP-SRI TP-Status-Report-Indication O b Parameter indicating if the SME
has requested a status report.
TP-OA TP-Originating-Address M 2-12o Address of the originating SME.
TP-PID TP-Protocol-Identifier M o Parameter identifying the above layer
protocol, if any
TP-DCS TP-Data-Coding-Scheme M o Parameter identifying the coding scheme
within the TP-User-Data.
TP-SCTS TP-Service-Centre-Time-Stamp M 7o Parameter identifying time
when the SC received the message.
TP-UDL TP-User-Data-Length M I Parameter indicating the length of the
TP-User-Data field to follow.
TP-UD TP-User-Data O 3)
1) Provision; Mandatory (M) or Optional (O).
2) Representation; Integer (I), bit (b), 2 bits (2b), Octet (o),
7 octets (7o), 2-12 octets (2-12o)
3) Dependent on the TP-DCS
Layout of SMS-DELIVER:
Bit no.
7 6 5 4 3 2 1 0
1
TP-MTI, TP-MMS, TP-SRI, TP-UDHI, TP-RP
Number of octets 1
2
2 to 12
TP-OA
1
TP-PID
1
TP-DCS
TP-SCTS
1
TP-UDL
1
TP-UD
NOTE: Any unused bits will be set to zero by the sending entity and
will be ignored by the receiving entity.
9.2.2.1a SMS-DELIVER-REPORT type
An SMS-DELIVER-REPORT TPDU is carried as a RP-User-Data element within
an RP-ERROR PDU and is part of the negative acknowledgement to an
SMS-DELIVER or SMS-STATUS-REPORT.
An SMS-DELIVER-REPORT TPDU is also carried as a RP-User-Data element
within an RP-ACK PDU and is part of a positive acknowledgement to a
SMS-DELIVER or SMS-STATUS REPORT
(i) SMS-DELIVER-REPORT for RP-ERROR
Basic elements of the SMS-DELIVER-REPORT type:
Abbr. Reference P1) P2) Description
TP-MTI TP-Message-Type-Indicator M 2b Parameter describing the message
type
TP-FCS TP-Failure-Cause M I Parameter indicating the reason for
SMS-DELIVER failure
1) Provision: Mandatory (M) or Optional (O)
2) Representation: Integer (I), bit (b), 2bits (2b), octet (o)
Layout of SMS-DELIVER-REPORT:
Number 1
TP-MTI
of octets 1
TP-FCS
Bits 7 - 2 in octet 1 are presently unused and the sender shall set them
to zero. If any of these bits is non-zero, the receiver shall not
examine the other field and shall treat the TP-Failure-Cause as
" Unspecified error cause " .
(ii) SMS-DELIVER-REPORT for RP-ACK
Basic elements of the SMS-DELIVER-REPORT type:
Abbr Reference P1) P2) Description
TP-MTI TP-Message Type Indicator M 2b Parameter describing the message
type
TP-UDHI TP-User-Data-Header-Indication O b Parameter indicating that the
TP-UD field contains a Header
TP-PI TP-Parameter-Indicator M o Parameter indicating the presence of
any of the optional parameters which follow
TP-PID TP-Protocol-Identifier O o see sect 9.2.3.9
TP-DCS TP-Data-Coding-Scheme O o see sect 9.2.3.10
TP-UDL TP-User-Data-Length O o see sect 9.2.3.16
TP-UD TP-User-Data O 3) 4) see sect 9.2.3.24
1) Provision: Mandatory (M) or Optional (O)
2) Representation: Integer (I), Bit (b), 2 bits (2b), octet (o)
3) Dependent upon the TP-DCS
4) The TP-User-Data field in the SMS-DELIVER-REPORT is only available
for use by the MT.
Layout of SMS-DELIVER-REPORT:
Bit Number
Number of Octets
6 5 4 3 2 1 0
1
TP-MTI, TP-UDHI
1
TP-PI
0,1
TP-PID
0,1
TP-DCS
0,1
TP-UDL
0 to 159
TP-UD
Bits 7 - 2 in the TP-MTI are presently unused in the SMS-DELIVER-REPORT
and the sender shall set them to zero,. If any of these bits is
non-zero, the receiver shall ignore them.
9.2.2.2 SMS-SUBMIT type
Basic elements of the SMS-SUBMIT type:
Abbr. Reference P1) P2) Description
TP-MTI TP-Message-Type-Indicator M 2b Parameter describing the message
type.
TP-RD TP-Reject-Duplicates M b Parameter indicating whether or not the
SC shall accept an SMS-SUBMIT for an SM still held in the SC which has
the sam TP-MR and the same TP-DA as a previously submitted SM from the
same OA
TP-VPF TP-Validity-Period-Format M 2b Parameter indicating whether or
not the TP-VP field is present.
TP-RP TP-Reply-Path M b Parameter indicating the request for Reply Path.
TP-UDHI TP-User-Data-Header-Indicator O b Parameter indicating that the
TP-UD field contains a Header.
TP-SRR TP-Status-Report-Request O b Parameter indicating if the MS is
requesting a status report.
TP-MR TP-Message-Reference M I Parameter identifying the SMS-SUBMIT.
TP-DA TP-Destination-Address M 2-12o Address of the destination SME.
TP-PID TP-Protocol-Identifier M o Parameter identifying the above layer
protocol, if any
TP-DCS TP-Data-Coding-Scheme M o Parameter identifying the coding scheme
within the TP-User-Data.
TP-VP TP-Validity-Period O o/7o Parameter identifying the time from
where the message is no longer valid.
TP-UDL TP-User-Data-Length M I Parameter indicating the length of the
TP-User-Data field to follow.
TP-UD TP-User-Data O 3)
1) Provision; Mandatory (M) or Optional (O).
2) Representation; Integer (I), bit (b), 2 bits (2b), Octet (o), 7
octets (7o), 2-12 octets (2-12o).
3) Dependent on the TP-DCS
Layout of SMS-SUBMIT:
Bit no
7 6 5 4 3 2 1 0
1
TP-MTI, TP-RD, TP-VPF TP-SRR, TP-UDHI, TP-RP
1
TP-MR
Number of
1
octets
2
2 to 12
TP-DA
1
TP-PID
1
TP-DCS
1
0, 1 or 7
TP-VP
1
TP-UDL
1
0 to 140
TP-UD
NOTE: Any unused bits will be set to zero by the sending entity and will
be ignored by the receiving entity.
9.2.2.2a SMS-SUBMIT-REPORT type
An SMS-SUBMIT-REPORT TPDU is carried as a RP-User-Data element within an
RP-ERROR PDU and is part of the negative acknowledgement to an
SMS-SUBMIT or SMS-COMMAND.
An SMS-SUBMIT-REPORT TPDU is also carried as a RP-User-Data element with
an RP-ACK PDU and is part of a positive acknowledgement to a SMS-SUBMIT
or SMS-COMMAND.
(I) SMS-SUBMIT-REPORT for RP-ERROR
Basic elements of the SMS-SUBMIT-REPORT type:
Abbr. Reference P1) P2) Description
TP-MTI TP-Message-Type-Indicator M 2b Parameter describing the message
type
TP-FCS TP-Failure-Cause M I Parameter indicating the reason for
SMS-SUBMIT failure
1) Provision: Mandatory (M) or Optional (O)
2) Representation: Integer (I), bit (b), 2bits (2b), octet (o)
Layout of SMS-SUBMIT-REPORT:
Bit no. 7 6 5 4 3 2 1 0
Number 1
TP-MTI
of octets 1
TP-FCS
Bits 7 - 2 in octet 1 are presently unused and the sender shall set them
to zero. If any of these bits is non-zero, the receiver shall not
examine the other field and shall treat the TP-Failure-Cause as
" Unspecified error cause " .
(ii) SMS-SUBMIT-REPORT for RP-ACK
Basic elements of the SMS-SUBMIT_REPORT type:
Abbr Reference P1) P2) Description
TP-MTI TP-Message Type-Indicator M 2b Parameter describing the message
type
TP-UDHI TP-User-Data-Header-Indication O b Parameter indicating that the
TP-UD field contains a Header
TP-PI TP-Parameter-Indicator M o Parameter indicating the presence of
any of the optional parameters which follow
TP-SCTS TP-Service-Centre-Time-Stamp M 7o
5) Parameter identifying the time when the SC received the SMS-SIBMIT
See sect 9.2.3.11
TP-PID TP-Protocol-Identifier O o See sect 9.2.3.9
TP-DCS TP-Data-Coding-Scheme O o see sect 9.2.3.10
TP-UDL TP-User-Data-Length O o see sect 9.2.3.16
TP-UD TP-User-Data O 3) 4) see sect 9.2.3.24
1) Provision: Mandatory (M) or Optional (O);
2) Representation: Integer (I), Bit (B), 2bits (2b), octet (o);
3) Dependent upon the TP-DCS;
4) The TP-User-Data field in the SMS-SUBMIT-REPORT is only available for
use by the SC.;
5) This same time value will also be carried in the SMS-STATUS-REPORT
relating to a particular SM. See section 9.2.2.3. This will allow the
submitting SME to associate a particular SMS-SUBMIT with a subsequent
SMS-STATUS-REPORT by correlating the TP-SCTS values.
Layout of SMS-SUBMIT REPORT
Bit Number
Number of Octets 7 6 5 4 3 2 1 0
1
TP-MTI, TP-UDHI
1
TP-PI
7
TP-SCTS
0,1
TP-PID
0,1
TP-DCS
0,1
TP-UDL
0 to 152
TP-UD
Bits 7 - 2 in the TP-MTI are presently unused in the SMS-SUBMIT-REPORT
and the sender shall set them to zero. If any of these bits is
non-zero, the receiver shall ignore them.
9.2.2.3 SMS-STATUS-REPORT type
Basic elements of the SMS-STATUS-REPORT type:
Abbr. Reference P1) R2) Description
TP-MTI TP-Message-Type-Indicator M 2b Parameter describing the message
type
TP-UDHI TP-User-Data-Header-Indication O b Parameter indicating that the
TP-UD field contains a Header
TP-MMS TP-More-Messages-to-Send M b Parameter indicating whether or not
there are more messages to send
TP-SRQ TP-Status-Report-Qualifier M b Parameter indicating whether the
previously submitted TPDU was an SMS_SUBMIT or an SMS-COMMAND
TP-MR TP-Message-Reference 3) M I Parameter identifying the previously
submitted SMS-SUBMIT or SMS-COMMAND
TP-RA TP-Recipient-Address M 2-12o Address of the recipient of the
previously submitted mobile originated short message
TP-SCTS TP-Service-Centre-Time-Stamp M 7o Parameter identifying time
when the SC received the previously sent SMS-SUBMIT
TP-DT TP-Discharge-Time M 7o Parameter identifying the time associated
with a particular TP-ST outcome
TP-ST TP-Status M o Parameter identifying the status of the previously
sent mobile originated short message
TP-PI TP-Parameter-Indicator O
4) o
Parameter indicating the presence of any of the optional parameters
which follow
TP-PID TP-Protocol-Identifier O o see sect 9.2.3.9. TP-PID of original
SMS-SUBMIT
TP-DCS TP-Data-Coding-Scheme O o see sect 9.2.3.10
TP-UDL TP-User-Data-Length O o see sect 9.2.3.16
TP-UD TP-User-Data O 5) see sect 9.2.3.24
1) Provision: Mandatory (M) or Optional (O).
2) Representation: Integer (I), bit (b), 2 bits (2b), Octet (o), 7
octets (7o), 2-12 octets (2-12o)
3) Where the SMS-STATUS-REPORT is the result of an SMS-COMMAND and the
TP-Command-Type was an Enquiry, the TP-MR returned in the
SMS-STATUS-REPORT shall be the TP-MN which was sent in the SMS-COMMAND
(i.e. the TP-MR of the previously submitted SM to which the Enquiry
refers).
4) Mandatory if any of the optional parameters following TP-PI is
present, otherwise optional.
5) TP-UD contains information related to a SMS-DELIVER; can contain
information transported in the TP-UD of SMS-DELIVER-REPORT, and
information inserted by the SMSC. The length of the TP-UD field is
limited and might not be long enough to fit information both from the
original receiving terminal (as included into the SMS-DELIVER-REPORT)
and information added by the SMSC. In these cases the former information
has higher priority, and the latter will be truncated.
Layout of SMS-STATUS-REPORT:
Bit no.
7 6 5 4 3 2 1 0
Number of octets 1
TP-MTI, TP-MMS, TP-SRQ, TP-UDHI
1
TP-MR
1
2
(TP-RA
2 to 12
7
TP-SCTS
7
(TP-DT
1
TP-ST
1
TP-PI
1
TP-PID
1
TP-DCS
1
. . . . . .
TP-UDL
1
0 to 131
. . . . . . . .
TP-UD
NOTE: Any unused bits will be set to zero by the sending entity and
will be ignored by the receiving entity.
9.2.2.4 SMS-COMMAND type
Basic elements of the SMS-COMMAND type:
Abbr. Reference P1) R2) Description
TP-MTI TP-Message-Type-Indicator M 2b Parameter describing the type
TP-UDHI TP-User-Data-Header-Indication O b Parameter indicating that the
TP-CD field contains a Header
TP-SRR TP-Status-Report- Request O b Parameter indicating if the SMS
Command is requesting a status report.
TP-MR TP-Message Reference M I Parameter identifying the SMS-COMMAND
TP-PID TP-Protocol- Identifier M o Parameter identifying the above layer
protocol, if any
TP-CT TP-Command-Type M o Parameter specifying which operation is to be
performed on a SM
TP-MN TP-Message-Number M3) o Parameter indicating which SM in the SC to
operate on
TP-DA TP-Destination-Address M4) 2-12o Parameter indicating the
Destination Address to which the TP-Command refers
TP-CDL TP-Command-Data-Length M o Parameter indicating the length of the
TP-CD field in octets
TP-CD TP-Command-Data O o Parameter containing user data
1) Provision: Mandatory (M) or Optional (O).
2) Representation: Integer (I), bit (b), 2bits (2b), octet (o)
3) For TP-Command-Types which are not for a specific SM this field shall
be ignored when received. Its value is of no concern but the field must
be present to maintain the structure.
4) For certain TP-Command-Types which operate on a specific SM (e.g.
Enquire, Delete etc.) the full TP-DA must be specified. For
TP-Command-Types which do not operate on a specific SM, the address
length must be set to zero indicating that the Address-Value fields are
not present. The Type-of-Address field must be present (see 9.1.2.5) and
shall be set to zero and ignored.
Layout of SMS-COMMAND:
Bit no. 7 6 5 4 3 2 1 0
Number 1
TP-MTI, TP-SRR, TP-UDHI
of octets 1
TP-MR
1
TP-PID
1
TP-CT
1
TP-MN
2 to 12
TP-DA
......................................
1
TP-CDL
......................................
0 to 156
TP-CD
NOTE: The maximum guaranteed length of TP-CD is 146 octets. In order to
achieve the maximum stated above (156 octets), the TP-DA field must have
a length of 2 octets.
9.2.3 Definition of the TPDU parameters
9.2.3.1 TP-Message-Type-Indicator (TP-MTI)
The TP-Message-Type-Indicator is a 2-bit field, located within bits no 0
and 1 of the first octet of all PDUs which can be given the following
values:
bit1 bit0 Message type
0 0 SMS-DELIVER (in the direction SC to MS)
0 0 SMS-DELIVER REPORT (in the direction MS to SC)
1 0 SMS-STATUS-REPORT (in the direction SC to MS)
1 0 SMS-COMMAND (in the direction MS to SC)
0 1 SMS-SUBMIT (in the direction MS to SC)
0 1 SMS-SUBMIT-REPORT (in the direction SC to MS)
1 1 Reserved
If an MS receives a TPDU with a " Reserved " value in the TP-MTI it shall
process the message as if it were an " SMS-DELIVER " but store the message
exactly as received.
9.2.3.2 TP-More-Messages-to-Send (TP-MMS)
The TP-More-Messages-to-Send is a 1-bit field, located within bit no 2
of the first octet of SMS-DELIVER and SMS-STATUS-REPORT, and to be given
the following values:
Bit no 2: 0 More messages are waiting for the MS in this SC
1 No more messages are waiting for the MS in this SC
Note: In the case of SMS-STATUS-REPORT this parameter refers to messages
waiting for the mobile to which the status report is sent. The term
message in this context refers to SMS-messages or status reports.
9.2.3.3 TP-Validity-Period-Format (TP-VPF)
The TP-Validity-Period-Format is a 2-bit field, located within bit no 3
and 4 of the first octet of SMS-SUBMIT, and to be given the following
values:
bit4 bit3
0 0 TP-VP field not present
1 0 TP-VP field present - relative format
0 1 TP-VP field present - enhanced format
1 1 TP-VP field present - absoluteformat
Any unsupported value may be rejected by the SC by returning the `TP-VPF
not supported' TP-FCS value in the SMS Submit Report for RP-Error.
9.2.3.4 TP-Status-Report-Indication (TP-SRI)
The TP-Status-Report-Indication is a 1-bit field, located within bit no.
5 of the first octet of SMS-DELIVER, and to be given the following
values:
Bit no. 5: 0 A status report will not be returned to the SME
1 A status report will be returned to the SME
9.2.3.5 TP-Status-Report-Request (TP-SRR)
The TP-Status-Report-Request is a 1-bit field, located within bit no. 5
of the first octet of SMS-SUBMIT and SMS-COMMAND, and to be given the
following values:
Bit no. 5: 0 A status report is not requested
1 A status report is requested
9.2.3.6 TP-Message-Reference (TP-MR)
The TP-Message-Reference field gives an integer representation of a
reference number of the SMS-SUBMIT or SMS-COMMAND submitted to the SC by
the MS. The MS increments TP-Message-Reference by 1 for each SMS-SUBMIT
or SMS-COMMAND being submitted. The value to be used for each SMS-SUBMIT
is obtained by reading the Last-Used-TP-MR value from the SMS Status
data field in the SIM (see GSM 11.11) and incrementing this value by 1.
After each SMS-SUBMIT has been submitted to the network, the
Last-Used-TP-MR value in the SIM is updated with the TP-MR that was used
in the SMS-SUBMIT operation. The reference number may possess values in
the range 0 to 255. The value in the TP-MR assigned by the MS is the
same value which is received at the SC.
In the case where no acknowledgement or an appropriate RP-Error is
received in response to an SMS-SUBMIT or SMS-COMMAND, then the MS may
automatically repeat the SMS-SUBMIT or SMS-COMMAND but must use the same
TP-MR value. The number of times the MS may repeat the SMS-SUBMIT or
SMS-COMMAND is an implementation matter.
If all automatic attempts fail (including the case where no automatic
repeat is provided), the user shall be informed. The failed message
shall be stored in the mobile in such a way that the user can request a
retransmission using the same TP-MR value, without needing to re-enter
any information. Such storage need only be provided for a single failed
message, the one most recently attempted.
The SC may discard an SMS-SUBMIT or SMS-COMMAND which has the same TP-MR
value as the previous SMS-SUBMIT or SMS-COMMAND received from the same
originating address.
A Phase 2 or later ME using a Phase 1 SIM cannot read or update the
TP-Message-Reference from/to the SIM, and so the ME shall always retain
the Last-Used-TP-MR value in its own memory, to be used only in the case
of a Phase 1 SIM.
The SMS-STATUS-REPORT also contains a TP-Message-Reference field. The
value sent to the MS will be the same as the TP-Message-Reference value
generated by the MS in the earlier SMS-SUBMIT or SMS-COMMAND to which
the status report relates.
9.2.3.7 TP-Originating-Address (TP-OA)
The TP-Originating-Address field is formatted according to the
formatting rules of address fields.
9.2.3.8 TP-Destination-Address (TP-DA)
The TP-Destination-Address field is formatted according to the
formatting rules of address fields.
9.2.3.9 TP-Protocol-Identifier (TP-PID)
The TP-Protocol-Identifier parameter serves the purposes indicated in
section 3.2.3. It consists of one octet, and the bits in the octet are
used as follows:
The MS will interpret reserved or unsupported values as the value
00000000 but shall store them exactly as received.
The SC may reject messages with a TP-Protocol-Identifier containing a
reserved value or one which is not supported.
bits usage
7 6
0 0 Assigns bits 0..5 as defined below
0 1 Assigns bits 0..5 as defined below
1 0 reserved
1 1 Assigns bits 0-5 for SC specific use
In the case where bit 7 = 0 and bit 6 = 0,
bit 5 indicates telematic interworking:
value = 0 : no interworking, but SME-to-SME protocol
value = 1 : telematic interworking
In the case of telematic interworking, the following five bit patterns
in bits 4..0 are used to indicate different types of telematic devices:
4.. .0
00000 implicit - device type is specific to this SC, or can be
concluded on the basis of the address
00001 telex (or teletex reduced to telex format)
00010 group 3 telefax
00011 group 4 telefax
00100 voice telephone (i.e. conversion to speech)
00101 ERMES (European Radio Messaging System)
00110 National Paging system (known to the SC)
00111 Videotex (T.100/T.101)
01000 teletex, carrier unspecified
01001 teletex, in PSPDN
01010 teletex, in CSPDN
01011 teletex, in analog PSTN
01100 teletex, in digital ISDN
01101 UCI (Universal Computer Interface, ETSI DE/PS 3 01-3)
01110..01111 (reserved, 2 combinations)
10000 a message handling facility (known to the SC)
10001 any public X.400-based message handling system
10010 Internet Electronic Mail
10011..10111 (reserved, 5 combinations)
11000..11110 values specific to each SC, usage based on mutual
agreement between the SME and the SC (7 combinations available for each
SC)
11111 A GSM mobile station. The SC converts the SM from the received
TP-Data-Coding-Scheme to any data coding scheme supported by that MS
(e.g. the default).
If bit 5 has value 1 in an SMS-SUBMIT PDU, it indicates that the SME is
a telematic device of a type which is indicated in bits 4..0, and
requests the SC to convert the SM into a form suited for that device
type. If the destination network is ISDN, the SC must also select the
proper service indicators for connecting to a device of that type.
If bit 5 has value 1 in an SMS-DELIVER PDU, it indicates that the SME is
a telematic device of a type which is indicated in bits 4..0.
If bit 5 has value 0 in an SMS-DELIVER PDU, the value in bits 4..0
identifies the SM-AL protocol being used between the SME and the MS.
Note that for the straightforward case of simple MS-to-SC short message
transfer the Protocol Identifier is set to the value 0.
In the case where bit 7 = 0, bit 6 = 1, bits 5..0 are used as defined
below
5 .. . .0
000000 Short Message Type 0
000001 Replace Short Message Type 1
000010 Replace Short Message Type 2
000011 Replace Short Message Type 3
000100 Replace Short Message Type 4
000101 Replace Short Message Type 5
000110 Replace Short Message Type 6
000111 Replace Short Message Type 7
001000..011110 Reserved
011111 Return Call Message
100000..111100 Reserved
111101 ME Data download
111110 ME De-personalization Short Message
111111 SIM Data download
A short message type 0 indicates that the ME must acknowledge receipt of
the short message but may discard its contents.
The Replace Short Message feature is optional for the ME and the SIM but
if implemented it shall be performed as described here.
For MT short messages, on receipt of a short message from the SC, the MS
shall check to see if the associated Protocol Identifier contains a
Replace Short Message Type code.
If such a code is present, then the MS will check the associated SC
address and originating address and replace any existing stored message
having the same Protocol Identifier code, SC address and originating
address with the new short message and other parameter values. If there
is no message to be replaced, the MS shall store the message in the
normal way.
If a Replace Short Message Type code is not present then the MS will
store the message in the normal way.
In MO short messages the SC reacts similarly but only the address of the
originating MS or any other source is checked.
A Return Call Message indicates to the MS to inform the user that a call
(e.g. a telephone call) can be established to the address specified
within the TP-OA. The RP-OA contains the address of the SC as usual. The
message content (if present) gives displayable information (e.g. the
number of waiting voice messages). The message is handled in the same
way as all other messages of the Replace Short Message Types.
The ME De-personalization Short Message is a ME-specific message which
instructs the ME to de-personalities the ME (see GSM 02.22 [25]). The
TP-DCS shall be set to Uncompressed, Default Alphabet, and Message Class
1 (ME-specific), which corresponds to a bit coding of 00010001. The
TP-UD field contains de-personalization information coded according to
GSM 02.22 [25]. This information shall not be displayed by an ME which
supports the scheme. The acknowledgement to this message is a
SMS-DELIVER-REPORT for RP-ACK in which the TP-User-Data shall be coded
according to GSM 02.22.
SIM Data download is a facility whereby the ME must pass the short
message in its entirety including all SMS elements contained in the SMS
deliver to the SIM using the mechanism described in GSM 11.11. The DCS
shall be set to 8 bit message class 2 (either bit coding 1111 0110 or
00010110). The entire user data field is available for SIM Data
download.
ME Data download is a facility whereby the ME shall process the short
message in its entirety including all SMS elements contained in the SMS
deliver to the ME. The DCS shall be set to message class 1. The entire
user data field is available for ME data download.
9.2.3.10 TP-Data-Coding-Scheme (TP-DCS)
The TP-Data-Coding-Scheme is defined in GSM 03.38.
9.2.3.11 TP-Service-Centre-Time-Stamp (TP-SCTS)
The TP-Service-Centre-Time-Stamp field is given in semi-octet
representation, and represents the local time in the following way:
Year: Month: Day: Hour: Minute: Second: Time Zone
Digits:
(Semi-octets) 2 2 2 2 2 2 2
The Time Zone indicates the difference, expressed in quarters of an
hour, between the local time and GMT. In the first of the two
semi-octets, the first bit (bit 3 of the seventh octet of the
TP-Service-Centre-Time-Stamp field) represents the algebraic sign of
this difference (0 : positive, 1 : negative).
The Service-Centre-Time-Stamp, and any other times coded in this format
that are defined in this specification, represent the time local to the
sending entity.
If the MS has knowledge of the local time zone, then any time received
(e.g. Service-Centre-Time-Stamp) at the MS may be displayed in the local
time rather than the time local to the sending entity. Messages shall be
stored as received without change to any time contained therein.
The Time Zone code enables the receiver to calculate the equivalent time
in GMT from the other semi-octets in the Service-Centre-Time-Stamp, or
indicate the time zone (GMT, GMT+1H etc.), or perform other similar
calculations as required by the implementation.
If the MS receives a non-integer value in the SCTS, it shall assume that
the digit is set to 0 but shall store the entire field exactly as
received.
9.2.3.12 TP-Validity-Period (TP-VP)
9.2.3.12.1 TP-VP (Relative format)
The TP-Validity-Period comprises 1 octet in integer representation,
giving the length of the validity period, counted from when the
SMS-SUBMIT is received by the SC.
The representation of time is as follows:
TP-VP value Validity period value
0 to 143 (TP-VP + 1) x 5 minutes (i.e. 5 minutes intervals up to 12
hours)
144 to 167 12 hours + ((TP-VP -143) x 30 minutes)
168 to 196 (TP-VP - 166) x 1 day
197 to 255 (TP-VP - 192) x 1 week
9.2.3.12.2 TP-VP (Absolute format )
The TP-Validity Period comprises 7 octets in semi octet representation
giving the absolute time of the validity period termination
The representation of time is identical to the representation of the
TP-Service-Centre-Time-Stamp.
9.2.3.12.3 TP-VP ( Enhanced format )
The TP-Validity Period comprises 7 octets. The presence of all octets is
mandatory although they may not all be used. The first octet indicates
the way in which the following 6 octets are used. Any reserved/unused
bits or octets must be set to zero.
Octet 1 TP-VP functionality indicator
bit 7 Extension bit
Set to 1 if the TP-VP functionality indicator is to be extended to
another octet. A setting of 0 indicates that there are no more TP-VP
functionality indicator extension octets to follow.
Any such extension octet will immediately follow the previous TP-VP
functionality indicator.
bit 6 Single shot SM.
Set to 1 if the SC is required to make up to one delivery attempt. The
TP-Validity Period, where present, will be applicable to the Single
shot SM.
bits 5, 4, 3 Reserved
bits 2, 1, 0 Validity Period Format.
Value bits 2 1 0
0 0 0 No Validity Period specified
0 0 1 Validity Period is as specified for the relative case. The
following octet contains the TP-VP value as described in 9.2.3.12.1
0 1 0 Validity period is relative in integer representation and the
following octet contains the TP-VP value in the range 0 to 255
representing 0 to 255 seconds. A TP-VP value of zero is undefined and
reserved for future use.
0 1 1 Validity period is relative in semi-octet representation. The
following 3 octets contain the relative time in Hours Minutes and
Seconds giving the length of the validity period counted from when the
SMS SUBMIT is received by the SC. The representation of time uses the
same representation as the Hours, Minutes and Seconds in the
TP-Service-Centre-Time-Stamp.
1 0 0 Reserved
1 0 1 Reserved
1 1 0 Reserved
1 1 1 Reserved
The SC will reject any Unsupported/ Reserved values received by
returning the `TP-VP not supported' TP-FCS value in the Submit SM Report
for RP-Error
9.2.3.13 TP-Discharge-Time (TP-DT)
The TP-Discharge-Time field indicates the time at which a previously
submitted SMS-SUBMIT was successfully delivered to or attempted to
deliver to the recipient SME or disposed of by the SC.
In the case of " transaction completed " the time shall be the time of the
completion of the transaction. In the case of " SC still trying to
transfer SM " the time shall be the time of the last transfer attempt. In
the case of " permanent or temporary error - SC not making any more
transfer attempts " the time shall be the time of either the last
transfer attempt or the time at which the SC disposed of the SM
according to the Status outcome in TP-ST.
The TP-Discharge-Time is given in semi-octet representation in a format
identical to the TP-SCTS.
9.2.3.14 TP-Recipient-Address (TP-RA)
The TP-Recipient-Address field indicates the address of the SME that was
the destination of the previously submitted mobile originated short
message being subject to the status report. The field is formatted
according to the formatting rules of address fields.
9.2.3.15 TP-Status (TP-ST)
The TP-Status field indicates the status of a previously submitted
SMS-SUBMIT and certain SMS COMMANDS for which a Status -Report has been
requested. It consists of one octet and the bits in the octet are used
as follows:
The MS will interpret any reserved values as " Service Rejected "
(01100011) but shall store them exactly as received.
bits value/usage
7 0 Bits 0..6 as defined below:
6....0 Indicate whether the previously submitted short message was
successfully forwarded to the SME, or whether an error condition has
been encountered, as follows:
Short message transaction completed
0000000 Short message received by the SME
0000001 Short message forwarded by the SC to the SME but the SC is
unable to confirm delivery
0000010 Short message replaced by the SC
Reserved values
0000011..0001111 Reserved
0010000..0011111 Values specific to each SC
Temporary error, SC still trying to transfer SM
0100000 Congestion
0100001 SME busy
0100010 No response from SME
0100011 Service rejected
0100100 Quality of service not available
0100101 Error in SME
0100110..0101111 Reserved
0110000..0111111 Values specific to each SC
Permanent error, SC is not making any more transfer attempts
1000000 Remote procedure error
1000001 Incompatible destination
1000010 Connection rejected by SME
1000011 Not obtainable
1000100 Quality of service not available
1000101 No interworking available
1000110 SM Validity Period Expired
1000111 SM Deleted by originating SME
1001000 SM Deleted by SC Administration
1001001 SM does not exist (The SM may have previously existed in the
SC but the SC no longer has knowledge of it or the SM
may never have previously existed in the SC)
1001010..1001111 Reserved
1010000..1011111 Values specific to each SC
Temporary error, SC is not making any more transfer attempts
1100000 Congestion
1100001 SME busy
1100010 No response from SME
1100011 Service rejected
1100100 Quality of service not available
1100101 Error in SME
1100110..1101001 Reserved
1101010..1101111 Reserved
1110000..1111111 Values specific to each SC
bits value/usage
7 1 Bits 0..6 reserved
9.2.3.16 TP-User-Data-Length (TP-UDL)
If the TP-User-Data is coded using the GSM 7 bit default alphabet, the
TP-User-Data-Length field gives an integer representation of the number
of characters (septets) within the TP-User-Data field to follow. If a
TP-User-Data-Header field is present, then the TP-User-Data-Length value
is the sum of the number of septets in the TP-User-Data-Header field
(including any padding) and the number of septets in the TP-User-Data
field which follows. See Fig. 9.2.3.24.(a).If the TP-User-Data is coded
using 8-bit data, the TP-User-Data-Length field gives an integer
representation of the number of octets within the TP-User-Data field to
follow. If a TP-User-Data-Header field is present, then the
TP-User-Data-Length value is the sum of the number of octets in the
TP-User-Data-Header field and the number of octets in the TP-User-Data
field which follows. See Fig. 9.2.3.24.(b).
If the TP-User-Data is coded using UCS2 [24] data, the
TP-User-Data-Length field gives an integer representation of the number
of octets within the TP-User-Data field to follow. If a
TP-User-Data-Header field is present, then the TP-User-Data-Length value
is the sum of the number of octets in the TP-User-Data-Header field and
the number of octets in the TP-User-Data field which follows.See Fig
9.2.3.24.(b).
If the TP-User-Data is coded using compressed GSM 7 bit default alphabet
or compressed 8 bit data or compressed UCS2 [24] data, the
TP-User-Data-Length field gives an integer representation of the number
of octets after compression within the TP-User-Data field to follow. If
a TP-User-Data-Header field is present, then the TP-User-Data-Length
value is the sum of the number of uncompressed octets in the
TP-User-Data-Header field and the number of octets in the compressed
TP-User-Data field which follows.See Fig. 9.2.3.24.(c)
For other Data Coding Schemes, see GSM 03.38.If this field is zero, the
TP-User-Data field will not be present.
9.2.3.17 TP-Reply-Path (TP-RP)
The TP-Reply-Path is a 1-bit field, located within bit no 7 of the first
octet of both SMS-DELIVER and SMS-SUBMIT, and to be given the following
values:
Bit no 7: 0 TP-Reply-Path parameter is not set in this
SMS-SUBMIT/DELIVER
1 TP-Reply-Path parameter is set in this SMS-SUBMIT/DELIVER
Please refer to annex D for details about the Reply procedures.
9.2.3.18 TP-Message-Number (TP-MN)
The TP-Message-Number is an 8-bit field allowing an MS to refer uniquely
to an SM in the SC which that MS has previously submitted. The TP-MN
value is the TP-MR value of a previously submitted SM.
9.2.3.19 TP-Command-Type (TP-CT)
The TP-Command-Type is an 8-bit field specifying the type of operation
that the SC is to perform. It has the following values:
Value (bit 7 .. 0)
Command Description Status Report Request Value
00000000 Enquiry relating to previously submitted short message 1
00000001 Cancel Status Report Request relating to previously submitted
short message 0
00000010 Delete previously submitted Short Message 0
00000011 Enable Status Report Request relating to previously submitted
short message 0
00000100..00011111 Reserved unspecified
11100000..11111111 Values specific for each SC 1 or 0
The SC will return an RP-Error with an appropriate TP-Failure-Cause for
any TP-Command value which is reserved, unsupported or invalid or the
actioning of the command has failed.
The SC will return an RP-ACK if the actioning of the Command has
succeeded.
A successful Enquiry will result in the SC sending a SMS-STATUS-REPORT
for the SM to which the Enquiry refers. In the case where the SC has a
number of SMs which have the same TP-MR, the same TP-DA and have come
from the same originating address the SC will send a SMS-STATUS-REPORT
for each SM.
In the case where a TP-Command is to Delete a previously submitted short
message, the SC will send a Status Report indicating that the SM has
been deleted if the original Submit SM request requested a status
Report.
9.2.3.20 TP-Command-Data-Length (TP-CDL)
The TP-Command-Data-Length field is used to indicate the number of
octets contained within the TP-Command-Data-field. If this field is set
to zero, the TP-Command-Data field will not be present.
9.2.3.21 TP-Command-Data (TP-CD)
The TP-Command-Data field contains data relating to the operation
requested by the MS which is to be performed at the SC. The maximum
length of this field is 157 octets. The usage and provision of the
optional TP-Command-Data field will be determined by the function
selected by the TP-Command-Type field.
9.2.3.22 TP-Failure-Cause (TP-FCS)
The TP-Failure-Cause field is used to report the reason for failure to
transfer or process a short message. It consists of a single octet used
as follows:
TP-FCS
Value
(Hex)
Meaning
When used
MO MT
00 - 7F Reserved
80 - 8F TP-PID errors
80 Telematic interworking not supported x
81 Short message Type 0 not supported x x
82 Cannot replace short message x x
83 - 8E Reserved
8F Unspecified TP-PID error x x
90 - 9F TP-DCS errors
90 Data coding scheme (alphabet) not supported x
91 Message class not supported
x
92 - 9E Reserved
9F Unspecified TP-DCS error x x
A0 - AF TP-Command Errors
A0 Command cannot be actioned x
A1 Command unsupported x
A2 - AE Reserved
AF Unspecified TP-Command error x
B0 TPDU not supported x x
B1 - BF Reserved
C0 SC busy x
C1 No SC subscription x
C2 SC system failure x
C3 Invalid SME address x
C4 Destination SME barred x
C5 SM Rejected-Duplicate SM x
C6 TP-VPF not supported X
C7 TP-VP not supported X
C8 - CF Reserved
D0 SIM SMS storage full
x
D1 No SMS storage capability in SIM
x
D2 Error in MS
x
D3 Memory Capacity Exceeded
X
D4 SIM Application Toolkit Busy x x
D5 - DF Reserved
E0 - FE Values specific to an application x x
FF Unspecified error cause x x
NOTE: Any reserved codes which are received should be treated as an
unspecified error cause.
MT and MO refer to the overall mobile terminated and mobile originated
services; not the direction of transmission of TP-FCS.
9.2.3.23 TP-User-Data-Header-Indicator (TP-UDHI)
The TP-User-Data-Header-Indicator is a 1 bit field within bit 6 of the
first octet of an SMS-SUBMIT and SMS-DELIVER PDU and has the following
values.
The TP-User-Data-Header-Indicator is a 1 bit field within bit 6 of the
first octet of the following six PDUs:
- SMS-SUBMIT,
- SMS-SUBMIT-REPORT in case it is carried within RP-ACK
- SMS-DELIVER,
- SMS-DELIVER-REPORT in case it is carried within RP-ACK
- SMS-STATUS-REPORT
- SMS-COMMAND.
TP-UDHI has the following values.
Bit no. 6 0 The TP-UD field contains only the short message
1 The beginning of the TP-UD field contains a Header in addition to
the short message
9.2.3.24 TP-User Data (TP-UD)
The TP-User-Data field contains up to 140 octets of user data.
The TP-User-Data field may comprise just the short message itself or a
Header in addition to the short message depending upon the setting of
TP-UDHI.
Where the TP-UDHI value is set to 0 the TP-User-Data field comprises the
short message only, where the user data can be 7 bit (default alphabet)
data, 8 bit data, or 16 bit (UCS2) data.
Where the TP-UDHI value is set to 1 the first octets of the TP-User-Data
field contains a Header in the following order starting at the first
octet of the TP-User-Data field.
Irrespective of whether any part of the User Data Header is ignored or
discarded, the MS shall always store the entire TPDU exactly as
received.
FIELD LENGTH
Length of User Data Header 1 octet
Information-Element-Identifier " A " 1 octet
Length of Information-Element " A " 1 octet
Information-Element " A " Data 1 to " n " octets
Information-Element-Identifier " B " 1 octet
Length of Information-Element " B " 1 octet
Information-Element " B " Data 1 to " n " octets
Information-Element-Identifier " n " 1 octet
Length of Information-Element " n " 1 octet
Information-Element " n " Data 1 to " n " octets
The diagram below shows the layout of the TP-User-Data-Length and the
TP-User-Data for uncompressed GSM 7 bit default alphabet data. The UDHL
field is the first octet of the TP-User-Data content of the Short
Message.
Figure 9.2.3.24 (a)
The diagram below shows the layout of the TP-User-Data-Length and the
TP-User-Data for uncompressed 8 bit data or uncompressed UCS2 data. The
UDHL field is the first octet of the TP-User-Data content of the Short
Message.
Figure 9.2.3.24 (b)
The diagram below shows the layout of the TP-User-Data-Length and the
TP-User-Data for compressed GSM 7 bit default alphabet data, compressed
8 bit data or compressed UCS2 data. The UDHL field is the first octet of
the TP-User-Data content of the Short Message.
Figure 9.2.3.24 (c)
The definition of the TP-User-Data-Length field which immediately
precedes the " Length of User Data Header " is unchanged and will
therefore be the total length of the TP-User-Data field including the
Header, if present. (see 9.2.3.16)
The " Length-of-Information-Element " fields shall be the integer
representation of the number of octets within its associated
" Information-Element-Data " field which follows and shall not include
itself in its count value.
The " Length-of-User-Data-Header " field shall be the integer
representation of the number of octets within the " User-Data-Header "
information fields which follow and shall not include itself in its
count or any fill bits which may be present (see text below).
Information Elements may appear in any order and need not necessarily
follow the order used in this specification. If Information Elements
are duplicated (either with the same or different content) then the
contents of the last occurrence of the Information Element shall be
used. If the length of the User Data Header overall is such that there
appear to be too few or too many octets in the final Information Element
then the whole User Data Header shall be ignored.
If any reserved values are received within the content of any
Information Element then that part of the Information Element shall be
ignored.
The Information Element Identifier octet shall be coded as follows:
VALUE (hex) MEANING
00 Concatenated short messages
01 Special SMS Message Indication
02 Reserved
03 Value not used to avoid misinterpretation as & lt; LF & gt; character
04 Application port addressing scheme, 8 bit address
05 Application port addressing scheme, 16 bit address
06 Selective Status Report
07 UDH Source Indicator
08-6F Reserved for future use
70-7F SIM Toolkit Security Headers
80 - 9F SME to SME specific use
A0 - BF Reserved for future use
C0 - DF SC specific use
E0 - FF Reserved for future use
A receiving entity shall ignore (i.e. skip over and commence processing
at the next information element) any information element where the IEI
is Reserved or not supported. The receiving entity calculates the start
of the next information element by looking at the length of the current
information element and skipping that number of octets.
The SM itself may be coded as 7, 8 or 16 bit data.
If 7 bit data is used and the TP-UD-Header does not finish on a septet
boundary then fill bits are inserted after the last Information Element
Data octet so that there is an integral number of septets for the entire
TP-UD header. This is to ensure that the SM itself starts on an septet
boundary so that an earlier Phase mobile will be capable of displaying
the SM itself although the TP-UD Header in the TP-UD field may not be
understood.
It is optional to make the first character of the SM itself a Carriage
Return character encoded according to the default 7 bit alphabet so that
earlier Phase mobiles, which do not understand the TP-UD-Header, will
over-write the displayed TP-UD-Header with the SM itself.
If 16 bit (USC2) data is used then padding octets are not necessary. The
SM itself will start on an octet boundary.
If 8 bit data is used then padding is not necessary. An earlier
Phase mobile will be able to display the SM itself although the TP-UD
header may not be understood.
It is also possible for mobiles not wishing to support the TP-UD header
to check the value of the TP-UDHI bit in the SMS-Deliver PDU and the
first octet of the TP-UD field and skip to the start of the SM and
ignore the TP-UD header.
9.2.3.24.1 Concatenated Short Messages
This facility allows short messages to be concatenated to form a longer
message.
In the case of uncompressed 8-bit data, the maximum length of the short
message within the TP-UD field is 134 (140-6) octets.
In the case of uncompressed GSM Default 7 bit data, the maximum length
of the short message within the TP-UD field is 153 (160-7) characters.
In the case of 16 bit uncompressed USC2 data, the maximum length of the
short message within the TP-UD field is 67 ((140-6)/2) characters. A
UCS2 character must not be split in the middle; if the length of the
User Data Header is odd, the maximum length of the whole TP-UD field is
139 octets.
In the case of compressed GSM Default alphabet 7 bit data, 8 bit data or
UCS2 the maximum length of the compressed short message within the TP-UD
field is 134 ( 140-6) octets including the Compression Header and
Compression Footer, both or either of which may be present ( See
subclause 3.9).
The maximum length of an uncompressed concatenated short message is
39015 (255*153) default alphabet characters, 34170 (255*134) octets or
17085 (255*67) UCS2 characters.
The maximum length of a compressed concatenated message is 34170
(255*134) octets including the Compression Header and Compression Footer
( see section 3.9 and Fig 9.2.3.24.1(a) below.
Figure 9.2.3.24.1.(a) Concatenation of a Compressed short message
The Information-Element-Data field contains information set by the
application in the SMS-SUBMIT so that the receiving entity is able to
re-assemble the short messages in the correct order. Each concatenated
short message contains a reference number which together with the
originating address and Service Centre address allows the receiving
entity to discriminate between concatenated short messages sent from
different originating SMEs and/or SCs.
The TP elements in the SMS-SUBMIT PDU, apart from TP-MR, TP-UDL and
TP-UD, should remain unchanged for each SM which forms part of a
concatenated SM, otherwise this may lead to irrational behaviour.
The Information-Element-Data octets shall be coded as follows.
Octet 1 Concatenated short message reference number
This octet shall contain a modulo 256 counter indicating the reference
number for a particular concatenated short message. This reference
number shall remain constant for every short message which makes up a
particular concatenated short message.
Octet 2 Maximum number of short messages in the concatenated short
message.
This octet shall contain a value in the range 0 to 255 indicating the
total number of short messages within the concatenated short message.
The value shall start at 1 and remain constant for every short message
which makes up the concatenated short message. If the value is zero then
the receiving entity shall ignore the whole Information Element.
Octet 3 Sequence number of the current short message.
This octet shall contain a value in the range 0 to 255 indicating the
sequence number of a particular short message within the concatenated
short message. The value shall start at 1 and increment by one for every
short message sent within the concatenated short message. If the value
is zero or the value is greater than the value in octet 2 then the
receiving entity shall ignore the whole Information Element.
9.2.3.24.2 Special SMS Message Indication
There are three levels of " Message Waiting " indication provided within
this specification. The first level is to set the Protocol Identifier to
" Return Call message " , which indicates that a message is waiting and
relies on the text of the message to supply the detail. The second level
uses the Data Coding Scheme with or without Return Call Message (see
GSM 03.38) to indicate the type of message waiting and whether there are
some messages or no messages. The third level is described here, and
provides the maximum detail level for analysis by the mobile, i.e. an
indication of the number and type of messages waiting in systems
connected to the PLMN. This third level is provided for future
flexibility, as it cannot immediately be used without compatibility
problems with the earliest Phase mobiles. It is envisaged that this
scheme can start to be used once mobiles supporting TP-UDH become widely
available.
This information may be stored by the MS in a form other than an SMS
message, for example an indicator may be shown if the number of messages
is non-zero or removed if the number of messages is zero. The MS may
also store actual number of messages waiting and provide some other MMI
to access this information. Text may be included by the SMS Service
Centre for backward compatibility with the earliest Phase mobiles and
the Data Coding Scheme may also be used to convey this information in
parallel for backward compatibility with " middle " Phase mobiles (which
support the use of Data Coding Scheme for Message Waiting Indication but
not the use of TP-UDH for Message Waiting Indication).
The information-Element octets shall be coded as follows:
Octet 1 Message Indication type and Storage
Bit 7 Indicates whether or not the message shall be stored.
Bit 7
0 Discard message after updating indication
1 Store message
In the event of a conflict between this setting and the setting of the
Data Coding Scheme (see GSM 03.38) then the message shall be stored if
either the DCS indicates this, or Octet 1 above indicates this.
Bits 6..0 show the message indication type
000 0000 Voice Message Waiting
000 0001 Fax Message Waiting
000 0010 Electronic Mail Message Waiting
000 0011 Other Message Waiting (see GSM 03.38 for definition of
" other " )
Other values are reserved for future use
Octet 2 Message Count
This octet shall contain a value in the range 0 to 255 indicating the
number of messages of the type specified in Octet 1 waiting. The value
255 shall be taken to mean 255 or greater. In the event of a conflict
between this setting and the setting of the Data Coding Scheme (see
GSM 03.38) then the Message Count in the TP-UDH shall override the
indication in the TP-DCS.
If more than one type of message is required to be indicated within one
SMS message, then further octets must be used, as in the following
example:
[00] TP-UDL [1E] (30 decimal septets)
[01] Length of TP-UDH [08]
[02] IEI = Special SMS Message Indication [01]
[03] Length = 02
[04] Octet 1 = Voice Mail, do not store [00]
[05] Octet 2 = 04 Messages
[06] IEI = Special SMS Message Indication [01]
[07] Length = 02
[08] Octet 1 = Fax Mail, Store [81]
[09] Octet 2 = 02 Messages
+ 5 Fill bits
+ 19 seven-bit character message text
The Total number of bits is 210.
9.2.3.24.3 Application Port Addressing 8 bit address
This facility allows short messages to be routed to one of multiple
applications in the TE (terminal equipment), using a method similar to
TCP/UDP ports in a TCP/IP network. An application entity is uniquely
identified by the pair of TP-DA/TP-OA and the port address. The port
addressing is transparent to the transport, and also useful in Status
Reports.
The total length of the IE is 2 octets
octet 1 Destination port
This octet contains a number indicating the receiving port, i.e.
application, in the receiving device.
octet 2 Originator port
This octet contains a number indicating the sending port, i.e.
application, in the sending device.
The port range is up to 255 using 8 bit addressing space. The Integer
value of the port number is presented as in GSM 03.40 section 9.1.2.1.
VALUE (port number) MEANING
0 - 239 Reserved
240 - 255 Available for allocation by applications
A receiving entity shall ignore (i.e. skip over and commence processing
at the next information element) any information element where the value
of the Information-Element-Data is Reserved or not supported.
9.2.3.24.4 Application Port Addressing 16 bit address
This facility allows short messages to be routed to one of multiple
applications in the TE (terminal equipment), using a method similar to
TCP/UDP ports in a TCP/IP network. An application entity is uniquely
identified by the pair of TP-DA/TP-OA and the port address. The port
addressing is transparent to the transport, and also useful in Status
Reports.
The total length of the IE is 4 octets
octet 1,2 Destination port
These octets contain a number indicating the receiving port, i.e.
application, in the receiving device.
octet 3,4 Originator port
These octets contain a number indicating the sending port, i.e.
application, in the sending device.
The port range is up to 65535 using 16 bit addressing space. The Integer
value of the port number is presented as in GSM 03.40 section 9.1.2.1.
VALUE (port number) MEANING
0 - 15999 Reserved
16000 - 16999 Available for allocation by applications
17000 - 65535 Reserved
A receiving entity shall ignore (i.e. skip over and commence processing
at the next information element) any information element where the value
of the Information-Element-Data is Reserved or not supported.
9.2.3.24.5 SMSC Control Parameters
The facility enables the SMS protocol headers to be expanded using a
flexible method. It is used to control the SMSC, but is also passed
transparently to the receiving mobile. The Information Element must be
present in every short message affected by it, i.e. in every short
message in a concatenated message.
The Information Element data octets shall be coded as follows:
octet 1 Selective Status Report
This facility is used to control the creation of Status Reports,
depending on the error code of the particular message. It is also used
by the sending entity to request inclusion of the original UDH into the
Status Report. In this case the original UDH must be separated from the
rest of the UDH using the Source Indicator. The TP-SRR must be set in
order for the Selective Status Report to be enabled. The bits are
defined as follows
bit 0
0 No Status Report for short message transaction completed
1 Status Report for short message transaction completed
bit 1
0 No Status Report for permanent error when SC is not making any more
transfer attempts
1 Status Report for permanent error when SC is not making any more
transfer attempts
bit 2
0 No Status Report for temporary error when SC is not making any more
transfer attempts
1 Status Report for temporary error when SC is not making any more
transfer attempts
bit 3
0 No Status Report for temporary error when SC is still trying to
transfer SM
1 Status Report for temporary error when SC is still trying to transfer
SM
bits 4 and 5
reserved for future use.
bit 6
0 No activation
1 A Status Report generated by this Short Message, due to a permanent
error or last temporary error, cancels the SRR of the rest of the Short
Messages in a concatenated message.
bit 7
0 Do not include original UDH into the Status Report
1 Include original UDH into the Status Report
9.2.3.24.6 UDH Source Indicator
The facility is used to separate the UDH of the original message, a UDH
created by the SMSC, and a UDH provided by the original receiving
entity. The Source Indicator is placed in front of the content inserted
by the source. The indicated content (one or more Information-Elements)
ends at the next UDH-Source-Indicator, or at the end of the UDH. The
Separator is intended to be used especially in Status Reports, but can
also be used by the SMSC to add information into Short Message (for
example Message waiting). The default content for a UDH in a
SMS-DELIVERY is the headers inserted by the sending device, and the
default content for a UDH in a SMS-STATUS-REPORT is the headers copied
from the SMS-DELIVERY-REPORT.
Values of octet:
01 The following part of the UDH is created by the original sender
(valid in case of Status Report)
02 The following part of the UDH is created by the original receiver
(valid in case of Status Report)
03 The following part of the UDH is created by the SMSC (can occur in
any message or report)
9.2.3.24.7 SIM Toolkit Security Headers
There are no IEI data values associated with these IEI values and so the
associated Length of Information element field is present but set to
zero.
These IEI values implicitly define that a Security Header is always
present at the start of the TP-User-Data field which immediately follows
the TP-User-Data-Header. Details of the Security Header will be found in
GSM 03.48.
In the case where a concatenated message contains a Security Header then
the Security Header will only be present in the first segment of a
concatenated message.
In the case where SMS compression is applied to a TP-User-Data field
which contains a Security Header then the SMS compression header (GSM
03.42) will immediately precede the Security Header.
9.2.3.25 TP-Reject-Duplicates (TP-RD)
The TP-Reject-Duplicates is a 1 bit field located within bit 2 of the
first octet of SMS-SUBMIT and has the following values.
Bit no. 2: 0 Instruct the SC to accept an SMS-SUBMIT for an SM still
held in the
SC which has the same TP-MR and the same TP-DA as a previously
submitted SM from the same OA.
1 Instruct the SC to reject an SMS-SUBMIT for an SM still held in the
SC which has the same TP-MR and the same TP-DA as the previously
submitted SM from the same OA. In this case an appropriate TP-FCS
value will be returned in the SMS-SUBMIT-REPORT.
9.2.3.26 TP-Status-Report-Qualifier (TP-SRQ)
The TP-Status-Report-Qualifier is a 1 bit field located within bit 5 of
the first octet of SMS-STATUS-REPORT and has the following values
Bit no. 5: 0 The SMS-STATUS-REPORT is the result of a SMS-SUBMIT.
1 The SMS-STATUS-REPORT is the result of an SMS-COMMAND e.g.
an Enquiry.
9.2.3.27 TP-Parameter-Indicator (TP-PI)
The TP-Parameter-Indicator comprises a number of octets between 1 and n
where each bit when set to a 1 indicates that a particular optional
parameter is present in the fields which follow. The TP-PI is present
as part of the RP-User-Data in the RP-ACK for both the SMS-DELIVER TPDU
and the SMS-SUBMIT TPDU.
The structure of the TP-PI is as follows:
Octet 1
bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
Extension bit Reserved Reserved Reserved Reserved TP-UDL TP-DCS TP-PID
The most significant bit in octet 1 and any other TP-PI octets which may
be added later is reserved as an extension bit which when set to a 1
will indicate that another TP-PI octet follows immediately afterwards.
If the TP-UDL bit is set to zero then by definition then neither the
TP-UDL field or the TP-UD field can be present.
If a Reserved bit is set to " 1 " then the receiving entity shall ignore
the setting. The setting of this bit will mean that additional
information will follow the TP-User-Data, so a receiving entity shall
discard any octets following the TP-User-Data.
9.3 Service provided by the SM-RL
9.3.1 General
The Short Message Relay Layer (SM-RL) provides a service to the Short
Message Transfer Layer (SM-TL). This service enables the SM-TL to send
Transfer Protocol Data Units (TPDUs) to its peer entity, receive TPDUs
from its peer entity and receive reports about earlier requests for
TPDUs to be transferred.
In order to keep track of TPDUs and reports about those TPDUs,
primitives between the SM-TL and SM-RL contain a Short Message
Identifier (SMI), which is a reference number for the TPDU associated
with the primitive. This Short Message Identifier is not carried via the
SM-RL protocol of section 9.3.2. It is carried via the relay layer
service between the SC and GMSC. It is also carried by SM-RL of
GSM 04.11, between the visited MSC and MS. The parameter is not carried
by MAP but is mapped to and from the TCAP dialogue Identifier (see CCITT
recommendation Q.771, " Blue Book " ) at the GMSC and the visited MSC
(therefore the Message Identifier at the SC/GMSC interface is not the
same as at the visited MSC/MS interface).
The SM-RL communicates with its peer entity by the protocol described in
the following sections.
9.3.2 Protocol element repertoire at SM-RL
Different protocols are required between different pairs of SM-RL
entities. Those are described in other GSM specifications. This section
gives a survey of the different information elements which have to be
conveyed between those entities. (Note that the notation of the protocol
and information elements may vary between different GSM specifications).
The SM-RL comprises the following 6 protocol elements:
RP-MO-DATA for transferring a TPDU from MS to SC
RP-MT-DATA for transferring a TPDU from SC to MS
RP-ACK for acknowledging an RP-MO-DATA, an RP-MT-DATA or an
RP-SM-MEMORY-AVAILABLE
RP-ERROR for informing of an unsuccessful RP-MO-DATA or an RP-MT-DATA
transfer attempt
RP-ALERT-SC for alerting the SC that the MS has recovered operation
(information
sent from the HLR to the SC)
RP-SM-MEMORY-AVAILABLE for notifying the network that the MS has memory
available to
accept one or more short messages (information sent from the MS to
the HLR)
9.3.2.1 RP-MO-DATA
Basic elements of the RP-MO-DATA type.
Abbr. Reference P1) Description
RP-OA RP-Originating-Address ++- Address of the originating MS.
RP-DA RP-Destination-Address -++ Address of the destination SC.
RP-UD RP-User-Data +++ Parameter containing the TPDU
1) Provision on the links SC & lt; - & gt; MSC, MSC & lt; - & gt; MSC or MSC & lt; - & gt; SGSN, and
MSC & lt; - & gt; MS or SGSN & lt; - & gt; MS indicated by " xxx " , where x may be either " + " or
" - " , dependent on whether the parameter is mandatory or not on the
respective link.
9.3.2.2 RP-MT-DATA
Basic elements of the RP-MT-DATA type.
Abbr. Reference P1) Description
RP-PRI RP-Priority-Request +-- Parameter indicating whether or not the
short message transfer should be stopped if the originator SC address is
already contained in the MWD.
RP-MMS RP-More-Messages-To-Send OO- Parameter indicating that there are
more messages waiting in the SC
RP-OA RP-Originating-Address +++ Address of the originating SC.
RP-DA RP-Destination-Address ++- Address of the destination MS.
RP-UD RP-User-Data +++ Parameter containing the TPDU
RP-MTI RP-Message Type Indicator O-- Parameter indicating if the TPDU is
a SMS Deliver or a SMS Status Report 2)
RP-SMEA RP-originating SME-Address O-- Address of the originating SME 2)
1) Provision on the links SC & lt; - & gt; MSC, MSC & lt; - & gt; MSC or MSC & lt; - & gt; SGSN, and
MSC & lt; - & gt; MS or SGSN & lt; - & gt; MS indicated by " xxx " , where x may be " + " , " - " or
" O " , dependent on whether the parameter is mandatory, not present or
optional on the respective link.
2) These information elements may be included in the " Send Routing
Information for SM " sent by the SMS-GMSC to the HLR.
When transmitted, the RP-SMEA shall take the TP-OA value.
When transmitted, the RP-MTI shall be given the following values:
0 SMS Deliver
1 SMS Status Report.
This may be used by the HLR to distinguish the two cases in order not
to apply any filtering mechanism based on the RP-SMEA value in case of a
SMS-Status Report transmission.
9.3.2.3 RP-ACK
The RP-ACK contains the RP-User-Data which is a parameter containing the
TPDU (see 9.2.2.1a and 9.2.2.2a).
9.3.2.4 RP-ERROR
Basic elements of the RP-ERROR type.
Abbr. Reference P1) Description
RP-MSI RP-MW-Set-Indication +-- Parameter indicating whether or not the
MWI has been up-dated. 2)
RP-CS RP-Cause +++ Parameter identifying the error type. The RP-Cause
parameter gives the reason why a short message transfer attempt fails.
In practice three relay layer protocols are used - SC to GMSC/IWMSC (see
GSM 03.47), MAP (see GSM 09.02) and via the radio interface (see
GSM 04.11)
RP-MSIsdn RP-international--MS-ISDN-number +-- MSIsdn-Alert of the MS,
see section 3.2.7 3)
RP-UD RP-User-Data OO O Parameter containing a TPDU
1) Provision on the links SC & lt; - & gt; MSC, MSC & lt; - & gt; MSC or MSC & lt; - & gt; SGSN, and
MSC & lt; - & gt; MS or SGSN & lt; - & gt; MS indicated by " xxx " , where x may be " + " , " - " or " O "
dependent on whether the parameter is mandatory, not present or optional
on the respective link.
2) Only present when the RP-ERROR is transferred from the SMS-GMSC to
the SC.
3) Only present when the RP-MT-DATA transfer attempt failed because the
MS is not reachable or because the MS memory capacity was exceeded and
the MSIsdn-Alert is different from the MSIsdn used by the SC to address
the recipient MS
9.3.2.5 RP-ALERT-SC
Basic elements of the RP-ALERT-SC type:
Abbr. Reference P1) Description
RP-MSIsdn RP-International-MS-ISDN-Number M MSIsdn of the MS.
1) Provision; Mandatory (M).
9.3.2.6 RP-SM-MEMORY-AVAILABLE
Basic elements of the RP-SM-MEMORY-AVAILABLE type:
Abbr. Reference P1) Description
RP-IMSI RP-International-Mobile-Subscriber-Identity ++- IMSI of the MS.
1) Provision on the links HLR & lt; - & gt; VLR or HLR & lt; - & gt; SGSN, VLR & lt; - & gt; MSC and
MSC & lt; - & gt; MS or SGSN & lt; - & gt; MS indicated by " xxx " , where x may be either " + " or
" - " , dependent on whether the parameter is mandatory or not present on
the respective link.
10 Fundamental procedures within the point-to-point SMS
The point-to-point SMS comprises 3 fundamental procedures:
1) Short message mobile terminated. This procedure consists of all
necessary operations to:
a) transfer a short message or status report from the SC to the MS;
b) return a report to the SC, containing the result of the message
transfer attempt.
2) Short message mobile originated. This procedure consists of all
necessary operations to:
a) transfer a short message from the MS to the SC;
b) return a report to the MS, containing the result of the message
transfer attempt.
3) Transfer of an Alert. This procedure consists of all necessary
operations for an HLR or a VLR to initiate a transfer of an Alert to a
specific SC, informing the SC that the MS has recovered operation.
GSM 09.02 defines operations necessary for the provision of the Short
Message Service point-to-point. The operations defined in section 10
describe the requirement that the Short Message Service puts upon the
network functionality. If discrepancies exist in nomenclature, it is the
GSM 09.02 that will be the reference.
Annex C indicates the flow of primitives and parameters during the short
message transfer between the SC and the MS. Both the Mobile terminated
and the Mobile originated cases are covered.
10.1 Short message mobile terminated
The entities involved in this procedure are depicted in figure 03.40/14.
NOTE: Since the short message mobile terminated procedure covers the
functionality required at SM-RL for transferring TPDUs from SC to MS,
the procedure described covers both short message (SMS-DELIVER) and
status report (SMS-STATUS-REPORT) transfer. The term " short message
transfer " therefore, in this section, covers both cases.
Figure 03.40/14: Interfaces involved in the Short message mobile
terminated procedure. GSM 03.02. X is the interface between an MSC and
an SC as defined in section 5.
In figure 03.40/15, sequence diagrams are shown for the following basic
situations of short message mobile terminated transfer attempt:
- Successful short message transfer via the MSC or the SGSN;
- Short message transfer attempt failing due to error at the SMS-GMSC;
- Short message transfer attempt failing due to negative outcome of HLR
information retrieval;
- Short message transfer attempt failing due to error at the MSC or
SGSN;
- Short message transfer attempt failing due to negative outcome of VLR
information retrieval;
- Short message transfer attempt failing due to erroneous message
transfer on the radio path.
- Short message transfer attempt failing over the first path (e.g. SGSN)
and succeeding over the second path (e.g. MSC)
- Short message transfer attempt failing over the first path (e.g. SGSN)
and over the second path (e.g. MSC)
References to the relevant specifications of the different operations
are given in section 4.
NOTE:
1): This operation is not used by the SGSN
Figure 03.40/15a): Successful short message transfer attempt via the MSC
or the SGSN
Figure 03.40/15b): Short message transfer attempt failing due to error
at the SMS-GMSC
Figure 03.40/15c): Short message transfer attempt failing due to
negative outcome of
HLR information retrieval
Figure 03.40/15d): Short message transfer attempt failing due to error
at the MSC or SGSN
Figure 03.40/15e): Short message transfer attempt failing due to
negative outcome of
VLR information retrieval
NOTE:
1): This operation is not used by the SGSN
Figure 03.40/15f): Short message transfer attempt failing due to
erroneous message transfer
on the radio path
NOTES:
1): This operation is not used by the SGSN
2): Two addresses (SGSN and MSC) are received from HLR
3): Successful transfer over second path and unsuccessful transfer over
first path (e.g. Absent subscriber) are sent to HLR
4): The SMS transfer towards the second path is only triggered by the
reception of some MAP errors on the first path as described in chapter
8.1.1.
Figure 03.40/15g): Short message transfer attempt failing over the first
path (e.g. SGSN) and
succeeding over the second path (e.g. MSC)
NOTES:
1): This operation is not used by the SGSN
2): Two addresses (SGSN and MSC) are received from HLR
3): Unsuccessful transfer over the second path (e.g.
MemoryCapacityExceeded) and over the first path (e.g. Absent subscriber)
are sent to HLR
4): The SMS transfer towards the second path is only triggered by the
reception of some MAP errors on the first path as described in chapter
8.1.1.
Figure 03.40/15h): Short message transfer attempt failing over the first
path (e.g. SGSN) and
over the second path (e.g. MSC)
Operation 1: Message transfer SC - & gt; SMS-GMSC
This operation is used to transfer a short message from an SC to an
SMS-GMSC.
The operation consists of:
- the transfer of a message containing the TPDU from the SC to the
SMS-GMSC (see " 1a. Message transfer " in figure 03.40/15); and
- the return of either a " Failure report " (see 1c. in figure 03.40/15)
or a " Delivery report " (see 1b. in figure 03.40/15).
" Failure report " is returned to the SC when the SMS-GMSC has received
indication from another entity (MSC, SGSN or HLR) the procedure was
unsuccessful. The error indications which the SMS-GMSC may receive from
the MSC, SGSN, HLR, VLR or MS enable the SMS-GMSC to return one of the
error indications given in subclause 3.3 back to the SC.
Operation 2: sendRoutingInfoForShortMsg
The operation is an interrogation of the HLR by the SMS-GMSC to retrieve
information necessary to forward the short message.
The result may contain the MSC, SGSN or both addresses, and shall also
indicates which address belongs the MSC and the SGSN.
Operation 3: SM-DeliveryReportStatus
The operation provides a means for the SMS-GMSC to request the HLR to
add an SC address to the MWD, and is activated when the SMS-GMSC
receives an absent subscriber indication from the MSC, SGSN or both,
and/or when the SMS-GMSC receives a failure report for a short message
transfer with cause MS Memory Capacity Exceeded via the MSC or SGSN.
The Return Result optionally contains the MSIsdn-Alert.
This operation is also activated at successful delivery short message
when the MNRF, MNRG or both are set in HLR.
The operation consists of:
- the transfer of a message, containing the MSISDN of the MS to which
the short message was addressed, the SC-address, the successful outcome
and/or the causes (Absent Subscriber, MS memory capacity exceeded or
both) for updating the MWD, from the SMS-GMSC to the HLR (see 3. in
figure 03.40/15).
Operation 4: forwardShortMessage
The operation provides a means for the SMS-GMSC to transfer a short
message to the MSC or to the SGSN at which the MS is currently located.
The operation works in tandem with the forwarding of the short message
from the MSC or from the SGSN to the MS. Thus, the outcome of the
operation comprises either success, i.e. that the message has been
delivered to the MS; or a failure that may be caused by several reasons,
e.g. failure in the transfer SMS-GMSC - & gt; MSC or SMS-GMSC - & gt; SGSN, MS
being detached, or no paging response.
It should be noted that the MNRG setting is implicitly carried out in
SGSN when the message transfer is denied due to GPRS DETACH
Operation 5: sendInfoForMT-SMS
The operation provides a means for the MSC to retrieve subscriber
information from VLR for mobile terminated short message transfer. The
operation may be associated with an authentication procedure, as shown
in figure 03.40/16. Unsuccessful retrieval (e.g. absent subscriber) is
indicated by a cause indication to the SMS-GMSC.
An overall depiction of how operation 5 interacts with signalling on the
radio path is given in figure 03.40/16.
It should be noted that the MNRF setting is implicitly carried out when
the message transfer is denied due to IMSI DETACH.
NOTE: This operation is not used by the SGSN.
Operation 6: Message transfer MSC - & gt; MS
The operation is used to transfer a short message from the MSC to the
MS.
If the transfer is not successful, e.g. due to the MS losing radio
coverage after having successfully authenticated, a failure report
(RP-ERROR) is returned to the SMS-GMSC. In this case, MWD and MCEF in
the HLR will be updated only for the case where the transfer fails with
cause MS Memory Capacity Exceeded.
If the MS notifies the network that the MS has been unable to accept a
short message because its memory capacity has been exceeded, then the ME
will set the memory capacity Exceeded Notification flag if present.
Operation 7: InformSC
The operation is used to transfer the MSIsdn-Alert from the HLR to the
SMS-GMSC in case of the error Absent Subscriber or positive result given
as an answer to the operation SendRoutingInfoForSM.
SC SMS-GMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½ ½
½
½ ½ ½ ½ ½
½
½ ½ 4a. forwardShortMessage ½ ½
½
½ ½(((((((((((((((((((((((((((((((((((( & gt; ½
½ ½
½ ½ ½ ½ ½
½
½ ½ ½ ½5a. sendInfoFor- ½
½
½ ½ ½ ½(((((((((((((((( & gt; ½
½
½ ½ ½ ½ MT-SMS 2) ½
½
½ ½ ½ ½ ½
Page 1) ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½ ½
½
½ ½ ½ ½ ½
½
½ ½ ½ ½ ½
Authent. 1) ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½ ½
½
½ ½ ½ ½5b. sendInfoFor- ½
½
½ ½ ½ ½ & lt; (((((((((((((((( ½
½
½ ½ ½ ½ MT-SMS (Ack) 2)½
½
½ ½ ½ ½ ½
½
½ ½ ½ ½ ½
½
½ ½ ½ ½ 6. Message
transfer (correct) ½
½ ½ ½
½ & lt; ((((((((((((((((((((((((((((((((( & gt; ½
½ ½ ½ ½ ½
½
½ ½ 4b. Delivery report ½ ½
½
½ ½ & lt; ((((((((((((((((((((((((((((((((((((½
½ ½
½ ½ ½ ½ ½
½
((((((((( & gt; : Operation invocation or message transfer
& lt; (((((((( & gt; : Successful operation invocation or message transfer incl.
report
NOTES:
1): Described in GSM 04.08 and GSM 09.02
If the SGSN is used, Paging and Authentication are performed from
SGSN
2): This operation is not used by the SGSN
Figure 03.40/16a): " Send information for MT SMS " procedure; error free
case
SC SMS-GMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 4a. forwardShortMessage ½
½ ½
½ ½(((((((((((((((((((((((((((((((((((( & gt; ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½5a.
sendInfoFor- ½ ½
½ ½ ½
½(((((((((((((((( & gt; ½ ½
½ ½ ½ ½ MT-SMS 1)
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 5c. Failure
½ ½
½ ½ ½ ½ & lt; - - - - - - -
- ½ ½
½ ½ ½ ½ report 1)
½ ½
½ ½ ½ ½
½ ½
½ ½ 4c. Failure report ½
½ ½
½ ½ & lt; - - - - - - - - - - - - - - - - - - ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 3a. SMDelivery ½ ½
½ ½
½ ½((((((((((((((((( & gt; ½ ½
½ ½
½ ½ ReportStatus ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
- - - - & gt; : Error report
NOTE:
1): The GPRS DETACH information is in the SGSN
This operation is not used by the SGSN
Figure 03.40/16b): " Send information for MT SMS " procedure;
erroneous case: absent subscriber (e.g. IMSI DETACH or GPRS DETACH)
SC SMS-GMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 4a. forwardShortMessage ½
½ ½
½ ½(((((((((((((((((((((((((((((((((((( & gt; ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½5a.
sendInfoFor- ½ ½
½ ½ ½
½(((((((((((((((( & gt; ½ ½
½ ½ ½ ½ MT-SMS 2)
½ ½
½ ½ ½ ½
½ Page 1) ½
½ ½ ½ ½
½((((((((((((((((( & gt; ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 5c. Paging
½ ½
½ ½ ½ ½ & lt; - - - - - - -
- ½ ½
½ ½ ½ ½ failure2)
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 4c. Failure report ½
½ ½
½ ½ & lt; - - - - - - - - - - - - - - - - - - ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 3a. SM-Delivery ½
½ ½
½ ½((((((((((((((((( & gt; ½ ½
½ ½
½ ½ ReportStatus ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
- - - - & gt; : Error report
NOTES:
1): Described in GSM 04.08 and GSM 09.02
If the SGSN is used, Paging is performed from SGSN
2): This operation is not used by the SGSN
Figure 03.40/16c): " Send information for MT SMS " procedure;
erroneous case: Absent subscriber (e.g. no paging response)
SC SMS-GMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 4a. forwardShortMessage ½
½ ½
½ ½(((((((((((((((((((((((((((((((((((( & gt; ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½5a.
sendInfoFor- ½ ½
½ ½ ½
½(((((((((((((((( & gt; ½ ½
½ ½ ½ ½ MT-SMS 2)
½ ½
½ ½ ½ ½
½ Page 1) ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ Authent. 1) ½
½ ½ ½ ½
½ & lt; - - - - - - - - & gt; ½
½ ½ ½ ½
½ (incorr. resp.)½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 5c.
½ ½
½ ½ ½ ½ & lt; - - - - - - -
- ½ ½
½ ½ ½ ½ auth. failure
2)½ ½
½ ½ ½ ½
½ ½
½ ½ 4c. Failure report ½
½ ½
½ ½ & lt; - - - - - - - - - - - - - - - - - - ½
½ ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
- - - - & gt; : Error report
& lt; - - - - & gt; : Unsuccessful operation invocation or message transfer
including error report
(or with missing confirmation)
NOTES:
1): Described in GSM 04.08 and GSM 09.02
If the SGSN is used, Paging and Authentication are performed from
SGSN
2): This operation is not used by the SGSN
Figure 03.40/16d): " Send information for MT SMS " procedure; incorrect
authentication
10.2 Short message mobile originated
The entities involved in this procedure is depicted in figure 03.40/17.
Figure 03.40/17: Interfaces involved in the Short message mobile
originated procedure.
GSM 03.02. X is the interface between an MSC or an SGSN and an SC as
defined in chapter 5
Note that since the short message mobile originated procedure covers the
functionality required at SM-RL for transferring TPDUs from SC to MS,
the procedure described covers both short message (SMS-SUBMIT) and
command (SMS-COMMAND) transfer. The term " short message transfer "
therefore in this section, covers both cases.
In figure 03.40/18, sequence diagrams for the following basic situations
of short message mobile terminated transfer attempt:
- Successful short message transfer;
- Short message transfer attempt failing due to error at the MSC or
SGSN;
- Short message transfer attempt failing due to negative outcome of VLR
information retrieval;
- Short message transfer attempt failing due to error at the SMS-IWMSC;
- Short message transfer attempt failing due to error at the SC.
References to the relevant specifications of the different operations
are given in section 4.
SC SMS-IWMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ Access request ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½
½ and possible ½
½ ½ ½ ½
½ authentication 1)
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7a.
Message transfer ½
½ ½ ½
½ & lt; ((((((((((((((((((((((((((((((((((½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 8a.
sendInfoFor-½ ½
½ ½ ½ ½ & lt; ((((((((((((
((( & gt; ½ ½
½ ½ ½ ½ MO-SMS 2)
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 9. forwardShortMessage ½
½ ½
½ ½ & lt; ((((((((((((((((((((((((((((((((((((½
½ ½
½ ½ ½ ½
½ ½
½ 10a. Message ½ ½ ½
½ ½
½ & lt; ((((((((((((((((½ ½ ½
½ ½
½ transfer ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ 10b. Delivery ½ ½ ½
½ ½
½(((((((((((((((( & gt; ½ ½ ½
½ ½
½ report ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 9b. Delivery report ½
½ ½
½ ½(((((((((((((((((((((((((((((((((((( & gt; ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7b.
Delivery report ½
½ ½ ½
½(((((((((((((((((((((((((((((((((( & gt; ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
& lt; ((((((((( & gt; : Successful operation invocation or message transfer
including report
NOTES:
1): Described in GSM 04.08 and GSM 09.02.
2): This operation is not used by the SGSN
Figure 03.40/18a): Successful short message transfer attempt
SC SMS-IWMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ Access request ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½
½ and possible ½
½ ½ ½ ½
½ authentication 1)
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7a.
Message transfer ½
½ ½ ½
½ & lt; ((((((((((((((((((((((((((((((((((½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7c.
Failure report ½
½ ½ ½ ½ - - - - - - -
- - - - - - - - - - & gt; ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
& lt; ((((((((( & gt; : Successful operation invocation or message transfer
including report
- - - - & gt; : Error report
NOTE:
1) : Described in GSM 04.08 and GSM 09.02
Figure 03.40/18b): Short message transfer attempt failing due to error
at the MSC or SGSN
SC SMS-IWMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ Access request ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½
½ and possible ½
½ ½ ½ ½
½ authentication 1)
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7a.
Message transfer ½
½ ½ ½
½ & lt; ((((((((((((((((((((((((((((((((((½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 8.
sendInfoFor- ½ ½
½ ½ ½ ½ & lt; - - - - - - -
- & gt; ½ ½
½ ½ ½ ½ MO-SMS 2)
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7c.
Failure report ½
½ ½ ½ ½ - - - - - - -
- - - - - - - - - - & gt; ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
& lt; ((((((((( & gt; : Successful operation invocation or message transfer
including report
- - - - & gt; : Error report
& lt; - - - - & gt; : Unsuccessful operation invocation or message transfer incl.
error report (or with
missing confirmation)
NOTES:
1): Described in GSM 04.08 and GSM 09.02
2): This operation is not used by the SGSN
Figure 03.40/18c): Short message transfer attempt failing due to
negative outcome of
VLR information retrieval
SC SMS-IWMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ Access request ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½
½ and possible ½
½ ½ ½ ½
½ authentication 1)
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7a.
Message transfer ½
½ ½ ½
½ & lt; ((((((((((((((((((((((((((((((((((½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 8a.
sendInfoFor-½ ½
½ ½ ½
½ & lt; ((((((((((((((( & gt; ½ ½
½ ½ ½ ½ MO-SMS 2)
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 9. forwardShortMessage ½
½ ½
½ ½ & lt; ((((((((((((((((((((((((((((((((((((½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 9c. Failure report ½
½ ½
½ ½ - - - - - - - - - - - - - - - - - - & gt; ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7c.
Failure report ½
½ ½ ½ ½ - - - - - - -
- - - - - - - - - - & gt; ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
& lt; ((((((((( & gt; : Successful operation invocation or message transfer
including report
- - - - & gt; : Error report
NOTES:
1): Described in GSM 04.08 and GSM 09.02
2): This operation is not used by the SGSN
Figure 03.40/18d): Short message transfer attempt failing due to error
at the SMS-IWMSC
SC SMS-IWMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ Access request ½
½ ½ ½ ½
½ & lt; ((((((((((((((( & gt; ½
½ ½ ½ ½
½ and possible ½
½ ½ ½ ½
½ authentication 1)
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7a.
Message transfer ½
½ ½ ½
½ & lt; ((((((((((((((((((((((((((((((((((½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 8a.
sendInfoFor-½ ½
½ ½ ½
½ & lt; ((((((((((((((( & gt; ½ ½
½ ½ ½ ½ MO-SMS 2)
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 9. forwardShortMessage ½
½ ½
½ ½ & lt; ((((((((((((((((((((((((((((((((((((½
½ ½
½ ½ ½ ½
½ ½
½ 10a. Message ½ ½ ½
½ ½
½ & lt; ((((((((((((((((½ ½ ½
½ ½
½ transfer ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ 10c. Failure ½ ½ ½
½ ½
½ - - - - - - - - & gt; ½ ½ ½
½ ½
½ report ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ 9c. Failure report ½
½ ½
½ ½ - - - - - - - - - - - - - - - - - - & gt; ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½ 7c.
Failure report ½
½ ½ ½ ½ - - - - - - -
- - - - - - - - - - & gt; ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
& lt; ((((((((( & gt; : Successful operation invocation or message transfer
including report
- - - - & gt; : Error report
NOTES:
1): Described in GSM 04.08 and GSM 09.02.
2): This operation is not used by the SGSN
Figure 03.40/18e): Short message transfer attempt failing due to error
at the SC
Operation 7: Message transfer MS - & gt; MSC or MS - & gt; SGSN
The operation is used to transfer a short message from the MS to the MSC
or to the SGSN.
Operation 8: sendInfoForMO-SMS
The operation provides a means for the MSC to verify from the VLR that
the mobile originated short message transfer does not violate
supplementary services invoked or restrictions imposed using the network
feature Operator Determined Barring.
A successful VLR response carries the MSIsdn of the originating MS being
transferred to the SC at SM-RL.
NOTE: This operation is not used by SGSN.
Operation 9: forwardShortMessage
The operation provides a means for the MSC or for the SGSN to transfer a
short message to the SMS-IWMSC.
The procedure is required if the serving MSC or SGSN cannot access the
SC directly, e.g. because it has no connection to SC (see clause 5).
The procedure works in tandem with the forwarding of the short message
from the SMS-IWMSC to the SC. Thus, the outcome of the operation
comprises either success, i.e. that the message has been delivered to
the SC; or a failure that may be caused by several reasons, e.g. failure
in the transfer MSC -- & gt; SMS-IWMSC or SGSN -- & gt; SMS-IWMSC, SC does not
comply.
Operation 10: Message transfer SMS-IWMSC - & gt; SC
The operation is used to transfer a short message from an SMS-IWMSC to
an SC, and consists of:
- the transfer of a message containing the TPDU from the SMS-IWMSC to
the SC (see " 10a. Message transfer " in figure 03.40/18); and
- the return of either a " Failure report " (see 10c. in figure 03.40/18)
or a " Delivery report " (see 10b. in figure 03.40/18).
" Failure report " is returned to the MS when the SMS-IWMSC has received
indication from the network or the SC that the procedure was
unsuccessful.
10.3 Alert transfer
The entities involved in this procedure are depicted in figure 03.40/19.
Figure 03.40/19: Interfaces involved in the Alert procedure. X is the
interface between an SC and
an MSC as defined in section 5
This procedure consists of the operations shown in figure 03.40/20.
Three cases are distinguished:
- the MS becomes reachable when the MNRF, MNRG or both are set but the
MCEF is not set (figure 03.40/20a);
- the MS becomes reachable when the MNRF, MNRG or both, and the MCEF
are set (figure 03.40/20b);
- the MS notifies the network that it has memory available to receive
one or more short messages when the MCEF is set (figure 03.40/20c).
The operations between MSC and VLR, between HLR and VLR or SGSN and
between HLR and SMS-IWMSC are specified in GSM 09.02. The operation
between MS and MSC or SGSN is specified in GSM 04.11. References to
specifications of other operations are given in clause 4.
SC SMS-IWMSC HLR MSC
VLR or SGSN MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ 11. ReadyForSM
½ ½
½ ½
½ & lt; ((((((((((((((((((((((((((((((((((( ½ ½
½ ½ ½ ½ (MS reachable)
1) ½
½ ½ ½ ½
½ ½
½ ½12. alertService- ½ ½
½ ½
½ ½ & lt; ((((((((((((((((( ½ ½
½ ½
½ ½ Centre ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½13. Service- ½ ½ ½
½ ½
½ & lt; (((((((((((((((( ½ ½ ½
½ ½
½ CentreAlert ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
NOTE:1): In case ReadyForSM is sent by the SGSN, the reason may be MS
reachable via the SGSN, or MS reachable via the SGSN and the MSC (see
GSM 03.60).
Figure 03.40/20a: The alert procedure when the MS becomes reachable,
MNRF, MNRG or both are set and MCEF is not set
SC SMS-IWMSC HLR MSC VLR
or SGSN MS
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ 11. ReadyForSM
½
½ ½
½ & lt; ((((((((((((((((((((((((((((((((((( ½ ½
½ ½ ½ ½ (MS
reachable) 1) ½
((((((((( & gt; : Operation invocation or message transfer
NOTE:1): In case ReadyForSM is sent by the SGSN, the reason may be MS
reachable via the SGSN, or MS reachable via the SGSN and the MSC (see
GSM 03.60).
Figure 03.40/20b: The alert procedure when the MS becomes reachable,
MNRF, MNRG or both are set and MCEF is set
SC SMS-IWMSC HLR MSC or SGSN
VLR MS
½ ½ ½ ½
½ ½
½ ½ ½ ½ ReadyForSM
½ ½
½ ½ ½ 14.
(smMemoryCapacityAvailable) 1) ½
½ ½
½ & lt; (((((((((((((((((((((((((((((((((((((((((((((((((((( & gt; ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½12. alertService- ½ ½
½ ½
½ ½ & lt; (((((((((((((((((½ ½
½ ½
½ ½ Centre ½ ½
½ ½
½ ½ ½ ½
½ ½
½13. Service-½ ½ ½ ½
½
½ & lt; ((((((((((((((((½ ½ ½
½ ½
½ Centrealert ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
½ ½ ½ ½
½ ½
((((((((( & gt; : Operation invocation or message transfer
& lt; ((((((((( & gt; : Successful operation invocation or message transfer
including report
NOTE:1): Described in GSM 04.11 and GSM 09.02.
Figure 03.40/20c; The alert procedure when the MS notifies the network
that it has
memory available to receive one or more short messages and MCEF is set
Operation 11: ReadyForSM (MS reachable)
The operation provides a means to transfer alert information from VLR or
SGSN to HLR.
The procedure is activated when the VLR or the SGSN detects that the MS
is active, i.e. when the MS responds to a paging request.
Operation 12: alertServiceCentre
The operation provides a means to transfer alert information from HLR to
MSC.
Operation 13: ServiceCentrealert
The operation provides a means to transfer alert information from an
SMS-IWMSC to an SC.
The operation consists of transfer of a message ( " RP-ALERT-SC " ) from the
SMS-IWMSC to the SC.
Operation 14: ReadyForSM (smMemoryCapacityAvailable)
The operation provides a means for the MS to notify the network that it
has memory available to receive one or more short messages.
The following applies if the memory capacity available notification flag
is implemented in the SIM.
The operation consists of transfer of a message
( " RP-SM-MEMORY-AVAILABLE " ) from the MS to the HLR, and the return of an
acknowledgement to the MS. When the MS rejects a short message due to
lack of available memory capacity the need to transfer notification
shall be stored in the SIM. After a attempt to transfer the
RP-SM-Memory-Available message the following applies:
If the MS receives a positive acknowledgement it will unset the memory
capacity exceeded notification flag in the SIM and exit this procedure.
If the MS receives a negative acknowledgement indicating a permanent
failure condition (as specified in GSM 04.11) it will unset the memory
capacity exceeded notification flag in the SIM and exit the procedure.
If the MS receives a negative acknowledgement indicating a temporary
failure condition (as specified in GSM 04.11) or receives no
acknowledgement or an indication of failure by lower layers, it will
repeat the attempt to transfer the message in accordance with procedures
defined in GSM 04.11. If these repeat procedures fail, the mobile will
unset the memory capacity exceeded notification flag in the SIM and exit
this procedure.
If memory capacity has become available because memory is cleared, the
value of the memory capacity exceeded notification flag is read. If the
flag is set, the MS notifies the network that memory capacity is now
available as described above.
When the mobile is powered up or the SIM is inserted, the mobile shall
check the memory capacity exceeded notification flag in the SIM; if the
flag is set and the SIM has memory available to receive a short message
the mobile shall attempt to notify the network that it has memory
available, as described above.
11 Mapping of error causes between RP layers
This clause describes the interworking between the relay layers on the
radio interface (i.e. between the servicing MSC/SGSN and the mobile
station), and within the network (i.e. between servicing MSC/SGSN, VLR,
HLR, or GMSC).
11.1 Mobile Terminated short message transfer
If errors are indicated by the VLR after invocation of the
" sendInfoFor-MT-SMS " operation, the appropriate error information is
returned to the SMS-GMSC in a failure report as specified in GSM 09.02
(negative outcome of " forwardShortMessage " see section 10),
If errors are detected by the MSC or by the SGSN during the transfer on
the radio interface, the error cause returned in the return error of the
MAP procedure ForwardShortMessage shall be set as follows:
Failure at the MSC or SGSN Return error to be included in the MAP-proc
RP-ERROR message with error cause:
22 Memory capacity exceeded SM_DeliveryFailure with
cause " MemoryCapacityExceeded " 1)
Other error causes SM_DeliveryFailure with
cause " equipmentProtocolError " 1)
CP or lower layer error SM_DeliveryFailure with
(e.g. RR, layer 2 failure)2) cause " equipmentProtocolError " 1)
Mobile has no SM capability SM_DeliveryFailure with
cause " equipmentNotSM-Equiped " 1)0
TR1N timeout 2) SM_DeliveryFailure with
MNSMS-error-ind (No SAPI 3) cause " equipmentProtocolError " 1)
1) For definition of MAP error SM_DeliveryFailure and its parameter
" cause " see GSM 09.02.
2) The error causes of the RP-ERROR message, the CP layer and timer TR1N
are defined in
GSM 04.11.
11.2 Memory available notification
If errors are indicated by the HLR (via the VLR or the SGSN) after
invocation of the " ReadyForSM " operation, the MSC or the SGSN shall
return the appropriate error information to the MS in a failure report
(i.e. a RP-ERROR message) containing the following error cause:
Return error from ReadyForSM
(Alert Reason is " memory available " ) Cause value in the RP-ERROR message
DataMissing
UnexpectedDataValue
UnknownSubscriber
FacilityNotSupported
System Failure 38 Network out of order
38 Network out of order
30 Unknown Subscriber
69 Requested facility not implemented
38 Network out of order
Local or lower layer failure
(e.g. reject condition, timer expired or transaction abort) 38 Network
out of order
NOTE: The coding and the use of the RP-ERROR message is specified in
GSM 04.11.
11.3 Mobile Originated short message transfer
If errors are indicated by the VLR after invocation of the
" sendInfoForMO-SMS " operation.(see section 10), the MSC shall return the
appropriate error information to the MS in a failure report (i.e. a
RP-ERROR message) containing the following error cause:
Return error from SendInfoForMO-SMS Cause value in the RP-ERROR message
DataMissing 38 Network out of order
UnexpectedDataValue 38 Network out of order
TeleserviceNotProvisioned 50 Requested facility not subscribed
CallBarred
- barringServiceActive 10 Call barred
- operatorBarring 8 Operator determined barring
NOTE: The coding and the use of the RP-ERROR message is specified in
GSM 04.11.The operation SendInfoForMO-SMS is not used by the SGSN.
If errors are indicated by the SMS-IWMSC (negative outcome of the
" forwardShortMessage),) the MSC or the SGSN shall send a failure report
(i.e. a RP-ERROR message) to the MS, with the error cause coded as
follows:
Return error from ForwardShortMessage Cause value in the RP-ERROR
message
DataMissing 38 Network out of order
FacilityNotSupported 69 Requested facility not implemented
UnexpectedDataValue 38 Network out of order
SM-DeliveryFailure 1 Unassigned number
cause: unknownSC
SM-DeliveryFailure 42 Congestion
cause: SC-Congestion
SM-DeliveryFailure 21 Short message transfer rejected
cause: invalidSME-Addr
SM-DeliveryFailure 28 Unidentified subscriber
cause: subscriberNotSC-Subscriber
Local or lower layer failure 38 Network out of order
(e.g. reject condition,
timer expired or transaction abort)
NOTE: The coding and the use of the RP-ERROR message is specified in
GSM 04.11.
Annex A (informative):
Protocol stacks for interconnecting SCs and MSCs
No mandatory protocol between the Service Centre (SC) and the Mobile
Switching Centre (MSC) below the transfer layer is specified by GSM;
this is a matter of agreement between SC and PLMN operators.
Some example protocols are provided in GSM 03.47 to assist SC and PLMN
operators. These are based on the following principles, which SC and
PLMN operators are recommended to follow even if they choose not to use
one of the examples given in GSM 03.47:
The protocol(s) between SC and MSC below transfer layer should:
a) provide the service defined for SM-RL (see Section 9.3);
b) be based on widely accepted telecommunications protocols in the
public domain;
c) permit open interconnection.
Annex B (informative):
Information now contained in GSM 03.38
Annex B held information that is now contained in GSM 03.38.
Annex C (informative):
Short message information flow
The diagrams in this annex describe the flow of primitives and
parameters during the short message transfer. These diagrams refer to
specifications GSM 03.40, 04.11 and 09.02. The parameters in dotted
lines are optional. The abbreviations used in diagrams are listed below.
The relevant specifications are given in parentheses. (*) stands for a
common GSM abbreviations and (-) for a general abbreviation.
CM Call Management (*)
CS CauSe (-)
DA Destination Address (-)
DCS Data Coding Scheme (03.40)
DI Dialogue Identifier TCAP
GMSCA Gateway MSC Address
GPRS General Packet Radio Services (03.60)
HLR Home Location Register (*)
IMSI International Mobile Subscriber Identity (*)
MAL MSIsdn-Alert (03.40)
MMS More Messages to Send (03.40)
MR Message Reference (03.40)
MS Mobile Station (*)
MSC Mobile services Switching Centre (*)
MSCA MSC Address
MSI Mobile waiting Set Indication (03.40)
MSIsdn Mobile Station ISDN number (*)
MSM More Short Messages (09.02)
MSRN Mobile Station Roaming Number (*)
MT Message Type (04.11)
MTI Message Type Indicator (04.11)
MWS Message Waiting Set (03.40)
OA Originating Address (-)
OC Operation Code (09.02)
PCI Protocol Control Information (-)
PDI Protocol DIscriminator (*)
PRI PRIority (03.40)
RCT ReCeption Time (03.40)
REA REcipient Address (03.40)
RL ReLay function (04.11)
RP Reply Path (03.40)
SC Service Centre (03.40)
SCA Service Centre Address (03.40)
SCTS Service Centre Time Stamp (03.40)
SGSN Serving GPRS Support Node (03.0)
SM Short Message (03.40)
SM-AL Short Message Application Layer (03.40)
SME Short Message Entity (03.40)
SMI Short Message Identifier (03.40)
SM-RL Short Message Relay Layer (03.40, 04.11)
SMS-GMSC Short Message Service Gateway MSC (03.40)
SMS-IWMSC Short Message Service Interworking MSC (03.40)
SoR Status of Report (03.40)
SM-TL Short Message Transfer Layer (03.40)
SRI Status Report Indication (03.40)
SRR Status Report Request (03.40)
ST STatus (03.40)
TCAP Transaction Capabilities Application Part (-)
TID Transaction Identifier (*)
UD User Data (-)
UDL User Data Length (03.40)
VLR Visitor Location Register (*)
VP Validity Period (03.40)
VPF Validity Period Format (03.40)
NOTE: SMI is not carried via SM-RL of section 9.3.5 but is carried via
the relay service between the SC and GMSC (see section 9.3.4.1).
Figure 1.1: Mobile terminated short message
NOTE: A sequence of short messages will have MMS set to 1 in each
RP-MT-DATA except the last (last will have MMS set to 0). Each
RP-MT-DATA will be carried via FORWARD SHORT MESSAGE via TCAP and will
be assigned the same Dialogue Identifier as previous RP-MT-DATAS in the
sequence.
Figure 1.2: Mobile terminated short message
NOTE: MR is of local significance to the MSC/MS interface and is not the
value supplied to the MSC
Figure 1.3: Mobile terminated short message
Figure 1.4: Mobile terminated short message
Figure 2.1: Acknowledgement in the MT case
NOTE: The cause carried via UD of TCAP is not the cause supplied via
RP-ERROR but is the cause resulting from application of the mapping
specified by table 8.5 of 04.11.
Figure 2.2: Acknowledgement in the MT case
NOTE 1: The MAP operation " SetMessageWaitingData " is invoked only if a
cause " Absent Subscriber " is carried in TCAP UD.
NOTE 2: The cause delivered to the SC is not necessarily the cause
carried via TCAP but is one of the set specified by table 03.40/1.
Figure 2.3a: Acknowledgement in the MT case
Figure 2.3b: Acknowledgement in the MT case
NOTE: The mapping of SMI to MR by the MS is a local matter.
Figure 3.1: Mobile originated short message
Figure 3.2: Mobile originated short message
NOTE: MR is of local significance to the IWMSC/SC interface and is not
the value supplied by the MS via the MS/MSC interface
Figure 3.3: Mobile originated short message
Figure 3.4: Mobile originated short message
Figure 4.1a: Acknowledgement in the MO case
Figure 4.1b: Acknowledgement in the MO case
Figure 4.2: Acknowledgement in the MO case
Figure 4.3: Acknowledgement in the MO case
Annex D (informative):
Mobile Station reply procedures
D.1 Introduction
The reply procedures specified in this annex should be followed by a
mobile station when replying to a short message, i.e. when generating a
MO SM in response to a received MT SM, addressed to the originator of
that MT SM. The main purpose of this annex is to specify how the MS
selects the service centre for delivering that MO SM: an arbitrary SME
may only be reached by submitting the reply SM to a specific SC, known
to be able of delivering to that SME.
D.2 The scope of applicability
The reply procedures in sections 5 and 6 of this annex should be
followed by every MS which fulfils the following criteria:
1) The MS automatically selects the value for the RP-Destination-Address
parameter in RP-MO-DATA, or the MS has the SC address within the SM-RL
entity. (That is to say: the human user is not obliged to manually key
in the SC address for every MO short message).
2) The MS or an application within it supports some form of replying to
a MT SM with a MO SM. (That is to say: in the process of generating the
reply MO SM, any reference whatsoever, implicit or explicit, is made to
the original MT SM.).
3) The replying support of (2) is to be equally available towards every
SME.
When an SME submits an SM to an SC for delivery, it may request that the
SC sets the TP-Reply-Path parameter in the SM to be delivered. If the
submitting SME is an MS, the reply path requesting procedure; in
section 4 of this annex may be applied. However, an SC may support the
reply procedures without supporting the reply path requesting procedure;
in that case, the SC sets the TP-Reply-Path parameter on another basis,
which must be the case if the SM originates from an SME which is not an
MS.
D.3 Terminology
An originating SME submits an original SM to an original SC, which
delivers the original MT SM to a replying MS. The replying MS sends back
a reply MO SM, a MO SM which is generated (automatically or by human
operations) in response to the original MT SM, and which is addressed to
the originating SME.
If the originating SME is an MS, the original MT SM is submitted within
an SMS-SUBMIT PDU; we say that reply path is requested if the
TP-Reply-Path parameter is set in the SMS-SUBMIT PDU of the original MT
SM.
We say that reply path exists if the TP-Reply-Path parameter was set in
the SMS-DELIVER PDU of the original MT SM; we say that reply path does
not exist otherwise.
The replying MS may have a default SC which is normally used for
delivering all the MO short messages originated from the replying MS.
Alternatively, a human user or automatic application may specify a
selected SC for delivering a particular SM (thus the term selected SC
refers to an SC address selected for one short message only).
D.4 The reply path requesting procedure
The discussion in this section applies to cases when the originating SME
is a mobile station only. The reply procedures discussed in the sections
to follow this one are independent of the type of the originating SME.
The reply path is requested by the originating SME (an MS) by setting
the TP-Reply-Path parameter in the SMS SUBMIT PDU of the original SM. If
the original SC supports reply path requesting for the originating SME
(an MS), it will take notice of the TP-Reply-Path parameter in the
SMS-SUBMIT PDU and set the TP-Reply-Path parameter in the SMS-DELIVER
PDU of the original MT SM towards the replying MS. Hence, reply path
exists for the replying MS towards the originating SME (an MS).
D.5 The reception of an original MT SM
When a replying MS receives an original MT SM, it then has
1) originating SME = TP-Originating-Address in the SMS-DELIVER PDU,
2) original SC = RP-Originating-Address in RPS-MT-DATA, and
3) reply path exists / reply path does not exist = TP-Reply-Path in
SMS-DELIVER PDU (set / not set).
D.6 The submission of the reply MO SM
According to section 5, the replying MS knows if
a) reply path exists or
b) reply path does not exist.
We then specify that when submitting the reply MO SM, the replying MS
should use parameters as follows:
1) TP-Destination-Address in SMS-SUBMIT PDU = originating SME,
2a) If reply path exists:
RP-Destination-Address in RP-MO-DATA = original SC,
2b) If reply path does not exist:
RP-Destination-Address in RS-MO-DATA = selected SC or default SC or
original SC,
3a) If reply path exists:
after submitting one reply MO SM, the reply path does not exist any
more.
In case (2b), it is allowed to use the original SC or the default SC,
but then there is no guarantee that the original/default SC will deliver
the reply MO SM. (The original SC may refuse to deliver, if the replying
MS is not its subscriber; the default SC may be unable to deliver, if it
has no access path to the originating SME.)
Requirement (3a) states that the case (a), reply path exists, holds for
one reply MO SM only (per original MT SM).
D.7 Usage of SCs for replying
The specification in this annex supports the following way of replying.
The original MT SM and the reply MO SM are delivered by the same SC, the
original SC. This principle maximizes the probability that the SC can
e.g. route the reply MO SM to the proper data network for reaching the
originating SME; this principle is a must, if the originating SME is
integrated within the original SC.
If the original SC by any means whatsoever knows that it is both willing
and able to deliver one (potential) reply MO SM, it may indicate this
fact by setting the TP-Reply-Path parameter in the original MT SM. The
original SC thus commits itself to delivering one reply MO SM; let us
call this reply delivery commitment.
One reason for the SC to make the reply delivery commitment may be the
reply path requesting procedure specified in section 4 on this annex.
The reply path commitment is not valid forever, but the original SC pay
have e.g. a time limit for maintaining this commitment.
D.8 Replying possibilities for Phase 1 mobile stations
The Phase 2 mobile stations should support the procedures in this annex
(if they fulfil the criteria in section 2 of it). Yet, Phase 1 mobile
stations, too, may apply steps (1) and (2a) in section 6 of this annex,
i.e. reply via the original SC, automatically or manually (by choosing
selected SC = original SC), despite the fact that the TP-Reply-Path
parameter will be ignored by them. The delivery of the reply MO SM
cannot be guarantied in this case, yet the possibility of delivery may
be improved (especially if the originating SME is not an MS.)
D.9 The resulting service for originating SMEs
As the consequence of the replying procedures specified in this annex,
all SMEs and applications within them may assume that replying from all
mobile stations is always possible, provided that the mobile stations do
support the proper replying mechanism itself (human response in context
with the original MT SM, automatic replying by an application,
application level protocols, etc.).
Annex E (informative):
Change History
SMG# TDoc SPEC VERS CR REV PHASE CAT SUBJECT NEW_VERS WORKITEM
s23 97-696 03.40 5.7.0 A060
R97 B Code points for SIM Toolkit secure messaging
Draft 1.0 of V6.0.0 (PT SMG internal) 6.0.0d1.0 SIM Toolkit Security
s23 97-696 03.40 5.7.0 A062
R97 F User Data Header Indicator
Draft 1.0 of V6.0.0 (PT SMG internal) 6.0.0d1.0
s23 97-706 03.40 5.7.0 A063
R97 B SMS transfer over GPRS
Draft 1.0 of V6.0.0 (PT SMG internal) 6.0.0d1.0 GPRS
s24 97-918 03.40 5.7.0 A064
R97 B Security headers
Draft 2.0 of V6.0.0 (PT SMG internal) 6.0.0d2.0 SIM Toolkit Security
s24 97-918 03.40 5.7.0 A065
R97 B Transmission of the SME OA
Draft 2.0 of V6.0.0 (PT SMG internal) 6.0.0d2.0 SMS Enh.: Filtering
s25 98-096 03.40 5.7.0 A066
R97 B MS Management PID R97 6.0.0 MS Management
History
Document history
December 1995 Publication of Version 5.0.0
March 1996 Publication of Version 5.1.0
May 1996 Publication of Version 5.2.0
July 1996 Publication of Version 5.3.0
November 1996 Unified Approval Procedure UAP 58: 1996-11-18 to
1997-03-14
April 1997 First Edition
May 1997 One-step Approval Procedure OAP 9735: 1997-05-02 to 1997-08-29
(Second Edition)
August 1997 One-step Approval Procedure OAP 9852: 1998-08-28 to
1998-12-25
(Third Edition)
March 1998 Not for Publication
PAGE
styleref ZA Draft EN (GSM 03.40) V6.0.0 (1998-03)
PAGE 50
styleref ZGSM GSM 03.40 version 6.0.0
Page PAGE 120
Draft prETS 300 901 (GSM 03.40 Version 6.0.0): March 1998
Page PAGE 108
Draft prETS 300 901 (GSM 03.40 Version 6.0.0): March 1998
Page PAGE 124
Draft prETS 300 901 (GSM 03.40 Version 6.0.0): March 1998
Page PAGE 113
Draft prETS 300 901 (GSM 03.40 Version 6.0.0): March 1998
CD
CF
TP-UDH
Final segment
Intermediate segments
CD
TP-UDH
CD
CH
TP-UDH
Compression Footer
Compressed Data (CD)
Compression Header HHeannder Header
Segmentation / De-segmentation
First segment
This file was downloaded/obtained from:
---------------------------------------
GSM Traders Group
http://software-gsm.prv.pl
soft@gsm.w.pl
We have:
--------
* newest solutions and hotest programs on the WORLD
* free section download with TOP 20 GSM programs
* free section download with user manual (only PL)
* membership option with 24h access to ALL programs
that you can see in our service WEB (2Mbit/s access)
* GSM CD for sell (with ALL programs that we have in
our service on WEB -over 700 Mb recorded on 80min CD-R)
* cables to connect yours cellphone to PC ! From now you
may upload logos, tones and at least UNLOCK cellphones
* universal cable which supports most phones in the world
Don't waste your time - VISIT and BUY NOW !
--
Our official World Wide Web page : http://software-gsm.prv.pl
For inf. about programs/solutions : soft@gsm.w.pl
For inf. about deliver & payment con.: info@software-gsm.prv.pl
For sales subject you can mail to : sales@software-gsm.prv.pl