10.4 Contents of DFs at the GSM application level

11.113GPPRelease 1999Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) InterfaceTS

10.4.1 Contents of files at the GSM SoLSA level

This subclause specifies the EFs in the dedicated file DFSoLSA. It only applies if the SoLSA feature is supported (see TS 23.073 [33]).

The EFs contain information about the users subscribed local service areas.

10.4.1.1 EFSAI (SoLSA Access Indicator)

This EF contains the ‘LSA only access indicator’. This EF shall always be allocated if DFSoLSA is present.

If the indicator is set, the network will prevent terminated and/or originated calls when the MS is camped in cells that are not included in the list of allowed LSAs in EFSLL. Emergency calls are, however, always allowed.

The EF also contains a text string which may be displayed when the MS is out of the served area(s).

Identifier: ‘4F30’

Structure: transparent

Optional

File size: X + 1 bytes

Update activity: low

Access Conditions:

READ CHV1

UPDATE ADM

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1

LSA only access indicator

M

1 byte

2 to X+1

LSA only access indication text

M

X bytes

‑ LSA only access indicator

Contents: indicates whether the MS is restricted to use LSA cells only or not.

Coding:

b8

b7

b6

b5

b4

b3

b2

b1

b1=0: LSA only access not activated

b1=1: LSA only access activated

RFU

‑ LSA only access indication text

Contents: text to be displayed by the ME when it’s out of LSA area.

Coding: the string shall use either

– the SMS default 7‑bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. The alpha identifier shall be left justified. Unused bytes shall be set to ‘FF’; or

– one of the UCS2 coded options as defined in annex B.

10.4.1.2 EFSLL (SoLSA LSA List)

This EF contains information describing the LSAs that the user is subscribed to. This EF shall always be allocated if DFSoLSA is present.

Each LSA is described by one record that is linked to a LSA Descriptor file. Each record contains information of the PLMN, priority of the LSA, information about the subscription and may also contain a text string and/or an icon that identifies the LSA to the user. The text string can be edited by the user.

Identifier: ‘4F31’

Structure: linear fixed

Optional

Record length: X + 10 bytes

Update activity: low

Access Conditions:

READ CHV1

UPDATE CHV1

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1 to X

LSA name

O

X bytes

X+1

Configuration parameters

M

1 byte

X+2

RFU

M

1 byte

X+3

Icon Identifier

M

1 byte

X+4

Priority

M

1 byte

X+5 to X+7

PLMN code

M

3 bytes

X+8 to X+9

LSA Descriptor File Identifier

M

2 byte

X+10

LSA Descriptor Record Identifier

M

1 byte

‑ LSA name

Contents: LSA name string to be displayed when the ME is camped in the corresponding area, dependant on the contents of the LSA indication for idle mode field.

Coding: the string shall use either

– the SMS default 7‑bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. The alpha identifier shall be left justified. Unused bytes shall be set to ‘FF’; or

– one of the UCS2 coded options as defined in annex B.

‑ Configuration parameters

Contents: Icon qualifier, control of idle mode support and control of LSA indication for idle mode.

Coding:

b8

b7

b6

b5

b4

b3

b2

b1

Icon qualifier

Idle mode support

LSA indication for idle mode

RFU

Icon qualifier:

Contents: The icon qualifier indicates to the ME how the icon is to be used.

b2, b1: 00: icon is not to be used and may not be present
01: icon is self-explanatory, i.e. if displayed, it replaces the LSA name
10: icon is not self-explanatory, i.e. if displayed, it shall be displayed together with the LSA name
11: RFU

Idle mode support:

Contents: The idle mode support is used to indicate whether the ME shall favour camping on the LSA cells in idle mode.

b3 = 0: Idle mode support disabled
b3 = 1: Idle mode support enabled

LSA indication for idle mode:

Contents: The LSA indication for idle mode is used to indicate whether or not the ME shall display the LSA name when the ME is camped on a cell within the LSA.

b4 = 0: LSA indication for idle mode disabled
b4 = 1: LSA indication for idle mode enabled

Bits b5 to b8 are RFU (see subclause 9.3).

– Icon Identifier

Contents: The icon identifier addresses a record in EFIMG.

Coding: binary.

‑ Priority

Contents: Priority of the LSA which gives the ME the preference of this LSA relative to the other LSAs.

Coding:

b8

b7

b6

b5

b4

b3

b2

b1

Priority

RFU

‘0’ is lowest priority, ‘F’ is highest.

‑ PLMN code

Contents: MCC + MNC for the LSA.

Coding: according to GSM 04.08 [15] and EFLOCI.

– LSA Descriptor File Identifier:

Contents: these bytes identify the EF which contains the LSA Descriptors forming the LSA.

Coding: byte X+8: high byte of the LSA Descriptor file;
byte X+9: low byte of the LSA Descriptor file.

– LSA Descriptor Record Identifier:

Contents: this byte identifies the number of the first record in the LSA Descriptor file forming the LSA.

Coding: binary.

10.4.1.3 LSA Descriptor files

Residing under DFSoLSA, there may be several LSA Descriptor files. These EFs contains one or more records again containing LSA Descriptors forming the LSAs. LSAs can be described in four different ways. As a list of LSA IDs, as a list of LAC + CIs, as a list of CIs or as a list of LACs. As the basic elements (LSA ID, LAC + CI, CI and LAC) of the four types of lists are of different length, they can not be mixed within one record. Different records may contain different kinds of lists within the EFs. Examples of codings of LSA Descriptor files can be found in annex F.

Identifier: ‘4FXX’

Structure: linear fixed

Optional

Record length: n*X+2 bytes

Update activity: low

Access Conditions:

READ CHV1

UPDATE ADM

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1

LSA descriptor type and number

M

1 byte

2 to X+1

1st LSA Descriptor

M

X bytes

X+2 to 2X+1

2nd LSA Descriptor

M

X bytes

(n-1)*X+2 to n*X+1

nth LSA Descriptor

M

X bytes

n*X+2

Record Identifier

M

1 byte

– LSA descriptor type and number:

Contents: The LSA descriptor type gives the format of the LSA descriptor and the number of valid LSA Descriptors within the record.

Coding:

b8

b7

b6

b5

b4

b3

b2

b1

LSA descriptor type

Number of LSA Descriptors

LSA descriptor type:

Contents: Gives the format of the LSA Descriptors.

b2, b1: 00: LSA ID.
01: LAC + CI
10: CI
11: LAC

Number of LSA Descriptors:

Contents: Gives the number of valid LSA Descriptors in the record.

Coding: binary, with b8 as MSB and b3 as LSB leaving room for 64 LSA Descriptors per record.

‑ LSA Descriptor

Contents: Dependant of the coding indicated in the LSA descriptor type:

– in case of LSA ID the field length ‘X’ is 3 bytes;

– in case of LAC + CI the field length ‘X’ is 4 bytes;

– in case of CI the field length ‘X’ is 2 bytes;

– in case of LAC the field length ‘X’ is 2 bytes.

Coding: according to TS 04.08 [15].

– Record Identifier:

Contents: This byte identifies the number of the next record containing the LSA Descriptors forming the LSA.

Coding: record number of next record. ‘FF’ identifies the end of the chain.

This file utilises the concept of chaining as for EFEXT1.

The identifier ‘4FXX’ shall be different from one LSA Descriptor file to the other and different from the identifiers of EFSAI and EFSLL. For the range of ‘XX’, see subclause 6.6.

10.4.2 Contents of files at the MExE level

This subclause specifies the EFs in the dedicated file DFMExE. It only applies if support of MExE by the SIM is supported (see TS 23.057 [50]).

The EFs in the Dedicated File DFMExE contain execution environment related information.

10.4.2.1 EFMExE-ST (MExE Service table)

This EF indicates which MExE services are allocated, and whether, if allocated, the service is activated. If a service is not allocated or not activated in the SIM, the ME shall not select this service.

Identifier: ‘4F40’

Structure: transparent

Optional

File size: X bytes, X ≥ 1

Update activity: low

Access Conditions:

READ CHV1

UPDATE ADM

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1

Services n°1 to n°4

M

1 byte

2

Services n°5 to n°8

O

1 byte

etc.

X

Services (4X‑3) to (4X)

O

1 byte

‑Services

Contents:

Service n°1 :

Operator root public key

Service n°2 :

Administrator root public key

Service n°3 :

Third party root public key

Service n°4 :

RFU

Coding:

2 bits are used to code each service:

first bit = 1: service allocated

first bit = 0: service not allocated

where the first bit is b1, b3, b5 or b7;

second bit = 1: service activated

second bit = 0: service not activated

where the second bit is b2, b4, b6 or b8.

Service allocated means that the SIM has the capability to support the service. Service activated means that the service is available for the card holder (only valid if the service is allocated).

The following codings are possible:

‑ first bit = 0: service not allocated, second bit has no meaning;

‑ first bit = 1 and second bit = 0: service allocated but not activated;

‑ first bit = 1 and second bit = 1: service allocated and activated.

The bits for services not yet defined shall be set to RFU. For coding of RFU see subclause 9.3.

First byte:

b8

b7

b6

b5

b4

b3

b2

b1

Service n°1

Service n°2

Service n°3

Service n°4

etc.

For an example of coding see sub-clause 10.3.7

10.4.2.2 EFORPK (Operator Root Public Key)

This EF contains the descriptor(s ) of certificates containing the Operator Root Public Key. This EF shall only be allocated if the operator wishes to verify applications and certificates in the MExE operator domain using a root public key held on the SIM. Each record of this EF contains one certificate descriptor.

For example, Operator may provide a second key for recover disaster procedure in order to limit OTA data to load.

Identifier: ‘4F41’

Structure: linear fixed

Optional

Record length : X + 10 bytes, X ≥ 1

Update activity: low

Access Conditions:

READ CHV1

UPDATE ADM

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1

Parameters indicator

M

1 byte

2

Flags

M

1 byte

3

Type of certificate

M

1 byte

4 to 5

Key/certificate file identifier

M

2 bytes

6 to 7

Offset into key/certificate file

M

2 bytes

8 to 9

Length of key/certificate data

M

2 bytes

10

Key identifier length (X)

M

1 byte

11 to 10+X

Key identifier

M

X bytes

‑ Parameter indicator

Contents:
The parameter indicator indicates if record is full and which optional parameters are present

Coding: bit string

b8

b7

b6

b5

b4

b3

b2

b1

Certificate descriptor is valid (bit1=0 key descriptor is valid)

Reserved bit set to 1 (bitx=0 optional parameter present)

‑ Flags

Contents:
The authority flag indicates whether the certificate identify an authority (i.e. CA or AA) or not.

Coding: bit string

b8

b7

b6

b5

b4

b3

b2

b1

Authority certificate (bit=1 certificate of an authority)

RFU

RFU

‑ Type of certificate

Contents:
This field indicates the type of certificate containing the key.

Coding: binary :
0 : WTLS
1 : X509
2 : X9.68
Other values are reserved for further use

– Key/certificate File Identifier

Contents:

these bytes identify an EF which is the key/certificate data file (see subclause 10.7.5), holding the actual key/certificate data for this record.

Coding:

byte 4: high byte of Key/certificate File Identifier;

byte 5: low byte of Key/certificate File Identifier.

– Offset into Key/certificate File

Contents:

these bytes specify an offset into the transparent key/certificate data File identified in bytes 4 and 5.

Coding:

byte 6: high byte of offset into Key/certificate Data File;

byte 7: low byte of offset into Key/certificate Data File

– Length of Key/certificate Data

Contents:

these bytes yield the length of the key/certificate data, starting at the offset identified in "Offset into Key/certificate File" field.

Coding:

byte 8: high byte of Key/certificate Data length;

byte 9: low byte of Key/certificate Data length.

‑ Key identifier length

Contents:
This field gives length of key identifier

Coding:
binary

‑ Key identifier

Contents:
This field provides a means of identifying certificates that contain a particular public key (chain building) and linking the public key to its corresponding private key. For more information about value and using see TS 23.057 [50].

Coding:
octet string

Note: transparent key/certificate data longer than 256 bytes may be read using successive READ BINARY commands.

10.4.2.3 EFARPK (Administrator Root Public Key)

This EF contains the descriptor(s ) of certificates containing the Administrator Root Public Key. This EF shall only be allocated if the SIM issuer wishes to control the Third Party certificates on the terminal using an Administrator Root Public Key held on the SIM. Each record of this EF contains one certificate descriptor.

This file shall contain only one record.

Identifier: ‘4F42’

Structure: linear fixed

Optional

Record length: X + 10 bytes, X ≥ 1

Update activity: low

Access Conditions:

READ CHV1

UPDATE ADM

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1

Parameters indicator

M

1 byte

2

Flags

M

1 byte

3

Type of certificate

M

1 byte

4 to 5

Key/certificate file identifier

M

2 bytes

6 to 7

Offset into key/certificate file

M

2 bytes

8 to 9

Length of key/certificate data

M

2 bytes

10

Key identifier length (X)

M

1 byte

11 to 10+X

Key identifier

M

X bytes

For contents and coding of all data items see the respective data items of the EFORPK (sub-clause 10.4.2.1).

10.4.2.4 EFTPRPK (Third Party Root Public key)

This EF contains descriptor(s ) of certificates containing the Third Party Root Public key (s). This EF shall only be allocated if the SIM issuer wishes to verify applications and certificates in the MExE Third Party domain using root public key(s) held on the SIM. This EF can contain one or more root public keys. Each record of this EF contains one certificate descriptor.

For example, an operator may provide several Third Party root public keys.

Identifier: ‘4F43’

Structure: linear fixed

Optional

Record length : X + Y + 11 bytes, X ≥ 1; Y ≥ 1

Update activity: low

Access Conditions:

READ CHV1

UPDATE ADM

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1

Parameters indicator

M

1 byte

2

Flags

M

1 byte

3

Type of certificate

M

1 byte

4 to 5

Key/certificate file identifier

M

2 bytes

6 to 7

Offset into key/certificate file

M

2 bytes

8 to 9

Length of key/certificate data

M

2 bytes

10

Key identifier length (X)

M

1 byte

11 to 10+X

Key identifier

M

X bytes

11+X

Certificate identifier length (m)

M

1 byte

12+X to 11+X+Y

Certificate identifier

M

Y bytes

‑ Certificate identifier length

Contents:
This field gives length of certificate identifier

Coding:
binary

‑ Certificate identifier

Contents:
This field identify the issuer and provide a easy way to find a certificate. For more information about value and usage, see TS 23.057 [50].

Coding:
Octet string

For contents and coding of all other data items see the respective data items of the EFORPK (sub-clause 10.7.1).

10.4.2.5 Trusted Key/Certificates Data Files

Residing under DFMExE, there may be several key/certificates data files. These EFs containing key/certificates data shall have the following attributes:

Identifier: ‘4FXX’

Structure: transparent

Optional

File size: Y bytes

Update activity: low

Access Conditions:

READ CHV1

UPDATE ADM

INVALIDATE ADM

REHABILITATE ADM

Bytes

Description

M/O

Length

1 to Y

Key/Certicates Data

M

Y bytes

Contents and coding:

Key/certificate data are accessed using the key/certificates descriptors provided by EFTPRPK (see sub-clause 10.4.2.4).

The identifier ‘4FXX’ shall be different from one key/certificate data file to the other. For the range of ‘XX’, see sub-clause 6.6. The length Y may be different from one key/certificate data file to the other.