Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑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  Transmission protocolsp. 39

7.0  Introductionp. 39

Clause 7 defines the transmission protocols used to exchange data between the terminal and the UICC. The structure and processing of commands initiated by the terminal for transmission control and for specific control in asynchronous half duplex transmission protocols will be described.
Two different protocols are defined, the character based protocol T = 0 and the block based protocol T = 1.
Both protocols T = 0 and T = 1 are mandatory for the terminal. The UICC shall support either T = 0 or T = 1 or both protocols. The protocols shall be supported as specified in the present document.
The protocol starts after either the answer to reset or a successful PPS exchange. Other parameters provided in the ATR and relevant to a specific protocol are defined in the respective parts of this clause.
The protocol applies a layering principle of the OSI-reference model. Four layers are considered. The layers are:
  • the physical layer. The contained definitions are valid for T = 0 and T = 1;
  • the data link layer, which consists of:
    • a character component;
    • a block component;
    • block identification;
    • send blocks;
    • detect transmission and sequence errors;
    • handle errors;
    • synchronize the protocol;
  • the transport layer, which defines the transmission of application-oriented messages specific to each protocol;
  • the application layer, which defines the exchange of messages according to an application protocol that is common to both protocols.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.1: Layers
Figure 7.1: Layers
(⇒ copy of original ETSI image)
Up

7.1  Physical layerp. 40

Both protocols T = 0 and T = 1 shall use the physical layer and character frame as defined in clause 7.2.1.

7.2  Data link layerp. 40

7.2.0  Introductionp. 40

This clause describes the timing, specific options and error handling for the protocols T = 0 and T = 1.

7.2.1  Character framep. 40

7.2.1.0  Structure, coding and timingp. 40

A character that is transmitted over the I/O line is embedded in a character frame.
Before the transmission of a character, the I/O line shall be in state H. Depending upon the convention used, the logical '1' in a character is either represented by state H on the I/O line, direct convention, or state L on the I/O line, inverse convention.
A character consists of 10 consecutive bits (see Figure 7.2):
  • 1 start bit in state L;
  • 8 bits, which comprise the data byte;
  • 1 even parity checking bit.
The parity bit is set, in a way, that there is an even number of bits set to '1' including the parity bit in the character frame.
The time origin is fixed as the mean between the last observation of state H and the first observation of state L. The receiver shall confirm the existence of a start bit before 0,7 etu (receiver time). Then the subsequent bits shall be received at intervals of (n + 0,5 ± 0,2) etu (n being the rank of the bit). The start bit is bit 1.
Within a character, the time from the leading edge of the start bit to the trailing edge of the nth bit is (n ± 0,2) etu.
The interval between the leading edges of the start bits of two consecutive characters comprises the character duration (10 ± 0,2) etu, plus a guardtime. Under error free transmission, during the guardtime both the UICC and the terminal shall be in reception mode (I/O line in state H), unless specified otherwise.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.2: Character frame
Figure 7.2: Character frame
(⇒ copy of original ETSI image)
Up
The data shall always be passed over the I/O line with the most significant byte first. The order of bits within a byte (that is, whether the least significant or most significant bit is transferred first) is specified in character TS returned in the answer to reset (see ISO/IEC 7816-3 [11]).

7.2.1.1  Low impedance I/O line behaviourp. 41

If the low impedance driver on the I/O line has been selected, as the result of a successful PPS exchange, the following protocol on the I/O line applies.
The transmission state is defined as the period starting from the start bit of the first character to the end of the guardtime of the last character to transmit. During the transmission state the transmitter shall drive the I/O line to the desired level using the low impedance driver, with the exception of the error indication period, e.g. character guardtime of T = 0.
After reception of the last character in a command or response sequence when the communication direction is changed, the entity that is in turn to transmit, terminal or UICC, shall drive the I/O line to the high level using the low impedance driver during the interface inactivity period During clock stop the terminal shall drive the I/O line to high state.
The interface inactivity period ends when the transmission of a new command or its response starts.
Up

7.2.2  Transmission protocol T = 0p. 41

7.2.2.0  Introductionp. 41

The T = 0 is a half-duplex asynchronous character based transmission protocol.
All commands using the protocol T = 0 are initiated from the terminal by sending a five byte header, which informs the UICC what to do. The terminal will always act as master and the UICC as a slave. The direction of the transmission is assumed to be known to both the UICC and the terminal.

7.2.2.1  Timing and specific options for characters in T = 0p. 41

The minimum interval between the leading edge of the start bits of two consecutive characters shall be at least 12 etu.
The maximum interval between the start leading edge of any character sent by the UICC and the start leading edge of the previous character sent either by the UICC or the terminal is the WWT. The value of the WWT shall not exceed 960 × WI × Fi/f. WI is an integer received in the specific interface byte TC2. If no TC2 is available, default value of WI is 10. The clock rate conversion factor, Fi, and the baud rate conversion factor Di, may be indicated in TA1. If TA1 is absent the default values 372 and 1 respectively are used.
If the WWT is exceeded, the terminal shall initiate a deactivation within 960 etu.
Up

7.2.2.2  Command headerp. 42

A command is always initiated by the terminal which sends an instruction to the UICC in the form of a five byte-header called the command header. The command header comprises five consecutive bytes, CLA, INS, P1, P2 and P3.
These bytes together with any data to be sent with the command form the Command-Transport Protocol Data Unit (C-TPDU) for T = 0. The mapping of the C-APDU onto the C-TPDU is described in clause 7.3.
The terminal transmits the header to the UICC and waits for a procedure byte or a status byte.
Up

7.2.2.3  Command processingp. 42

7.2.2.3.0  General descriptionp. 42
When the UICC has received the command header, a response containing a procedure byte or a status byte shall be sent to the terminal. Both the terminal and the UICC shall be able to keep track of the direction of the data flow and who has the access to the I/O-line.
7.2.2.3.1  Procedure bytesp. 42
The procedure byte indicates to the terminal what action it shall take next.
Procedure bytes are used to keep up the communication between the terminal and the UICC. They shall not be transmitted to the application layer.
The coding of the procedure byte and the action that shall be taken by the terminal is shown in Table 7.1.
Byte Value Action
ACKEqual to INS byteAll remaining data bytes shall be transferred by the terminal, or the terminal shall be ready to receive all remaining data bytes from the UICC.
Equal to complement of INS byte (INS)The next data byte shall be transferred by the terminal, or the terminal shall be ready to receive the next data byte from the UICC.
NULL'60'The NULL-byte requests no further data transfer and the terminal shall only wait for a character conveying a procedure byte. This behaviour provides additional work waiting time as defined in this clause.
SW1'61'The terminal shall wait for a second procedure byte then send a GET RESPONSE command header to the UICC with a maximum length of 'XX', where 'XX' is the value of the second procedure byte (SW2).
'6C'The terminal shall wait for a second procedure byte then immediately repeat the previous command header to the UICC using a length of 'XX', where 'XX' is the value of the second procedure byte (SW2).
After these actions, the terminal shall wait for a further procedure byte or status word.
Up
7.2.2.3.2  Status bytesp. 42
The status bytes SW1 SW2 form an end sequence indicating the status of the UICC at the end of a command. A normal ending of a command is indicating by SW1 SW2 = '90 00'.
Byte Value Action
SW1'6X' or '9X'
(except '60', '61' and '6C')
The terminal shall wait for a further status word (SW2).
The terminal shall return the status words (together with any appropriate data) to the application layer and shall wait for another C-APDU.
Up

7.2.2.4  Error detection and correctionp. 43

The error detection and correction procedure is mandatory for T = 0 protocol except for the terminal during the ATR-procedure.
An error, from the receiver's point of view, is defined by an incorrect parity. The error is indicated on the I/O line, which is set to state L at (10,5 ± 0,2) etu after the leading edge of the start bit for the character. The I/O line shall be in state L for a maximum of 2 etu and a minimum of 1 etu. The transmitter shall check the I/O line for parity error indication at (11 ± 0,2) etu starting from the leading edge of the start bit, in the character being transmitted.
If the UICC or terminal as receiver detects a parity error in a character just received, it shall set the I/O line to state L at (10,5 ± 0,2) etu after the leading edge of the start bit for the character for a maximum of 2 etu to indicate the error to the sender (see Figure 7.2).
If the transmitter detects an error indication at (11 ± 0,2) etu starting from the leading edge of the start bit, in the character being transmitted, the character shall be sent again after a minimum delay of 2 etu.
Up

7.2.3  Transmission protocol T = 1p. 43

7.2.3.0  Introductionp. 43

The T = 1 protocol is a half-duplex asynchronous block based transmission protocol. 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 = 1p. 43

7.2.3.1.0  Introductionp. 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 sizep. 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 TA3 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 integerp. 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 TB3.
7.2.3.1.3  Character waiting timep. 43
CWT is defined as the maximum delay between the leading edges of two consecutive characters in the block.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.3: Character waiting time
Figure 7.3: Character waiting time
(⇒ copy of original ETSI image)
Up
The value of CWT may be calculated from the following equation: CWT = (11 + 2CWI) etu.
7.2.3.1.4  Block waiting timep. 44
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.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.4: Block waiting time
Figure 7.4: Block waiting time
(⇒ copy of original ETSI image)
Up
BWT is used to detect an unresponsive card.
7.2.3.1.5  Block guard timep. 44
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.
Copy of original ETSI image for 3GPP TS 31.ETSI-102-221, Fig. 7.5: Block guard time
Figure 7.5: Block guard time
(⇒ copy of original ETSI image)
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 extensionp. 44
WTX is a parameter used to ask for more time to process a command.
7.2.3.1.7  Error detection codep. 44
The parameter tCi in the ATR is used to define which error detection code to use. LRC shall be used (b1 = 0). All other bits in tCi are RFU and shall be set to 0.

7.2.3.2  Block frame structurep. 44

7.2.3.2.0  Overall structurep. 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 fieldp. 45
7.2.3.2.1.0  Field Structurep. 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 bytep. 45
The NAD-byte identifies the source and the intended destination of the block. The NAD may also be used to distinguish between different logical connections 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
In the first block sent from the terminal, a logical connection is set up based on the addresses in SAD and DAD. Subsequent blocks with an NAD containing the same pair of addresses are associated with the same logical connection.
Only the default value SAD = DAD = 0 shall be supported. All other combinations are RFU.
Up
7.2.3.2.1.2  Protocol Control Bytep. 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
00010'2'Abortion
00011'3'Extension of BWT
00100'4'Error on VPP State (see note)
XXXXX'X'Other values are RFU
NOTE 1:
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  Lengthp. 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 fieldp. 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 with WTX;
  • INF shall be absent to signal error on VPP, or managing chain abortion or resynchronization.
Up
7.2.3.2.2  Epilogue fieldp. 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 notationsp. 47
7.2.3.2.3.1  I-blockp. 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-blockp. 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-blockp. 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 waiting time;
  • S(WTX response), an acknowledge of the extension of the waiting time.
Up

7.2.3.3  Error free operationp. 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 with N(S) = 0 or an S-block.
  • 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.
  • 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).
  • To change the value of IFSD, the terminal sends an S(IFS request). The request shall be acknowledged by the UICC with an S(IFS response) with the same INF. The new IFSD is assumed to be valid as long as no new S(IFS request) has been received by the UICC.
  • 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 = 1p. 48

7.2.3.4.0  General descriptionp. 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 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.
Up
7.2.3.4.1  Protocol initializationp. 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 errorsp. 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.
Up

7.2.3.5  Chainingp. 49

7.2.3.5.0  Chaining Mechanismp. 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 should 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.
Up
7.2.3.5.1  Rules for chainingp. 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