Content for TS 31.102 Word version: 18.5.0

0… 3… 4… 4.2.9… 4.2.17… 4.2.26… 4.2.34… 4.2.44… 4.2.52… 4.2.60… 4.2.68… 4.2.76… 4.2.85… 4.2.93… 4.2.101… 4.2.107… 4.3… 4.4.2… 4.4.2.4… 4.4.3… 4.4.4… 4.4.5… 4.4.6… 4.4.8… 4.4.8.7… 4.4.9… 4.4.11… 4.4.11.7… 4.4.11.17… 4.4.12… 4.5… 4.6… 4.6.5… 4.6.6… 4.7 5… 5.2… 5.3… 5.4… 5.9… 6… 7… 7.1.2… 7.3… A B… D E… G H… I… L… M…

4.4.2.4 EF_EXT1 (Extension1) 4.4.2.5 EF_PBC (Phone Book Control) 4.4.2.6 EF_GRP (Grouping file) 4.4.2.7 EF_AAS (Additional number Alpha String) 4.4.2.8 EF_GAS (Grouping information Alpha String) 4.4.2.9 EF_ANR (Additional Number) 4.4.2.10 EF_SNE (Second Name Entry) 4.4.2.11 EF_CCP1 (Capability Configuration Parameters 1) 4.4.2.12 Phone Book Synchronisation 4.4.2.13 EF_EMAIL (e-mail address) 4.4.2.14 Phonebook restrictions 4.4.2.15 EF_PURI (Phonebook URIs)
...

4.4.2.4 EF_EXT1 (Extension1) p. 143

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
RFU						Additional data	Called Party Subaddress

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. All information defined in TS 24.008, 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 EFADN 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 EFADN) 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) p. 145

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

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

Structure of control file EFPBC

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 DFTELECOM (see clause 4.4.2).

Coding:

b8	b7	b6	b5	b4	b3	b2	b1
RFU (see TS 31.101)							Modified phonebook entry '1', no change '0'

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 EFDIR of the associated USIM application.

4.4.2.6 EF_GRP (Grouping file) p. 146

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

Structure of grouping file EFGRP

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 EFGAS.
One entry can be assigned to a maximum of 10 groups.

Coding:

'00' - no group indicated;

'XX' - record number in EFGAS 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) p. 146

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

Structure of EFAAS

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 EFADN.

4.4.2.8 EF_GAS (Grouping information Alpha String) p. 147

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

Structure of EFGAS

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 EFADN.

4.4.2.9 EF_ANR (Additional Number) p. 147

Several phone numbers and/or Supplementary Service Control strings (SSC) can be attached to one EFADN record, using one or several EFANR. The amount of additional number entries may be less than or equal to the amount of records in EFADN. 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 EFAAS, containing the text to be displayed. The following part indicates the additional number and the reference to the associated record in the EFADN file. In addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records.

Structure of EFANR

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 EFAAS.

Coding:

'00' - no additional number description;

'xx' - record number in EFAAS 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 EFEXT1 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 EFADN.

TON and NPI

Contents:

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

Coding:

same as the TON and NPI byte in EFADN.

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 EFADN.

Capability/Configuration1 Record Identifier

Contents:

This byte identifies the number of a record in the EFCCP1 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 EFEXT1 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 EFEXT1 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 EFADN 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) p. 149

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 EFADN. Each record contains a second name entry. This record cannot be shared between several phonebook entries.

Structure of EFSNE

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 EFADN.

ADN file SFI

Content:

Short File identifier of the associated EFADN 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) p. 150

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 EFCCP1

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. The Information Element Identity (IEI) shall be excluded; i.e. the first byte of the EFCCP1 record shall be Length of the bearer capability contents.

Unused bytes are filled with 'FF'.

4.4.2.12 Phone Book Synchronisation p. 150

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 EFPSC, EFUID, EFPUID and EFCC are all mandatory.

4.4.2.12.1 EF_UID (Unique Identifier) p. 150

The EFUID 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 EFUID, 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 EFUID 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 EFUID

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) p. 151

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 EFPSC

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 EFPSC is described hereafter:

For a phone book residing in DF-telecom:
- PBID = ICCid (10bytes) "fixed part" + 4 bytes (in EFPSC) "variable part".
For a phone book residing in an USIM application:
- PBID = 10 last bytes of (ICCid XOR AID) "fixed part" + 4 bytes (in EFPSC) "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}.

4.4.2.12.3 EF_CC (Change Counter) p. 152

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 EFCC. 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 2nd and 3rd generation of terminals).

Structure of EFCC

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) p. 153

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 EFUID.

Structure of EFPUID

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 EFUID

4.4.2.13 EF_EMAIL (e-mail address) p. 153

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 EFADN record, using one or several EFEMAIL. The number of email addresses may be equal to or less than the amount of records in EFADN. 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 EFADN file. This record cannot be shared between several phonebook entries.

Structure of EFEMAIL

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 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 EFADN file.

Coding:

as defined in TS 31.101.

ADN file Record Identifier

Content:

record identifier of the associated phone book entry.

Coding:

binary.

4.4.2.14 Phonebook restrictions p. 154

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

if an EFPBR file contains more than one record, then they shall all be formatted identically on a type-by-type basis, e.g. if EFPBR record #1 contains one type 1 e-mail then all EFPBR records shall have one type 1 email;
if an EFPBR record contains more than one reference to one kind of file, such as two EFEMAIL files, then they shall all be formatted identically on a type-by-type basis, e.g. if an EFPBR record has 2 email addresses, then they shall have the same record size and the same number of records in each EFPBR entry;
an EFPBR 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 EFPBR record shall not contain more than one occurrence of a given kind of file indicated in tag 'AA' (type 3 link). For instance, an EFPBR record may only contain one reference to an EFEXT1.

4.4.2.15 EF_PURI (Phonebook URIs) |R12| p. 154

This EF contains the URI address that may be linked to a phonebook entry. Several URI addresses can be attached to one EFADN record, using one or several EFPURI. The number of URI addresses may be equal to or less than the amount of records in EFADN. 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 EFADN file. This record cannot be shared between several phonebook entries.

Structure of EFPURI

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 EFIMPU defined in TS 31.103.

ADN file SFI

Content:

Short File identifier of the associated EFADN file.

Coding:

as defined in TS 31.101.

ADN file Record Identifier

Content:

record identifier of the associated phone book entry.

Coding:

binary.

Content for TS 31.102 Word version: 18.5.0

4.4.2.4 EFEXT1 (Extension1) p. 143

4.4.2.5 EFPBC (Phone Book Control) p. 145

4.4.2.6 EFGRP (Grouping file) p. 146

4.4.2.7 EFAAS (Additional number Alpha String) p. 146

4.4.2.8 EFGAS (Grouping information Alpha String) p. 147

4.4.2.9 EFANR (Additional Number) p. 147

4.4.2.10 EFSNE (Second Name Entry) p. 149

4.4.2.11 EFCCP1 (Capability Configuration Parameters 1) p. 150

4.4.2.12 Phone Book Synchronisation p. 150

4.4.2.12.1 EFUID (Unique Identifier) p. 150

4.4.2.12.2 EFPSC (Phone book Synchronisation Counter) p. 151

4.4.2.12.3 EFCC (Change Counter) p. 152

4.4.2.12.4 EFPUID (Previous Unique Identifier) p. 153

4.4.2.13 EFEMAIL (e-mail address) p. 153

4.4.2.14 Phonebook restrictions p. 154

4.4.2.15 EFPURI (Phonebook URIs) |R12| p. 154

4.4.2.4 EF_EXT1 (Extension1) p. 143

4.4.2.5 EF_PBC (Phone Book Control) p. 145

4.4.2.6 EF_GRP (Grouping file) p. 146

4.4.2.7 EF_AAS (Additional number Alpha String) p. 146

4.4.2.8 EF_GAS (Grouping information Alpha String) p. 147

4.4.2.9 EF_ANR (Additional Number) p. 147

4.4.2.10 EF_SNE (Second Name Entry) p. 149

4.4.2.11 EF_CCP1 (Capability Configuration Parameters 1) p. 150

4.4.2.12.1 EF_UID (Unique Identifier) p. 150

4.4.2.12.2 EF_PSC (Phone book Synchronisation Counter) p. 151

4.4.2.12.3 EF_CC (Change Counter) p. 152

4.4.2.12.4 EF_PUID (Previous Unique Identifier) p. 153

4.4.2.13 EF_EMAIL (e-mail address) p. 153

4.4.2.15 EF_PURI (Phonebook URIs) |R12| p. 154