6 Implementation for SMS-PP

03.483GPPRelease 1999Security mechanisms for SIM application toolkitStage 2TS

6.1 Structure of the UDH of the Security Header in a Short Message Point to Point

The coding of the SMS-DELIVER, SMS-SUBMIT, SMS-DELIVER-REPORT or SMS-SUBMIT-REPORT header shall indicate that the data is binary (8 bit), 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]. However, in the case of a Response Packet originating from the SIM, due to the inability of the SIM 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.

Figure 2: Structure of User Data Header in the Short Message Point to Point

The generalised structure of the UDH in the Short Message element is shown in figure 2, which is contained in the User Data part of the Short Message element. The Command Packet and the Response Packet are partially mapped into this UDH structure.

Information Element Identifiers (IEI’s) values ’70 – 7F’ are reserved for use in the present document. Values ’70’ and ’71’ are used in the present document, values ’72 – 7D’ are reserved, and ‘7E’ and ‘7F’ are for proprietary implementations.

Where a Response Packet is too large to be contained in a single SMS-DELIVER-REPORT or SMS-SUBMIT-REPORT TP element, a Response Packet containing the Status Code "more time" should be returned to the SE using the SMS-REPORT element, followed by a complete Response Packet, contained in a SMS-DELIVER or SMS-SUBMIT element, which may be concatenated.

6.2 A Command Packet contained in a Single Short Message Point to Point

The relationship between the Command Packet and its inclusion in the UDH structure of a single Short Message with no other UDH elements is indicated in table 6.

Table 6: Relationship of Command Packet in UDH for single Short Message Point to Point

SMS specific elements

Generalised Command Packet Elements (Refer to Table 1)

Comments

UDL

Indicates the length of the entire SM.

UDHL

=’02’

The first octet of the content or User Data part of the Short Message itself. Length of the total User Data Header, in this case, includes the length of IEIa + IEIDLa + IEDa (see figure 2), and is ’02’ in this case.

IEIa

CPI= ’70’

Identifies this element of the UDH as the Command Packet Identifier. This value is reserved in TS 23.040 [3].

IEIDLa

=’00’

Length of this object, in this case the length of IEDa, which is zero, indicating that IEDa is a null field..

IEDa

Null field.

SM (8 bit data)

Length of Command Packet (2 octets)(Note)

Length of the Command Packet (CPL), coded over 2 octets, and shall not be coded according to ISO/IEC  7816-6 [8].

Command Header Identifier

(CHI) Null field.

Length of the Command Header

Length of the Command Header (CHL), coded over one octet, and shall not be coded according to ISO/IEC 7816-6 [8].

SPI to RC/CC/DS in the Command Header

The remainder of the Command Header.

Secured Data

Application Message, including possible padding octets.

NOTE: Whilst not absolutely necessary in this particular instance, this field is necessary for the case where concatenated Short Message is employed (see subclause 6.3).

IEIa identifies the Command Packet and indicates that the first portion of the SM contains the Command Packet Length, the Command Header length followed by the remainder of the Command Header: the Secured Data follows on immediately as the remainder of the SM element. The UDHL field indicates the length of the IEIa and IEIDLa octets only (’02’ in this case).

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.

6.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]. In this case, the entire Command Packet including the Command Header shall be assembled, and then separated into its component concatenated parts. The first Short Message shall contain the concatenation User Data Header and the Command Packet Identifier in the UDH in no particular order. Subsequent Short Messages shall contain only the concatenation User Data Header. The concatenation Header contains a Reference number that will allow the Receiving Entity to link individual Short Messages together to re-assemble the original Command Packet before unpacking the Command Packet.

The relationship between the Command Packet and its inclusion in the structure of the first concatenated Short Message is indicated in table 7; the ordering of the various elements of the UDH is not important.

Table 7: Relationship of Command Packet in UDH for concatenated Short Message Point to Point

SMS specific elements

Generalised Command Packet Elements (Refer to Table 1)

Comments

UDL

Indicates the length of the entire SM

UDHL

=’07’

The first octet of the content or User Data part of the Short Message itself. Length of the total User Data Header, in this case, includes the length of IEIa + IEIDLa + IEDa + IEIb + IEIDLb + IEDb (see figure 2), which is ’07’ in this case.

IEIa

’00’, indicating concatenated short message

identifies this Header as a concatenation control header defined in TS 23.040 [3].

IEIDLa

Length of Concatenation header

length of the concatenation control header (= 3).

IEDa

3 octets containing data concerned with concatenation

These octets contain the reference number, sequence number and total number of messages in the sequence, as defined in TS 23.040 [3].

IEIb

CPI= ’70’

Identifies this element of the UDH as the Command Packet Identifier.

IEIDLb

=’00’

Length of this object, in this case the length of IEDb alone, which is zero, indicating that IEDb is a null field.

IEDb

Null field.

SM (8 bit data)

Length of Command Packet (2 octets)

Length of the Command Packet (CPL), coded over 2 octets, and shall not be coded according to ISO/IEC 7816-6 [8].

Command Header Identifier

(CHI) Null field.

Length of the Command Header

Length of the Command Header (CHL), coded over one octet, and shall not be coded according to ISO/IEC 7816-6 [8].

SPI to RC/CC/DS in the Command Header

The remainder of the Command Header.

Secured Data (part)

Contains the first portion of the Secured Data. The remaining Secured Data will be contained in subsequent concatenated short messages.

In the case where the Command Packet requires to be concatenated, then in table 7, IEIa identifies the concatenation control element of the Short Message, and is repeated in each subsequent Short Message in the concatenated series. In the first Short Message alone, in this example, IEIb identifies the Command Packet, which indicates that the first portion of the content of the Short Message contains the Command Header, which is followed immediately by the secured data as the SM part in table 7. In the first Short Message, the UDHL field contains the length of the concatenation control and the Command Packet Identifier, whereas in subsequent Short Message’s in the concatenated series, the UDHL contains the length of the concatenation control only, as there is no subsequent Command Header.

If the data is ciphered, then it is ciphered as described above, before being broken down into individual concatenated elements. The concatenation control portion 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.

An example illustrating the relationship between a Command Packet split over a sequence of three Short Messages is shown below.

Figure 3: Example of command split using concatinated point to point SMS

6.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 SIM, depending on bit 6 of the second octet of the SPI, this Response Packet is generated on the SIM, either:

– retrieved by the ME from the SIM, and included in the User-Data part of the SMS-DELIVER-REPORT returned to the network;

or

– retrieved by the ME from the SIM using the Send Short Message proactive command.

Table 8: Relationship of Response Packet in UDH

SMS-REPORT specific elements

Generalised Response Packet Elements (Refer to Table 3)

Comments

UDL

Indicates the length of the entire SMS

UDHL

=’02’

The first octet of the content of the SMS itself. Length of the total User Data Header, in this case, includes the length of IEIa + IEIDLa + IEDa.

IEIa

RPI= ’71’

Identifies this element of the UDH as the Response Packet Identifier. This value is reserved in TS 23.040 [3].

IEIDLa

=’00’

Length of this object, in this case the length of IEDa alone, which is zero, indicating that IEDa is a null field.

IEDa

Null field.

SM (8 bit data)

Length of Response Packet

Length of the Response Packet (RPL), coded over 2 octets, and shall not be coded according to ISO/IEC  7816-6 [8]. (see note)

Response Header Identifier

(RHI) Null field.

Length of the Response Header

Length of the Response Header (RHL), coded over one octet, and shall not be coded according to ISO/IEC 7816-6 [8].

TAR to RC/CC/DS elements in the Response Header

The remainder of the Response Header.

Secured Data

Additional Response Data (optional), including padding octets.

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 in the above table) shall be included in the calculation of RC/CC/DS if used. These fields shall not be ciphered.

The structure of an SMS-DELIVER/SUBMIT-REPORT User Data object is very similar to that of the SMS-SUBMIT or SMS-DELIVER, see TS 23.040 [3].