Content for ETSI TS 102 221 PDF version: 18.2.0

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…

6 Initial communication establishment procedures p. 33

6.0 Introduction p. 33

The provisions of clause 6 apply to the LSE base.

6.1 UICC activation and deactivation p. 33

The terminal shall activate and deactivate the contacts of the UICC according to clause 4.5.2. During activation supply

voltage switching, as defined in clause 6.2, shall take place prior to any further activity not related to the supply voltage switching.

6.2 Supply voltage switching p. 34

6.2.0 UICC activation voltage p. 34

The terminal shall initially activate the UICC with the lowest voltage class available, i.e. the class providing the lowest voltage. If no ATR is received, the UICC shall be deactivated and activated with the next higher class, if supported by the terminal. If an ATR is received at the first applied voltage class, the contents of the ATR shall be analysed by the terminal. If the operating class used by the terminal is not supported by the UICC, then:

if the terminal supports any of the voltage classes indicated in the ATR, the terminal shall deactivate the UICC and activate it with a supply voltage class indicated by the UICC;
if the terminal does not support any of the voltage classes indicated in the ATR, the terminal shall not send any APDU to the UICC. The terminal may deactivate the UICC.

If the ATR is corrupted, the terminal shall reset the UICC at least 3 times using the same operating class before rejecting the UICC. In case of 3 consecutive corrupted ATRs, the terminal may activate the UICC with the next higher class. The terminal's behaviour is restricted, and shall only use the next higher voltage class in the retry attempt in this case.

6.2.1 Supply voltage classes p. 34

The supply voltage class shall be indicated in the ATR by the UICC (Ta_i, i > 2).

Table 6.1: Supply voltage classes indicated in ATR

Symbol	Minimum	Maximum	Unit	Class	Encoding (Binary)
Vcc	4,5	5,5	V	A	xx xxx1
Vcc	2,7	3,3	V	B	xx xx1x
Vcc	1,62	1,98	V	C	xx x1xx
Vcc	1,1	1,3	V	D	xx 1xxx
Vcc	RFU	RFU	V	E	x1 xxxx
NOTE 1: Class A, B and C values are according to ISO/IEC 7816-3 [11]. Class D is a further evolution of values specified in ISO/IEC 7816-3 [11]. It is possible to support one class or a range of classes. In the latter case, the support shall be consecutive e.g. AB, BC, CD. A combination like AC or BD is not allowed.

6.2.2 Power consumption of the UICC during ATR p. 34

The maximum power consumption of the UICC during ATR shall not exceed the minimum power supplied by the terminal during a UICC session as defined in clause 6.2.3.

6.2.3 Application related electrical parameters p. 34

The power consumption of the UICC after ATR is restricted to the values indicated in Table 6.4.

The Terminal shall be able to provide more current if one of the following conditions is met:

During the power negotiation procedure (as described in clause 14.5.5), a TERMINAL CAPABILITY command is issued by the terminal indicating a higher value for the maximum available power supply of the terminal. In this case the UICC may draw the indicated power until power-down.
After an application indicating a higher application power consumption is selected by the terminal. An application is considered selected when the access condition is successfully verified. If no access condition is required for the application, the application is considered selected when an application related command is executed within the selected application. Selecting the application and performing a STATUS command is not considered to be the execution of an application command for these purposes. If the application power consumption indicated in the response to the SELECT or STATUS command is higher than the value indicated by the terminal in the TERMINAL CAPABILITY command, the terminal should deselect the application.
The Inter-Chip USB interface is activated by the terminal.

The terminal retrieves the application power consumption requirements by selecting the application. It then gets back the application power consumption indication in the response of the SELECT command. It may as well issue a STATUS command within the application and get this information in the response of the command.

Table 6.2: Void

Table 6.3: Maximum power consumption of the UICC during the UICC session

Symbol	Voltage Class	Maximum for Release 12 and higher (see note)	Maximum for pre-Release 12	Unit
Icc	A	60	60	mA
Icc	B	50	50	mA
Icc	C	60	30	mA
Icc	D	60	N/A	mA
Icc	E	RFU	RFU	mA
NOTE: The maximum power consumption for Class D applies from Release 17 onwards.

Applications may specify their own maximum power consumption values, up to the maximum specified in Table 6.3.

If an application does not indicate its consumption, the terminal shall assume the maximum application power consumption is as specified in Table 6.4 or within the limit given in the TERMINAL CAPABILITY command.

The minimum power supply that the terminal shall be able to supply to the UICC during application session at maximum clock speed is specified in Table 6.4.

Table 6.4: Minimum power supply by the terminal during the UICC session

Symbol	Voltage Class	Minimum	Unit
Icc	A	10	mA
Icc	B	10	mA
Icc	C	10	mA
Icc	D	10	mA
Icc	E	RFU	mA

6.3 Answer To Reset content p. 35

6.3.0 Introduction p. 35

The ATR is the first string of bytes sent from the UICC to the terminal after a reset has been performed. The ATR is defined in ISO/IEC 7816-3 [11].

The terminal shall be able to receive interface characters for transmission protocols other than T = 0 and T = 1, historical bytes and a check byte, even if only T = 0 and T = 1 are used by the terminal.

T = 15 global interface parameters shall be returned by the UICC.

6.3.1 Coding of historical bytes p. 36

The historical bytes indicate to the external world how to use the card. The information carried by the historical bytes of the UICC follows ISO/IEC 7816-4 [12].

The category indicator is the first byte sent by the UICC. Its value shall be '80' which means that the historical bytes are coded in COMPACT-TLV data objects.

The first information sent by the card shall be the "card data service" data object. This data object is introduced by tag '31'. The second information sent by the card shall be the "card capabilities" data object. This data object is introduced by tag '73'. The other data objects are optional.

6.3.2 Speed enhancement p. 36

The terminal and the UICC shall at least support (F,D) = (512,8) and (512,16) in addition to (372,1), the default values. However, other values may also be supported. If the terminal requests PPS using values other than those above then the PPS procedure shall be initiated accordingly. The value of the transmission factors F and D is given by the UICC in TA1 of the ATR.

Table 6.5: Void

When Di = 64 is supported, the interface shall meet the additional requirements below, regardless of the operating conditions used.

Table 6.6: Complement to the I/O characteristics under normal operating conditions when Di = 64 is supported

Symbol	Conditions	Minimum	Maximum	Unit
t_R t_F	C_in = C_out = 30 pF		400	ns
NOTE: To support the additional requirement above, the value of the pull-up resistor that is used on the interface device should be about 10 kΩ.

6.3.3 Global Interface bytes p. 36

The global interface bytes are present after T = 15 indication in the ATR. The presence of global interface bytes is optional and the presence is indicated in the tD_i (i > 1) indicating T = 15. The content and coding of the first tA_i (i > 2) after T = 15 is defined in ISO/IEC 7816-3 [11]. The content and coding of the first tB_i (i > 2) after T = 15 is defined in the present document.

Table 6.7: Coding of the first tB_i (i > 2) after T = 15 of the ATR

b8	b7	b6	b5	b4	b3	b2	b1	Meaning
0	0	0	0	0	0	0	0	No additional global interface parameters supported
1	-	-	1	-	-	-	-	Low Impedance drivers and protocol available on the I/O line available (see clause 7.2.1)
1	1	-	-	-	-	-	-	Inter-Chip USB UICC-Terminal interface supported as defined in ETSI TS 102 600 [18]
1	-	1	-	-	-	-	-	UICC-CLF interface supported as defined in ETSI TS 102 613 [19]
1	-	-	-	1	-	-	-	Secure Channel supported as defined in ETSI TS 102 484 [20]
1	-	-	-	1	1	-	-	Secured APDU - Platform to Platform required as defined in ETSI TS 102 484 [20]
1	-	-	-	-	-	1	-	eUICC-related functions supported as defined in GSMA SGP.22 [33] or GSMA SGP.32 [35]
1	-	-	-	-	-	-	-	LSIs supported (see clause 7.5)
NOTE: Any other value is RFU.

6.4 PPS procedure p. 37

The terminal and the UICC shall support the PPS procedure in order to use transmission parameters other than the default values. The alternative parameters are indicated in the ATR. The interpretation of these parameters is according to ISO/IEC 7816-3 [11] and to the first tB_i (i > 2) after T = 15 in the ATR as defined in Table 6.7 in clause 6.3.3. For PPS1 the terminal shall select a value within the range indicated by the UICC as defined in ISO/IEC 7816-3 [11] and complemented in clause 6.3.2. For PPS2 the terminal shall select a value in accordance with the indication in the first tB_i (i > 2) after T = 15. PPS2 shall only be used if the first tB_i (i > 2) after T = 15 is present in the ATR. The coding for PPS2 is identical to that of the first tB_i (i > 2) after T = 15. The value selected depends upon the features supported by the terminal. The content of PPS2 is coded the same way as the first tB_i (i > 2) after T = 15. A terminal not supporting any of the features indicated in the first tB_i (i > 2) after T = 15 need not to support PPS2 in the PPS procedure.

When the terminal does not support or cannot interpret the values indicated by the card in character TA1 of the ATR, it shall initiate at least one PPS procedure indicating in (Fi, Di) the highest speed the terminal supports before issuing PPS using the default values (372,1).

6.5 Reset procedures p. 37

6.5.1 Cold reset p. 37

Cold reset is the first reset occurring after activation of the contacts. The cold reset is performed according to ISO/IEC 7816-3 [11] and the UICC shall enter the negotiable mode. After a cold reset, the security status shall be reset.

6.5.2 Warm reset p. 37

Warm reset is any reset which is not a cold reset. The warm reset is performed according to of ISO/IEC 7816-3 [11] and the UICC shall enter either the negotiable or the specific mode. If the UICC enters the specific mode, it shall present the same protocol and interface parameters (Fi, Di) as in the session prior to the warm reset. The UICC shall respond with an identical ATR after every warm reset issued within the same session regardless of what application was active. After a warm reset, the security status shall be reset.

6.5.3 Reaction to resets p. 37

A UICC complying with the present document shall either be a "Type 1 UICC" or a "Type 2 UICC".

Figure 6.1 illustrates how the respective types of a UICC react to the cold or warm reset.

Reproduction of ETSI TS 31.ETSI-102-221, Fig. 6.1: Reaction to resets

Figure 6.1: Reaction to resets

6.6 Clock stop mode p. 38

The UICC shall support the clock stop procedure as defined in this clause. The clock stop mode is indicated in tA_i (i > 2) in T = 15 in the ATR, see ISO/IEC 7816-3 [11]. For a UICC supporting only class A operating conditions, clock stop mode "not allowed" may be indicated, see clause 6.3. If the UICC supports any other operating conditions even together with class A, clock stop mode shall be supported and the indication shall be set accordingly. The terminal shall follow this indication independently of operating conditions indicated by the card.

The terminal shall wait at least 1 860 clock cycles after having received the last character, including the guard time (2 etu), of the response before it switches off the clock (if it is allowed to do so). It shall wait at least 744 clock cycles before it sends the first command after having started the clock.

6.7 Bit/character duration and sampling time p. 38

The bit/character duration and sampling time specified in ISO/IEC 7816-3 [11] are valid for all communications.

6.8 Error handling p. 38

If mandatory ATR characters (as defined in the present document) are not present in the ATR then it is up to the terminal to decide if a UICC has been activated or not, e.g. it is a card supporting an application not based on the present document.

If, from the terminal point of view, a UICC has been activated and the terminal has received an ATR with protocol errors then the terminal shall perform a Reset. ATR protocol errors are defined as where the ATR has indicated the presence of certain characters but they are not present. If mandatory UICC ATR characters (as specified in the present document) are absent and not indicated to be present then the terminal may consider this from an error handling point of view to be an ATR protocol error. The terminal shall not reject the UICC until at least three consecutive ATRs with protocol errors are received.

During the transmission of the ATR, the error detection and character repetition procedure specified in clause 7.2.2.4 is optional for the terminal. For the subsequent transmission on the basis of T = 0 this procedure is mandatory for the terminal.

For the UICC the error detection and character repetition procedure is mandatory for all communications using T = 0.

6.9 Compatibility p. 38

For compatibility with existing terminals, UICCs that are used in applications where the supply voltage class indication is based on the STATUS response procedure (see clause 6.2.3) shall support this procedure in addition to the supply voltage class indication in the ATR as defined in the present document.

In case the UICC does not support any supply voltage indication, the UICC shall be treated as a 5 V only card by the terminal.