`Date
`Issued by
`
`: January 1994
`: ETSI/PTIZ
`
`UPDAifl NOTE
`
`Recommendation GSM 03.40
`
`Technical Realization of the SMS Point-to-Point
`
`New updated version January 19941
`
`Released version 1/90:
`Corrected Release version 1/90:
`Updated version January 1991:
`Updated version October 1993:
`
`1. Reason for Change
`
`Change Request 03.40-72 for GSM Phase 1 - approved at SMG#9
`included.
`‘
`
`—
`
`is
`
`2. Details of Change
`
`Page 28 has been changed and shall be replaced by the attached
`updated page marked with the new version number
`and
`"Updated
`October~ 1993“.
`The
`front sheet of
`the recommendation. has also
`been updated to highlight the new version number.
`
`(a list
`the attached 'Document Change Control Record‘
`In addition,
`with the "history" of
`the recommendation)
`should be appended to
`the recommendation, and PT12 will update it when necessary.
`
`3. Instructions to update GSM Recommendation
`
`old pages
`
`to remove
`no. of sheet2 new pages
`
`to insert
`no.0f sheets
`
`Document
`
`
` 27 and 28
`
`Change
`Control
`Record
`
` _ _l.....and _ 2.. __
`_
`__
`.1...s¥.1¢.___?_—‘.
`
`27 and 28
`
`1) To be inserted after Release Note
`
`The version 3.6.0 together with these changes constitutes version
`3.7.0.
`
`1
`
`GOOGLE 1027
`
`GOOGLE 1027
`
`1
`
`
`
`2
`
`
`
`ETSI/TC sue
`Date
`
`: October 1993
`
`Issued by
`
`: ETSI/PT 12
`
`DOCUMENT CHANGE CONTROL RECORD
`
`Recommendation GSM 03.40
`
`New Updated version January 1994: 3.7.0
`
`Technical Realization of the SMS Point—to-Point
`
`Released version 1/90: 3.4 0
`Corrected Release version 1/90: 3.4.1
`Updated version January 1991: 3.5 0
`Updated version October 1993: 3.6.0
`
`Page:
`Doc
`Decided Pages
`Subject
`
`
`
`Marked GEMat affected
`
`Change Request
`
`N° GSM 03.40—72
`
`SMG#9
`
`42/94
`
`28
`
`END OF DOCUMENT CHANGE CONTROL RECORD
`
`3
`
`
`
`4
`
`
`
`GSM 03.40 - version 3.7.0 - page 1
`Updated January 1994
`
`EHSI/GSM
`
`lgsued by:
`
`ETSI PT12
`
`_§L§:
`
`January 1994
`
`Recommendation :
`
`GSM 03.40
`
`Title:
`
`TECHNICAL REALIZATION OF THE SHORT MESSAGE SERVICE
`— POINT—TO—POINT
`
`_ist of contents:
`
`0. Scope
`1. Introduction
`2 Definitions and abbreviations
`na
`3 Services and service elements
`4. Network Architecture
`5. Service Centre and PLMN interconnection
`Service Centre functionality
`MS functionality
`. MSC functionality
`. Protocols and protocol structure
`0. Procedures within the point—to—point services
`
`6 7 B 9 1
`
`Annex 1: A protocol stack for interconnecting SCs and MSCs
`Annex 2: Default alphabet, and coding scheme
`Annex 3: Short message information flow
`
`griginal language: English
`
`finmber of pages:
`
`100
`
`5
`
`
`
`GSM 03.40 — version 3.6.0 ~ page 2
`
`THIS PAGE DOES NOT CONTAIN ANY TEXT
`
`6
`
`
`
`GSM 03.40 — version 3.6.0 « page 27
`
`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.
`
`representation and
`and bit
`Below is given an example of octet
`transmission order of an integer represented field.
`
`the complete octet no 6 and
`the 2 rightmost bits of octet no 5,
`Let
`7, and the 3
`leftmost bits of octet no 8 represent an integer, as
`shown in Figure 03.40/8.
`
`a)
`
`Oct.no.
`
`7
`
`6
`
`5
`
`4
`
`3 I
`
`2
`
`l
`
`0
`
`
`5 m%
`6 EEE
`
`7126 7195
`'7
`
`8b? shea“
`8
`
`
`
`
`
`
`3)
`
`5b1 5b0 5b7 6b6 -
`
`-
`
`-
`
`-5b1 6bo 7b7 7b6 -
`
`-
`
`-
`
`-7b1 7b0 3b7 abs abs
`
`r)
`
`
`
`5b0 5b1 5b2 5b3 5b4 5b5 5b6 5b7 6b0 6b1 5b2 6b3 6b4 6b5 6b5 6b? t
`
`> 7b0 7b1 ibz 7b3 7b4 7b5 7b6 7b7 abo 8b1 8b2 8b3 8b4 3b5 3b6 8b7
`
`t
`
`*)
`
`: Bits not representing the integer.
`
`Figure 03.40/8.
`
`in a
`and 8
`7,
`6,
`21 bits from the octets 5,
`short message a) will
`represent an integer as
`ShOWn in E}, and will be transmitted in an order
`as shown in r).
`
`7
`
`
`
`GSM 03.40 — version 3.7.0 - page 28
`Updated January 1994
`
`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 represent
`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 represent 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 should always be set to '1111'.
`\
`
`Below is given an example:
`
`Octet no:
`
`I n+2
`
`n+3
`
`9.1.2.4 Address.fields
`
`Address
`09.02.
`
`fields used. by'
`'
`
`SM—RL are specified in TS GSM 04.11 and
`
`"each 'address"fieldf'Of 'the' SMéTL “conSistS”'of"”thE”'folIOWing””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:
`
`8
`
`
`
`ETSI/TC SMG
`Date
`
`Issued by
`
`October 1993
`ETSI/PT 12
`
`u.-
`
`ornate NOTE
`
`Recommendation GSM 03.40
`
`New Updated version October 1993: 3.6.0
`
`Technical Realization of the SMS Point-to—Point
`
`3.4.0
`Released version 1/90:
`Corrected Release version 1/90: 3.4.1
`3.5.0
`Updated version January 1991:
`
`1. Reason for Change
`
`Change Request 03.40—70rev1 for GSM Phase 1
`is‘included.
`
`- approved at SMG#8
`
`-
`
`2. Details of Change
`
`Page 43 has been changed and shall be replaced by the attached
`updated page marked with the new version number
`and
`"Updated
`October 1993".
`The
`front sheet of
`the recommendation has also
`been updated to highlight the new version number.
`
`{a list
`the attached 'Document Change Control Record'
`In addition,
`with the "history" of
`the recommendation)
`should be appended to
`the recommendation, and PT12 will update it when necessary.
`
`3. Instructions to update GSM Recommendation
`
`old pages
`
`to remove
`no. of sheetn new pages
`
`to insert
`no.of sheets
`
`Document
`
`Change
`Control
`Record
`
`..l and. .2
`
`
` _
`
`43 and 44
`
`1) To be inserted after Release Note
`
`The version 3.5.0 together with these changes constitutes version
`3.6.0.
`
`9
`
`
`
`10
`
`10
`
`
`
`ETSI/Tc SMG
`Date
`Issued by
`
`: October 1993
`ETSI/PT 12
`
`DOCUMENT CHANGE CONTROL RECORD
`
`Recommendation GSM 03.40
`
`.0
`
`Technical Realization of the SMS Point-to-Point
`
`0 l 0
`
`Released version 1/90: 3.4.
`Corrected Release version 1/90: g.:.
`Updated version January 1991:
`New Updated version October 1993: 3.6
`
`Subject
`
`Decided Pages
`at
`Marked
`
`Doc
`GSM
`
`Pages
`affected
`
`M C
`
`hange Request
`
`N° GSM 03.40—70rev1 SMG#8
`
`699/93
`
`43
`
`END OF DOCUMENT CHANGE CONTROL RECORDM
`
`11
`
`11
`
`
`
`12
`
`12
`
`
`
`GSM 03.40 — version 3.6.0 — page 1
`Updated October 1993
`
`ETSI/GSM
`
`Issued by:
`
`ETSI PT12
`
`
`Date:
`
`October 1993
`
`Recommendation :
`
`GSM 03.40
`
`Title:
`
`TECHNICAL REALIZATION OF THE SHORT MESSAGE SERVICE
`- POINT—TO-POINT
`
`List of contents:
`
`Scope
`Introduction
`Definitions and abbreviations
`Services and service elements
`Network Architecture
`Service Centre and PLMN interconnection
`Service Centre functionality
`MS functionality
`MSC functionality
`. Protocols and protocol structure
`0. Procedures within the point-to-point Services
`
`HmmflmlfirP-MNHO
`
`Annex 1: A protocol stack for interconnecting SCs and MSCs
`Annex 2: Default alphabet, and coding scheme
`Annex 3: Short message information flow
`
`Original language: English
`
`Number of pages:
`
`100
`
`13
`
`13
`
`
`
`GSM 03.40 — version 3.5.0 — page 2
`
`THIS PAGE DOES NOT CONTAIN ANY TEXT
`
`14
`
`14
`
`
`
`GSM 03.40 — version 3.6.0 ~ page 43
`Updated October 1993
`
`Note that for the straightforward case of simple MS-t0*SC or SC-to-
`MS short message transfer the Protocol Identifier field is set
`to
`the value 0.
`
`9.2.6.8. TP-Data-Codin —Scheme
`
`TPwDCS
`
`The TP—Data—Coding—Scheme field indicates the data coding scheme of
`the TP—UD
`field. The TP-Data—Coding-Scheme may possess
`integer
`values in the range 0 to 255.
`
`the TP‘UD consists of alphabet
`indicates that
`The default value 0
`given in Annex 2, without parity, and shall be supported by all M85
`and SCs offering the service.
`
`The characters of the message are packed in octets as precised in
`Annex 2, and consist of up to 160 characters.
`
`Other values are reserved, but if these are allocated,
`additional to the default value.
`
`they shall be
`
`9.2.6.9.
`
`’TP-Service-Centre—Time“Stamp (TP—SCTS)
`
`in semi-octet
`given
`field is
`TP—Service—Centre-Time—Stamp
`The
`representation, and represents the local time in the following way:
`
`Year
`
`: Month : Day : Hour
`
`: Minute : Second : Time Zone
`
`2
`Digits:
`(Semi—octets)
`
`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).
`
`in this
`coded.
`and. any other 'times
`The Service-Centre-Time-Stamp,
`The Time
`format,
`represents the time local
`to the sending entity.
`time in
`Zone code enables the receiver to calculate the equivalent
`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.
`
`9.2.6.10. TPwValidity—Period
`
`semi~
`The TP—Validity-Period field is given in either integer or
`octet
`representation.
`In the first case,
`the TP—Validity—Period
`comprises 1 octet, giving.the length of the validity period, counted
`from when the SMS—SUBMIT is received by the SC.
`In the second case,
`the TP—Validity-Period comprises 7 octets, giving the absolute time
`of the validity period termination.
`
`15
`
`15
`
`
`
`GSM 03.40 — version 3.5.0 — page 44
`
`In the first case,
`
`the representation of time is as follows:
`
`TP—VP value
`Validity period value
`
`0 to 143
`
`144 to 167
`
`168 to 196
`
`197 to 255
`
`(i.e. 5
`(TP—VP + l) x 5 minutes
`minutes intervals up to 12 hours}
`12 hours +I {{TP—VP ~1:13)
`x‘ 30 minutes)
`
`(TP-VP - 166) x 1 day
`
`(TP-VP - 192) x 1 week
`
`the representation of time is identical to the
`In the second case,
`representation of the TP-Service—Centre-Time—Stamp.
`
`9.2.6.1l. TP-User-Datangngth (TP-UDL!
`
`The TP-User—Data-Length field gives an integer representation of the
`number of characters within the TP—User-Data field to follow.
`
`9.3. Service provided by the SM—RL
`
`9.3.1.
`
`General
`
`service and associated
`This section describes the primitives of
`parameters provided by the SM—RL and used by the SM—TL to offer the
`Short Message Service to the SC and the M5 on the link 1
`(see Figure
`03.40/5).
`
`The service description includes:
`
`- The service definition
`
`- The definition of the primitives
`
`the parameters of
`- The definition of
`options attached to the parameters
`
`the primitives and the
`
`— The definition of the protocol elements
`
`— The definition of the parameters of the protocol elements
`
`— A description of what SM-RL has to provide (in the MS and in
`--the SC) when.receiving or.issuing primitives.
`
`9.3.2.
`
`Service definition
`
`Rec. GSM 04.11 defines the service provided by SM—RL in the MS. The
`figures 03.40/10 to 03.40/13 only give an overview of message
`exchange between SC and MS.
`If discrepancies exist
`in nomenclature
`at the MS side, it is the Rec. GSM 04.11 that will be the reference-
`
`16
`
`16
`
`
`
`ETSI/TC SMG
`Released by : ETSI/PT 12
`Release date: February 1992
`
`RELEASE NOTE
`
`Recommendation GSM 03.40
`
`Technical Realization of the Short Message Service —
`Point-to-Point
`
`(Release 92, Phase 1)
`
`Previously distributed version :
`New Released version February 92 :
`
`3
`3
`
`.5
`
`.0 (Updated Release 1/90)
`0
`.5.
`
`W N
`
`o changes since the previously distributed version.
`
`17
`
`17
`
`
`
`18
`
`18
`
`
`
`ETSI-GSM
`
`Technical
`
`Specification
`
`'
`
`UDC:
`
`621396.21
`
`GSM 03.40
`
`Version 3.5.0
`
`Key words:
`
`European Digitai Cellular Telecommunications System, Global System for Mobile
`Communications (GSM)
`
`European digital cellular
`telecommunication system (phase 1);
`
`Technical Realization of the Short Message Service -
`Point-to-Point
`
`ETSI I
`
`European Telecommunications Standards Institute
`
`.....F.._.O.é§é1.Vélbahhé..Céd.éx..;.F.réhcén
`
`.
`
`..
`
`.
`
`.
`
`..
`
`.
`
`.
`
`..
`
`.
`
`..
`
`..
`
`.
`
`TP.+3392944200 TF.+3393654716 TX.47004OF
`
`
`
`Copyright European Tetecommunications Standards institute 1992.
`All rights reserved.
`
`No part may be reproduced or used except as authorised by contract or other written permission. The
`copyright and the foregoing restriction on reproduction and use extend to all media in which the
`information may be embodied.
`1
`
`19
`
`19
`
`
`
`GSM 03.40 - version 3.5.0 - page 1
`
`ETSI/GSM
`
`BeleaseLbr:
`
`ETSI PT12
`
`Date:
`
`February 1992
`
`Recommendation :
`
`GSM 03.40
`
`Iitle:
`
`TECHNICAL REALIZATION OF THE SHORT MESSAGE SERVICE
`— POINT—TO—POINT
`
`List_ofiloontents:
`
`0. Scope
`1. Introduction
`2. Definitions and abbreviations
`3. Services and service elements
`‘-
`4. Aetwork Architecture
`5. Service Centre and PLMN interconnection
`6. Service Centre functionality
`7. MS functionality
`8. MSC functionality
`9. Protocols and protocol structure
`10. Procedures within the point—toupoint services
`
`Annex 1: A protocol stack for interconnecting $05 and MSCs
`Annex 2: Default alphabet, and coding scheme
`Annex 3: Short message information flow
`
`Qriginal_language: English
`
`Humberiofi_pages:
`
`1D!)
`
`20
`
`20
`
`
`
`GSM 03.40 4 version 3.5.0 - page 2
`
`
`
`THIS PAGE DOES NOT CONTAIN ANY TEXT
`
`
`
`21
`
`21
`
`
`
`GSM 03.40 - version 3.5.0 - page 3
`
`Wm
`
`Scope
`
`Introduction
`
`Definitions and abbreviations
`
`2.1. Key definitions
`
`2.2. Abbreviations
`
`Services and service elements
`
`3.1. Basic services
`
`3.2. Short Message Service elements
`
`3.2.1. Validity-period.
`. Service-Centre-Time—Stamp
`. Protocol-Identifier
`
`. More-Messages-to-Send
`. Priority
`. Message»Waiting
`. Alert-SC
`. Options concerning MWF and MWD
`
`3.3. Unsuccessful short message TPDU transfer SC ~> MS
`
`3.4. Unsuccessful short message TPDU transfer MS —> SC
`
`3.5. Use of Supplementary Services in combination
`with the Short Message Service
`
`Network architecture
`
`4.1. Basic network structure
`
`4.2. Transfer on link 3
`
`Service Centre and PLMN interconnection
`
`5.1. Service Centre connection
`
`
`
`. STZIWRbuting requirements........
`
`mmmmmmw.mm.m
`
`5.2.1.
`5.2.2.
`
`Mobile terminated short message
`Mobile originated short message
`
`10
`
`10
`
`12
`
`12
`12
`12
`12
`13
`13
`14
`15
`
`15
`
`17
`
`17
`
`18
`
`18
`
`19
`
`19
`
`19
`
`20
`20
`
`22
`
`22
`
`
`
`20
`
`20_
`21'
`
`21
`
`21
`
`21
`
`22
`
`22
`
`22
`23
`
`24
`
`24
`25
`
`25
`
`26
`
`26
`
`26
`26
`
`26
`28
`28
`28
`
`3O
`
`30
`31
`32
`
`.H32mnmm
`33
`34
`
`GSM 03.40 - version 3.5.0 — page 4
`
`IAELE_QE_CQNIEHIS_LchILdl
`
`6.
`
`Service Centre functionality
`
`5.1. Service Centre capabilities
`6.2. SC functional requirements
`
`MS functionality
`
`7.1. MS capabilities
`
`7.2. MS configuration
`
`MSC functionaiity
`
`8.1. MSC functionality related to SM MT
`
`8.1.1. Functionality of the sms-GMsc
`8.1.2. Functionality of the MSC
`
`7 8.2. MSC functionality related to SM‘MO
`
`8.2.1. Functionality of the MSC
`8.2.2. Functionality of the SMS—IWMSC
`
`8.3. SMS—IWMSC functionality related to alerting
`
`Protocols and protocol interworking
`
`9.1. Protocol element features
`
`9.1.1 Octet and bit transmission order
`9.1.2. Numeric representation
`
`Integer representation
`9.1.2.1.
`9.1.2.2. Octet representation
`9.1.2.3.
`Semi—octet representation
`9.1.2.4. Address fields
`‘
`
`9.2. Service provided by the SM~TL
`
`1 2
`
`. General
`. Service definition
`3. Definition of primitives
`
`.2. Tszeport
`.3.
`Ts—Submit
`
`9 9 9
`
`23
`
`23
`
`
`
`34
`
`34
`35
`35
`35
`35
`35
`35
`35
`35
`36
`36
`36
`36
`
`36
`
`37
`39
`
`40
`
`4O
`41
`41
`41
`41
`41
`41
`43
`43
`43
`44
`
`44
`
`44
`
`44
`
`48
`
`4B
`48
`49
`n49n...mnm.um “H
`50
`
`GSM 03.40 - version 3.5.0 - page 5
`
`IABLEnDE_CQNIEHIS_L£nnILdl
`
`\D N
`
`Definition of parameters
`
`1 2 3 4 5 6 7 8 9 l 1 l 1
`
`
`
`\DD‘DWtDIDKDQLDLO‘DOKDII:-IIIIII
`
`IIIIIII
`
`NNNNMNMNNNNMNoIIIfiblfitfihhhfihbhhlfi
`
`II
`
`U0IIIIIIIIII
`
`. TS—OriginatingaAddress
`. TS~Service-Centre-Address
`TS-Protocol-Identifier
`Tswnata-Coding-Scheme
`TS-Service«Centre-Time-Stamp
`TSvMessage-Waiting—Set
`TS-Priority
`D.
`. TS—Status-of-Report
`1. TS-More-Messages.to—Send
`2. TS-Validity-Period
`. 3. TS-Short-Message-Information
`
`. TS—Short-Message-Identifier
`. Ts-Destinationahddress
`
`PDU Type repetoire at SM—TL
`
`.2.
`
`5.1.
`.2.5.2.
`
`EMS-DELIVER type
`SMS—SUBMIT type
`
`l
`
`Definition of the TPDU parameters
`
`NNNNNNNNNNN
`
`I._0IImmmmmmmmmmm
`
`III
`
`IIIIIIIlHHUDGNJOUIIFUJNH
`
`(TP~MTI)
`TP—Meseage—Type—Indicator
`TP-More-Messagee-to-Send (TP-MMS)
`TP—Validity-Period-Format
`(TP-VPF)
`TP-Message-Reference (TP-MR)
`TP«Originating-Address (TP—OA)
`TF-Deetination-Address (TP—DA)
`TP-Protoool—Identifier (TP-PID)
`TP-Data—Coding-Scheme (TP—DCS)
`TP«Service»Centre—Time-Stamp (TP—SCTS)
`TP—Validity-Period (TP~VP)
`. TP-Ueer-Data-Length (TP-UDL)
`
`IIIIIII
`Ho.I I
`
`9.3. Service provided by the SM—RL
`
`9.3.1. General
`
`9.3.2. Service definition
`
`9.3.3. Definition of the primitives
`
`9.3.
`
`cameohmomma
`
`wuwwm
`
`mwémmwIl_IIu1p¥nh3H
`
`RS—MT-Data
`RS—MO-Data
`
`-."R$:R§EPIFWWWHNMHmW.H
`RS—Error
`RS-Alert
`
`Definition of parameters
`
`(00301030)
`
`IIIII
`
`nun-end:
`
`(HIP-WNHCO'II
`
`RS-Short-Message—Identifier
`RS-Destination—Addrees
`RS—Originating-Address
`RS-Priority
`Rs—Cause
`
`50
`
`50
`50
`5O
`
`50
`
`24
`
`24
`
`
`
`GSM 03.40 - verSiOn 3.5.0 - page 6
`
`IABLE_QE.00NIEHI$mLcnnILdl
`
`9.3.4.6. RS—Alerting-MS
`9.3.4.7. RS—Messages-Waiting-Set
`9.3.4.8. RS-User—Data
`
`9.3.5. Protocol Element repetoire at SM-RL
`
`9.3.5.1.
`9.3.5.2.
`9.3.5.3.
`9.3.5.4.
`9.3.5.5.
`
`RP-MO-DATA
`RP—MT—DATA
`RP-ACK
`RP-ERROR
`RP-ALERT-SC
`
`'10. Fundamental procedures within the point—to-point SMS
`
`10.1.
`
`Short message mobile terminated
`
`10.2.
`
`Short message mobile originated
`
`10.3.
`
`Alert transfer
`
`'
`
`I
`
`'Annex 1: A protocol stack for interconnecting 505 and MSCs
`
`OJ‘QGU‘HP-DJNH
`
`The transport service
`The session layer protocol
`The presentation layer
`Service elements on the application layer
`SMRSE definition
`Detailed specification of the SMRSE services
`' Application rules for avoiding collision
`Timing terminology
`
`Annex 2: Default alphabet and coding scheme
`
`Annex 3: Short message information flow
`
`51
`51
`51
`
`51
`
`.51
`52
`52
`52
`53
`
`53
`
`54
`
`65
`
`72
`
`74
`
`94
`
`96
`
`25
`
`25
`
`
`
`GSM 03.40 - version 3.5.0 - page 7
`
`0-
`
`SCQEE
`
`the point-to-point Short Message
`recommendation describes
`This
`Service (SMS) of the GSM PLMN system. it defines:
`
`— the services and servica elements,
`- the network architecture,
`- the Service Centre functionality,
`— the MSC functionality (with regard to the SMS),
`- the routing requirements,
`a the protocols and protocol layering,
`
`for the Teleservices 21 and 22, as specified in the Rec. GSM 02.03.
`
`the transfer of short messages
`for
`radio resources
`The use of
`between the MS and the MSC is described in Rec. GSM 04.11 'Point-tc—
`Point Short Message Service Support on Mobile Radio Interface', and
`is dealt with in that recommendation.
`
`The network aspects of Short Message Service provision are outside
`the scope of
`this recommendation (i.e.
`the provision of network
`connectivity between the PLMN subsystems). The required and assumed
`network service offered to the higher‘layers is defined in this
`recommendation.
`
`is a
`The Cell Broadcast Short Message Service (Teleservice 23)
`separate service,
`and is described in Rec. GSM 03.41 'Technical
`Realization of the short Message Service — Cell Broadcast'.
`
`l.
`
`INIBQDHCIIQN
`
`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.
`
`26
`
`26
`
`
`
`GSM 03.40 - version 3.5.0 - page 8
`
`Antire_Msi A switched-on mobile station with a SIM module attached.
`
`Alert;ag; 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.
`
`WWW 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 of the recipient Ms.
`
`An MSC
`Injezflflzking MSQ fig: shag: Message sargiye (sms-IHMSQ):
`capable of
`receiving ‘a short message
`from within the PLMN and
`submitting it to the recipient SC.
`
`that makes a PLMN store
`Service element
`Messages;flairins_iMflii
`listing those SCs
`that
`information (Messages-Waiting-Indication),
`have made unsuccessful short message delivery attempts to M33
`in
`that PLMN.
`_
`|
`
`MBESflQEEzHaitingzlndiflaiiflnaLfiflllL 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 SOS to be delivered to the MS (due
`to unsuccessful delivery attempt(s)}.
`
`to be stored in
`The part of the MWI
`-
`-
`'
`'
`-
`the HLR. MWD consists of an address list of
`the SCs which have
`messages waiting to be delivered to the MS.
`
`to be stored in
`The part of the MWI
`-
`—
`-
`the VLR. MWF is a boolean parameter indicating if the address list
`of MWD is empty (no SC has any messages waiting to be delivered to
`the MS) or not.
`
`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.
`
`Erioritxi 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.
`
`Information element by which the originator of
`EIQIQQQl:Idan$i£iezi
`a short message (either an SC or an MS) may refer to a higher layer
`
`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 deliyerx_rennrt, which confirms the delivery of the Short message
`to the recipient, or it may be a failureixennri, which informs the
`originator that the short message was never delivered and the reason
`why .
`
`27
`
`27
`
`
`
`GSM 03.40 — version 3.5.0 — page 9
`
`the delivery report confirms the
`When issued by the Service Centre,
`reception of the Short Message by the SC, and not
`the delivery of
`the Short Message to the SME.
`
`the delivery report confirms the
`When issued by the Mobile Station,
`reception of
`the Short Message by the Mobile Station, and not
`the
`delivery of the Short Message to the user.
`
`the relaying and
`Function responsible for
`SerxicfiLiCenI13L_ijfilli
`store—and-forwarding of a short message between an SME and an MS.
`The SC is not a part of the GSM PLMN.
`
`Information that may be conveyed by means of the
`snort_Messaga;
`Short Message Service described in this recommendation.
`
`An entity which may send or receive
`Shorr_Message_Enrirr_iSMEii
`Short Messages. The SME may be located in a fixed network, an MS, or
`an SC.
`.
`
`Short message transfer protocol data unit containing
`smsznriiyne;
`user data (the short message), being sent from an SC to an MS.
`
`Short message transfer protocol data unit containing
`SME:SHBMEL;
`user data (the short message), being sent from an MS to an SC.
`
`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.
`
`Information element offering the origiator MS
`Ealidiixefiezindmiyfili
`to indicate the time period during which the originator considers
`the short message to be valid.
`
`2.2. abbreviations
`
`CUG :
`
`Closed User Group
`
`MS:
`MSIsdn:
`
`Mobile Station
`ISDN number of the mobile subscriber
`
`MTG :
`
`Mobile Terminal with support of no terminal interfaces
`
`ISDN:
`PLMN:
`PSPDN :
`
`Integrated Services Digital Network
`Public Land Mobile Network
`Packet Switched Public Data Network
`
`ROSE:
`ACSE:
`
`Remote Operations Service Element
`.Association Control Service Element__
`
`SM MT'
`SM M0
`
`IIat
`
`Short Message Mobile Terminated Point-to—Point
`Short Message Mobile Originated Point—toePoint
`
`SM-AL :
`SM-TL :
`SM-RL :
`SM-LL :
`
`Short Message Application Layer
`Short Message Transfer Layer
`Short Message Relay Layer
`Short Message-Lower Layers
`
`28
`
`28
`
`
`
`GSM 03.40 a version 3.5!0 - page 10
`
`SM-TP :
`SM-RP :
`
`Short Message Transfer Layer Protocol
`Short Message Relay Layer Protocol
`
`SM—TS :
`SM—RS :
`
`Short Message Transfer Service
`Short Message Relay Service
`
`SMS :
`
`Short Message Service
`
`TPDU:
`
`Transfer protocol data unit
`
`3.
`
`SEBIIQES_AHD_SEB¥IEE_ELEMEHIS
`
`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 recommendation describes only the short message point-towpoint
`services between the MS and SC. It may, however, refer to possible
`higher layer applications.
`
`3.1 Basic_sermicas
`
`short message point~to~point
`The
`services:-
`
`services
`
`comprise
`
`two basic
`
`SM MT
`SM MO
`
`(Short Message Mobile Terminated Pointwto—Point),
`(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 should eventually 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.
`
`29
`
`29
`
`
`
`GSM 03.40 - version 3.5.0 - page 11
`
`Short message delivery
`
`SC
`
`w‘—_—_— 7
`
`MS
`
`Report
`
`Figure 03.40/1
`
`The Short Message Service mobile
`pointnto«point.
`
`terminated,
`
`Short message submission
`
`SC
`
`
`
`“w
`
`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:
`
`reception of a short message
`the transmission or
`When
`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.
`
`30
`
`30
`
`
`
`GSM 03.40 - version 3.5.0 a page 12
`
`3.2 WW5
`
`7 elements particular
`SMS comprises
`The
`reception of messages:
`
`to the submission and
`
`'Validity-Period
`Service-Centre-Time—Stamp
`Protocol—Identifier
`
`More-Messages—to-Send
`Priority
`Messages-Waiting
`Alert—SC
`
`3.2.1
`
`Iaiidiixzferiod
`
`The Validity—Period is the information element which gives an MS
`submitting an EMS-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 should guarantee its existence in the SC memory
`before delivery to the recipient has been carried out.
`
`3.2.2
`
`'
`
`-
`
`-
`
`v
`
`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
`
`Erntocnl:ldantifier
`
`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.
`
`a
`of
`use
`element makes
`information
`The Protocol—Identifier
`particular field in the message types SMS~SUBMIT and SMS«DELIVER,
`TPwProtocol-Identifier (TPwPID).
`
`3-2.4
`
`-
`
`-
`
`*
`
`mThe_More»Messages—to-Send is the information element by which the SC
`informs the MS thathhe e 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—MoredMessages-to-Send (TP—MMS).
`
`31
`
`31
`
`
`
`GSM 03.40 - version 3.5.0 - page 13
`
`3.2.5
`
`EIiDIiIX
`
`SME to
`Priority is the information element provided by an SC or
`indicate to the PLMN whether or not a message is anriQrithessaue.
`
`Delivery of a nonzprioritx_message will not be attempted if the MS
`has been identified as temporarily absent (see section 3.2.6).
`
`Delivery of a prioritz_message will be attempted irrespective of
`whether or not the MS has been identified as temporarily absent.
`
`3.2.5
`
`Messauaszflaiting
`
`The Messages-Waiting is the service element that enables the PLMN to
`provide the HLR 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. This information, de
`noted the Messages—WaitingwIndication (MWI), consists of Messages-
`Waiting—Data (MWD)
`located in the HLR and the Messages—Waiting-Flag
`(MWF)
`located in the VLR, as depicted in Figure 03.40/3.
`
`HLR:
`
`VLR:
`
`SC—Addr1 MSIsdn11 . MSIsdnlm
`
`MSIsdn21 . MSIsdnzm
`
`SC-addrn MSIsdnn1 . MSIsdnnm
`
`In
`
`Figure 03.40/3.
`
`the Messages—Waiting-Indication
`Structuring of
`(MWl)
`in the HLR and VLR (example).
`
`.. The .MWD....s.ha.l;L..con.tain..a.....l.i.$t.. oi . addressee (5.93%!) .Of. SCS .WhiCh.
`have made previous unsuccessful delivery attempts of a message (see
`section 5).
`In order to link an alert message to an earlier delivery
`attempt in the multiple MSIsdn scenario,
`the HLR shall store each SC
`address together with references to the MSIsdn(s) used with the SMS-
`DELIVER(s). The requirements placed upon the HLR are specified in
`rec GSM 03.08. The description of how the HLR is provided with EC
`and MS address information is given in GSM 09.02.
`‘
`
`32
`
`32
`
`
`
`GSM 03.40 a version 3.5.0 - page 14
`
`boolean
`a
`is
`VLR
`(MWF) within the
`The Messages—Waiting-Flag
`parameter with the value FALSE when the list MWD is empty, and with
`the value TRUE when the list contains one or more list elements.
`
`The MWD and MWF 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),
`the SC address is inserted into the MWD
`list (if it is not already present) and the MWF is set (if
`it is not already set), as described in section 10.
`
`2.
`
`(with a
`the MS
`When either the HLR or VLR detects that
`non-empty MWD in the HLR and the MWF set in the VLR) has
`recovered operation (e.g.
`has
`responded to a paging
`request),
`the HLR directly or on request of the VLR will
`invoke operations to alert
`the 503 within the MWD
`(see
`section 3.2.7
`and
`section 10). Once
`the Alert
`SC
`operations have been invoked,
`the MWF is cleared. After
`each SC is alerted by the HLR,
`the address for that SC is
`deleted from the MWD.
`
`3.2.7
`
`Alertzsc
`
`The Alert-SC is the service element, which may be provided by some
`GSM PLMNs,
`to inform the SC that an MS
`
`1)
`
`2)
`
`to which there has been an unsuccessful delivery attempt
`and
`which is now recognized by the PLMN to have recovered
`operation (e.g.
`to have responded to a paging request),
`
`is again attainable. The SC may - on reception of an Alert-SC -
`initiate the delivery attempt procedure for
`the queued messages
`destined for this MS.
`
`several MSIsdn
`identified by
`is
`subscriber
`the mobile
`Where
`identities (i.e. several MSIsdn identities are stored in the HLR),
`the Alert-SC shall provide the SC with the MSIsdn identity used in
`the SMS-DELIVER.
`
`If an SC has attempted to send more than one message to a