4.4.2 Contents of files at the DF PHONEBOOK level

31.1023GPPCharacteristics of the Universal Subscriber Identity Module (USIM) applicationRelease 17TS

The Efs in the DF_PHONEBOOK level contain phone book related features as required in 3GPP TS 21.111 [1].

The UICC may contain a global phonebook, or application specific phonebooks, or both in parallel. When both phonebook types co-exist, they are independent and no data is shared. In this case, when the terminal supports application specific phonebooks, it shall be possible for the user to select which phonebook the user would like to access.

Support of the global phonebook is mandatory, except for Terminals of type ND, NK or NS, as specified in 3GPP TS 31.111 [12] Annex P, for which support is optional. Terminals that support the global phonebook shall conditionally support, the application specific phonebooks, also known as local phonebook. The support of local phone book is:

a) optional for terminals that support alternative phonebook applications; and

NOTE 1: Such terminals could be of type "Smartphone" as described in GSMA: "IMEI Allocation and Approval Process" [84].

b) mandatory for terminals that do not support alternative phonebook applications.

NOTE 2: Such terminals could be of type "Feature Phone" as described in GSMA: "IMEI Allocation and Approval Process" [84].

It is recommended that the terminal searches for the global phonebook located under DF_TELECOM as its presence is not indicated anywhere in the USIM application.

The global phonebook is located in DF_PHONEBOOK under DF_TELECOM.. Each specific USIM application phonebook is located in DF_PHONEBOOK of its respective Application ADF_USIM. The organisation of files in DF_PHONEBOOK under ADF_USIM and under DF _TELECOM follows the same rules. Yet DF_PHONEBOOK under ADF_USIM may contain a different set of files than DF_PHONEBOOK under DF_TELECOM. All phonebook related Efs are located under their respective DF_PHONEBOOK. USIM specific phonebooks are dedicated to application specific entries. Each application specific phonebook is protected by the application PIN.

EF_ADN and EF_PBR shall always be present if the DF_Phonebook is present. If any phonebook file other than EF_ADN or EF_EXT1, is used, then EF_PBC shall be present.

If a GSM application resides on the UICC, the Efs ADN and EXT1 from one DF_PHONEBOOK (defined at GSM application installation) are mapped to DF_TELECOM. Their file Ids are specified in 3GPP TS 51.011 [18], i.e. EF_ADN = ‘6F3A’ and EF_EXT1 = ‘6F4A’, respectively.

If the UICC is inserted into a terminal accessing the ADN and EXT1 files under DF_TELECOM; and a record in these files has been updated, a flag in the corresponding entry control information in the EF_PBC is set from 0 to 1 by the UICC. If the UICC is later inserted into a terminal that supports the global and/or application specific phonebook, the terminal shall check the flag in EF_PBC and if this flag is set, shall update the EF_CC, and then reset the flag. A flag set in EF_PBC results in a full synchronisation of the phonebook between an external entity and the UICC (if synchronisation is requested).

The EF structure related to the public phonebook is located under DF_PHONEBOOK in DF_TELECOM. A USIM specific phonebook may exist for application specific entries. The application specific phonebook is protected by the application PIN. The organisation of files in the application specific phonebook follows the same rules as the one specified for the public phone book under DF_TELECOM. The application specific phonebook may contain a different set of files than the one in the public area under DF_TELECOM.

4.4.2.1 EF_PBR (Phone Book Reference file)

This file describes the structure of the phonebook. All Efs representing the phonebook are specified here (with the exception of EF_PSC, EF_PUID and EF_CC), together with their file identifiers (FID) and their short file identifiers (SFI), if applicable.

Certain kinds of Efs can occur more than once in the phonebook, e.g. there may be two entities of Abbreviated Dialling Numbers, EF_ADN and EF_ADN1. For these kinds of Efs, no fixed FID values are specified. Instead, the value ‘4FXX’ indicates that the value is to be assigned by the card issuer. These assigned values are then indicated in the associated TLV object in EF_PBR.

The SFI value assigned to an EF which is indicated in EF_PBR shall correspond to the SFI indicated in the TLV object in EF_PBR.

The reference file is a file that contains information how the information in the different files is to be combined together to form a phone book entry. The reference file contains records. Each record specifies the structure of up to 254 entries in the phone book. Each phone book entry consists of data stored in files indicated in the reference file record. The entry structure shall be the same over all the records in the EF _PBR. If more than 254 entries are to be stored, a second record is needed in the reference file. The structure of a phone book entry is defined by different TLV objects that are stored in a reference file record. The reference file record structure describes the way a record in a file that is part of the phonebook is used to create a complete entry. Three different types of file linking exist.

Type 1 files: Files that contain as many records as the reference/master file (EF_ADN, EF_ADN1) and are linked on record number bases (Rec1 -> Rec1). The master file record number is the reference.

Type 2 files: Files that contain less entries than the master file and are linked via pointers in the index administration file (EF_IAP).

Type 3 files: Files that are linked by a record identifier within a record.

Table 4.1: Phone Book Reference file Constructed Tags

Tag Value	Constructed TAG Description
‘A8’	Indicating files where the amount of records equal to master EF, type 1
‘A9’	Indicating files that are linked using the index administration file, type 2. Order of pointer appearance in index administration EF is the same as the order of file Ids following this tag
‘AA’	Indicating files that are linked using a record identifier, type 3. (The file pointed to is defined by the TLV object.)

The first file ID in the first record of EF_PBR indicated using constructed Tag ‘A8’ is called the master EF. Access conditions for all other files in the Phonebook structure using Tags ‘A8’, ‘A9’ or ‘AA’ is set to the same as for the master EF unless otherwise specified in the present document.

File Ids indicated using constructed Tag ‘A8’ is a type 1 file and contains the same number of records as the first file that is indicated in the data part of this TLV object. All files following this Tag are mapped one to one using the record numbers/Ids of the first file indicated in this TLV object.

File Ids indicated using constructed Tag ‘A9’ are mapped to the master EF (the file ID indicated as the first data object in the TLV object using Tag ‘A8’) using the pointers in the index administration file. The order of the pointers in the index administration file is the same as the order of the file Ids presented after Tag ‘A9’. If this Tag is not present in the reference file record the index administration file is not present in the structure. In case the index administration file is not present in the structure it is not indicated in the data following tag ‘A8’.

File Ids indicated using constructed Tag ‘AA’ indicate files that are part of the reference structure but they are addressed using record identifiers within a record in one or more of the files that are part of the reference structure. The length of the tag indicates whether the file to be addressed resides in the same directory or if a path to the file is provided in the TLV object.

Type 2 and type 3 files contain records that may be shared between several phonebook entries (except when otherwise indicated). The terminal shall ensure that a shared record is emptied when the last phonebook entry referencing it is modified in such a way that it doesn’t reference the record anymore.

NOTE: in the current version of the specification, only type 3 files contain records that may be shared.

Each constructed Tag contains a list of primitive Tags indicating the order and the kind of data (e.g. ADN, IAP,…) of the reference structure.

The primitive tag identifies clearly the type of data, its value field indicates the file identifier and, if applicable, the SFI value of the specified EF. That is, the length value of a primitive tag indicates if an SFI value is available for the EF or not:

– Length = ’02’ Value: ‘FID (2 bytes)’

– Length = ’03’ Value: ‘FID (2 bytes)’, ‘SFI (1 byte)’

Table 4.2: Tag definitions for the phone book kind of file

Tag Value	TAG Description
‘C0’	EFADN data object
‘C1’	EFIAP data object
‘C2’	EFEXT1 data object
‘C3’	EFSNE data object
‘C4’	EFANR data object
‘C5’	EFPBC data object
‘C6’	EFGRP data object
‘C7’	EFAAS data object
‘C8’	EFGAS data object
‘C9’	EFUID data object
‘CA’	EFEMAIL data object
‘CB’	EFCCP1 data object
‘CC’	EFPURI data object

Table 4.3 (below) lists the allowed types for each kind of file:

Table 4.3: Presence of files as type

File name	Type 1	Type 2	Type 3
EFAAS			X
EFADN	X
EFANR	X	X
EFEMAIL	X	X
EFEXT1			X
EFGAS			X
EFGRP	X
EFIAP	X
EFPBC	X
EFSNE	X	X
EFUID	X
EFCCP1			X
EFPURI	X	X

Phone Book Reference file EF_PBR structure

Identifier: ‘4F30’		Structure: linear fixed			Conditional (see Note)
Record Length: X bytes			Update activity: low
Access Conditions: READ PIN UPDATE ADM DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	TLV object(s) for indicating Efs that are part of the phone book structure			M		X bytes
NOTE: This file is mandatory if and only if DFPhonebook is present.

At the end of each record, unused bytes, if any, shall be filled with ‘FF’.

4.4.2.2 EF_IAP (Index Administration Phone book)

This file is present if Tag ‘A9’ is indicated in the reference file.

The EF contains pointers to the different records in the files that are part of the phone book. The index administration file record number/ID is mapped one to one with the corresponding EF_ADN (shall be record to record). The index administration file contains the same amount of records as EF_ADN. The order of the pointers in an EF_IAP shall be the same as the order of file Ids that appear in the TLV object indicated by Tag ‘A9’ in the reference file record. The amount of bytes in a record is equal to the number of files indicated the EF_PBR following tag ‘A9’.

The value ‘FF’ is an invalid record number/ID and is used in any location in to indicate that no corresponding record in the indicated file is available.

The content of EF_IAP is set to ‘FF’ at the personalisation stage.

Index administration file EF_IAP structure

Identifier: ‘4FXX’		Structure: linear fixed			Conditional (see Note)
SFI: ‘YY’
Record Length: X bytes, (X ≥ 1)			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1	Record number of the first object indicated after Tag ‘A9’			M		1 byte
2	Record number of the second object indicated after Tag ‘A9’			C		1 byte
X	Record number of the xth object indicated after Tag ‘A9’			C		1 byte
NOTE 1: This file is mandatory if and only if type 2 files are present. NOTE 2: xth-field marked with ‘C’ is mandatory if xth-object indicated following tag ‘A9’ is present in EFPBR

4.4.2.3 EF_ADN (Abbreviated dialling numbers)

This EF contains Abbreviated Dialling Numbers (ADN) and/or Supplementary Service Control strings (SSC). In addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also contain an associated alpha‑tagging.

Identifier: ‘4FXX’		Structure: linear fixed			Conditional (see Note)
SFI: ‘YY’
Record length: X+14 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	Alpha Identifier			O		X bytes
X+1	Length of BCD number/SSC contents			M		1 byte
X+2	TON and NPI			M		1 byte
X+3 to X+12	Dialling Number/SSC String			M		10 bytes
X+13	Capability/Configuration1 Record Identifier			M		1 byte
X+14	Extension1 Record Identifier			M		1 byte
NOTE: This file is mandatory if and only if DFPHONEBOOK is present.

‑ Alpha Identifier.

Contents:

– Alpha‑tagging of the associated dialling number.

Coding:

– this alpha‑tagging shall use either:

– the SMS default 7‑bit coded alphabet as defined in TS 23.038 [5] 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 the annex of TS 31.101 [11].

NOTE 1: The value of X may be from zero to 241. Using the command GET RESPONSE the ME can determine the value of X.

‑ Length of BCD number/SSC contents.

Contents:

– this byte gives the number of bytes of the following two data items containing actual BCD number/SSC information. This means that the maximum value is 11, even when the actual ADN/SSC information length is greater than 11. When an ADN/SSC has extension, it is indicated by the extension1 identifier being unequal to ‘FF’. The remainder is stored in the EF_EXT1 with the remaining length of the additional data being coded in the appropriate additional record itself (see clause 4.4.2.4).

Coding:

– according to TS 24.008 [9].

‑ TON and NPI.

Contents:

– Type of number (TON) and numbering plan identification (NPI).

Coding:

– according to TS 24.008 [9]. If the Dialling Number/SSC String does not contain a dialling number, e.g. a control string deactivating a service, the TON/NPI byte shall be set to ‘FF’ by the ME (see note 2).

NOTE 2: If a dialling number is absent, no TON/NPI byte is transmitted over the radio interface (see TS 24.008 [9]). Accordingly, the ME should not interpret the value ‘FF’ and not send it over the radio interface.

B8

b7

b6

b5

b4

b3

b2

b1

NPI

TON

1

‑ Dialling Number/SSC String

Contents:

– up to 20 digits of the telephone number and/or SSC information.

Coding:

– according to TS 24.008 [9], TS 22.030 [4] and the extended BCD‑coding (see table 4.4). If the telephone number or SSC is longer than 20 digits, the first 20 digits are stored in this data item and the remainder is stored in an associated record in the EF_EXT1. The record is identified by the Extension1 Record Identifier. If ADN/SSC require less than 20 digits, excess nibbles at the end of the data item shall be set to ‘F’. Where individual dialled numbers, in one or more records, of less than 20 digits share a common appended digit string the first digits are stored in this data item and the common digits stored in an associated record in the EF_EXT1. The record is identified by the Extension 1 Record Identifier. Excess nibbles at the end of the data item shall be set to ‘F’.

Byte X+3

B8

b7

B6

b5

b4

b3

b2

b1

LSB of Digit 1

:

:

MSB of Digit 1

LSB of Digit 2

:

:

MSB of Digit 2

Byte X+4:

B8

b7

B6

b5

b4

b3

b2

b1

LSB of Digit 3

:

:

MSB of Digit 3

LSB of Digit 4

:

:

MSB of Digit 4

etc.

‑ Capability/Configuration1 Record Identifier.

Contents:

– capability/configuration identification byte. This byte identifies the number of a record in the EF_CCP1 containing associated capability/configuration parameters required for the call. The use of this byte is optional. If it is not used it shall be set to ‘FF’.

Coding:

– binary.

‑ Extension1 Record Identifier.

Contents:

– extension1 record identification byte. This byte identifies the number of a record in the EF_EXT1 containing an associated called party subaddress or additional data. The use of this byte is optional. If it is not used it shall be set to ‘FF’.

– if the ADN/SSC requires both additional data and called party subaddress, this byte identifies the additional record. A chaining mechanism inside EF_EXT1 identifies the record of the appropriate called party subaddress (see clause 4.4.2.4).

Coding:

– binary.

NOTE 3: EF_ADN in the public phone book under DF_TELECOM may be used by USIM, GSM and also other applications in a multi‑application card. If the non‑GSM application does not recognise the use of Type of Number (TON) and Number Plan Identification (NPI), then the information relating to the national dialling plan shall be held within the data item dialling number/SSC and the TON and NPI fields set to UNKNOWN. This format would be acceptable for 3GPP network operation and also for the non‑GSM application where the TON and NPI fields shall be ignored.

EXAMPLE: SIM storage of an International Number using E.164 [22] numbering plan.

TON NPI Digit field.

USIM application 001 0001 abc…

Other application compatible with 3GPP specification 000 0000 xxx…abc…

where "abc…" denotes the subscriber number digits (including its country code), and "xxx…" denotes escape digits or a national prefix replacing TON and NPI.

NOTE 4: When the ME acts upon the EF_ADN with a SEARCH RECORD command in order to identify a character string in the alpha‑identifier, it is the responsibility of the ME to ensure that the number of characters used as SEARCH RECORD parameters are less than or equal to the value of X if the MMI allows the user to offer a greater number.

Table 4.4: Extended BCD coding

BCD Value	Character/Meaning
‘0’	"0"
:	:
‘9’	"9"
‘A’	"*"
‘B’	"#"
‘C’	DTMF Control digit separator (see TS 22.101 [24]).
‘D’	"Wild" value. This will cause the MMI to prompt the user for a single digit (see TS 22.101 [24]).
‘E’	RFU.
‘F’	Endmark e.g. in case of an odd number of digits.

BCD values ‘C’, ‘D’ and ‘E’ are never sent across the radio interface.

NOTE 5: The interpretation of values ‘D’, ‘E’ and ‘F’ as DTMF digits is for further study.

NOTE 6: A second or subsequent ‘C’ BCD value will be interpreted as a 3 second PAUSE (see TS 22.101 [24]).

4.4.2.4 EF_EXT1 (Extension1)

This EF contains extension data of an ADN/SSC.

Extension data is caused by:

‑ an ADN/SSC which is greater than the 20 digit capacity of the ADN/SSC Elementary File or where common digits are required to follow an ADN/SSC string of less than 20 digits. The remainder is stored in this EF as a record, which is identified by a specified identification byte inside the ADN/SSC Elementary File. The EXT1 record in this case is specified as additional data;

‑ an associated called party subaddress. The EXT1 record in this case is specified as subaddress data.

Identifier: ‘4FXX’		Structure: linear fixed			Optional
SFI: ‘YY’
Record length: 13 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1	Record type			M		1 byte
2 to 12	Extension data			M		11 bytes
13	Identifier			M		1 byte

‑ Record type.

Contents:

– type of the record.

Coding:

B8

b7

b6

b5

b4

b3

b2

b1

Called Party Subaddress

Additional data

RFU

– b3 to b8 are reserved and set to 0;

– a bit set to 1 identifies the type of record;

– only one type can be set;

– ’00’ indicates the type "unknown" or "free".

The following example of coding means that the type of extension data is "additional data":

		B8		b7		b6		b5		b4		b3		b2		b1
		0		0		0		0		0		0		1		0

‑ Extension data.

Contents:
additional data or Called Party Subaddress depending on record type.

Coding:

Case 1, Extension1 record is additional data:

– The first byte of the extension data gives the number of bytes of the remainder of ADN/SSC. The coding of remaining bytes is BCD, according to the coding of ADN/SSC. Unused nibbles at the end shall be set to ‘F’. It is possible if the number of additional digits exceeds the capacity of the additional record to chain another record inside the EXT1 Elementary File by the identifier in byte 13. In this case byte 2 (first byte of the extension data) of all records for additional data within the same chain indicates the number of bytes (’01’ to ‘0A’) for ADN/SSC (respectively MSISDN, LND) within the same record unequal to ‘FF’.

Case 2, Extension1 record is Called Party Subaddress:

– The subaddress data contains information as defined for this purpose in TS 24.008 [9]. All information defined in TS 24.008 [9], except the information element identifier, shall be stored in the USIM. The length of this subaddress data can be up to 22 bytes. In those cases where two extension records are needed, these records are chained by the identifier field. The extension record containing the first part of the called party subaddress points to the record which contains the second part of the subaddress.

‑ Identifier.

Contents:
identifier of the next extension record to enable storage of information longer than 11 bytes.

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

– Example of a chain of extension records being associated to an ADN/SSC. The extension1 record identifier (Byte 14+X) of EF_ADN is set to 3.

In this example, ADN/SSC is associated to additional data (records 3 and 4) which represent the last 27 or 28 digits of the whole ADN/SSC (the first 20 digits are stored in EF_ADN) and a called party subaddress whose length is more than 11 bytes (records 6 and 1).

4.4.2.5 EF_PBC (Phone Book Control)

This EF contains control information related to each entry in the phone book. This EF contains as many records as the EF_ADN associated with it (shall be record to record). Each record in EF_PBC points to a record in its EF_ADN. This file indicates the control information and the hidden information of each phone book entry.

The content of EF_PBC is linked to the associated EF_ADN record by means of the ADN record number/ID (there is a one to one mapping of record number/identifiers between EF_PBC and EF_ADN).

Structure of control file EF_PBC

Identifier: ‘4FXX’		Structure: linear fixed			Conditional (see Note)
SFI: ‘YY’
Record length: 2 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1	Entry Control Information			M		1 byte
2	Hidden Information			M		1 byte
NOTE: This file is mandatory if one or both of the following is true: – hidden entries are supported – a GSM SIM application is supported in the UICC.

‑ Entry Control Information.

Contents:

– provides some characteristics about the phone book entry e.g. modification by a terminal accessing the ADN and EXT1 files under DF_TELECOM (see clause 4.4.2).

Coding:

b8

B7

b6

B5

b4

B3

b2

B1

Modified phonebook entry ‘1’, no change ‘0’

RFU (see TS 31.101)

‑ Hidden Information.

Contents:
indicates to which USIM application of the UICC this phone book entry belongs, so that the corresponding secret code can be verified to display the phone book entry. If the secret code is not verified, then the phone book entry is hidden.

Coding:
’00’ – the phone book entry is not hidden;
‘xx’ – the phone book entry is hidden. ‘xx’ is the record number in EF_DIR of the associated USIM application.

4.4.2.6 EF_GRP (Grouping file)

This EF contains the grouping information for each phone book entry. This file contains as many records as the associated EF_ADN. Each record contains a list of group identifiers, where each identifier can reference a group to which the entry belongs.

Structure of grouping file EF_GRP

Identifier: ‘4FXX’		Structure: linear fixed			Conditional (see Note)
SFI: ‘YY’
Record Length: X bytes (1 ≤ X ≤10)			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1	Group Name Identifier 1			M		1 byte
2	Group Name Identifier 2			O		1 byte
X	Group Name Identifier X			O		1 byte
NOTE: This file is mandatory if and only if EFGAS is present.

‑ Group Name Identifier x.

Content:
– indicates if the associated entry is part of a group, in that case it contains the record number of the group name in EF_GAS.
– One entry can be assigned to a maximum of 10 groups.

Coding:
– ’00’ – no group indicated;
‘XX’ – record number in EF_GAS containing the alpha string naming the group of which the phone book entry is a member.

4.4.2.7 EF_AAS (Additional number Alpha String)

This file contains the alpha strings that are associated with the user defined naming tags for additional numbers referenced in EF_ANR.

Structure of EF_AAS

Identifier: ‘4FXX’		Structure: linear fixed			Optional
SFI: Optional
Record length: X bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	Alpha text string			M		X bytes

‑ Alpha text string.

Content:
– user defined text for additional number.

Coding:
– same as the alpha identifier in EF_ADN.

4.4.2.8 EF_GAS (Grouping information Alpha String)

This file contains the alpha strings that are associated with the group name referenced in EF_GRP.

Structure of EF_GAS

Identifier: ‘4FXX’		Structure: linear fixed			Conditional (see Note)
SFI: Optional
Record length: X bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	Alpha text string			M		X bytes
NOTE: This file is mandatory if and only if EFGRP is present.

‑ Alpha text string

Content:
– group names.

Coding:
– same as the alpha identifier in EF_ADN.

4.4.2.9 EF_ANR (Additional Number)

Several phone numbers and/or Supplementary Service Control strings (SSC) can be attached to one EF_ADN record, using one or several EF_ANR. The amount of additional number entries may be less than or equal to the amount of records in EF_ADN. The EF structure is linear fixed. Each record contains an additional phone number or Supplementary Service Control strings (SSC). This record cannot be shared between several phonebook entries. The first byte indicates whether the record is free or the type of additional number referring to the record number in EF_AAS, containing the text to be displayed. The following part indicates the additional number and the reference to the associated record in the EF_ADN file. In addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records.

Structure of EF_ANR

Identifier: ‘4FXX’		Structure: linear fixed			Optional
SFI: ‘YY’
Record length: 15 or 17 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1	Additional Number Record identifier			M		1 byte
2	Length of BCD number/SSC contents			M		1 byte
3	TON and NPI			M		1 byte
4 to 13	Additional number/SSC String			M		10 bytes
14	Capability/Configuration1 Record Identifier			M		1 byte
15	Extension1 Record Identifier			M		1 byte
16	ADN file SFI			C		1 byte
17	ADN file Record Identifier			C		1 byte
NOTE: The fields marked C above are mandatory if and only if the file is not type 1 (as specified in EFPBR)

‑ Additional Number Record Identifier

Content:
– describes the type of the additional number defined in the file EF_AAS.

Coding:
– ’00’ – no additional number description;
‘xx’ – record number in EF_AAS describing the type of number (e.g. "FAX");
‘FF’ – free record.

– Length of BCD number/SSC contents

Contents:
– this byte gives the number of bytes of the following two data items containing actual BCD number/SSC information. This means that the maximum value is 11, even when the actual additional number/SSC information length is greater than 11. When the additional number/SSC has extension, it is indicated by the extension1 identifier being unequal to ‘FF’. The remainder is stored in the EF_EXT1 with the remaining length of the additional data being coded in the appropriate additional record itself (see clause 4.4.2.4).

Coding:
– same as the length of BCD number/SSC string byte in EF_ADN.

‑ TON and NPI.

Contents:
– Type of number (TON) and numbering plan identification (NPI).

Coding:
– same as the TON and NPI byte in EF_ADN.

‑ Additional number/SSC string

Content:
– up to 20 digits of the additional phone number and/or SSC information linked to the phone book entry.

Coding:
– same as the dialling number /SSC string in EF_ADN.

‑ Capability/Configuration1 Record Identifier.

Contents:
– This byte identifies the number of a record in the EF_CCP1 containing associated capability/configuration parameters required for the call. The use of this byte is optional. If it is not used it shall be set to ‘FF’.

Coding:
– binary.

‑ Extension1 Record Identifier.

Contents:
– extension1 record identification byte. This byte identifies the number of a record in the EF_EXT1 containing an associated called party subaddress or additional data. The use of this byte is optional. If it is not used it shall be set to ‘FF’.
if the number requires both additional data and called party subaddress, this byte identifies the additional record. A chaining mechanism inside EF_EXT1 identifies the record of the appropriate called party subaddress (see clause 4.4.2.4).

Coding:
– binary.

‑ ADN file SFI.

Content:
– Short File identifier of the associated EF_ADN file.

Coding:
– as defined in the UICC specification.

‑ ADN file Record Identifier

Content:
– record identifier of the associated phone book entry.

Coding:
– ‘xx’ – record identifier of the corresponding ADN record.

4.4.2.10 EF_SNE (Second Name Entry)

The phone book also contains the option of a second name entry. The amount of second name entries may be less than or equal to the amount of records in EF_ADN. Each record contains a second name entry. This record cannot be shared between several phonebook entries.

Structure of EF_SNE

Identifier: ‘4FXX’		Structure: linear fixed			Optional
SFI: ‘YY’
Record length: X or X+2 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	Alpha Identifier of Second Name			M		X bytes
X+1	ADN file SFI			C		1 byte
X+2	ADN file Record Identifier			C		1 byte
NOTE: The fields marked C above are mandatory if and only if the file is not type 1 (as specified in EFPBR)

‑ Alpha Identifier of Second Name.

Content:
– string defining the second name of the phone book entry.

Coding:
– as the alpha identifier for EF_ADN.

‑ ADN file SFI.

Content:
– Short File identifier of the associated EF_ADN file.

Coding:
– as defined in the UICC specification.

‑ ADN file Record Identifier

Content:
record identifier of the associated phone book entry.

Coding:
‘xx’ – record identifier of the corresponding ADN record.

4.4.2.11 EF_CCP1 (Capability Configuration Parameters 1)

This EF contains parameters of required network and bearer capabilities and ME configurations associated with a call established using a phone book entry.

Structure of EF_CCP1

Identifier: ‘4FXX’		Structure: linear fixed			Optional
SFI: ‘YY’
Record length: X bytes, X ≥ 15			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	Bearer capability information element			M		X bytes

‑ Bearer capability information element.

Contents and Coding:
– see TS 24.008 [9]. The Information Element Identity (IEI) shall be excluded; i.e. the first byte of the EF_CCP1 record shall be Length of the bearer capability contents.

”- unused bytes are filled with ‘FF’

4.4.2.12 Phone Book Synchronisation

To support synchronisation of phone book data with other devices, the USIM may provide the following files to be used by the synchronisation method: a phone book synchronisation counter (PSC), a unique identifier (UID) and change counter (CC) to indicate recent changes.

If synchronisation is supported in the phonebook, then EF_PSC, EF_UID, EF_PUID and EF_CC are all mandatory.

4.4.2.12.1 EF_UID (Unique Identifier)

The EF_UID is used to uniquely identify a record and to be able to keep track of the entry in the phone book. The terminal assigns the (UID) when a new entry is created. The value of the UID does not change as long as the value of the PBID remains the same. The UID shall remain on the UICC, in EF_UID, until the PBID is regenerated. This means that when a phone book entry is deleted, the content of the linked information (e.g. ADN, E-MAIL,..) shall be set to the personalization value ‘FF…FF’. But the UID-value of the deleted record shall not be used when a new entry is added to the phonebook until the PBID is regenerated, but it shall be set to a new value.

If/when the PBID is regenerated, all UIDs for the entry in the phone book shall be assigned new values starting from 1. If more than one EF_UID exists (i.e. multiple phone book file sets) then all values of UIDs used in that phone book shall be unique over all phone book file sets within that phone book. The new value of the UID for each entry shall then be kept until the PBID is regenerated again.

Structure of EF_UID

Identifier: ‘4FXX’		Structure: linear fixed			Conditional (see Note)
SFI: ‘YY’
Record length: 2 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to 2	Unique Identifier (UID) of Phone Book Entry			M		2 bytes
NOTE: This file is mandatory if and only if synchronisation is supported in the phonebook.

‑ Unique Identifier of Phone Book Entry.

Content:
– number to unambiguously identify the phone book entry for synchronisation purposes.

Coding:
– hexadecimal value. At initialisation all UIDs are personalised to ”00 00” (i.e. empty).

4.4.2.12.2 EF_PSC (Phone book Synchronisation Counter)

The phone book synchronisation counter (PSC) is used by the ME to construct the phone book identifier (PBID) and to determine whether the accessed phone book is the same as the previously accessed phone book or if it is a new unknown phone book (might be the case that there is one phonebook under DF-telecom and one phone book residing in a USIM-application). If the PSC is unknown, a full synchronisation of the phone book will follow.

The PSC is also used to regenerate the UIDs and reset the CC to prevent them from running out of range. When the UIDs or the CC has reached its maximum value, a new PSC is generated. This leads to a scenario where neither the CC nor the UIDs will run out of range.

The PSC shall be regenerated by the terminal if one of the following situation applies:

– the values of the UIDs have run out of range;

– the whole phone book has been reset/deleted;

– the value of the CC has run out of range.

Structure of EF_PSC

Identifier: ‘4F22’		Structure: transparent			Conditional (see Note)
SFI: ‘YY’
File size: 4 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to 4	Phone book synchronisation counter (PSC)			M		4 bytes
NOTE: This file is mandatory if and only if synchronisation is supported in the phonebook.

‑ PSC: Unique synchronisation counter of Phone Book.

Content:
number to unambiguously identify the status of the phone book for synchronisation purposes.

Coding:
hexadecimal value.

The phone book identifier (PBID) coding based on the EF_PSC is described hereafter:

– For a phone book residing in DF-telecom:

– PBID = ICCid (10bytes) "fixed part" + 4 bytes (in EF_PSC) "variable part".

– For a phone book residing in an USIM application:

– PBID = 10 last bytes of (ICCid XOR AID) "fixed part" + 4 bytes (in EF_PSC) "variable part".

To be able to detect if the PSC needs to be regenerated (i.e. the variable part) the following test shall be made by the terminal before for each update of either the CC or the assignment of a new UID:

– Each time the terminal has to increment the value of the UID the following test is needed:

– If UID = ‘FF FF’ then.

{Increment PSC mod ‘FF FF FF FF’; all the UIDs shall be regenerated}.

– Each time the terminal has to increment the value of CC the following test is needed:

If CC = ‘FF FF’ then.

{Increment PSC mod ‘FF FF FF FF’; CC=0001}.

NOTE: If the phonebook is deleted then the terminal will change the PSC according to:

Incrementing PSC modulus ‘FFFFFFFF’.

4.4.2.12.3 EF_CC (Change Counter)

The change counter (CC) shall be used to detect changes made to the phone book.

Every update/deletion of an existing phone book entry or the addition of a new phone book entry causes the terminal to increment the EF_CC. The concept of having a CC makes it possible to update the phone book in different terminals, which still are able to detect the changes (e.g. changes between different handset and/or 2^nd and 3^rd generation of terminals).

Structure of EF_CC

Identifier: ‘4F23’		Structure: transparent			Conditional (see Note)
SFI: ‘YY’
File size: 2 bytes			Update activity: high
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to 2	Change Counter (CC) of Phone Book			M		2 bytes
NOTE: This file is mandatory if and only if synchronisation is supported in the phonebook.

‑ Change Counter of Phone Book.

Content:
– indicates recent change(s) to phone book entries for synchronisation purposes.

Coding:
– hexadecimal value. At initialisation, CC shall be personalised to ’00 00′ (i.e. empty).

4.4.2.12.4 EF_PUID (Previous Unique Identifier)

The PUID is used to store the previously used unique identifier (UID). The purpose of this file is to allow the terminal to quickly generate a new UID, which shall then be stored in the EF_UID.

Structure of EF_PUID

Identifier: ‘4F24’		Structure: transparent			Conditional (see Note)
SFI: ‘YY’
File size: 2 bytes			Update activity: high
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to 2	Previous Unique Identifier (PUID) of Phone Book Entry			M		2 bytes
NOTE: This file is mandatory if and only if synchronisation is supported in the phonebook.

‑ Previous unique Identifier of Phone Book Entry.

Content:
– Previous number that was used to unambiguously identify the phone book entry for synchronisation purposes.

Coding:

– As for EF_UID

4.4.2.13 EF_EMAIL (e-mail address)

This EF contains the e-mail addresses that may be linked to a phone book entry. Several e-mail addresses can be attached to one EF_ADN record, using one or several EF_EMAIL. The number of email addresses may be equal to or less than the amount of records in EF_ADN. Each record contains an e-mail address. The first part indicates the e-mail address, and the second part indicates the reference to the associated record in the EF_ADN file. This record cannot be shared between several phonebook entries.

Structure of EF_EMAIL

Identifier: ‘4FXX’		Structure: linear fixed			Optional
SFI: ‘YY’
Record length: X or X+2 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	E-mail Address			M		X bytes
:	:			:		:
:	:			:		:
X+1	ADN file SFI			C		1 byte
X+2	ADN file Record Identifier			C		1 byte
NOTE: The fields marked C above are mandatory if and only if the file is not type 1 (as specified in EFPBR)

‑ E-mail Address.

Content:
– string defining the e-mail address

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

‑ ADN file SFI.

Content:
– short File identifier of the associated EF_ADN file.

Coding:
– as defined in TS 31.101 [11].

‑ ADN file Record Identifier.

Content:
– record identifier of the associated phone book entry.

Coding:
– binary.

4.4.2.14 Phonebook restrictions

This clause lists some general restrictions that apply to the phonebook:

– if an EF_PBR file contains more than one record, then they shall all be formatted identically on a type-by-type basis, e.g. if EF_PBR record #1 contains one type 1 e-mail then all EF_PBR records shall have one type 1 email;

– if an EF_PBR record contains more than one reference to one kind of file, such as two EF_EMAIL files, then they shall all be formatted identically on a type-by-type basis, e.g. if an EF_PBR record has 2 email addresses, then they shall have the same record size and the same number of records in each EF_PBR entry;

– an EF_PBR record may contain TLV entries indicating that the file exist as a type 1 and 2 file, e.g. a phonebook entry may have two emails, one with a one-to-one mapping (type 1) and one with a indirect mapping (type 2). Regardless of the type, files in all entries shall have the same record configuration;

– an EF_PBR record shall not contain more than one occurrence of a given kind of file indicated in tag ‘AA’ (type 3 link). For instance, an EF_PBR record may only contain one reference to an EF_EXT1.

4.4.2.15 EF_PURI (Phonebook URIs)

This EF contains the URI address that may be linked to a phonebook entry. Several URI addresses can be attached to one EF_ADN record, using one or several EF_PURI. The number of URI addresses may be equal to or less than the amount of records in EF_ADN. Each record contains a URI address. The first part indicates the URI address, and the second part indicates the reference to the associated record in the EF_ADN file. This record cannot be shared between several phonebook entries.

Structure of EF_PURI

Identifier: ‘4FXX’		Structure: linear fixed			Optional
SFI: ‘YY’
Record length: X or X+2 bytes			Update activity: low
Access Conditions: READ PIN UPDATE PIN DEACTIVATE ADM ACTIVATE ADM
Bytes	Description			M/O		Length
1 to X	URI Address			M		X bytes
X+1	ADN file SFI			C		1 byte
X+2	ADN file Record Identifier			C		1 byte
NOTE: The fields marked C above are mandatory if and only if the file is not type 1 (as specified in EFPBR)

‑ URI Address.

Content:
– The URI Address associated to the ADN Record.

Coding:
– Same as URI TLV data object in EF_IMPU defined in TS 31.103 [64].

‑ ADN file SFI.

Content:
– Short File identifier of the associated EF_ADN file.

Coding:
– as defined in TS 31.101 [11].

‑ ADN file Record Identifier.

Content:
– record identifier of the associated phone book entry.

Coding:
– binary.