Agenda Item: 	9.5 General issues
Source: 	NOKIA
Title: 					Analysis of GSM 11.11 v7.1.0 chapter 6 for 3G
To:     	TSG-T3
___________________________________________________________________________
Introduction comments: This input paper contains a Revised Version of GSM 11.11 v7.1.0 Ch. 6 with changes and comments for usage in 3G standards.
Furthermore it should be discussed whether the content of GSM 11.11 Ch. 6 should be present in 3G specifications or if it (or parts of it) should be handled in the ETSI WP GENERICS group since some of it is general to the UICC rather than the USIM application. 
6 Logical issues of the UICC
This clause describes the logical structure for applications residing on the UICC, the code associated with it, and the structure of files used.
General description
Figure 3 shows the general structural relationships which may exist between files. The files are organized in a hierarchical structure and are of one of three types as defined below. These files may be either administrative or application specific. The operating system handles the access to the data stored in different files.
+---------------------------------------------------------+
¦   MF    ¦                                               ¦
¦         ¦           +---------------------------------+ ¦
¦---------+           ¦ DF2 ¦                  +----+   ¦ ¦
¦                     ¦-----+                  ¦ EF ¦   ¦ ¦
¦         +----------------------------------+ +----+   ¦ ¦
¦         ¦ DF1 ¦                            ¦          ¦ ¦
¦         ¦-----+      +-------------------+ ¦ +----+   ¦ ¦
¦         ¦            ¦ DF11 ¦  +-------+ ¦ ¦ ¦ EF ¦   ¦ ¦
¦         ¦            ¦------+  ¦ DF111 ¦ ¦ ¦ +----+   ¦ ¦
¦         ¦   +-----------------++-------+ ¦ ¦  ....    ¦ ¦
¦         ¦   ¦ DF12 ¦  +----+  ¦----------+ ¦----------+ ¦
¦         ¦   ¦------+  ¦ EF ¦  ¦  +----+    ¦            ¦
¦         ¦   ¦         +----+  ¦  ¦ EF ¦    ¦    +----+  ¦
¦         ¦   +-----------------+  +----+    ¦    ¦ EF ¦  ¦
¦         ¦                                  ¦    +----+  ¦
¦         +----------------------------------+            ¦
¦                +----+            +----+                 ¦
¦                ¦ EF ¦            ¦ EF ¦                 ¦
¦                +----+            +----+                 ¦
¦                                                  ....   ¦
+---------------------------------------------------------+

Figure 3: Organization of memory
Files are composed of a header, which is internally managed by the SIM, and optionally a body part. The information of the header is related to the structure and attributes of the file and may be obtained by using the commands GET RESPONSE (In case T=0 transport protocol is used) or STATUS. This information is fixed during the administrative phase. The body part contains the data of the file.
6.2	File identifiers for a USIM application
A file ID is used to address or identify each specific file. The file ID consists of two bytes and shall be coded in hexadecimal notation. They are specified in clause ?
(Editors note: The location of the specification of the file ID is FFS and has to be defined).
The first byte identifies the type of file, and for UICC the following rules applies:
‑	'3F': Master File;
‑	'7F': 1st level Dedicated File;
The identifiers below are mandatory for USIM and GSM applications but optional (recomented?) for other applications:

-	'5F': 2nd level Dedicated File;
‑	'2F': Elementary File under the Master File;
‑	'6F': Elementary File under a 1st level Dedicated File;
-	'4F': Elementary File under 2nd level Dedicated File.
File IDs shall be subject to the following conditions:
‑	the file ID shall be assigned at the time of creation of the file concerned;
‑	no two files under the same parent shall have the same ID;
‑	a child and any parent, either immediate or remote in the hierarchy, e.g. grandparent, shall never have the same file ID.
In this way each file is uniquely identified.
6.3	Dedicated files
A Dedicated File (DF) is a functional grouping of files consisting of itself and all those files which contain this DF in their parental hierarchy (that is to say it consists of the DF and its complete "subtree"). A DF "consists" only of a header part.
Two 1st level DFs are defined in this specification:
‑	DFUSIM which contains the application for accessing GSM as well as UMTS systems.

-	DFTELECOM which contains telecom service features relevant for general usage NOTE1
NOTE1:	In phase 1 there is no requirement to have multiple USIM applications in a UICC but it may be implemented in later phases, hence there may be a need to share e.g. ADN’s.
Both files are immediate children of the Master File (MF) and may coexist on a multi‑application card.
2nd level DFs are defined in this specification under DFUSIM.
All 2nd level DFs are immediate children of the DFUSIM and may coexist on a multi-application card.
6.4	Elementary files
An Elementary File (EF) is composed of a header and a body part. The following three structures of an EF are used by GSM.
6.4.1	Transparent EF
An EF with a transparent structure consists of a sequence of bytes. When reading or updating, the sequence of bytes to be acted upon is referenced by a relative address (offset), which indicates the start position (in bytes), and the number of bytes to be read or updated. The first byte of a transparent EF has the relative address '00 00'. The total data length of the body of the EF is indicated in the header of the EF.
           +-------------+
Header     ¦             ¦
           ¦-------------¦
           ¦             ¦
Body       ¦ Sequence    ¦
           ¦ of          ¦
           ¦ bytes       ¦
           ¦             ¦
           ¦             ¦
           +-------------+

NOTE:	This structure was previously referred to as "binary" in GSM.

Figure 4: Structure of a transparent EF
6.4.2	Linear fixed EF
An EF with linear fixed structure consists of a sequence of records all having the same (fixed) length. The first record is record number 1. The length of a record as well as this value multiplied by the number of records are indicated in the header of the EF.
           +-------------+
Header     ¦             ¦
           ¦-------------¦
Body       ¦  Record 1   ¦
           +-------------¦
           ¦  Record 2   ¦
           +-------------¦
           ¦      :      ¦
           ¦      :      ¦
           +-------------¦
           ¦  Record n   ¦
           +-------------+

Figure 5: Structure of a linear fixed file
There are several methods to access records within an EF of this type:
‑	absolutely using the record number;
‑	when the record pointer is not set it shall be possible to perform an action on the first or the last record by using the NEXT or PREVIOUS mode;
‑	when the record pointer is set it shall be possible to perform an action on this record, the next record (unless the record pointer is set to the last record) or the previous record (unless the record pointer is set to the first record);
‑	by identifying a record using pattern seek starting:
‑	forwards from the beginning of the file;
‑	forwards from the record following the one at which the record pointer is set (unless the record pointer is set to the last record);
‑	backwards from the end of the file;
‑	backwards from the record preceding the one at which the record pointer is set (unless the record pointer is set to the first record).
If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it was set prior to the action.
NOTE 1:	It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be greater than 255 bytes.
NOTE 2:	This structure was previously referred to as "formatted" in GSM.
6.4.3	Linear variable EF
An EF with linear variable structure consists of a sequence of records having a variable size. The first record is record number 1. The number of records are indicated in the header of the EF 
(Editors note: how about the total size of  the record is that indicated in the header as well??).

Header					
Body	Record 1				
	Record 2				
	:				
	:				
	Record n				

Figure 5: Structure of a linear variable file
There are several methods to access records within an EF of this type:
‑	absolutely using the record number;
‑	when the record pointer is not set it shall be possible to perform an action on the first or the last record by using the NEXT or PREVIOUS mode;
‑	when the record pointer is set it shall be possible to perform an action on this record, the next record (unless the record pointer is set to the last record) or the previous record (unless the record pointer is set to the first record);
‑	by identifying a record using pattern seek starting:
‑	forwards from the beginning of the file;
‑	forwards from the record following the one at which the record pointer is set (unless the record pointer is set to the last record);
‑	backwards from the end of the file;
‑	backwards from the record preceding the one at which the record pointer is set (unless the record pointer is set to the first record).
If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it was set prior to the action.
NOTE 1:	It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be greater than 255 bytes.
NOTE 2:	This structure was previously referred to as "formatted" in GSM.

6.4.4	Cyclic EF
Cyclic files are used for storing records in chronological order. When all records have been used for storage, then the next storage of data shall overwrite the oldest information.
An EF with a cyclic structure consists of a fixed number of records with the same (fixed) length. In this file structure there is a link between the last record (n) and the first record. When the record pointer is set to the last record n, then the next record is record 1. Similarly, when the record pointer is set to record 1, then the previous record is record n. The last updated record containing the newest data is record number 1, and the oldest data is held in record number n.
	           +-------------+
	Header     ¦             ¦
	           ¦-------------¦
	Body       ¦  Record 1   ¦ --+
	           +-------------¦   ¦
	           ¦  Record 2   ¦   ¦
	           +-------------¦   ¦
	           ¦      :      ¦   ¦
	           ¦      :      ¦   ¦
	           +-------------¦   ¦
	           ¦  Record n   ¦ --+
	           +-------------+

Figure 6: Structure of a cyclic file
For update operations only PREVIOUS record shall be used. For reading operations, the methods of addressing are Next, Previous, Current and Record Number.
After selection of a cyclic file (for either operation), the record pointer shall address the record updated or increased last. If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it was set prior to the action.
NOTE:	It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be greater than 255 bytes.
6.5	Methods for selecting a file
After the Answer To Reset (ATR), the Master File (MF) is implicitly selected and becomes the Current Directory. Each file may then be selected by using the SELECT function in accordance with the following rules.
Selecting a DF or the MF sets the Current Directory. After such a selection there is no current EF. Selecting an EF sets the current EF and the Current Directory remains the DF or MF which is the parent of this EF. The current EF is always a child of the Current Directory.
Any application specific command shall only be operable if it is specific to the Current Directory.
The following files may be selected from the last selected file:
‑	any file which is an immediate child of the Current Directory;
‑	any DF which is an immediate child of the parent of the current DF;
‑	the parent of the Current Directory;
‑	the current DF;
‑	the MF.
This means in particular that a DF shall be selected prior to the selection of any of its EFs. All selections are made using the file ID.
The following figure gives the logical structure for the UICC. Currently only two levels of DFs under the MF for the UICC.

Figure 7: Logical structure
The following table gives the valid selections for UICC for the logical structure in figure 7. Reselection of the last selected file is also allowed but not shown.
Table 6: File selection
Last selected file	Valid Selections	
MF
DF1
DF2
DF3
EF1
EF2
EF3
EF4
EF5	DF1, DF2, EF1
MF, DF2, DF3, EF2
MF, DF1, EF3, EF4
MF, DF1, EF5
MF, DF1, DF2
MF, DF1, DF2, DF3
MF, DF1, DF2, EF4
MF, DF1, DF2, EF3
MF, DF1, DF3	
6.6	Reservation of file IDs
In addition to the identifiers used for the files specified in the present document, the following file IDs are reserved for use by GSM.
Dedicated Files:
‑	administrative use: 
	'7F 4X', '5F1X', '5F2X'
‑	operational use:
	'7F 10' (DFTELECOM), '7F 20' (DFGSM), '7F 21' (DFDCS1800), and '7F 2X', where X ranges from '2' to 'F'.
-	reserved under '7F10':
	'5F50' (DFGRAPHICS)    $(Image)$
-	reserved under '7F20':
	'5F30' (DFIRIDIUM), '5F31' (DFGlobalstar), '5F32' (DFICO), '5F33' (DFACeS), ‘5F3X’, where X ranges from '4' to 'F' for other MSS.
	'5F40'(DFPCS-1900), '5F4Y' where Y ranges from '1' to 'F' and,
	'5FYX' where Y ranges from '5' to 'F'.
Elementary files:
‑	administrative use:
	'6F XX' in the DFs '7F 4X'; '4F XX' in the DFs '5F 1X', '5F2X'
	'6F 1X' in the DFs '7F 10', '7F 20', '7F 21';
	'4F 1X' in all 2nd level DFs
	'2F 01', '2F EX' in the MF '3F 00';
‑	operational use:
	'6F 2X', '6F 3X', '6F 4X' in '7F 10' and '7F 2X';
	'4F YX', where Y ranges from '2' to 'F' in all 2nd level DFs.
	'2F 1X' in the MF '3F 00'.
In all the above, X ranges, unless otherwise stated, from '0' to 'F'.
6.7	Application selection
Two different  methods for selecting applications in the UICC exists [7816-4 1995,ch. 9.3.2 and 9.4]; the direct application selection and selection by data retrieval, i.e. reading a EFDIR file.
6.7.1 Direct application selection
A card in a multi-applicatrion environment shall be able to respond positively to a direct application selection performed by a SELECT FILE command specifying the application identifier (AID) as DF name.
6.7.2	EFDIR application selection
Direct under the MF the application selection file EFDIR resides. EFDIR contains a list of all selectable applications residing in the UICC including an alpha ID for each application