3GPP TSG-T3 (USIM) #3	Tdoc T3-99068
16-18 th of March, 1999
Espoo, Finland

Considerations when using T=1 in GSM/3GPP applications

Source: Nokia

A request on input papers on the usage of T=1 for the GSM and 3GPP applications has been asked for by the responsible groups SMG9 and TSG-T3. This document highlights a couple of issues that are related to the usage of T=1. It also deals with the compatibility aspects as T=0 always must be supported by the card and the terminal if the GSM SIM is intended to be one of the applications on the card.

On the low level interface protocol the main difference is that there is no need for parity checking on the fly for character repetition when using T=1. The parity can still be used in order to indicate problems in the transmission but no automatic retransmission is used. Otherwise the low-level protocol is similar.

The following characteristics of the low level protocol is however specific to the T=1 protocol. For more details on the T=1 specification please refer to ISO/IEC 7816-3 2nd Ed and ISO/IEC 7816-4.

Node address byte (NAD). The NAD consists of a Source address byte SAD and a destination address byte DAD. The node address byte may be used to indicate different logical channels when used. Different logical channels may also be indicated by the Class byte. The proposal is not to use node addressing to indicate the use of logical channels. Using the class byte for indicating logical channels is the only mechanism provided by the T=0 protocol. In order to keep the mechanism the same the class byte is to be used for indication of logical channel also when using T=1 protocol.

Protocol Control Byte (PCB). The PCB is used for different purpose depending upon if it is sent together with an I-block (Information block), R-block (Response block) or an S-block (Supervisory block). The T=1 protocol allows for resynchronisation in case of transmission errors where there is a need to return to initial protocol parameters. As there are other means for recovering transmission errors the use of the resynchronisation feature should be considered not to be implemented. The resynchronisation initiative lies on the terminal so no problems are encountered if this procedure is not implemented.  

Information Field Size (IFS). As the T=1 protocol is a block protocol the IFS must be agreed between the terminal and the card. There is no corresponding functionality in the T=0 protocol. The length of the IFS can be different for the card IFSC or the terminal IFSD. The IFSC value is indicated by the card in TA(i), with the default value of 32. The maximum length of the information field is 254 bytes. The default value for both IFSC and IFSD is 32. The block size can be negotiated between the terminal and the card by using. In order to reduce the amount of negotiation the card shall indicate an IFSC value of 254 in TA(i).  The terminal shall initiate and IFSD request with the value of 254 at the start of the session. After this the communication in both directions may use up to 254 bytes in the information field.

Character Waiting Time (CWT). The character waiting time is the maximum delay between the leading edge of two characters sent within a block. The CWT can be calculated for the following formula: CWT = (11+ 2 CWI) etu. The default value for CWI is 13. This gives a CWT of 8203 etu. This figure is to be compared with the work waiting time of T=0 that has a default value of 9600 etu. In order to improve the data exchange on the interface an other value than the default should be used as the maximum value. The CWT value is the maximum allowed value, which means that in practice lower values are used. However in error cases either the terminal or the card must wait the CWT time before an error indication can be given. A value of 0-4 should be considered.

Block Waiting Time (BWT). This is the time between the leading edge of the last character send by the card/terminal to the leading edge of the first character sent by the terminal/card. This BWT applies when changing direction of the transmission. The BWT can be used to detect a mute card. The response from the card is dependent upon the command that has been issued. The goal should be that the card is able to come back with a response within the BWT. If this is not possible using T=0 protocol the card can ask for more time. However the use of procedure bytes is T=0 specific and more time indication is different for T=1. The card may send an S-block with waiting time extension request. The additional waiting time information is coded on one byte in the command. The terminal shall acknowledge this request. In order to reduce the need for using waiting time extension it is essential that the BWT is set to a value that allows the card to in average process the commands that are issued. The authentication algorithm is expected be one of the commands that will load the card with internal computing. However the response to the authentication algorithm is expected back to the network within a certain time. Therefore the value for the BWT should be set to at least cover the execution time of the authentication algorithm. Based on the fact that the response to the authentication algorithm is to be expected within less than 1s the value for BWT should be in the range of 0-4.

Block Guard Time (GBT). The block guard time is the minimum time between the leading edge of the last character sent by the card/terminal and the leading edge of the first character sent by the terminal/card. The minimum value of BGT is 22 etu.

Error detection code. One of the two error detection types is to be used. It is to be considered if there is a need to support both from the card side. The error correction code to be used is indicated in TC(i). The default value is LRC b1=0.

VPP state control. No VPP control is used which means that b8, b4=0 in the NAD byte.