|
TECHNICAL SPECIFICATION
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Secured packet structure for (Universal)
Subscriber Identity Module (U)SIM Toolkit applications
(3GPP TS 31.115 version 15.0.0 Release 15)
---------------------- Page: 1 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 1 ETSI TS 131 115 V15.0.0 (2019-04)
Reference
RTS/TSGC-0631115vf00
Keywords
GSM,LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - 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
Important notice
The present document can be downloaded from:
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
If you find errors in the present document, please send your comment to one of the following services:
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 2 ETSI TS 131 115 V15.0.0 (2019-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI 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 ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 3 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 3 ETSI TS 131 115 V15.0.0 (2019-04)
Contents
Intellectual Property Rights . 2
Foreword . 2
Modal verbs terminology . 2
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Implementation for SMS-PP . 6
4.1 Structure of the UDH in a secured Short Message Point to Point . 6
4.2 Structure of the Command Packet contained in a Single Short Message Point to Point . 7
4.3 A Command Packet contained in Concatenated Short Messages Point to Point . 8
4.4 Structure of the Response Packet . 9
4.5 A Response Packet contained in Concatenated Short Messages Point to Point . 10
5 Implementation for SMS-CB . 11
5.1 Structure of the CBS page in the SMS-CB Message . 11
5.2 A Command Packet contained in a SMS-CB message. 11
5.3 Structure of the Response Packet for a SMS-CB Message . 12
6 Implementation for USSD . 12
6.1 Structure of the Command Packet contained in a Single USSD Message. 12
6.2 Structure of the Command Packet contained in concatenated USSD Messages . 13
6.3 Structure of the Response Packet . 13
6.4 Structure of the Response Packet contained in concatenated USSD Messages . 14
7 Specific Response Status Codes . 15
8 Implementation for HTTP . 15
Annex A (normative): USSD String format . 16
Annex B (informative): Change History . 17
History . 18
ETSI
---------------------- Page: 4 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 4 ETSI TS 131 115 V15.0.0 (2019-04)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
Y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
Z the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
The present document is the result of a split of TS 23.048 Release 5 between the generic part and the bearers specific
application. The generic part has been transferred to SCP. The present document is the bearers specific part.
ETSI
---------------------- Page: 5 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 5 ETSI TS 131 115 V15.0.0 (2019-04)
1 Scope
The present document specifies the structure of the Secured Packets in implementations using Short Message Service
Point to Point (SMS-PP), Short Message Service Cell Broadcast (SMS-CB), Unstructured Supplementary Service Data
(USSD) and and Hyper Text Transfer Protocol (HTTP) based on ETSI TS 102 225 [9].
The structure of the Secured Packets shall comply with the one defined in ETSI TS 102 225 [9]. The present document
only contains additional requirements or explicit limitations for SIM/USIM applications.
It is applicable to the exchange of secured packets between an entity in a 3G or GSM PLMN and an entity in the
(U)SIM.
Secured Packets contain application messages to which certain mechanisms according to ETSI TS 102 224 [2] have
been applied. Application messages are commands or data exchanged between an application resident in or behind the
3G or GSM PLMN and on the (U)SIM. The Sending/Receiving Entity in the 3G or GSM PLMN and the UICC are
responsible for applying the security mechanisms to the application messages and thus turning them into Secured
Packets.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: “Vocabulary for 3GPP Specifications”.
[2] ETSI TS 102 224 V8.0.0: “Smart Cards; Security mechanisms for UICC based Applications –
Functional requirements”.
[3] 3GPP TS 23.040: “Technical realization of the Short Message Service (SMS)”.
[4] 3GPP TS 24.011: “Point-to-Point (PP) Short Message Service (SMS) support on mobile radio
interface”.
[5] ETSI TS 101 220 “Smart Cards; ETSI numbering system for telecommunication application
providers”.
[6] 3GPP TS 23.041: “Technical realization of Cell Broadcast Service (CBS)”.
[7] 3GPP TS 24.012: “Short Message Service Cell Broadcast (SMSCB) support on the mobile radio
interface”.
[8] 3GPP TS 23.038: “Alphabets and language-specific information”.
[9] ETSI TS 102 225 V12.1.0: “Smart Cards; Secured packet structure for UICC based applications”.
[10] 3GPP TS 24.090: “Unstructured Supplementary Service Data (USSD) – Stage 3”.
ETSI
---------------------- Page: 6 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 6 ETSI TS 131 115 V15.0.0 (2019-04)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 102 225 [9] and the following
apply:
Message Identifier: two-octet field used to identify the source and type of the message
Page Parameter: single octet field used to represent the CBS page number in the sequence and the total number of
pages in the SMS-CB message
Serial Number: two octet field which identifies a particular message
It is linked to the Message Identifier and is altered every time the message is changed
Short Message: information that may be conveyed by means of the SMS Service as defined in TS 23.040 [3].
USSD message: information that may be conveyed in the USSD-String field of a Facility message as defined in
TS 24.090 [10].
3.2 Abbreviations
For the purpose of the present document, the abbreviations given in ETSI TS 102 225 [9] and the following apply:
CBC Cipher Block Chaining
CBS Cell Broadcast Service
CCF Concatenation Control Field
DCS Data Coding Scheme
IEI Information Element Identifier
IEIDL Information Element Identifier Data Length
IED Information Element Data
MID Message Identifier
MO-SMS Mobile Originated Short Message Service
MT-SMS Mobile Terminated Short Message Service
PFI Packet Format Information
PLMN Public Land Mobile Network
PP Page Parameter
SIM Subscriber Identity Module
SM Short Message
SMS Short Message Service
SMS-PP Short Message Service – Point to Point
SMS-CB Short Message Service – Cell Broadcast
SMS-SC Short Message Service – Service Centre
SN Serial Number
UM USSD message
USIM Universal Subscriber Identity Module
USSD Unstructured Supplementary Service Data
4 Implementation for SMS-PP
4.1 Structure of the UDH in a secured Short Message Point to
Point
The coding of the SMS-DELIVER, SMS-SUBMIT, SMS-DELIVER-REPORT header shall indicate that the data is
binary (8 bit data), and not 7 bit or 16 bit. In order to invoke the UDH functionality of relevant SMS element, the UDHI
bit shall be set as defined in TS 23.040 [3].
ETSI
---------------------- Page: 7 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 7 ETSI TS 131 115 V15.0.0 (2019-04)
However, in the case of a Response Packet originating from the UICC, due to the inability of the UICC to indicate to a
ME that the UDHI bit should be set, the Response Packet SMS will not have the UDHI bit set, and the Sending Entity
shall treat the Response Packet as if the UDHI bit was set.
The generalised structure of the UDH in the Short Message element is contained in the User Data part of the Short
Message element and is described in TS 23.040 [3]. The Command Packet and the Response Packet are partially
mapped into this UDH structure.
Information Element Identifiers (IEI’s) values range ‘70 – 7F’ are reserved in TS 23.040 [3] for use in the present
document and allocated as follows:
- ‘70’ and ‘71’ are specified in the present document
- values ‘72 – 7D’ are reserved for future use
- ‘7E’ and ‘7F’ are for proprietary implementations.
If a Response Packet (Response Header + Data) is too large to be contained in a single Short Message (including the
Response Header), it shall be concatenated according to TS 23.040 [3].
If it is indicated in the SPI2 of a Command Packet to send back a PoR using SMS-DELIVER-REPORT and if the
Response Packet is too large to be contained in a single SMS-DELIVER-REPORT – TP element, then:
- One single Response Packet shall be sent back to the SE using SMS-DELIVER-REPORT. This Response
Packet:
- Shall not contain any additional response data.
- Shall contain the Response Status Code set to “Actual response data to be sent using SMS-SUBMIT”.
- The security applied to this Response Packet shall follow the coding and rules as defined in ETSI TS 102 225
[9].
- This shall be followed by a complete Response Packet, contained in one SMS-SUBMIT element or in a
concatenated Short Message composed of several SMS-SUBMIT elements.
4.2 Structure of the Command Packet contained in a Single
Short Message Point to Point
CPI identifies the Command Packet and indicates that the first portion of the SM (8 bit data) contains the Command
Packet Length (CPL), the Command Header Length (CHL) followed by the remainder of the Command Header: the
Secured Data follows on immediately as the remainder of the SM element.
The relationship between the Command Packet and its inclusion in the UDH structure of a single Short Message
defined in TS 23.040 [3] is as following:
- CPI is mapped to IEIa defined in TS 23.040 [3] and shall be set to ‘70’.
- IEDa defined in TS 23.040 [3] shall be a null field and its length IEIDLa shall be set to ‘00’.
The following Table 1 indicates the Command Packet contained in a single SMS-PP. It is a particular implementation
for single SMS-PP of the generic Command Packet structure described in ETSI TS 102 225 [9].
ETSI
---------------------- Page: 8 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 8 ETSI TS 131 115 V15.0.0 (2019-04)
Table 1: Structure of the Command Packet contained in the SM (8 bit data)
Command Packet Length Description
Elements
Command Packet 2 octets (see NOTE) Length of the Command Packet (CPL), coded over 2
Length octets, and shall not be coded as the length of BER-TLV
data objects described in ETSI TS 101 220 [5].
Command Header Null field (CHI) Null field.
Identifier
Command Header 1 octet Length of the Command Header (CHL), coded over one
Length octet, and shall not be coded as the length of BER-TLV
data objects described in ETSI TS 101 220 [5].
SPI to RC/CC/DS in Variable The remainder of the Command Header as described in
the Command ETSI TS 102 225 [9].
Header
Secured Data Variable Application Message, including possible padding octets as
described in ETSI TS 102 225 [9].
NOTE: Whilst not absolutely necessary in this particular instance, this field is necessary for the case where
concatenated Short Message is employed (see subclause 4.3).
It is recognised that most checksum algorithms require input data in modulo 8 length. In order to achieve a modulo 8
length of the data before the RC/CC/DS field in the Command Header the Length of the Command Packet and the
Length of the Command Header shall be included in the calculation of RC/CC/DS if used. These fields shall not be
ciphered.
When receiving a secured Command Packet requesting a Proof of Receipt (PoR), the Receiving Entity shall follow the
coding and rules as defined in ETSI TS 102 225 [9]. The Receiving Entity shall verify the authenticity of the Sending
Entity. If the Receiving Entity cannot authenticate the Sending Entity, the Receiving Entity shall not send any Response
Packet and discard the Command Packet with no further action being taken, as described in ETSI TS 102 225 [9],
clause 4.1.
The SPI shall be coded as specified in ETSI TS 102 225 [9]. The b6 of the second octet is used for SMS only and shall
be coded as followed:
Second Octet:
b8 b7 b6 b5 b4 b3 b2 b1
Coded as defined in ETSI TS 102 225 [9]
Coded as defined in ETSI TS 102 225 [9]
Coded as defined in ETSI TS 102 225 [9]
For SMS only
0: PoR response shall be sent using
SMS-DELIVER-REPORT
1: PoR response shall be sent using SMS-SUBMIT
Coded as defined in ETSI TS 102 225 [9]
4.3 A Command Packet contained in Concatenated Short
Messages Point to Point
If a Command Packet is longer than 140 octets (including the Command Header), it shall be concatenated according to
TS 23.040 [3].
The relationship between the Command Packet and its inclusion in the structure of a concatenated Short Message
defined in TS 23.040 [3] is as following:
- The entire Command Packet including the Command Header shall be separated into its component concatenated
parts. The structure of the Command Packet contained in a concatenated SMS-PP is as described in Table 1 of
this specification.
ETSI
---------------------- Page: 9 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 9 ETSI TS 131 115 V15.0.0 (2019-04)
- The first Short Message shall contain the Concatenation Control Header as defined in TS 23.040 [3] identified
by IEIx and the Command Packet Identifier (CPI) in the User Data Header. The relationship between the
Command Packet and its inclusion in the structure of the first concatenated Short Message is as described in
clause 4.2 for a single Short Message.
NOTE: The ordering of the various elements of the UDH defined in TS 23.040 [3] is not important.
Figure 2009 In each subsequent Short Message in the concatenated series, the Concatenation Control Header shall be
present. The Concatenation Control Header shall be set as defined in TS 23.040[3]. The CPI, CPL and
Command Header shall not be present.
Example of concatenation, 8-bit reference number:
if in the first Short Message the Concatenation Control Header isidentified by IEIa, the CPI is
mapped to IEIb and no other IEI is present, then the UDHL fieldcontains the length of the total
User Data Header i.e the Concatenation Control Header, the CPI and IEIDLb (UDHL shall be set
to ‘07’ with IEIa set to ‘00’). In subsequent Short Message’s in the concatenated series, the UDHL
contains the length of the Concatenation Control Header only, as there is no subsequent Command
Packet Information Element CPI and IEIDLb).
If the data is ciphered, then it is ciphered as described above, before being broken down into individual concatenated
elements. The Concatenation Control Header of the UDH in each SM shall not be ciphered.
In order to achieve a modulo 8 length of the data before the RC/CC/DS field in the Command Header, the Length of the
Command Packet and the Length of the Command Header shall be included in the calculation of RC/CC/DS if used.
These fields shall not be ciphered.
The SPI shall be coded and shall follow the rules as specified in TS 102 225 [9]. The b6 of the second octet is used only
for SMS and shall be coded as described for a single short message.
An example illustrating the relationship between a Command Packet split over a sequence of three Short Messages is
shown below.
CH Secured data Padding
CC1 CH CC2 CC3
First SMS in sequence Second SMS Third and final SMS
where CCn = Concatenation Control (1,2,3)
CH = Command Header
The Command Header includes here CPL, CHL, SPI to RC/CC/DS
Figure 2: Example of command split using concatenated point to point SMS
4.4 Structure of the Response Packet
The Response Packet is as follows. This message is generated by the Receiving Entity and possibly includes some data
supplied by the Receiving Application, and returned to the Sending Entity/Sending Application. In the case where the
Receiving Entity is the UICC, depending on bit 6 of the second octet of the SPI, this Response Packet is generated on
the UICC, either:
- retrieved by the ME from the UICC, and included in the User-Data part of the SMS-DELIVER-REPORT
returned to the network; or
- fetched by the ME from the UICC after the Send Short Message proactive command.
The structure of an SMS-DELIVER/SUBMIT User Data object is defined in TS 23.040 [3].
RPI identifies the Response Packet and indicates that the first portion of the SM (8 bit data) contains the Response
Packet Length (RPL), the Response Header Length (RHL) followed by the remainder of the Response Header: the
Secured Data follows on immediately as the remainder of the SM element.
ETSI
---------------------- Page: 10 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 10 ETSI TS 131 115 V15.0.0 (2019-04)
The relationship between the Response Packet and its inclusion in the UDH structure of a single Short Message defined
in TS 23.040 [3] is as following:
- RPI is mapped to IEIa defined in TS 23.040 [3] and shall be set to ‘71’.
- IEDa defined in TS 23.040 [3] shall be a null field and its length IEIDLa shall be set to ‘00’.
The following Table 3 indicates the Response Packet contained in a single SMS-PP. It is a particular implementation for
single SMS-PP of the generic Response Packet structure described in ETSI TS 102 225 [9].
Table 3: Structure of the Response Packet contained in the SM (8 bit data)
Generalised Response Length Description
Packet Elements
(Refer to table 3)
Response Packet 2 octets Length of the Response Packet (RPL), coded over 2 octets, and
Length shall not be coded as the length of BER-TLV data objects described
in ETSI TS 101 220 [5]. (see note)
Response Header (RHI) Null field.
Identifier
Response Header 1 octet Length of the Response Header (RHL), coded over one octet, and
Length shall not be coded as the length of BER-TLV data objects described
in ETSI TS 101 220 [5].
TAR to RC/CC/DS Variable The remainder of the Response Header as described in
elements in the ETSI TS 102 225 [9].
Response Header Response Status Codes are defined in clause 7.
Secured Data Variable Additional Response Data (optional), including padding octets as
described in ETSI TS 102 225 [9].
NOTE: This field is not absolutely necessary but is placed here to maintain compatibility with the structure of the
Command Packet when included in a SMS-SUBMIT or SMS-DELIVER.
In order to achieve a modulo 8 length of the data before the RC/CC/DS field in the Response Header, the Length of the
Response Packet, the Length of the Response Header and the three preceding octets (UDHL, IEIa and IEIDLa defined
in TS 23.040 [3]) shall be included in the calculation of RC/CC/DS if used. These fields shall not be ciphered.
4.5 A Response Packet contained in Concatenated Short
Messages Point to Point
- The relationship between the Response Packet and its inclusion in the structure of a concatenated Short Message
defined in TS 23.040 [3] is as following:The entire Response Packet including the Response Header shall be
separated into its component concatenated parts. The structure of the Response Packet contained in a
concatenated SMS-PP is as described in Table 5 of this specification.
- The first Short Message shall contain the Concatenation Control Header as defined in TS 23.040 [3] identified
by IEIxand the Response Packet Identifier (RPI) in the User Data Header. The relationship between the
Response Packet and its inclusion in the structure of the first concatenated Short Message is as described in
clause 4.4 for a single Short Message.
NOTE: The ordering of the various elements of the UDH defined in TS 23.040 [3] is not important.
Figure 2009 In each subsequent Short Message in the concatenated series, the Concatenation Control Header shall be
present. The concatenation Control Header shall be set as defined in TS 23.040 [3]. The RPI, RPL and
Response Header shall not be present.
Example of concatenation, 8-bit reference number:
if in the first Short Message the Concatenation Control Header is identified by IEIa, the RPI is
mapped to IEIb and no other IEI is present, then the UDHL field contains the length of the total
User Data Header i.e the Concatenation Control Header, the RPI and IEIDLb (UDHL shall be set
to ‘07’ with IEIa set to ‘00’). In subsequent Short Message’s in the concatenated series, the UDHL
contains the length of the Concatenation Control Header only, as there is no subsequent Response
Packet Information Element (RPI and IEIDLb).
ETSI
---------------------- Page: 11 ----------------------
3GPP TS 31.115 version 15.0.0 Release 15 11 ETSI TS 131 115 V15.0.0 (2019-04)
Table 5: Structure of the Response Packet contained in the SM (8 bits data)
SMS-REPORT Length Comments
specific Elements
(Refer to table 3)
RPL 2 octets Length of the Response Packet (RPL), coded over 2
octets, and shall not be coded as the length of BER-TLV
data objects described in ETSI TS 101 220 [5].
RHI (RHI) Null field.
RHL 1 octet Length of the Response Header (RHL), coded over one
octet, and shall not be coded as the length of BER-TLV
data objects described in ETSI TS 101 220 [5].
TAR to RC/CC/DS Variable The remainder of the Response Header as described in
elements in the ETSI TS 102 225 [9].
Response Header
Secured Data Variable Additional Response Data (o
...