3GPP  T3#5 and ETSI SMG9 #18	Tdoc T3-99150 and Tdoc SMG9  9-99-150
31 May - 4 June, 1999
Mariehamn, Finland

Source: Gemplus, Schlumberger

T=1 efficiency and compliance with the proactive protocol

1	Comparison between T=0 and T=1

1.1	Figures about the performance

The following table is a simulation aiming at illustrating protocol efficiency according to protocol implementation. The figures shown represent the number of characters actually exchanged on the IO line (including both application data and protocol signalisation).
This simulation assumes that the application buffer is 64 bytes long.

	T=0	T=1
(using a 32 bytes long IO buffer)	T=1
(using a 64 bytes long IO buffer)	
Case 1	7	14	14	
Case 2:
Le=32
Le=64
Le=128	
40
72
136	
55
95
175	
47
87
159	
Case 3:
Lc=32
Lc=64
Lc=128	
40
72
200	
55
95
175	
47
87
159	
Case 4:
Lc=32, Le=32
Lc=64, Le=32
Lc=128, Le=32	
80
112
240	
96
136
216	
80
120
192	

1.2	Implementation choices to be made in T=1

	ISO 7816-3	EMV 96 & 97	PSP	VisaCash 1.5	
NAD parity error	Nothing	Rule 5.2.5.1:
R-Block	Card does not answer but remains in reception state	R-block	
Other NAD errors	Nothing	R-Block	Card does not answer but remains in reception state	R-block	
Which NAD to use if the first block is wrong	Ambiguous	00h	If first byte valid, it is taken as NAD	If parity, EDC, overrun,…error, use 00h	
When the retry counter is to be incremented?	"when an invalid block is received"
but what is an invalid block?	Idem ISO	PSP defines its own list of cases. (not detailed here)	Not clarified: the cou nter is incremented as soon as the block is unexpected	
…					

Amongst other ambiguous situations where choices are to be made:
•	Card behaviour after 2 retries
•	Card send a S-request and receives a S-Resynch request
•	Card behaviour when it receives a S-WTX request
•	ISO 7816-3 scenarii 10, 11, 25
•	…

2	Support of Extended addressing mode in T=0 and T=1
Extended addressing allows IFD and ICC to exchange more than 256 bytes (65535 bytes of incoming data, 65536 bytes of outgoing data).
This feature requires 3 bytes long Lc or Le fields (see ISO/IEC 7816 for more details).

2.1	T=1
This is quite easy to implement in T=1 as the protocol layer doesn’t deal with the content of the transported data. The only adaptation to be implemented is the format of the conveyed TPDUs (3 bytes long length fields in place of 1 byte long fields).

2.2	T=0
Due to the design of T=0, it is very difficult to implement extended addressing in this protocol. The solution proposed by ISO/IEC 7816 is to split the APDU in a plurality of blocks and to convey each block in an envelope command using short addressing mode.

2.3	Conclusion
It is proposed to reserve T=0 protocol for short addressing mode, and to reserve T=1 for extended addressing mode. Thus, each of these protocol will be used in its most efficient way.

3	Proactive protocol support by T=1

A brut force approach to mapping the proactive protocol onto T=1 shall consist of:

Terminal	Case 1 or case 3 APDU + Data		Fetch		Terminal response	
Card		91XX		Proactive command

The case 2 and case 4 are even more complex as a get response/data pair must be inserted in the transaction.

It shall be clearly less efficient than in T=0 as each TPDU transportation suffers from T=1 TPDU overhead.

Alternately, the proactive protocol could take advantage of T=1 capabilities to improve its efficiency. The idea is to adapt TPDU transportation in accordance with this requirement (obviously, the new APDU transportation model will not be compliant with ISO/IEC 7816-4 any longer).

The following chart is a preliminary proposal to transport proactive commands encapsulated into T=1 data blocks.
The basic idea is to gather in one TPDU all that has not to be implemented in a handshake way and to remove the "Fetch" command as "get response" was removed from T=1.
The status word 91XX might be concatenated with its subsequent proactive command. In case of case 2 and case 4 commands this might be concatenated to the response data of the initial APDU.