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:  18.2.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   7…   7.2.3…   7.3…   7.3.2…   7.4…   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…   N…   O… 
7.2.3 Transmission protocol T = 1  7.2.3.0 Introduction  7.2.3.1 Timing and specific options for blocks sent with T = 1  7.2.3.1.0 Introduction  7.2.3.1.1 Information field size  7.2.3.1.2 Character waiting integer  7.2.3.1.3 Character waiting time  7.2.3.1.4 Block waiting time  7.2.3.1.5 Block guard time  7.2.3.1.6 Waiting time extension  7.2.3.1.7 Error detection code  7.2.3.2 Block frame structure  7.2.3.2.0 Overall structure  7.2.3.2.1 Prologue field  7.2.3.2.1.0 Field Structure  7.2.3.2.1.1 Node address byte  7.2.3.2.1.2 Protocol Control Byte  7.2.3.2.1.3 Length  7.2.3.2.1.4 Information field  7.2.3.2.2 Epilogue field  7.2.3.2.3 Block notations  7.2.3.2.3.1 I-block  7.2.3.2.3.2 R-block  7.2.3.2.3.3 S-block  7.2.3.3 Error free operation  7.2.3.4 Error handling for T = 1  7.2.3.4.0 General description  7.2.3.4.1 Protocol initialization  7.2.3.4.2 Block dependent errors  7.2.3.5 Chaining  7.2.3.5.0 Chaining Mechanism  7.2.3.5.1 Rules for chaining 
...

 

7.2.3  Transmission protocol T = 1  p. 42

7.2.3.0  Introduction  p. 42

The T = 1 protocol is a half-duplex asynchronous block based transmission protocol. Unless specified otherwise, it shall follow ISO/IEC 7816-3 [11]. The protocol may be initiated as follows:
  • after an ATR due to a cold reset;
  • after an ATR due to a warm reset;
  • after a successful PPS exchange.
The communication starts with a block sent by the terminal to the UICC. The right to send a block keeps alternating between the terminal and the UICC. A block is the smallest data unit, which can be sent and can contain either application data or transmission control data. A check of the received data might be performed before further processing of the received data.
Up

7.2.3.1  Timing and specific options for blocks sent with T = 1  p. 43

7.2.3.1.0  Introduction  p. 43
This clause defines options regarding timing, information field sizes and error detection parameters for blocks sent with T = 1.
7.2.3.1.1  Information field size  p. 43
The IFSC defines the maximum length of the information field of blocks that can be received by the UICC. The default value of the IFSC is 32 bytes another value may be indicated in the first TA for T = 1 of the ATR.
The IFSD defines the maximum length of the information field of blocks that the terminal can receive. IFSD has a default value of 32 bytes and may be adjusted during the card session. The maximum value of the IFSD is 254 bytes.
7.2.3.1.2  Character waiting integer  p. 43
CWI is used to calculate CWT and shall be in the range from 0 to 5. The value is set in bits b4 to b1 in the first TB for T = 1 of the ATR.
7.2.3.1.3  Character waiting time  p. 43
CWT is defined as the maximum delay between the leading edges of two consecutive characters in the block.
Reproduction of ETSI TS 31.ETSI-102-221, Fig. 7.3: Character waiting time
Figure 7.3: Character waiting time
Up
The value of CWT may be calculated from the following equation: CWT = (11 + 2CWI) etu.
7.2.3.1.4  Block waiting time  p. 43
BWT is defined as the maximum delay between the leading edge of the last character of the block received by the card and the leading edge of the first character of the next block sent by the card.
Reproduction of ETSI TS 31.ETSI-102-221, Fig. 7.4: Block waiting time
Figure 7.4: Block waiting time
Up
BWT is used to detect an unresponsive card.
7.2.3.1.5  Block guard time  p. 43
BGT is defined as the minimum delay between the leading edge of two consecutive characters sent in opposite directions. The value of BGT shall be 22 etu.
Reproduction of ETSI TS 31.ETSI-102-221, Fig. 7.5: Block guard time
Figure 7.5: Block guard time
Up
The delay between the last character of a block received by the UICC and the first character of the next block sent from the UICC shall be in the interval:
  • BGT < delay < BWT.
7.2.3.1.6  Waiting time extension  p. 44
WTX is a procedure used to ask for more time to process a command.
7.2.3.1.7  Error detection code  p. 44
The parameter in the first TC for T = 1 in the ATR is used to define which error detection code to use. LRC shall be used (b1 = 0). All other bits in the first TC for T = 1 of the ATR are RFU and shall be set to 0.

7.2.3.2  Block frame structure  p. 44

7.2.3.2.0  Overall structure  p. 44
The protocol consists of blocks, which are transmitted between the terminal and the UICC. Each block has the following structure.
Prologue field Information field Epilogue field
NAD PCB LEN INF EDC
1 byte1 byte1 byte0 byte to 254 bytes1 byte
The prologue field and the epilogue field are mandatory. The Information field is optional.
Up
7.2.3.2.1  Prologue field  p. 44
7.2.3.2.1.0  Field Structure  p. 45
The prologue field is divided into the following three mandatory fields:
  • Node ADdress byte (NAD), 1 byte;
  • Protocol Control Byte (PCB), 1 byte;
  • LENgth (LEN), 1 byte.
7.2.3.2.1.1  Node address byte  p. 45
The NAD-byte identifies the source and the intended destination of the block. The NAD may also be used to distinguish between different LSIs if they coexist as well as to provide Vpp state control (bit b8 and b4). Since b8 and b4 are not used, they shall be coded as '0'. Below is the structure of the NAD-byte.
b8 b7 b6 b5 b4 b3 b2 b1
Unused DAD Unused SAD
If multiple LSIs are supported and the terminal and the UICC agreed to use the NAD byte to indicate the LSI, then the LSI is identified by the combination of SAD and DAD values using the encoding in Table 7.4a.
LSI number Terminal address UICC address
SAD (terminal to UICC) DAD (terminal to UICC)
DAD (UICC to terminal) SAD (UICC to terminal)
b3 b2 b1 b3 b2 b1
'00'000000
'01'000001
...
'07'000111
'08'001000
RFU001001
'09'001010
...
'1F'100010
NOTE 1:
The use of the same value for terminal and UICC addresses is RFU, except for SAD = DAD = '0'.
NOTE 2:
Blocks transmitted from the terminal to the UICC use terminal address as the SAD value and the UICC address as the DAD value. Blocks transmitted from the UICC to the terminal using the same UICC address as the SAD value and the same terminal as the DAD value belong to the same LSI.
If multiple LSI is not supported, only the default value SAD = DAD = 0 shall be supported. All other combinations are RFU.
Up
7.2.3.2.1.2  Protocol Control Byte  p. 45
All information needed to control the transmission is transferred in the protocol control byte PCB. The coding of the PCB specifies the type of block. In the T = 1 protocol the following three different types of blocks are supported:
  • Information block (I-block): which is used to transfer command and response APDUs;
  • Receive-ready block (R-block): which is used to transfer acknowledgements;
  • Supervisory block (S-block): which is used to send control information.
Table 7.5 to Table 7.9 present the coding of the PCB for each block-type, starting with the I-block.
b8 b7 b6 b5 b4 b3 b2 b1
0 Sequence number, N(S) Chaining, more-data bit, M RFU
b8 b7 b6 b5 b4 b3 b2 b1
1 0 0 Sequence number N(R) See Table 7.7
b4 b3 b2 b1 Value Meaning
0000'0'Error free
0001'1'EDC and/or parity error
0010'2'Other errors
XXXX'X'Other values are RFU
b8 b7 b6 b5 b4 b3 b2 b1
1 1 X See Table 7.9
b5 b4 b3 b2 b1 Value Meaning
00000'0'Resynchronization
00001'1'Information field size
00010'2'Chain abortion
00011'3'Extension of BWT
00100'4'Error on VPP State (see note)
XXXXX'X'Other values are RFU
NOTE:
Not used by UICCs and terminals conforming to the present document.
The coding of b6 indicates whether it is a request (b6 = 0) or a response (b6 = 1).
Up
7.2.3.2.1.3  Length  p. 46
The length byte codes the number of bytes in the Information field of the block. The number of bytes in the information field may vary in the range from 0 byte to 254 bytes, depending on the type of block.
The value LEN = '00' indicates that the information field is absent and the value 'FF' is RFU.
7.2.3.2.1.4  Information field  p. 46
The information field, INF, is optional and it depends on the type of the block what the field will be used for.
Type of block INF used for
I-blockTransfer command and response APDUs.
R-blockNot used.
S-blockTransfers non application related information:
  • INF shall be present (single byte) to adjust IFS and WTX;
  • INF shall be absent to signal error on VPP, or for managing chain abortion or resynchronization.
Up
7.2.3.2.2  Epilogue field  p. 46
The epilogue field contains the Error Detection Code-byte (EDC), which transfers the error detection code of the transmitted block.
The LRC as defined in ISO/IEC 7816-3 [11] shall be used.
7.2.3.2.3  Block notations  p. 46
7.2.3.2.3.1  I-block  p. 47
The I-blocks are denoted as follows: I(N(S), M) where:
  • N(S) is the send-sequence number of the block;
  • M is the more-data bit used in the chaining function.
7.2.3.2.3.2  R-block  p. 47
The R-block is denoted as follows: R(N(R)), where:
  • N(R) is the number of the expected I-block.
7.2.3.2.3.3  S-block  p. 47
S-blocks are always used in pairs. An S(request) is always followed by an S(response) block. The S-blocks are denoted as follows:
  • S(RESYNCH request), a request of a resynchronization;
  • S(RESYNCH response), an acknowledge of the resynchronization;
  • S(IFS request), an offering of a maximum size of the information field;
  • S(IFS response), an acknowledge on the information field;
  • S(ABORT request), a request to abort the chain function;
  • S(ABORT response), an acknowledge of the abortion of the chain function;
  • S(WTX request), a request for an extension of the block waiting time;
  • S(WTX response), an acknowledge of the extension of the block waiting time.
Up

7.2.3.3  Error free operation  p. 47

This clause describes the rules for error free operation with T = 1:
  • The first block sent to the UICC shall be either an I-block or an S-block.
  • The first I-block of each sender shall use N(S) = 0.
  • If a sender S sends I(Ns(S), 0), the block is acknowledged by the receiver R with an I(Nr(S), M). The contents of I(Nr(S)) indicate data transfer data and that the receiver is ready to receive the next block from the sender.
  • If a sender S sends an I(Ns(S), 1) it should be acknowledged by the receiver R with R(Nr(R)), where Ns(S) ≠ Nr(R), to indicate that the received block was correct and that the receiver is ready to receive the next block.
  • If the NAD byte is used to indicate LSIs, all I-blocks and R-blocks related to the transfer of one APDU shall be sent on the same LSI.
  • If the NAD byte is used to indicate LSIs, sequence numbers Ns and Nr are of global significance. I.e. only one pair of counters is used, which are incremented independently, irrespective of the LSIs that the blocks belong to.
  • The UICC might need more than BWT to process the previously received block, an S(WTX request) is sent by the UICC. The terminal shall acknowledge with an S(WTX response). The new allocated time starts at the leading edge of the last character of the S(WTX response). If the NAD byte is used to indicate LSIs, S(WTX …) blocks shall be exchanged on the same LSI as the previously received block.
  • To change the value of IFSC/IFSD, the UICC/terminal sends an S(IFS request). The request shall be acknowledged by the terminal/UICC with an S(IFS response) with the same INF. The new IFSC/IFSD is assumed to be valid as long as no new S(IFS request) has been received by the terminal/UICC. If the NAD byte is used to indicate LSIs, IFSC and IFSD are of global significance. S(IFS …) blocks shall be exchanged on LSI 0.
  • When the receiver has received the number of characters as indicated in the value of the LEN and EDC the receiver returns the right to send.
Up

7.2.3.4  Error handling for T = 1  p. 48

7.2.3.4.0  General description  p. 48
This clause contains a description of the rules used to control the error handling for the T = 1 protocol.
The block component of the data link layer shall be able to handle errors like:
  • BWT time-out;
  • receive an invalid block, i.e. a block with parity errors, EDC error, invalid NAD (if the NAD byte is used to indicate LSIs), invalid PCB, invalid length, lost synchronization or failure to receive relevant S(… response) after an S(… request).
Resynchronization of the protocol may be attempted at three consecutive levels. If one level is unsuccessful, then the next level is tried:
  • For the terminal, the three levels are:
    • Retransmission of blocks.
    • Use of S(RESYNCH request).
    • Card reset or deactivation.
  • For the UICC, the three levels are:
    • Retransmission of blocks.
    • Use of S(RESYNCH response).
    • Without action by the terminal, the UICC becomes unresponsive.
If the NAD byte is used to indicate LSIs, S(RESYNCH …) blocks shall be exchanged on LSI 0.
Up
7.2.3.4.1  Protocol initialization  p. 48
After an ATR due to a Warm reset or successful PPS procedure, the communication between the terminal and the UICC can be initiated. But if the terminal fails to receive an error-free block, in the beginning of the protocol, a maximum of two more successive attempts to receive the block is allowed before resetting or a deactivation of the card takes place.
If the response on the first block sent by the terminal is not sent within BWT, the terminal shall send an R(0).
When the protocol has been initiated and the first block received by the UICC is invalid, the UICC responses with an R(0).
If the terminal fails to receive an error-free block during a card-session, a maximum of two further attempts is allowed before an S(RESYNCH request) is sent.
Up
7.2.3.4.2  Block dependent errors  p. 48
When an I-block has been sent and a BWT time-out occurs or an invalid block has been received (with the terminal), an R-block is sent, which requests with its N(R) for the expected I-block with N(S) = N(R).
When an R-block was sent and an invalid block is received or BWT time-out, the R-block shall be resent.
When an S(… request) has been sent and either a BWT time-out occurs (with the terminal) or the received response is not an S(… response), the S(… request) shall be resent. But if an S(… response) has been sent and either an invalid block is received or a BWT time-out occurs (with the terminal), an R-block shall be sent. The terminal shall not send an S(IFS request) before the R-block acknowledging a reception of the previous I-block sent by the card.
When the UICC sends an S(IFS request) and receives an invalid block, the S(IFS request) shall be resent maximum one extra time to receive an S(IFS response). After the second failure to receive an S(IFS response), the UICC shall stay in reception mode.
If the NAD byte is used to indicate LSIs, any block received with an invalid NAD value shall be treated as invalid block. Examples for invalid NAD values are:
  • an NAD byte coding an LSI outside of the range agreed when setting up the LSI configuration (see clause 11.1.25);
  • during the transfer of an APDU: an NAD byte coding an LSI different from the LSI that shall be used for all blocks related to this transfer;
  • for an S-block with global significance: an NAD byte coding an LSI different from 0.
Up

7.2.3.5  Chaining  p. 49

7.2.3.5.0  Chaining Mechanism  p. 49
Chaining allows the terminal or the UICC to transfer information, which is longer than IFSC or IFSD. If information longer than IFSC or IFSD is transferred, the information should be divided into pieces, each has a length ≤ IFSC or IFSD. Each piece should be sent in an I-block using the chaining function.
The value of the M-bit in the PCB byte of the I-block controls the chaining function according to:
  • M = 0, the block is not chained to the next block;
  • M = 1, the block is chained to the next block, which shall be an I-block.
When a receiver receives a more-data I-block, an R(N(R)) shall be sent. N(R) = N(S) of the expected I-block. At least one chained block shall follow.
A physical error, e.g. buffer overrun, in the UICC can cause an error in a chaining process. To abort a chain an S(ABORT request) can be sent by either the sender or the receiver. The request shall be answered with an S(ABORT response). When the S(ABORT response) has been received an R-block may be sent to either the terminal or the UICC to give back the right to send to either. If the NAD byte is used to indicate LSIs, S(ABORT …) blocks and the optional subsequent R-block shall be exchanged on the same LSI as the I-blocks of the aborted chain.
Up
7.2.3.5.1  Rules for chaining  p. 49
  • When the terminal is the receiver, the terminal shall accept a sequence of chained I-blocks sent from the UICC. The length of each block is ≤ IFSD.
  • When the UICC is the receiver, the UICC shall accept a sequence of chained I-blocks sent from the terminal. The length of each block shall be equal to the value of IFSC except for the last block whose length can be any value in the range of 0 to IFSC.
  • When the terminal is the sender, all I-blocks of a chain shall have LEN = IFSC bytes except for the last, which could have a value in the range of 0 to IFSC.
  • When the UICC is the sender, all I-blocks of a chain shall have LEN ≤ IFSD bytes per block.
  • When the UICC is the receiver and receives block with LEN > IFSC, the block shall be rejected and acknowledged with an R-block with bits b1 to b4 in the PCB having a value of 2.
For reasons of efficiency, it is not recommended to send empty I-blocks.
Up

Up   Top   ToC