TSG-Terminals Working Group 3 (USIM) meeting #4	TSGT3#4(99)135
Tokyo 19th - 21th April, 1999	Page  1

Source:	Schlumberger & Gemplus 

Title:	T=1 and T=0 issues in 21.11  
___________________________________________________________________________

1.	CONTEXT
The possibility of having two different transport protocols T=0 and T=1 mandatory for the UICC has been advocated. It is believed that such an approach does not bring a proven benefit for the whole Usim application and process.
This technical contribution compares both protocols with respect to speed, backwards compatibility, interoperability, card implementation.

2.	GENERAL CHARACTERISTICS of T=0 and T=1

T=0

T=0 is an Asynchronous Transport Protocol Character Oriented. It is the only Transport Protocol so far used in the SIM/Terminal Interface (GSM 11.11).It is a very simple protocol, low memory consuming currently used in most of Smart Cards.
Error recovery is very simple :The wrong character is immediately detected by the Receiver, a signal Error is signaled over the I/O line, then the Transmitter retransmits the Character.
An important point is that whatever the protocol negotiated for normal operation, the card OS has to implement T=0 for ATR Transport purposes.
Limitations of T=0 are writing of Large Block Data into small buffers and use of Applicative APDU (GET RESPONSE) for the Transport of some APDU (Type 4 as defined in ISO 7816-4).

T=1

T=1 is a classic Block  Transport Protocol based on X-25.
This protocol is more suitable when transmitting large Data Blocks through a Low Error Rate I/O link. Additionally it allows for a real separation of both transport and applicative layers. The T=1 software does not have to analyze (other that the length from LC and/or LE) the APDU to be sent. It simply packages it within the Informative Field of the I-Block.
But on the other hand T=1 involves fixed heavy overhead for both APDU Command and Response regardless the APDU lenght.
As all the protocols T=1 runs well as long as no error recovery is required.Error recovery procedures are complicated and can lead to collapse situations with unexpected abort transaction. In the event of lost blocks the procedure for resynchronization is not fully defined. A particularly case appears after a Card Time-out :The Reader has to recover the control of the transmission. There is risk for I/O line contention.

3.	IMPLEMENTATION COSTS

T=0 allows for lowest cost card implementation.Transmission of large Data Block involves the use of large ,expensive RAM buffer into the Card. The philosophy for design of the Card/Terminal Interface is not to send data to the Card that can not be immediately exploitable. This minimizes waste of memory.

4.	SPEED
T=1 Protocol does not allow for a systematic faster transmission of APDUs.
This is because the characters within the Block are asynchronous in the same way than for T=0 but with extra overhead for Block Framing. In fact we can consider T=1 as an “Character Oriented ” Block Transport Protocol: Sequential characters can be separated as much as CWT , which is defined during the ATR.
Let’s see some examples  :

	-When transmitting CR1 APDU (No Field Data) the T=0 is faster :5 characters are to be transmitted whereas the same APDU Command/Response pair is packaged in T=1 with 9/10 characters. The transmission speed is the same.
	-When transmitting CR2 APDU (The application requires Data from the Card. A READ operation).The T=0 is faster again for the same reasons than for CR1.
	-When transmitting CR3 APDU (WRITE) operation the speed depends on the Card Buffer Size. With small buffers T=1 will be faster. Small buffers penalize Cards when writing because the transmission is to be done on a character by character basis. Since the buffer of most of the existing SIM card are more than 176 bytes only very long APDU will be penalized.
	-When Transmitting CR4 APDU at first sight the T=1 is more efficient: You can package it in only one TPDU instead of 2 TPDU in T=0 (The second one being the GET RESPONSE command).But once again the real speed will depend on the Data Field APDU Size. With short APDU, the T=0 may be more efficient even if a GET RESPONSE additional APDU is needed for Transport Purposes.

5.	INTEROPERABILITY

T=1 does not guarantee interoperability to the same extent than T=0.
1.The Error Corrector algorithm is not defined :It is only mentioned that it must takes up two bytes as much. Both a single XOR LCR byte or a 2-byte CRC are possible. One terminal and one card using different ECC are not interoperable.
2. There are ambiguous situations when Error Procedure Recovery is needed.
	
6.	BACKWARDS COMPATIBILITY

GSM application only considers T=0 for APDU Transport Purposes. Furthermore the Toolkit application Protocol is supported by T=0.
Toolkit Protocol modification for T=1 involves potentially a long process of specification and development, and the feasibility of an efficient implementation  is not demonstrated today.

7.	CONCLUSION

Mandatory Coexistence of both protocols within the ICC Card seems not fully justified by a uniform performance enhancement and it could create limitations.
The position of this paper is that making both protocols mandatory for the card will have the effect that the terminal will force the transport protocol. Conversely, making T=1 optional would allow the card to decide what is the best protocol in accordance with its internal data organisation and the nature of its embedded applications.
More investigation in the implementation issues is mandatory to decide for the best scheme. 
In order to not delay the issuance of the 21.11 for the TSG-T approval it is suggested that the mention of T=1 has to be removed from the document for the time being and possibly replaced by the performance needs.