Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 31.102  Word version:  18.3.0

Top   Top   Up   Prev   Next
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.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 Contents of files at the DF PHONEBOOK level  4.4.2.1 EFPBR (Phone Book Reference file)  4.4.2.2 EFIAP (Index Administration Phone book)  4.4.2.3 EFADN (Abbreviated dialling numbers) 
...

 

4.4.2  Contents of files at the DF PHONEBOOK level  p. 136

The EFs in the DFPHONEBOOK level contain phone book related features as required in TS 21.111.
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 TS 31.111 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:
  1. optional for terminals that support alternative phonebook applications; and
  2. mandatory for terminals that do not support alternative phonebook applications.
It is recommended that the terminal searches for the global phonebook located under DFTELECOM as its presence is not indicated anywhere in the USIM application.
The global phonebook is located in DFPHONEBOOK under DFTELECOM.. Each specific USIM application phonebook is located in DFPHONEBOOK of its respective Application ADFUSIM. The organisation of files in DFPHONEBOOK under ADFUSIM and under DF TELECOM follows the same rules. Yet DFPHONEBOOK under ADFUSIM may contain a different set of files than DFPHONEBOOK under DFTELECOM. All phonebook related EFs are located under their respective DFPHONEBOOK. USIM specific phonebooks are dedicated to application specific entries. Each application specific phonebook is protected by the application PIN.
EFADN and EFPBR shall always be present if the DFPhonebook is present. If any phonebook file other than EFADN or EFEXT1, is used, then EFPBC shall be present.
If a GSM application resides on the UICC, the EFs ADN and EXT1 from one DFPHONEBOOK (defined at GSM application installation) are mapped to DFTELECOM. Their file Ids are specified in TS 51.011, i.e. EFADN = '6F3A' and EFEXT1 = '6F4A', respectively.
If the UICC is inserted into a terminal accessing the ADN and EXT1 files under DFTELECOM; and a record in these files has been updated, a flag in the corresponding entry control information in the EFPBC 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 EFPBC and if this flag is set, shall update the EFCC, and then reset the flag. A flag set in EFPBC 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 DFPHONEBOOK in DFTELECOM. 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 DFTELECOM. The application specific phonebook may contain a different set of files than the one in the public area under DFTELECOM.
Up

4.4.2.1  EFPBR (Phone Book Reference file)  p. 137

This file describes the structure of the phonebook. All EFs representing the phonebook are specified here (with the exception of EFPSC, EFPUID and EFCC), 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, EFADN and EFADN1. 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 EFPBR.
The SFI value assigned to an EF which is indicated in EFPBR shall correspond to the SFI indicated in the TLV object in EFPBR.
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 EFPBR. 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 (EFADN, EFADN1) 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 (EFIAP).
Type 3 files:
Files that are linked by a record identifier within a record.
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 EFPBR 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.
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)'
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:
File name Type 1 Type 2 Type 3
EFAASX
EFADNX
EFANRXX
EFEMAILXX
EFEXT1X
EFGASX
EFGRPX
EFIAPX
EFPBCX
EFSNEXX
EFUIDX
EFCCP1X
EFPURIXX
 
Phone Book Reference file EFPBR structure
Identifier: '4F30'Structure: linear fixedConditional (see Note)
Record Length: X bytesUpdate activity: low
Access Conditions:
READPIN
UPDATEADM
DEACTIVATEADM
ACTIVATEADM
Bytes Description M/O Length
1 to XTLV object(s) for indicating EFs that are part of the phone book structureMX 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'.
Up

4.4.2.2  EFIAP (Index Administration Phone book)  p. 139

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 EFADN (shall be record to record). The index administration file contains the same amount of records as EFADN. The order of the pointers in an EFIAP 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 EFPBR 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 EFIAP is set to 'FF' at the personalisation stage.
Index administration file EFIAP structure
Identifier: '4FXX'Structure: linear fixedConditional (see Note)
SFI: 'YY'
Record Length: X bytes, (X ≥ 1)Update activity: low
Access Conditions:
READPIN
UPDATEPIN
DEACTIVATEADM
ACTIVATEADM
Bytes Description M/O Length
1Record number of the first object indicated after Tag 'A9'M1 byte
2Record number of the second object indicated after Tag 'A9'C1 byte
XRecord number of the xth object indicated after Tag 'A9'C1 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
Up

4.4.2.3  EFADN (Abbreviated dialling numbers)  p. 139

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 fixedConditional (see Note)
SFI: 'YY'
Record length: X+14 bytesUpdate activity: low
Access Conditions:
READPIN
UPDATEPIN
DEACTIVATEADM
ACTIVATEADM
Bytes Description M/O Length
1 to XAlpha IdentifierOX bytes
X+1Length of BCD number/SSC contentsM1 byte
X+2TON and NPIM1 byte
X+3 to X+12Dialling Number/SSC StringM10 bytes
X+13Capability/Configuration1 Record IdentifierM1 byte
X+14Extension1 Record IdentifierM1 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 with bit 8 set to 0. The alpha identifier shall be left justified. Unused bytes shall be set to 'FF'.
    or
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 EFEXT1 with the remaining length of the additional data being coded in the appropriate additional record itself (see clause 4.4.2.4).
Coding:
TON and NPI
Contents:
  • Type of number (TON) and numbering plan identification (NPI).
Coding:
  • according to TS 24.008. 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).
    b8 b7 b6 b5 b4 b3 b2 b1
    1 TON NPI
Dialling Number/SSC String
Contents:
  • up to 20 digits of the telephone number and/or SSC information.
Coding:
  • according to TS 24.008, TS 22.030 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 EFEXT1. 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 EFEXT1. 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
    MSB of Digit 2 : : LSB of Digit 2 MSB of Digit 1 : : LSB of Digit 1
     
    Byte X+4:
    b8 b7 b6 b5 b4 b3 b2 b1
    MSB of Digit 4 : : LSB of Digit 4 MSB of Digit 3 : : LSB of Digit 3
     
    etc.
Capability/Configuration1 Record Identifier
Contents:
  • capability/configuration identification byte. 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 ADN/SSC 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.
EXAMPLE:
SIM storage of an International Number using E.164 [22] numbering plan.
TONNPIDigit field
USIM application0010001 abc...
Other application compatible with 3GPP specification000 0000xxx...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.
BCD Value Character/Meaning
'0' "0"
::
'9' "9"
'A' "*"
'B' "#"
'C'DTMF Control digit separator (see TS 22.101).
'D' "Wild" value. This will cause the MMI to prompt the user for a single digit (see TS 22.101).
'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.
Up

Up   Top   ToC