The provisions of clause 8 apply to the logical UICC with the following exceptions:

• The provisions of clause 8.10 describe the concept of LSEs.

An example of organization of applications in the UICC is listed in Figure 8.1.

The present document does not impose any restrictions on the location of applications. All applications are uniquely identified by application identifiers that are obtained from EFDIR. These application identifiers are used to select the application. EFDIR, EFPL, EFICCID and EFUMPC are all mandatory and reside directly under the Master File. See clause 13 for details. DFTELECOM is optional. If present it resides under the MF and use the reserved FID '7F 10'. DFTELECOM contains application independent information.

A File Identifier (FID) is used to address or identify a specific file. The FID consists of two bytes and shall be coded in hexadecimal notation. FIDs shall be subject to the following conditions:

• the FID shall be assigned at the time of creation of the file concerned;
• no two files under the same parent shall have the same ID;
• the immediate children of the current DF, the parent DF or the immediate children of the parent DF shall not have the same FID.

A path is a concatenation of FIDs. The path starts from MF or the current DF, and ends with the identifier of the file itself. The order of the FIDs is always in the direction from father to child. A Short File Identifier (SFI) is coded as 5 bits valued in the range from 1 to 30. No two files under the same parent shall have the same SFI. A DF name is coded on 1 to 16 bytes. The DF name is the AID and shall be unique within a card. The reserved FID '7FFF' can be used as a FID for the ADF of the current active application on a given logical channel.

The following FIDs are reserved by the present document:

• ADF:
  • Operational use (implicit FID for the current ADF):
    • '7FFF'.
• Dedicated Files:
  • Administrative use:
    • '7F4X', '5F1X', '5F2X'.
  • Operational use:
    • '7F10' (DFTELECOM);
      '7F20' (DFGSM);
      '7F21' (DFDCS1800); and
      '7F23' (DFFP-CTS) are reserved for 3GPP, 3rd Generation Partnership Project;
    • '7F11' (DFCD) is reserved for assignment in the present document;
    • '7F22' (DFIS-41) is reserved for ANSI, American National Standards Institute, USA;
    • '7F24' (DFTIA/EIA-136') is reserved for TIA, Telecommunications Industry Association, USA;
    • '7F25' (DFTIA/EIA-95') is reserved for 3GPP2, 3rd Generation Partnership Project 2;
    • '7F26' (DFGSMA) is reserved for GSMA, GSM Association;
    • '7F2X', where X ranges from '6' to 'F' are reserved for future assignments.
  • For information:
    • '7F31' (DFIDEN) is used in the iDEN specification by Motorola, Inc, USA;
    • '7F80' (DFPDC) is used in the PDC specification by ARIB, Association of Radio Industries and Businesses, Japan;
    • '7F90' (DFTETRA) is used by TETRA Association, Terrestrial Trunked Radio.

If a DF is reserved for an organization, it is responsible for all content inside this DF and requests for allocation of DF or EF identifiers under the DFs shall be made to the responsible organization. The same should be done for DFs used by an organization:

• 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 EX' in the MF '3F 00'; '2F07' EFENV-CLASSES (specified in ETSI TS 102 671 [27]).
  • 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;
    • '2F05', '2F06' and '2F 1X' in the MF '3F 00'.
  • Operational use ISO/IEC 7816-4 [12]:
    • '2F00' EFDIR, '2F01' EFATR in the MF '3F00'.

In all the above, X ranges, unless otherwise stated, from '0' to 'F'.

Logical channels are defined in ISO/IEC 7816-4 [12]. The present document supports the first (i.e. CLA byte coded as in Table 10.3) and the further (i.e. CLA byte coded as in Table 10.4a) interindustry values for the CLA byte as defined in ISO/IEC 7816-4 [12], which support up to 19 logical channels in addition to the basic logical channel 0. Channel 0 is always available and open throughout the card session. A UICC which supports logical channels indicates it in the ATR, together with the assignment methods and maximum number of logical channels it supports. The UICC supporting logical channels shall support:

• at least one channel in addition to the basic channel; and
• logical channel number assignment by the UICC.

Command interdependencies on one logical channel are independent of command interdependencies on another logical channel. There is no interleaving of commands and their responses across logical channels; between the receipt of the command APDU and the sending of the response APDU to that command, only one logical channel is active. In order to be accessed from several logical channels at the same time, a given file (EF, DF, ADF) shall be indicated as "shareable" in its file descriptor. Applications are responsible for keeping data consistency (in the card and the terminal) when accessing the same file from different logical channels. A logical channel is opened by using a MANAGE CHANNEL command, in which the card assigns a channel number and returns it in the response. The logical channel remains open until it is explicitly closed by a MANAGE CHANNEL command, or if the UICC is deactivated. When the open function is performed from the basic channel, then after a successful open, the MF shall be implicitly selected as the current DF. When the open function is performed from a logical channel which is not the basic one, then after a successful open, the current DF of the logical channel from which the command was issued shall be selected as the current DF. In both cases, no current EF is selected in the new logical channel.

Once a new channel is opened, the current DF and the current EF are independent per each logical channel. If the MANAGE CHANNEL command is performed on a DF or ADF that is not shareable, the card shall respond with an appropriate error message. The response shall indicate that the command is not allowed. No new channel is opened.

A file (EF, DF or ADF) can be accessed (selected, read, updated, deleted, deactivated, activated, increased, searched, etc.) concurrently by different applications:

• by terminal applications through different logical channels;
• by UICC-based applications such as remote file management and toolkit applications.

The outcome of concurrent access is determined by the shareable/not-shareable bit in the file descriptor byte in the FCP of the accessed file as follows:

• If a file is indicated as shareable, then applications may perform authorized operations on the file independently of whether or not the file is the current file of any other application.
• If a file is indicated as not-shareable and is the current file of one application, then another application cannot perform any operation on the file regardless of authorization.

A consequence of the first rule is that if changes to a shareable file are permitted by the file's security conditions, then the file can be changed by one application while it is currently selected and being used by a second application. Descriptions of individual commands include the details of behaviour interaction in the shareable case. A consequence of the second rule is that an application acquires exclusive access to a not-shareable file by successfully selecting it. Access by any other application, including an attempt to select the file, shall return the status word '6985' (conditions of use not satisfied). For the purpose of this clause, concurrent access to a file by two executing instances of a single application is considered to be accessed by two different applications. For shareable files, file access shall be managed independently for each accessing application. In particular, a record-based file and a BER-TLV structure file shall have different pointers for each accessing application.

Secure channels are defined in ETSI TS 102 484 [20]. There are two types of APDU based secure channel: Application to Application APDU secure channels and Platform to Platform APDU secure channels. Support of secure channels is optional for the Terminal and the UICC. The support by the UICC is indicated in the ATR. A secure channel is a special secured version of a logical channel. A secure channel is created by first opening a logical channel, and then securing the channel using the MANAGE SECURE CHANNEL command. Logical channel 0 cannot be a secure channel for application to application secure channel. A Platform to Platform APDU secure channel shall only be allowed on logical channel 0. Logical channel use shall be allowed within a Platform to Platform secure channel. All commands other than MANAGE SECURE CHANNEL, TRANSACT DATA and GET RESPONSE are secured by using a Platform to Platform secure channel, including proactive commands. For the application-to-application secure channel, a UICC application shall be selected by one of the following mechanisms:

• a UICC application becomes explicitly selected before the MANAGE SECURE CHANNEL - Establish SA - Master SA command; or
• a UICC application becomes implicitly selected upon successful completion of a MANAGE SECURE CHANNEL - Establish SA - Master SA command.

A UICC may support several LSEs on the same physical element. Each LSE acts and is handled by the terminal like a separate secure element. The terminal communicates with the different LSEs via LSIs. Each LSE operates logically independently from the others. As seen on the interface, each LSE has its own file system, its own applications, its own AIDs, its own independent security status, its own CAT session (which means that several of them can run interleaved in parallel on the different LSIs), and its own runtime environment. The terminal can switch between the LSEs by sending MANAGE LSI (select LSI) commands or by selecting the LSI via the NAD byte when using T = 1. The MANAGE LSI command also allows resetting an LSE. Such a reset shall be equivalent to a warm reset of the interface for a UICC not supporting LSEs. A cold reset or a warm reset of the physical interface results in resetting all LSEs. When the terminal receives a REFRESH proactive command with mode "UICC reset" on an LSI, the terminal shall reset only the corresponding LSE via a MANAGE LSI command. If the UICC supports the UICC-CLF interface as defined in ETSI TS 102 613 [19], this interface shall be assigned to at most one LSE. The ATRs returned in MANAGE LSI (reset LSE) for the different LSEs shall reflect the support of this interface by the LSE. The assigned LSE may be updated by the terminal using the MANAGE LSI (assign SWP) command. The assigned LSE does not change with a reset of the UICC and is also used for any communication that occurs while the interface defined in the present document is deactivated.