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  ETSI TS 102 221   PDF version:  17.1.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   7…   7.3…   8…   9…   10…   10.2…   11…   11.1.2…   11.1.9…   11.1.14…   11.1.19…   11.1.20…   11.1.21…   11.2…   11.3…   12…   13…   14…   15   A   B   C…   D   E…   F…   G…   H…   I   J…   K…   L…   M… 
7.3 Transport layer  7.3.0 Introduction  7.3.1 Transportation of an APDU using T = 0  7.3.1.0 Introduction  7.3.1.1 Mapping of APDUs to TPDUs  7.3.2 Transportation of a APDU using T = 1  7.3.2.0 General mechanism  7.3.2.1 Case 1  7.3.2.2 Case 2  7.3.2.3 Case 3  7.3.2.4 Case 4  7.4 Application layer  7.4.0 Overall description  7.4.1 Exchange of APDUs  7.4.2 CAT layer  7.4.2.0 Overview  7.4.2.1 Proactive command  7.4.2.2 ENVELOPE Commands  7.4.3 Application execution 
...

 

7.3  Transport layer  p. 49

7.3.0  Introduction  p. 49

This clause describes how the APDU are transported between the terminal and the UICC. For definition of the cases for Data in APDUs see clause 7.4.

7.3.1  Transportation of an APDU using T = 0  p. 49

7.3.1.0  Introduction  p. 49

This clause describes the mapping of C-APDUs and R-APDUs for T = 0 protocol, the APDU exchange and the use of the GET RESPONSE command for case 2 and case 4.

7.3.1.1  Mapping of APDUs to TPDUs  p. 50

7.3.1.1.0  General behaviour  p. 50
The mapping of the C-APDU onto the T = 0 command header is dependent upon the case of the command. The mapping of the data (if present) and status returned by the UICC onto the R-APDU is dependent upon the length of the data returned.
Procedure bytes '61XX' and '6CXX' are returned by the UICC to control exchanges between the transport layer of the terminal and the UICC, and should never be returned to the application layer of the terminal. Command processing in the UICC is not complete if it has returned procedure bytes '61XX' or '6CXX'.
Normal status on completion of processing a command is indicated if the UICC returns status words '9000' to the transport layer of the terminal. The transport layer of the terminal shall discontinue processing of a command (i.e. pass the R-APDU to the application layer and wait for a further C-APDU from the application layer) on receipt of any status words (but not on receipt of procedure bytes '61xx' and '6Cxx') from the UICC. For case 4 commands only, immediately following successful transmission of command data to the UICC, the transport layer of the terminal shall continue processing the command if warning status bytes ('62xx' or '63xx', with the specific case of '6282' response for SEARCH RECORD command being described in the corresponding section) or application related status bytes ('9xxx' except '9000') are received.
The following descriptions of the mapping of data and status returned by the UICC onto the R-APDU are for information, and apply only after the UICC has completed processing of the command, successfully or otherwise, and all data (if present) has been returned by the UICC under the control of '61XX' and '6CXX' procedure bytes. Detailed use of the INS, INS, and '60' procedure bytes is not described.
The status returned by the UICC shall relate to the most recently received command. Where a GET RESPONSE command is used to complete the processing of a case 2 or case 4 command, any status returned by the UICC after receipt of the GET RESPONSE command shall relate to GET RESPONSE command, not to the case 2 or case 4 command which it completes.
Up
7.3.1.1.1  Case 1  p. 50
The C-APDU is mapped onto the C-TPDU by assigning the value '00' to the body part (P3 = '00').
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.6:
Figure 7.6
(⇒ copy of original ETSI image)
Up
The flow of the exchange is as follows:
  1. The transport layer of the terminal shall send the T = 0 command header to the UICC.
  2. On receipt of the command header the UICC, under normal or abnormal processing, shall return status to the transport layer of the terminal.
    The UICC shall analyse the T = 0 command header to determine whether it is processing a case 1 command or a case 2 command requesting all data up to the maximum length available.
  3. On receipt of status from the UICC, the transport layer of the terminal shall discontinue processing of the command.
See Annex C for details of the exchanges between the transport layer of the terminal and the UICC.
The status words returned to the transport layer of the terminal from the UICC after completion of processing of the command are mapped onto the mandatory trailer of the R-APDU without change.
Up
7.3.1.1.2  Case 2  p. 51
The C-APDU is mapped onto the C-TPDU without any change.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.7:
Figure 7.7
(⇒ copy of original ETSI image)
Up
The flow of the exchange is as follows:
  1. The transport layer of the terminal shall send the T = 0 command header to the UICC.
  2. On receipt of the command header the UICC:
    1. under normal processing shall return data and status to the transport layer of the terminal. The UICC shall use procedure bytes '6Cxx' (and if required, procedure bytes '61xx') to control the return of data (see below); or
    2. under abnormal processing shall return status only to the transport layer of the terminal.
  3. On receipt of the data (if present) and status from the UICC, the transport layer of the terminal shall discontinue processing the command.
See Annex C for details of the exchanges between the transport layer of the terminal and the UICC, including use of the '61XX' and '6CXX' procedure bytes.
The R-TPDU is mapped onto the R-APDU without any change.
The data (if present) and status returned to the transport layer of the terminal from the UICC after completion of processing of the command are mapped onto the R-APDU as follows:
  • The data returned (if present) is mapped onto the conditional body of the R-APDU. If no data is returned, the
    conditional body of R-APDU is left empty.
  • The status returned is mapped onto the mandatory trailer of the R-APDU without change.
Up
7.3.1.1.3  Case 3  p. 51
The C-APDU is mapped onto the C-TPDU without any change. Lc is a value between 1 and 255.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.8:
Figure 7.8
(⇒ copy of original ETSI image)
Up
The flow of the exchange is as follows:
  1. The transport layer of the terminal shall send the T = 0 command header to the UICC.
  2. On receipt of the command header, if the UICC:
    1. returns a procedure byte, the transport layer of the terminal shall send the data portion of the conditional body of the C-APDU to the UICC under the control of procedure bytes returned by the UICC; or
    2. returns status, the transport layer of the terminal shall discontinue processing of the command.
  3. If processing was not discontinued in step 2(b), the UICC shall return status following receipt of the conditional body of the C-APDU and completion of processing the command.
  4. On receipt of status from the UICC, the transport layer of the terminal shall discontinue processing the command.
See Annex C for details of the exchanges between the transport layer of the terminal and the UICC.
The status words returned to the transport layer of the terminal from the UICC after completion of processing of the command, or the status words returned by the UICC that caused the transport layer of the terminal to discontinue processing of the command, are mapped onto the R-APDU without change.
Up
7.3.1.1.4  Case 4  p. 52
The C-APDU is mapped onto the C-TPDU by cutting off the last byte (Le) of the body.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.9:
Figure 7.9
(⇒ copy of original ETSI image)
Up
The flow of the exchange is as follows:
  1. The transport layer of the terminal shall send the T = 0 command header to the UICC.
  2. On receipt of the command header, if the UICC:
    1. returns a procedure byte, the transport layer of the terminal shall send the data portion of the conditional body of the C-APDU to the UICC under the control of procedure bytes returned by the UICC; or
    2. returns status, the transport layer of the terminal shall discontinue processing of the command.
  3. If processing was not discontinued in step 2b), following receipt of the conditional body of the C-APDU, the UICC:
    1. under normal processing, shall return procedure bytes '61xx' to the transport layer of the terminal requesting the transport layer of the terminal to issue a GET RESPONSE command to retrieve the data from the UICC; or
    2. under abnormal processing, shall return status only to the transport layer of the terminal.
  4. On receipt of the procedure bytes or status returned in step 3, if the UICC:
    1. returned '61xx' procedure bytes as in step 3a), the transport layer of the terminal shall send a GET RESPONSE command header to the UICC with P3 set to a value less than or equal to the value contained in the 'xx' byte of '61xx' procedure bytes; or
    2. returned status as in step 3b) that indicates a warning ('62xx' or '63xx', with the specific case of '6282' response for SEARCH RECORD command being described in the corresponding section), or which is application related ('9xxx' but not '9000'), the transport layer of the terminal shall send a GET RESPONSE command with Le = '00'; or
    3. returned status as in step 3b) other than that described in step 4b), the transport layer of the terminal shall discontinue processing of the command.
  5. If processing was not discontinued in step 4c), the GET RESPONSE command shall be processed according to the rules for case 2 commands.
The first R-TPDU from the UICC indicates that the UICC performed the command correct and that the UICC has more data of length Luicc bytes to transfer. The first R-TPDU is mapped without any changes onto the R-APDU.
See Annex C for details of the exchanges between the transport layer of the terminal and the UICC, including use of the '61XX' and '6CXX' procedure bytes.
Up
7.3.1.1.5  Use of procedure bytes '61xx' and '6Cxx'  p. 53
7.3.1.1.5.0  Overall description  p. 53
The UICC returns procedure bytes '61xx 'and '6Cxx' to the transport layer of the terminal to indicate to it the manner in which it should retrieve the data requested by the command currently being processed. These procedure bytes are only used when processing case 2 and 4 commands using T = 0.
Procedure bytes '61xx' instruct the transport layer of the terminal to issue a GET RESPONSE command to the UICC. P3 of the GET RESPONSE command header is set to 'xx'.
Procedure bytes '6Cxx' instruct the transport layer of the terminal to immediately resend the previous command header setting P3 = 'xx'.
Usage of these procedure bytes during error free processing with case 2 and 4 commands is as defined in clauses 7.3.1.1.5.1 and 7.3.1.1.5.2. In the case of an error, the UICC may return status indicating error or warning conditions instead of the '61xx' or '6Cxx' response.
Up
7.3.1.1.5.1  Case 2 commands  p. 53
  1. If the UICC receives a case 2 command header and Le = '00' (with Luicc < 256 bytes) or Le > Luicc, it shall return:
    1. procedure bytes '6C Luicc' instructing the transport layer of the terminal to immediately resend the command header with P3 = Luicc; or
    2. status indicating a warning or error condition (but not SW1 SW2 = '90 00').
  2. If the UICC receives a case 2 command header and Le = '00' (with Luicc = 256 bytes) or Le = Luicc, it shall return:
    1. data of length Le (= Luicc) under the control of the INS, INS, or '60' procedure bytes followed by the associated status; or
    2. procedure bytes '61xx' instructing the transport layer of the terminal to issue a GET RESPONSE command with a maximum length of 'xx', 'xx' being less than Luicc (this could happen if the card buffer size is smaller than Luicc); or
    3. status indicating a warning or error condition (but not SW1 SW2 = '90 00').
  3. If the UICC receives a case 2 command header and Le < Luicc it shall return:
    1. data of length Le under the control of the INS, INS, or '60' procedure bytes followed by procedure bytes '61xx' instructing the transport layer of the terminal to issue a GET RESPONSE command with a maximum length of 'xx'; or
    2. status indicating a warning or error condition (but not SW1 SW2 = '90 00').
Up
7.3.1.1.5.2  Case 4 commands  p. 53
If the UICC receives a case 4 command, after processing the data sent with the C-APDU, it shall return:
  1. procedure bytes '61 xx' instructing the transport layer of the terminal to issue a GET RESPONSE command with a maximum length of 'xx'; or
  2. status indicating a warning or error condition (but not SW1 SW2 = '90 00').
The GET RESPONSE command so issued is then treated as described for case 2 commands.

7.3.2  Transportation of a APDU using T = 1  p. 54

7.3.2.0  General mechanism  p. 54

A C-APDU is sent from the application layer of the terminal to the transport layer of the terminal. The transport layer maps the C-APDU onto the INF of an I-block without change. The I-block is sent to the UICC. The Response data (if present) and the status are returned from the UICC to the transport layer of the terminal in the INF of an I-block. If the UICC returns a status which indicates:
  • a warning ('62XX' or '63XX');
  • an application condition ('9XXX'); or
  • a successful execution of the command ('9000');
then it shall also return data (if available) associated with the processing of the command. No data shall be returned with any other status.
The contents of the INF of the I-block are mapped onto the R-APDU without change and returned to the application layer of the terminal. The transportation of APDU messages with T = 1 is mapped to the information of an I-block according to the four different cases described below. Each case is described in detail in clauses 7.3.2.1 to 7.3.2.4.
Up

7.3.2.1  Case 1  p. 54

C-APDU is mapped to the INF of the I-block without any changes:
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.10:
Figure 7.10
(⇒ copy of original ETSI image)
Up
The response received from the INF in the I-block is mapped unchanged to the R-APDU.

7.3.2.2  Case 2  p. 54

The C-APDU is mapped to the INF of an I-block without any changes.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.11:
Figure 7.11
(⇒ copy of original ETSI image)
Up
The R-APDU consists of either the INF of the I-block or the concatenation of the INF of successive I-blocks all received in the same response, which all shall be chained.

7.3.2.3  Case 3  p. 55

The C-APDU is mapped without any changes to either an INF or is concatenated onto several successive I-blocks, which all shall be chained.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.12:
Figure 7.12
(⇒ copy of original ETSI image)
Up
The INF of the I-block is mapped to the R-APDU without any changes.

7.3.2.4  Case 4  p. 55

The C-APDU is mapped without any changes to either an INF or is concatenated onto several successive I-blocks, which all shall be chained.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.13:
Figure 7.13
(⇒ copy of original ETSI image)
Up
The response consists of either the INF of an I-block received in the response or the concatenation of INF of successive I-blocks in response, which all shall be chained.

7.4  Application layer  p. 55

7.4.0  Overall description  p. 55

The application protocol consists of an ordered set of exchanges between the application layer and the transport layer of the terminal. Application protocols are defined in subsequent parts of the present document.
Each step in an application layer exchange consists of a command-response pair, where the application layer of the terminal sends a command to the UICC via the transport layer of the terminal, and the UICC processes it and sends a response to application layer of terminal using the transport layer of the UICC and the transport layer of terminal. Each specific command (C-APDU) has a specific response (R-APDU). The commands and responses are called command messages and response messages. The structure of the C-APDU can be found in clause 10.2. The structure of the R-APDU can be found in clause 10.2.
Both command and response messages may contain data. Thus, four cases shall be managed by the transmission protocols via the transport layer, as shown in Table 7.11.
Case Command data Response data
1AbsentAbsent
2AbsentPresent
3PresentAbsent
4PresentPresent
Up

7.4.1  Exchange of APDUs  p. 56

Figure 7.14 shows the principle exchange of command/response pairs.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.14:
Figure 7.14
(⇒ copy of original ETSI image)
Up

7.4.2  CAT layer  p. 56

7.4.2.0  Overview  p. 56

The CAT layer uses application status words to indicate:
  • the availability of a proactive command for the terminal ('91XX');
  • the usage of response data to an envelope command by the terminal (nominal '9000', warning '62XX' or '63XX', checking error '6FXX');
  • the temporary unavailability of the CAT to handle an envelope command ('9300'), see clause 14.6.6.

7.4.2.1  Proactive command  p. 56

Where the status word SW1-SW2 is equal to '9000', the card can reply '91XX' to indicate that a proactive command is pending. The terminal uses the FETCH C-APDU to get the pending proactive command. The terminal sends to the UICC the response of the proactive command execution with the TERMINAL RESPONSE C-APDU.
Even if the command to which the card replied with '91 XX' was sent on a logical channel different from the basic channel, the terminal shall send the FETCH and TERMINAL RESPONSE commands on the basic channel.
The mechanism, described hereafter for a case 4 C-APDU, is independent from the transport protocol.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.15:
Figure 7.15
(⇒ copy of original ETSI image)
Up

7.4.2.2  ENVELOPE Commands  p. 57

The ENVELOPE C-APDU is used to transmit data to the CAT as specified in in ETSI TS 102 223 [4]. For some command data, the card may send back response data.
This command is case 3 or 4 and is described hereafter for the different options.
Case 3: negative acknowledgement
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.16:
Figure 7.16
(⇒ copy of original ETSI image)
Up
The terminal shall consider the status word received as a negative acknowledgement when the status word present in the
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.16a:
Figure 7.16a
(⇒ copy of original ETSI image)
Up
The terminal shall consider the data field received as a positive acknowledgement when the status word present in the
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.16b:
Figure 7.16b
(⇒ copy of original ETSI image)
Up
The terminal shall consider the data field received as a negative acknowledgement when the status word present in the R-APDU is either '62XX' or '63XX'.

7.4.3  Application execution  p. 57

When a Network Access Application (NAA) is selected on a logical channel, the UICC-Terminal interface should also enable execution of commands for other applications in order to minimize the impacts on service provisioning to the user. Terminals shall set the time-out before terminating a command being processed by the UICC to a value of at least what is specified in Table 7.12.
Case Time-out
The terminal indicates a maximum available power supply in the terminal power supply of TERMINAL CAPABILITY command that is greater than or equal to the UICC Maximum Power Consumption as indicated in EFUMPC. 20 seconds
The terminal is not able to supply the UICC Maximum Power Consumption as indicated in EFUMPC. T_OP value from EFUMPC
UICC Maximum Power Consumption (EFUMPC) is not present on the UICC.Not specified
Application providers are advised to give appropriate warnings to the user before starting an operation that may impact user experience.
Up

Up   Top   ToC