TS 102 613 - ETSI

TS 102 613 - ETSI

ETSI TS 102 613 V7.3.0 (2008-09) Technical Specification Smart Cards; UICC - Contactless Front-end (CLF) Interface; Part 1: Physical and data link la...

566KB Sizes 2 Downloads 9 Views

Recommend Documents

TS 102 980 - ETSI
Text: Eric Burdon. Figure 1: Simplified schematic of DL Plus object creation from DL message and DL Plus tags. The DL Pl

TS 102 657 - ETSI
15.02.2011 - delivery of retained data ..... Delivery of results or a failure response . ...... (SSD) for IP delivery; P

TS 102 042 - ETSI
2. Reference. RTS/ESI-0002042version231. Keywords e-commerce, electronic signature, extended validation certificat, publ

TS 129 002 - ETSI
07.06.2010 - This Technical Specification (TS) has been produced by the ETSI 3rd Generation Partnership Project (3GPP).

TR 102 664 - V1.2.1 - Electromagnetic compatibility and Radio - ETSI
European Telecommunications Standards Institute 2010. ...... penetration in the EU will rise similarly to North America

TS 102 905 - V1.1.1 - Digital Video Broadcasting (DVB); Technical
DVB BlueBook A109: " Digital Video Broadcasting DVB-HN (Home Network) ... Layer Specifications - Corrigendum 2: IEEE Std

TS 102 221 - V8.2.0 - Smart Cards; UICC-Terminal interface; Physical
ETSI TS 102 221 V8.2.0 (2009-06). Technical Specification. Smart Cards;. UICC-Terminal interface;. Physical and logical

TETRA - ETSI
Mar 4, 2010 - Intellectual Property Rights . .... Supplementary Service Pre-emptive Priority Call (SS-PPC) stage 1 speci

The 613 Commandments - ShulCloud
May 23, 2015 - Why were the Ten Commandments not said at the beginning of the Torah? The ..... animal. P203: Assisting t

Qualcomm - ETSI
2. Guillaume Lebrun, Director. Mai, 2015. Qualcomm Technologies, Inc. Media Distribution: Requirements. Page 3. 3. Busin

ETSI TS 102 613 V7.3.0 (2008-09) Technical Specification

Smart Cards; UICC - Contactless Front-end (CLF) Interface; Part 1: Physical and data link layer characteristics (Release 7)

Release 7

2

ETSI TS 102 613 V7.3.0 (2008-09)

Reference RTS/SCP-T070138d

Keywords smart card

ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88

Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp

Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 2008. All rights reserved. TM

TM

TM

TM

DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. TM 3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.

ETSI

Release 7

3

ETSI TS 102 613 V7.3.0 (2008-09)

Contents Intellectual Property Rights ................................................................................................................................6 Foreword.............................................................................................................................................................6 Introduction ........................................................................................................................................................6 1

Scope ........................................................................................................................................................7

2

References ................................................................................................................................................7

2.1 2.2

3 3.1 3.2 3.3 3.4

Normative references ......................................................................................................................................... 7 Informative references ........................................................................................................................................ 8

Definitions, symbols, abbreviations and coding conventions ..................................................................8 Definitions .......................................................................................................................................................... 8 Symbols .............................................................................................................................................................. 9 Abbreviations ..................................................................................................................................................... 9 Coding conventions .......................................................................................................................................... 10

4

Principle of the Single Wire Protocol.....................................................................................................10

5

System architecture ................................................................................................................................11

5.1 5.2 5.3 5.4

6 6.1 6.2 6.2.1 6.2.2 6.2.2.1 6.2.2.2 6.2.2.3 6.2.3 6.2.3.1 6.2.3.2 6.2.3.3 6.2.3.4 6.2.4 6.2.5 6.2.6

7 7.1 7.1.1 7.1.2 7.1.3 7.1.4 7.1.4.1

8 8.1 8.2 8.3 8.4

9 9.1 9.2 9.2.1

General overview ............................................................................................................................................. 11 TS 102 221 support .......................................................................................................................................... 11 Configurations .................................................................................................................................................. 12 Interaction with other interfaces ....................................................................................................................... 12

Physical characteristics...........................................................................................................................12 Temperature range for card operation .............................................................................................................. 12 Contacts ............................................................................................................................................................ 12 Provision of contacts ................................................................................................................................... 12 Contact activation and deactivation ............................................................................................................ 13 SWIO contact activation ....................................................................................................................... 13 SWIO contact deactivation.................................................................................................................... 13 Deactivation of the UICC...................................................................................................................... 13 Interface activation ..................................................................................................................................... 13 Initial interface activation ..................................................................................................................... 13 Subsequent interface activation ............................................................................................................. 14 Timing parameters ................................................................................................................................ 14 Impact on other interfaces ..................................................................................................................... 17 Behaviour of a UICC in a terminal not supporting SWP ............................................................................ 17 Behaviour of terminal connected to a UICC not supporting SWP.............................................................. 17 Inactive contacts ......................................................................................................................................... 17

Electrical characteristics .........................................................................................................................17 Operating conditions ........................................................................................................................................ 17 Supply voltage classes ................................................................................................................................ 18 Vcc (C1) low power mode definition ........................................................................................................... 18 Signal S1 ..................................................................................................................................................... 19 Signal S2 ..................................................................................................................................................... 19 Operating current for S2........................................................................................................................ 19

Physical transmission layer ....................................................................................................................20 S1 Bit coding and sampling time (Self-synchronizing code) ........................................................................... 20 S2 switching management ................................................................................................................................ 21 SWP interface states management.................................................................................................................... 22 Power mode states/transitions and Power saving mode ................................................................................... 23

Data link layer ........................................................................................................................................24 Overview .......................................................................................................................................................... 24 Medium Access Control (MAC) layer ............................................................................................................. 24 Bit order ................................................................................................................................................ 24

ETSI

Release 7

9.2.2 9.2.3 9.2.4 9.3 9.3.1 9.4 9.4.1

10

SHDLC LLC definition ..........................................................................................................................30 SHDLC overview ............................................................................................................................................. 30 Endpoints.......................................................................................................................................................... 30 SHDLC frame types ......................................................................................................................................... 30 Control Field .................................................................................................................................................... 31 I-Frames coding .......................................................................................................................................... 31 S-Frames coding ......................................................................................................................................... 31 U-Frames coding ........................................................................................................................................ 32 Changing sliding window size and endpoint capabilities ................................................................................. 32 RSET frame payload ................................................................................................................................... 32 UA frame payload....................................................................................................................................... 33 SHDLC context ................................................................................................................................................ 33 Constants .................................................................................................................................................... 33 Variables ..................................................................................................................................................... 33 Initial Reset State ........................................................................................................................................ 33 SHDLC sequence of frames ............................................................................................................................. 34 Nomenclature .............................................................................................................................................. 34 Link establishment with default sliding window size ................................................................................. 34 Link establishment with custom sliding window size ................................................................................. 35 Data flow .................................................................................................................................................... 36 Reject (go N back) ...................................................................................................................................... 36 Last Frame loss ........................................................................................................................................... 37 Receive and not ready ................................................................................................................................. 37 Selective reject ............................................................................................................................................ 38 Implementation model ...................................................................................................................................... 38 Information Frame emission ....................................................................................................................... 38 Information Frame reception ...................................................................................................................... 39 Reception Ready Frame reception .............................................................................................................. 40 Reject Frame reception ............................................................................................................................... 40 Selective Reject Frame reception................................................................................................................ 41 Acknowledge timeout ................................................................................................................................. 41 Guarding/transmit timeout .......................................................................................................................... 42

CLT LLC definition ...............................................................................................................................42

11.1 11.2 11.2a 11.3 11.4 11.5 11.5.1 11.5.2 11.5.3 11.5.3.1 11.5.3.2 11.5.3.3 11.6 11.6.1 11.6.2

12 12.1 12.2 12.2.1 12.2.2

ETSI TS 102 613 V7.3.0 (2008-09)

Structure ................................................................................................................................................ 25 Bit Stuffing............................................................................................................................................ 25 Error detection....................................................................................................................................... 26 Supported LLC layers ...................................................................................................................................... 26 Interworking of the LLC layers .................................................................................................................. 27 ACT LLC definition ......................................................................................................................................... 28 SYNC_ID verification process ................................................................................................................... 29

10.1 10.2 10.3 10.4 10.4.1 10.4.2 10.4.3 10.5 10.5.1 10.5.2 10.6 10.6.1 10.6.2 10.6.3 10.7 10.7.1 10.7.2 10.7.3 10.7.4 10.7.5 10.7.6 10.7.7 10.7.8 10.8 10.8.1 10.8.2 10.8.3 10.8.4 10.8.5 10.8.6 10.8.7

11

4

System Assumptions ........................................................................................................................................ 42 Overview .......................................................................................................................................................... 42 Supported RF protocols .................................................................................................................................... 42 CLT Frame Format ........................................................................................................................................... 43 CLT Command Set ........................................................................................................................................... 44 CLT Frame Interpretation ................................................................................................................................ 44 CLT frames with Type A aligned DATA_FIELD ...................................................................................... 44 Handling of DATA_FIELD by the CLF ..................................................................................................... 45 Handling of ADMIN_FIELD ..................................................................................................................... 46 CL_PROTO_INF(A)............................................................................................................................. 46 CL_PROTO_INF(F) ............................................................................................................................. 46 CL_GOTO_INIT and CL_GOTO_HALT ............................................................................................ 48 CLT Protocol Rules .......................................................................................................................................... 48 Rules for the CLF ....................................................................................................................................... 48 Rules for the UICC ..................................................................................................................................... 49

Timing and performance ........................................................................................................................49 SHDLC Data transmission mode ..................................................................................................................... 49 CLT data transmission mode for ISO/IEC 14443 Type A ............................................................................... 50 CLF processing delay when receiving data from the PCD ......................................................................... 50 CLF processing delay when sending data to the PCD ................................................................................ 51

ETSI

Release 7

12.2.3 12.2.4 12.3

5

ETSI TS 102 613 V7.3.0 (2008-09)

Timing values for the CLF processing delay .............................................................................................. 51 Timing value for the CLF processing delay (Request Guard Time) ........................................................... 52 CLT data transmission mode for ISO/IEC18092 212kbps/424kbps passive mode .......................................... 53

Annex A (informative):

(Void) ..............................................................................................................54

Annex B (informative):

Change history ...............................................................................................55

History ..............................................................................................................................................................57

ETSI

Release 7

6

ETSI TS 102 613 V7.3.0 (2008-09)

Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). The contents of the present document are subject to continuing work within TC SCP and may change following formal TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x

the first digit: 0

early working draft;

1

presented to TC SCP for information;

2

presented to TC SCP for approval;

3

or greater indicates TC SCP approved document under change control.

y

the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.

z

the third digit is incremented when editorial only changes have been incorporated in the document.

Introduction The present document defines a communication interface between the UICC and a contactless frontend (CLF) in the terminal. This interface allows the card emulation mode independent of the power state of the terminal as well as the reader mode when the terminal is battery powered. The aim of the present document is to ensure interoperability between a UICC and the CLF in the terminal independently of the respective manufacturer, card issuer or operator. Any internal technical realization of either the UICC or the CLF is only specified where these are reflected over the interface.

ETSI

Release 7

1

7

ETSI TS 102 613 V7.3.0 (2008-09)

Scope

The present document specifies the Single Wire Protocol (SWP). SWP is the interface between the UICC and the CLF. The present document defines: •

Layer1: The physical layer which is responsible for activating, maintaining and deactivating the physical link between the UICC and the CLF. It defines electrical (voltage and current levels, timing and coding of voltage and current levels), mechanical (physical contacts) and functional (data rates) specifications. It also defines the initial communication establishment and the end of the connection.



Layer 2: The data link layer which is responsible for the physical addressing of the data through frames and Link Protocol Data Units (LPDU). The data link layer is also responsible for error notification, ordered delivery of frames and flow control. This layer can be split into two sub-layers: -

The Medium Access Control (MAC) layer which manages frames.

-

The Logical Link Control layer which manages LPDUs and is responsible for the error-free exchange of data between nodes. Three different Logical Link Control layers are defined in the present document.

2

References

References are either specific (identified by date of publication and/or edition number or version number) or non-specific. •

For a specific reference, subsequent revisions do not apply.



In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version of that document in the same Release as the present document.



Non-specific reference may be made only to a complete document or a part thereof and only in the following cases: -

if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of the referring document;

-

for informative references.

Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference. For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the method of access to the referenced document and the full network address, with the same punctuation and use of upper case and lower case letters. NOTE:

2.1

While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity.

Normative references

The following referenced documents are indispensable for the application of the present document. For dated references, only the edition cited applies. For non-specific references, the latest edition of the referenced document (including any amendments) applies. [1]

ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics".

[2]

ISO/IEC 14443-2: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards Part 2: Radio frequency power and signal interface".

ETSI

Release 7

8

ETSI TS 102 613 V7.3.0 (2008-09)

[3]

ISO/IEC 14443-3: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards Part 3: Initialization and anticollision".

[4]

ISO/IEC 14443-4: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards Part 4: Transmission protocol".

[5]

ISO/IEC 13239: "Information technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures".

[6]

ETSI TS 102 600: "Smart Cards; UICC-Terminal interface; Characteristics of the USB interface".

[7]

ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT)".

[8]

ISO/IEC 18092: "Information technology - Telecommunications and information exchange between systems - Near Field Communication - Interface and Protocol (NFCIP-1)".

2.2

Informative references

The following referenced documents are not essential to the use of the present document but they assist the user with regard to a particular subject area. For non-specific references, the latest version of the referenced document (including any amendments) applies. Not applicable.

3

Definitions, symbols, abbreviations and coding conventions

3.1

Definitions

For the purposes of the present document, the following terms and definitions apply: card emulation mode: a mode where the UICC emulates a contactless card through the CLF class A operating conditions: terminal or a smart card operating at 5 V ± 10 % class B operating conditions: terminal or a smart card operating at 3 V ± 10 % class C operating conditions: terminal or a smart card operating at 1,8 V ± 10 % contactless frontend: circuitry in the terminal which: •

handles the analogue part of the contactless communication;



handles communication protocol layers of the contactless transmission link;



exchanges data with the UICC.

full duplex: Simultaneous bidirectional data flow half duplex: Sequential bidirectional data flow idle bit: bit with logical value 0 sent outside a frame master: entity which provides the S1 signal reader mode: mode where the UICC act as a contactless reader through the CLF state H: high electrical level of a signal (voltage or current) state L: low electrical level of a signal (voltage or current) S1: signal from the master to a slave

ETSI

Release 7

9

ETSI TS 102 613 V7.3.0 (2008-09)

S2: signal from the slave to the master slave: entity which is connected to the master and provides the S2 signal transition sequence: signal sent by the master during RESUME, consisting of the state L period of an idle bit TS 102 221 [1] interface: this term refers to the asynchronous serial UICC-Terminal interface defined in TS 102 221 [1], using RST on contact C2, CLK on contact C3 and I/O on contact C7 UICC powering modes: •

Full power mode: the UICC is powered according to TS 102 221 [1] limitations in operating state.



Low power mode: the UICC is running in a reduced power mode as defined in the present specification.

wakeup sequence: sequence transmitted by the slave before each frame

3.2

Symbols

For the purposes of the present document, the following symbols apply: Gnd IH IL T TH1 TH0 TCLF TRFn TSWP TUICC tF tR Vcc VIH VIL VOH VOL

3.3

Ground Current signalling state H of S2 Current signalling state L of S2 Bit duration Duration of the state H for coding a logical 1 of S1 Duration of the state H for coding a logical 0 of S1 Processing time of the CLF for a packet of data Transfer time of contactless command or response over the RF interface Transfer time a single SWP packet of date Processing time of the UICC for a contactless command Fall time Rise time Supply Voltage Input Voltage (high) Input Voltage (low) Output Voltage (high) Output Voltage (low)

Abbreviations

For the purposes of the present document, the following abbreviations apply: ACT CLF CLK CLT CRC EOF HDLC I/O ISO LLC LPDU LSB MAC MSB NFCIP-1

ACTivation protocol ContactLess Frontend CLocK ContactLess Tunnelling Cyclic Redundancy check End Of Frame High level Data Link Control Input/Output International Organization for Standardization Logical Link Control Link Protocol Data Unit Least Significant Bit Medium Access Control Most Significant Bit Near Field Communication - Interface and Protocol

ETSI

Release 7

PCD PICC REJ RF RFU RNR RR RST SREJ SHDLC SOF SWIO SWP USB

3.4

10

ETSI TS 102 613 V7.3.0 (2008-09)

Proximity Coupling Device Proximity Integrated Circuit Card Reject Radio Frequency Reserved for Future Use Receive Not Ready Receive Ready ReSeT Selective Reject Simplified High Level Data Link Control Start Of Frame Single Wire protocol Input/Output Single Wire Protocol Universal Serial Bus

Coding conventions

For the purposes of the present document, the following coding conventions apply: •

All lengths are presented in bytes, unless otherwise stated.



Each byte is represented by bits b8 to b1, where b8 is the Most Significant Bit (MSB) and b1 is the Least Significant Bit (LSB). In each representation, the leftmost bit is the MSB.



Hexadecimal values are enclosed in single quotes ('xx').

In the UICC, all bytes specified as RFU shall be set to '00' and all bits specifies as RFU shall be set to 0.

4

Principle of the Single Wire Protocol

The SWP interface is a bit oriented, point-to-point communication protocol between a UICC and a contactless frontend (CLF) as shown in figure 4.1. The CLF is the master and the UICC is the slave.

Figure 4.1: SWP data transmission

ETSI

Release 7

11

ETSI TS 102 613 V7.3.0 (2008-09)

The principle of the Single Wire Protocol is based on the transmission of digital information in full duplex mode: •

The signal S1 is transmitted by a digital modulation (L or H) in the voltage domain.



The signal S2 is transmitted by a digital modulation (L or H) in the current domain.

When the master sends S1 as state H then the slave may either draw a current (state H) or not (state L) and thus transmit S2. With pulse width modulation bit coding of S1, it is possible to transmit a transmission clock, as well as data in full duplex mode. This bit coding of S1 is described in clause 8.1 of the present document. S2 is meaningful only when S1 is in state H.

5

System architecture

5.1

General overview

Figure 5.1: CLF-UICC physical link Figure 5.1 represents the physical link between the CLF and the UICC. The contact C6 of the UICC is connected to the CLF for the transmission of S1 and S2.

5.2

TS 102 221 support

A UICC supporting the SWP interface and a terminal supporting SWP shall remain compliant with TS 102 221 [1]. In order to maintain low power characteristics needed by some operating mode, a terminal supporting the SWP interface shall not support class A operating condition. For the low power mode, the electrical characteristics of contact C1 (Vcc) are extended by the present document. Contacts C2, C3 and C7 shall behave as specified in TS 102 221 [1].

ETSI

Release 7

5.3

12

ETSI TS 102 613 V7.3.0 (2008-09)

Configurations

The terminal indicates the support of SWP interface in the terminal capability as defined in TS 102 221 [1]. The UICC indicates support of SWP interface in the Global Interface bytes of the ATR as defined in TS 102 221 [1]. When both the terminal and the UICC are supporting the SWP interface, several operation modes become possible in addition to the operation modes already supported by terminal not supporting the SWP interface and the UICC: •

Only the SWP interface is activated. This may occur while the whole terminal is powered and other interfaces (e.g. the TS 102 221 [1] or TS 102 600 [6] interfaces) are idle or not activated, or while the terminal is switched OFF (i.e. the whole terminal may not be operative).



The SWP interface is activated while a session on another terminal-UICC interface is in progress (e.g. the TS 102 221 [1] or TS 102 600 [6] interface). In this case, the different interfaces shall be active concurrently, and therefore actions on the SWP interface shall not disturb the terminal-UICC exchange on the other interfaces and vice-versa.

5.4

Interaction with other interfaces

Communication between a terminal supporting the SWP interface and a UICC supporting the SWP interface take place either over the SWP interface on contact C6 as specified in the present document, or over the interfaces using contacts C2, C3, C4, C7 and C8 as defined in TS 102 221 [1] and TS 102 600 [6]. Signalling on a contact assigned to one interface shall not affect the state of other contacts assigned to another interface. This also applies to the activation sequence of the UICC. The power provided on contacts C1 (Vcc) and C5 (Gnd) shall cover the power consumption of all active interfaces of the UICC. Operation of the SWP interface after activation shall be independent from operation of other interfaces (e.g. the TS 102 221 [1] or TS 102 600 [6] interface) that may be implemented on the UICC. Any reset signalling (RST signal on contact C2 as specific to the TS 102 221 [1] interface or logical reset on TS 102 600 [6] interface) shall only affect the UICC protocol stack related to these interfaces. SWP-related processes shall not be affected by another interface reset signal. A logical reset signalling on the data link layer (SHDLC RSET) over the SWP interface as well as activation and deactivation of SWP interface shall not affect any of the other interfaces.

6

Physical characteristics

6.1

Temperature range for card operation

In the present document, all parameter values for the SWP interface shall apply for the standard temperature range for storage and full operation as defined in TS 102 221 [1].

6.2

Contacts

6.2.1

Provision of contacts

Vcc (contact C1) and Gnd (contact C5) provided in the UICC shall be reused by the terminal to provide power supply. SWIO (contact C6) of the UICC shall be used for data exchange between the UICC and the CLF.

ETSI

Release 7

6.2.2

13

ETSI TS 102 613 V7.3.0 (2008-09)

Contact activation and deactivation

The terminal shall connect, activate and deactivate contacts C2, C3 and C7 of the UICC in accordance with the operating procedures specified in TS 102 221 [1] and the contacts C4 and C8 in accordance with the operating procedures specified in TS 102 600 [6] when these interfaces are used. The terminal shall activate the contact C1 (Vcc) according to the TS 102 221 [1]. A terminal may decide not to perform the contact and interface activation of SWP if it detected in either this or a previous card session that the UICC does not support the SWP.

6.2.2.1

SWIO contact activation

As long as Vcc (contact C1) is not activated, the terminal shall keep SWIO (contact C6) deactivated (S1 state L). The terminal activates Vcc (contact C1) in order to either activate the SWP interface or Vcc (contact C1) is activated due to the activation of another interface on the UICC. The activation of the SWIO (contact C6) takes place when the terminal sets the SWIO signal from state L to state H. This indicates to the UICC to activate its SWP interface.

6.2.2.2

SWIO contact deactivation

In order to deactivate SWIO (contact C6), the terminal shall set SWP to the DEACTIVATED state as defined in clause 8.3.

6.2.2.3

Deactivation of the UICC

In addition to the deactivation as given in TS 102 221 [1] and TS 102 600 [6] the terminal shall deactivate SWIO (contact C6) before deactivating Vcc (contact C1).

6.2.3

Interface activation

6.2.3.1

Initial interface activation

The following process shall take place after the contact activation of SWIO (contact C6). This process makes use of SWP interface states management described in clause 8.3 and of the ACT LLC layer as described in clause 9.4. The sequence is as follows: •

The UICC shall indicate that it is ready to exchange data via SWP by resuming SWP. -



The CLF shall put SWP into ACTIVATED state using the bit duration in the default range as described in clause 8.1. -



In case the CLF does not detect an SWP resume by the UICC, the CLF shall assume that the UICC does not support the SWP interface and the CLF may put SWP in the DEACTIVATED state or may deactivate the UICC.

In case the CLF does not put SWP into ACTIVATED state upon "SWP resume by the UICC", the UICC shall stop the SWP resume sequence (see TS2_INHIBIT in table 6.1). The UICC shall not respond to further attempts from the CLF to communicate via SWP and shall wait for UICC deactivation or shall retrieve information about SWP capability of the terminal via any other UICC interface (see clause 6.2.4).

The UICC shall send the first ACT_SYNC frame and wait for the first frame from the CLF.

ETSI

Release 7









ETSI TS 102 613 V7.3.0 (2008-09)

When the CLF has received the first ACT_SYNC frame from the UICC, the CLF shall take the following actions: -

If the CLF has received a correct ACT_SYNC frame and the terminal provides full power mode, the CLF shall respond with an ACT_POWER_MODE frame indicating full power mode.

-

If the CLF has received a correct ACT_SYNC frame and the terminal provides low power mode the CLF shall consider the initial interface activation as being successful.

-

If the CLF has received a corrupted frame the CLF shall request the UICC to repeat the last ACT_SYNC frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal power mode.

When the UICC has received an ACT_POWER_MODE frame from the CLF, the UICC shall take the following actions: -

If the UICC has received a correct ACT_POWER_MODE and the FR bit of this frame is 1, then the UICC shall repeat the ACT_SYNC frame. If the FR bit is 0 then the UICC shall respond with an ACT_READY frame.

-

If the UICC has received a corrupted frame, the UICC shall not respond.

When the CLF has received an ACT frame in response to an ACT_POWER_MODE frame, the CLF shall take the following actions: -

If the CLF has received a correct ACT frame, it shall consider the initial interface activation as being successful and shall not send further ACT frames.

-

If the CLF has received a corrupted frame, the CLF shall request the UICC to repeat the last ACT frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal power mode.

When the CLF has not received an ACT frame in response to an ACT_POWER_MODE frame, the CLF shall take the following actions: -



14

In this case, the CLF shall request the UICC to repeat the last ACT frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal power mode.

The CLF shall not send more than three ACT_POWER_MODE frames with the FR bit set to 1.

If the interface activation was not successful the CLF shall assume that the UICC does not support SWP interface. In this case the CLF may deactivate SWIO (contact C6) or may deactivate the UICC.

6.2.3.2

Subsequent interface activation

The initial interface activation sequence shall also be applied after the transition of S1 to state H from the state DEACTIVATED, with the following modifications: •

The UICC shall not send an ACT_INFORMATION field in any of the ACT frames.



When the CLF has received the first ACT_SYNC frame from the UICC, the CLF shall take the following action: -

6.2.3.3

If the CLF has received a correct ACT_SYNC frame, the CLF shall immediately consider the subsequent interface activation as being successful and shall not send further ACT frames.

Timing parameters

Figure 6.1 shows the timing conditions for the initial interface activation after Vcc (contact C1) activation, for the case when an ACT_POWER_MODE frame is sent. Table 6.1 gives the timing values.

ETSI

Release 7

15

ETSI TS 102 613 V7.3.0 (2008-09)

d l e i F F R

C C V C C I U

e F um se O S R

1 S P W S

e um se R

2 S P W S

F O S

_T CA

DI _C C NY RC S

_T CA

ED OC M R RC W P

F O E

e F um se O S R

F O E

TC A

)e sn C op R se C r(

F O E

NOTE 1: The relationship to RF-field appearance is shown for information only. NOTE 2: Timing marked (*) are informative. The compliancy to the startup time of the RF application TRF_1st_CMD (for ISO/IEC 14443-3 [3]: 5msec from RF-field 1.5A/m to be able to receive REQA, REQB) is achieved by the CLF by balancing TRF_VCC, TS1_ACT_PW , TCLFINIT and the SWP bit rate properly. The system is designed in a way, that the CLF may keep the timing constraints when relying on the 1st SYNC_ID transmission. In case this fails it is up to the CLF to request resending SYNC_ID and go for the next REQA, REQB. NOTE 3: The value of TS1_ACT_REP implemented by the CLF should be greater than TS1_ACT_FRP + the SWP resume time. This is to ensure that an ACT frame from the CLF is not sent when an ACT(response) frame from the UICC is sent.

Figure 6.1: Initial interface activation on RF-field appearance (example) Table 6.1: Timing parameters for initial interface activation on RF-field appearance Symbol TS1_HIGH_V TS2_ACT_RES_V TS2_ACT_FRP TS2_INHIBIT

Parameter SWIO (contact C6) activation time after Vcc (contact C1) activation. UICC resumes SWP for sending 1st ACT_SYNC frame. UICC responds to ACT_POWER_MODE frames (calculated from last bit of EOF to SWP resume). UICC re-enters SUSPENDED in case the CLF did not respond to resume

ETSI

Minimum

Maximum

Unit

1 000

-

µs

0

700

µs

0

2 000

µs

-

100

ms

Release 7

16

ETSI TS 102 613 V7.3.0 (2008-09)

The interface activation from the SWP DEACTIVATED state is given in figure 6.2 for the case when an ACT_POWER_MODE frame is sent. Additional timing values are given in table 6.2. TRF_1st_CMD(*)

d l e i F F R

TCLFINIT_D_2(*) TCLFINIT_D_1(*)

C C V C C I U

tS1_ACT_REP TS1_HIGH_D(*)

TS1_ACT_PW(*)

P3

e m us eR

1 S P W S

P3

F O S

_T CA

ED OC M R RC W P

TS2_ACT_RES_D

e m us eR

2 S P W S

F O S

_T CA

F O E

TS2_ACT_FRP

DI _C C NY RC S

e m us eR

F O E

F O S

TC A

)e nso C ps RC re(

F O E

NOTE 1: The relationship to RF-field appearance is shown for information only. NOTE 2: Timing marked (*) are informative. The compliancy to the startup time of the RF application TRF_1st_CMD (for ISO/IEC 14443-3 [3]: 5 ms from RF-field 1,5 A/m to be able to receive REQA, REQB) is achieved by the CLF by balancing TS1_HIGH_D, TS1_ACT_PW , TCLFINIT_D and the SWP bit rate properly. The system is designed in a way, that the CLF may keep the timing constraints when relying on the 2nd SYNC_ID transmission in case the 1st transmission fails.

Figure 6.2: Interface activation from the DEACTIVATED state on RF-field appearance (example) Table 6.2: Additional timing parameters for the interface activation from the deactivated state on RF-field appearance Symbol TS2_ACT_RES_D

Parameter UICC resumes SWP for sending 1st ACT_SYNC frame

ETSI

Minimum

Maximum

Unit

0

500

µs

Release 7

6.2.3.4

17

ETSI TS 102 613 V7.3.0 (2008-09)

Impact on other interfaces

Depending on the power state of the UICC the following conditions for the interfaces shall apply: •

If the UICC is in "low power mode" the terminal shall not activate the TS 102 221 [1] interface and if the UICC supports the USB interface according to TS 102 600 [6], it shall not perform an attachment on the USB interface.



If the UICC is in "full power mode", the terminal may independently activate any other UICC interfaces.



If the UICC was activated according to TS 102 221 [1], an additional activation of the SWP interface shall be considered as selected application on the UICC.

6.2.4

Behaviour of a UICC in a terminal not supporting SWP

The UICC shall take care of terminals having C6 contact connected with low impedance to Vcc or electrically isolated. When the UICC detects that the contact C6 is not connected to Vcc it shall connect the C6 contact with a low impedance to Gnd within 2 s after detecting that the terminal does not indicate the support of SWP interface. NOTE:

6.2.5

Implementation has to take care to minimize SWP related power consumption.

Behaviour of terminal connected to a UICC not supporting SWP

When the terminal detects that the UICC does not support SWP, it shall keep SWIO in the deactivated state (state L).

6.2.6

Inactive contacts

The conditions for inactive contacts as defined in TS 102 221 [1] shall apply to contact C6.

7

Electrical characteristics

7.1

Operating conditions

The voltage levels for the CLF (Master) and the UICC (Slave) signal S1 are illustrated in figure 7.1. CLF (Master)

VOH max 1,8 V

UICC (Slave) Input voltage VIH max Valid range for S1 high

VOH min VIH min VIL max VOL max

Valid range for S1 low

Gnd

VIL min

Figure 7.1: Voltage definitions for the signal S1 VIH and VIL refers to the receiving device signal level (Slave). VOH and VOL refers to the sending device signal level (Master). All voltages are referenced to Gnd.

ETSI

Release 7

18

ETSI TS 102 613 V7.3.0 (2008-09)

The SWP interface uses a second signal S2 which is the current from the master to the slave and allows data to be sent back from the slave to the master. S2 values are defined when S1 is state H. The current levels for S2 are defined in clause 7.1.4.1, as shown in figure 7.2. S2 (Current) IH max stateH IH min IL max stateL IL min

0

Figure 7.2: Definitions of the current level for S2 on SWIO

7.1.1

Supply voltage classes

A UICC supporting the SWP interface shall support the voltage classes B and C, as defined in TS 102 221 [1].

7.1.2

Vcc (C1) low power mode definition

When the system operates in low power mode table 7.1 applies. Table 7.1: Electrical characteristics of VCC in low power mode Symbol VCC ICC NOTE:

Conditions Minimum Class C 1,62 Class C The current value is averaged over 1 ms.

Maximum 1,98 5

Unit V mA

The maximum current in the table 7.1 is defined for the UICC. The terminal may deliver more. The voltage value shall be maintained within the specified range despite transient power consumption as defined in table 7.2. Table 7.2: Spikes on ICC Class

Maximum charge (see note 1)

Maximum duration

Maximum variation of ICC (see note 2) C 6 nA.s 400 ns 30 mA NOTE 1: The maximum charge is half the product of the maximum duration and the maximum variation. NOTE 2: The maximum variation is the difference in supply current with respect to the average value.

ETSI

Release 7

7.1.3

19

ETSI TS 102 613 V7.3.0 (2008-09)

Signal S1

S1 is a signal in the voltage domain to transmit data from the CLF to the UICC on SWIO (contact C6). S1 shares the same electrical contact as S2 as defined in clause 7.1.4. Electrical characteristics of S1 are given in tables 7.3 and 7.4. Table 7.3: Electrical characteristics of SWIO for S1 under normal operating conditions in voltage class B Symbol Parameter Conditions Minimum Maximum Unit VOH IL min ≤ I ≤ IH max Output High Voltage (high) 1,40 1,98 (see note) V VOL Output Low Voltage (low) 0 µA ≤ I ≤ 20 µA 0 (see note) 0,3 V VIH IL min ≤ I ≤ IH max Input High Voltage (high) 1,13 2,28 (see note) V VIL I ≤ I ≤ I Input Low Voltage (low) -0,3 0,48 V L min H max NOTE: To allow for overshoot the voltage on SWIO shall remain between -0,3 V and VOH max + 0,3 V during dynamic operation.

Table 7.4: Electrical characteristics of SWIO for S1 under normal operating conditions in voltage class C Symbol Parameter Conditions Minimum Maximum VOH I ≤ I ≤ I 0,85 x V V Output High Voltage (high) L min H max CC CC (see note) VOL 0,15 x VCC Output Low Voltage (low) 0 µA ≤ I ≤ 20 µA 0 (See note) VIH IL min ≤ I ≤ IH max 0,7 x VCC VCC+0,3 Input High Voltage (high) VIL I ≤ I ≤ I 0,25 x VCC Input Low Voltage (low) -0,3 L min H max NOTE: To allow for overshoot the voltage on SWIO shall remain between -0,3 V and VCC+ 0,3 V during dynamic operation.

7.1.4

Unit V V V V

Signal S2

S2 is a signal in the current domain to transmit data from the UICC to the master. S2 shares the same electrical contact as S1 (contact C6). In this clause the electrical characteristics of S2 are described.

7.1.4.1

Operating current for S2

S2 is considered as in state H when the current drawn on SWIO is between IH min and IH max and is considered in state L when the current drawn on SWIO is between IL min and IL max. Table 7.5: Electrical characteristics of SWIO for S2 under normal operating conditions Symbol IH IL

Parameter High Current Low Current

Conditions VIHmin ≤ S1 ≤ VIHmax VIHmin ≤S1 ≤ VIHmax

ETSI

Minimum 600 0

Maximum 1000 20

Unit µA µA

Release 7

20

ETSI TS 102 613 V7.3.0 (2008-09)

8

Physical transmission layer

8.1

S1 Bit coding and sampling time (Self-synchronizing code)

The bit coding of S1 is illustrated in figure 8.1. T 3/4 T V

Logical 1

S1

1/4 T

t

V

Logical 0

t

Figure 8.1: Bit-coding of S1 The nominal duration of the state H for a logical 1 is 0,75 x T, the nominal duration of the state H for a logical 0 is 0,25 x T. All bits shall be transmitted consecutively. A bit is defined as having two rising edges. These rising edges constitute the beginning and end of the bit period. The bit-duration may be different for each transmitted bit.

Figure 8.2: S1 waveform The input capacitance of the UICC (CLOAD ) on the C6 contact shall not exceed 10 pF. Table 8.1 gives S1 waveform timing.

ETSI

Release 7

21

ETSI TS 102 613 V7.3.0 (2008-09)

Table 8.1: S1 waveform timings Symbol

Parameter

tf

Fall time

tr

Conditions CLOAD ≤ 10 pF T < 5 000 ns CLOAD ≤ 10 pF T > 5 000 ns CLOAD ≤ 10 pF T < 5 000 ns CLOAD ≤ 10 pF T > 5 000 ns

Rise time

Minimum

Nominal

Maximum

5 ns

-

0,05 x T

5 ns

-

250 ns

5 ns

-

5 ns

-

Duration of the state H for 0,70 x T coding a logical 1 of S1 Duration of the state H for TH0 0,20 x T coding a logical 0 of S1 Default bit duration 1 T (see note 2) Extended bit duration 0,590 NOTE 1: Valid for the leading edge and the trailing edge of each bit. NOTE 2: Extended bit durations are indicated as per table 9.3. TH1

8.2

Unit

0,05 x T (see note 1) 250 ns (see note 1)

0,75 x T

0,80 x T

0,25 x T

0,30 x T

-

5 10

µs µs

S2 switching management

S2 is valid only when S1 is in state H. The UICC (Slave) shall only perform switching of S2 when S1 is in state L, or when resuming SWP (the only occasion when S2 is allowed to be switched while S1 is in state H due also to the SUSPENDED state of SWIO). Figure 8.3 illustrates the timing of S2 related to S1.

V VOHmin S1

A IHmin S2

Logical 0

Logical 1

ILmax

S2 is not valid

S2 is valid Figure 8.3: S2 timing

ETSI

Release 7

8.3

22

ETSI TS 102 613 V7.3.0 (2008-09)

SWP interface states management

The SWP has three states: ACTIVATED: In this state master and slave are sending bits. SWP remains in this state until a SUSPEND transition occurs. SUSPENDED: In this state S1 is in state H and S2 is in state L. This state is the initial state of SWP at activation of the SWP interface. SWP remains in this state until a RESUME or DEACTIVATE transition occurs. DEACTIVATED: In this state the signal S1 is in state L and the signal S2 is in state L. SWP remains in this state until an ACTIVATE transition occurs. The transitions between these states are defined as follows: RESUME: Transition from SUSPENDED state to ACTIVATED state. Both the master and the slave may execute a RESUME to bring SWP into ACTIVATED state. The master resumes by sending a transition sequence followed by P2 consecutive idle bits. SWP enters the ACTIVATED state at the end of the last of these bits. The slave resumes by drawing a current (S2 in state H). The master shall respond by sending a transition sequence in less than P3max time. At the end of the transition sequence, SWP enters the ACTIVATED state. The delay after the transition sequence until the SOF sent by the slave shall not exceed 4 bits. If the master resumes, the slave may start sending frames already during the P2 idle bits. Figure 8.4: Void SUSPEND: If there is no activity on SWP, other than idle bits during P1 time, the master may switch SWP to the SUSPENDED state by maintaining S1 in state H. DEACTIVATE: If SWP is in SUSPENDED state, the master may switch SWP to the DEACTIVATED state by maintaining SWIO in state L for longer than P4 time. ACTIVATE: If SWP is in DEACTIVATED state, the interface activation procedure as described in clause 6.2.3 shall be applied. The slave may request activation of the interface by using the ACTIVATE INTERFACE command as defined in TS 102 223 [7]. Figure 8.5 illustrates an example of SWP activities.

ETSI

Release 7

23

S1 ACTIVATED

SUSPENDED

ETSI TS 102 613 V7.3.0 (2008-09)

ACTIVATED

SUSPENDED

DEACTIVATED e c a f W r e S t n i P

P1

P3

Transition sequence

n io t a v i t c a

P4

P1

by slave

S2

S1 ACTIVATED

SUSPENDED

ACTIVATED

SUSPENDED

DEACTIVATED P

P1

W e S t in

P2

Transition sequence

e c a f r

P1

n io t a iv t c a

P4

by master

S2

Figure 8.5: SWP states and transitions Table 8.2 gives SWP management timings. Table 8.2: SWP Management Timing Symbol P1 P2 P3 P4

8.4

Parameter Suspend sequence Resume by master sequence Resume by slave time Deactivation time

Minimum 7 8 30

Maximum 8 5 -

Unit Bit Bit µs µs

Power mode states/transitions and Power saving mode

When the terminal activates Vcc (contact C1) the UICC shall enter the initial power state. This initial power state of the UICC shall conform to TS 102 221 [1]. Thereafter the terminal may activate the interfaces as described in clause 6.2. Upon activation of at least one interface, the UICC enters the operational power state. NOTE 1: The initial power state and the operational power state are part of the full power mode. If during SWP interface activation the terminal sends a power mode frame indicating low power mode, the UICC shall enter this mode. Switching from low power mode to full power mode shall be done by an upper layer command out of the scope of the present document. This transition may interrupt an ongoing contactless transaction due to internal UICC processing. Switching from full power mode to low power mode requires deactivation of Vcc (contact C1).

ETSI

Release 7

24

ETSI TS 102 613 V7.3.0 (2008-09)

The UICC shall enter the power saving mode when all of the following conditions for activated interfaces are given: •

clock stop mode according to TS 102 221 [1] if this interface is activated (if UICC is in full power mode);



suspend mode according to TS 102 600 [6] if this interface is activated (if UICC is in full power mode);



SWP contact deactivated (if UICC is in full power mode or in low power mode). The UICC shall enter the power saving mode no later than 10ms after the SWP interface is deactivated.

When the UICC is in power saving mode it shall not exceed the current defined for clock stop mode in TS 102 221 [1] or the limit given for suspend mode in TS 102 600 [6] whatever the interface is activated. The UICC shall exit the power saving mode when at least one of the UICC interfaces is resumed from these conditions. NOTE 2: In full power mode, all the resources in the terminal (e.g. display, keyboard, etc.) may not be available for the UICC applications.

9

Data link layer

9.1

Overview

The Data Link layer manages LPDUs (Link Protocol Data Units) as illustrated in figure 9.1. This layer can be divided into two sub-layers: •

MAC layer is in charge of framing.



LLC layer is in charge of error management and flow control.

Packet LLC layer LPDU MAC layer Frame Figure 9.1: Data link layer overview

9.2 9.2.1

Medium Access Control (MAC) layer Bit order

The bit order of the SWP communication channel is MSB first.

ETSI

Release 7

9.2.2

25

ETSI TS 102 613 V7.3.0 (2008-09)

Structure

Figure 9.2 illustrates the format of a frame sent from the master to the slave. Bit Stuffing

SOF FLAG

0

1

1

Payload

1

1

1

1

CRC16

0

0

1

1

6x1

EOF FLAG

1

1

1

1

1

7x 1

Figure 9.2: Frame structure sent by master The SOF flag has the value '7E' and the EOF flag has the value '7F'. Between frames, idle bits (logical value 0) are sent. There is at least one idle bit between frames. Figure 9.3 illustrates the format of a frame sent from the slave to the master. Bit Stuffing

SOF FLAG

W 0

1

1

Payload

1

1

1

1 0

CRC16

0

6x1

1

1

EOF FLAG

1

1

1

1

1

7x 1

Wakeup sequence

Figure 9.3: Frame structure sent by slave A wakeup sequence, consisting of a bit with logical value 1 shall be inserted before each frame sent from the slave to the master. In the case that the master starts suspending the interface at the same point in time when the slave starts sending the wakeup sequence, the bit with logical value 1 is transformed into a resume by slave sequence which brings SWP back to ACTIVATED state. The payload size is limited to 30 bytes. The CRC field is 16 bits long.

9.2.3

Bit Stuffing

In order to unambiguously detect the SOF and EOF flags, zero bit stuffing shall be employed by the transmitting entity when sending the payload and the CRC on SWP. After five consecutive bits with the logical value 1, a bit with the logical value 0 is inserted. If the last five bits of the CRC contain the logical value 1, then no bit with the logical value 0 will be added. The receiver shall recognize the stuffed bits and discard them.

ETSI

Release 7

26

ETSI TS 102 613 V7.3.0 (2008-09)

An example of a zero bit stuffed sequence is given in figure 9.4.

Figure 9.4: Bit stuffing

9.2.4

Error detection

The detection of errors in a frame is based on the standard CRC-16 CITT. The CRC polynomial is: X16+X12+ X5+1. Its initial value is 0xFFFF. The CRC is computed on the bits between SOF and EOF both excluded.

9.3

Supported LLC layers

Three Logical Link Control (LLC) layers using the previously defined MAC layer are defined in the present document: •

SHDLC: This is the generic LLC used during most of the contactless transactions. SHDLC is defined in clause 10. Support of this LLC in mandatory in the CLF and the UICC.



CLT: This LLC is used for some proprietary protocol handling. CLT mode is defined in clause 11 CLT LLC definition. Support of this LLC is optional in the CLF and optional (application dependant) in the UICC.



ACT: This LLC consist of frames used during interface activation. Support of this LLC is mandatory in the CLF and the UICC. Table 9.1: LLC Control field coding Frame Types RFU ACT CLT SHDLC

8 0 0 0 1

7 0 1 1

6 1 0

Bit Field 5 4 3 2 All settings ACT type CLT CMD All settings

1

The control field is the first byte of the SWP frame payload. Definition for the different LLC layers can be found in table 9.1. The LPDUs payload shall be structured according to figure 9.5.

ETSI

Release 7

27

LLC CONTROL FIELD

0 1 1

ACT TYPE

ETSI TS 102 613 V7.3.0 (2008-09)

0 to 3 BYTES

ACT PAYLOAD

ACT LPDU LLC CONTROL FIELD

0 1 0

MAX 29 BYTES

CLT CMD

CLT PAYLOAD

CLT LPDU LLC CONTROL FIELD

1

MAX 29 BYTES

SHDLC CONTROL FIELD

HDLC PACKET

SHDLC LPDU Figure 9.5: LPDU structure of the 3 defined LLC layers

9.3.1

Interworking of the LLC layers

After SWIO (contact C6) activation or after the transition of S1 to state H from DEACTIVATED state, the SHDLC link shall be not established and no CLT session shall be open. The ACT LLC shall be used by the UICC and by the CLF. The CLF shall take the following action after successful activation of the SWP: • If the CLF has data to be sent to the UICC (e.g. due to a contactless transaction) that requires the use of the CLT LLC, it shall initiate a CLT LLC session. • Otherwise it shall start the establishment of an SHDLC link as soon as possible. NOTE:

The CLF will always send the first non-ACT frame after activation of the SWP.

After the UICC and the CLF have established the SHDLC link or opened the CLT session, the UICC and the CLF shall not send ACT LLC frames; received ACT LLC frames shall be ignored. To enter the SHDLC LLC from ACT LLC or CLT LLC, the link establishment procedure as described in clauses 10.7.2 and 10.7.3 shall apply.

ETSI

Release 7

28

ETSI TS 102 613 V7.3.0 (2008-09)

Once the SHDLC link is established, a CLT session shall not invalidate the SHDLC context and the endpoint capabilities negotiated during the SHDLC link establishment. To enter the CLT LLC from ACT LLC or SHDLC LLC, the CLT session shall be opened as described in clause 11.6. The CLF shall open a CLT session only when all SHDLC I-Frames are acknowledged. SHDLC LLC frames received by the UICC or by the CLF during a CLT session close the CLT session. In case the UICC or the CLF receives a corrupted SWP frame, then the receiving entity shall use the error recovery procedure defined for the LLC of the last correctly received SWP frame. Immediately after SWIO (contact C6) activation or after the transition of S1 to state H from DEACTIVATED state, the error handling of the ACT LLC shall apply.

9.4

ACT LLC definition

The ACT LPDU shall be structured according to figure 9.6.

Figure 9.6: ACT LPDU structure Coding of ACT TYPE: •



Meaning of FR in a frame when received by the UICC: -

FR = 1: The UICC shall repeat the last sent ACT frame.

-

FR = 0: The UICC shall not repeat the last ACT frame.

Meaning of FR in a frame when received by the CLF: -

The CLF shall ignore the FR bit.

A frame sent from the UICC to the CLF shall have the FR bit set to 0. •



Meaning of INF in a frame when received by the CLF: -

INF = 1: Last byte of ACT payload contains the ACT_INFORMATION field.

-

INF = 0: ACT_INFORMATION field not available.

Meaning of INF in a frame when received by the UICC: -

The UICC shall ignore the INF bit.

A frame sent from the CLF to the UICC shall have the INF bit set to 0. The meaning of ACT_CTRL and ACT_DATA is given in table 9.2.

ETSI

Release 7

29

ETSI TS 102 613 V7.3.0 (2008-09)

Table 9.2: Meaning of ACT_CTRL and ACT_DATA ACT_CTRL 000

Meaning ACT_READY Sent from UICC to CLF ACT_POWER_MODE Sent from CLF to UICC to indicate the power mode for the UICC.

010

001

ACT_SYNC Sent from UICC to CLF to control the SYNC_ID verification process.

ACT_DATA FIELD 0 Byte 1 Byte '00': Low power mode '01': Full power mode (see Note) 2 Byte SYNC_ID

All other values (see note) NOTE: All other values are reserved for future use. These values shall not be set by the transmitting entity and shall be ignored by the receiving entity.

ACT_INFORMATION: By sending this field, the UICC indicates extended capabilities as defined in table 9.3. Table 9.3: Extended capability indication in ACT_INFORMATION field Bit field 8 .. 3 2

1

Value 000000 1

Meaning RFU Extended SWP bit durations down to 0,590 µs are supported

0

No lower extended SWP bit durations beyond the default range are supported Extended SWP bit durations up to 10 µs are supported

1 0

9.4.1

No higher extended SWP bit durations beyond the default range are supported

SYNC_ID verification process

The purpose of the SYNC_ID verification is to check the identity of the UICC. The SYNC_ID verification process consists of the following steps: •

The UICC presents the SYNC_ID to the CLF in an ACT_SYNC frame. The presented SYNC_ID is named verification data.



The CLF compares verification data with identity reference data. The provisioning of the identity reference data is out of scope of the present document.

For the SYNC_ID verification, the following conditions shall apply: •

The CLF and the UICC shall support SYNC_ID verification.



The SYNC_ID verification shall always be executed when the SWP interface is activated (see clause 6.2.3).

The CLF shall perform the SYNC_ID verification process based on ACT frames received from the UICC as outlined below: •

In case an ACT_SYNC frame is received, the CLF shall use the ACT_DATA field as verification data.

If the CLF evaluates that verification data and identity reference data values are equal, the identity check is successful. If the values are not equal, the identity check failed and the CLF shall not open a CLT session.. NOTE:

Within the scope of the present document, only the mechanism that the CLF checks the identity of the UICC is described. The consequences of a failed identity check and mechanisms to recover from this state are specified in a higher layer.

ETSI

Release 7

30

10

SHDLC LLC definition

10.1

SHDLC overview

ETSI TS 102 613 V7.3.0 (2008-09)

The SWP SHDLC layer as defined in the present document is a simplified version of ISO's High-level Data Link Control (HDLC ISO/IEC 13239 [5]) specification. It is responsible for the error-free transmission of data between network nodes. The SHDLC layer shall ensure that data passed up to the next layer has been received exactly as transmitted (i.e. error free, without loss and in the correct order). Also, the SHDLC layer manages the flow control, which ensures that data is transmitted only as fast as the receiver may receive it. SHDLC ensures a minimum of overhead in order to manage flow control, error detection and recovery. If data is flowing in both directions (full duplex), the data frames themselves carry all the information required to ensure data integrity. The concept of a sliding window is used to send multiple frames before receiving confirmation that the first frame has been received correctly. This means that data may continue to flow in situations where there may be long "turnaround" time lags without stopping to wait for an acknowledgement.

10.2

Endpoints

SHDLC communication occurs between two endpoints. Those endpoints are identified as the CLF and the UICC. There is no priority of traffic. CLF

UICC SHDLC

Figure 10.1: Endpoints

10.3

SHDLC frame types

SHDLC uses several types in order to transfer data and to manage or supervise the communication channel between the two endpoints (ends of the communication channel): •

I-Frames (Information frames): Carry upper-layer information and some control information. I-frame functions include sequencing, flow control, and error detection and recovery. I-frames carry send and receive sequence numbers.



S-Frames (Supervisory Frames): Carry control information. S-frame functions include requesting and suspending transmissions, reporting on status, and acknowledging the receipt of I-frames. S-frames carry only receive sequence numbers.



U-Frames (Unnumbered Frames): Carry control information. U-frame functions include link setup and disconnection, as well as error reporting. U-frames carry no sequence numbers.

ETSI

Release 7

10.4

31

ETSI TS 102 613 V7.3.0 (2008-09)

Control Field

The SHDLC control field has the structure described in table 10.1, including the first bits of the payload. Table 10.1: SHDLC Control field coding Frame Types 8 1 1 1

I S U

7 0 1 1

6 0 1

Bit Field 5 4 N(S) TYPE

3

2 N(R) N(R)

1

M

where: •

N(S):

Number of the information frame



N(R):

Number of next information frame to receive



TYPE: Type of S-Frame



M:

Modifier bits for U-Frame

The size of the sliding window is four frames by default. Frames types may be interleaved. For example, a U-Frame may be inserted between I-Frames.

10.4.1

I-Frames coding

The functions of the information command and response is to transfer sequentially numbered frames, each containing an information field, which might be empty, across the data link.

10.4.2

S-Frames coding

Supervisory(S) commands and responses are used to perform numbered supervisory functions such as acknowledgment, temporary suspension of information transfer, or error recovery. Frames with the S format control field do not contain an information field. Supervisory Format commands and responses are as follows: •

RR: Receive Ready is used by an endpoint to indicate that it is ready to receive an information frame and/or acknowledge previously received frames.



RNR: Receive Not Ready is used to indicate that an endpoint is not ready to receive any information frames or acknowledgments.



REJ: Reject is used to request the retransmission of frames.



SREJ: Selective Reject is used by an endpoint to request retransmission of specific frames. An SREJ shall be transmitted for each erroneous frame; each frame is treated as a separate error. Only one SREJ shall remain outstanding on the link at any one time.

The type coding is given by the table 10.2. Table 10.2: Type coding of the S-frames Frames RR REJ RNR SREJ

Type 00 01 10 11

Status Mandatory Mandatory Mandatory Optional

Optional type of frame shall not be used before capability negotiation is defined during initialization.

ETSI

Release 7

10.4.3

32

ETSI TS 102 613 V7.3.0 (2008-09)

U-Frames coding

The unnumbered format commands and responses are used to extend the number of data link control functions. The unnumbered format frames (see clause 10.4) have 5 modifier bits which allow for up to 32 additional commands and responses. Only a subset of the HDLC commands and responses are used for SHDLC: •

RSET: Reset of the data link layer is used to reset the sequence number variables in the both endpoints.



UA: Unnumbered Acknowledgment is used to acknowledge the receipt and acceptance of a RSET command. Table 10.3: Modifier coding of the U-frames Frames RSET UA

10.5

Modifier 11001 00110

Status Mandatory Mandatory

Changing sliding window size and endpoint capabilities

The sliding window size is negotiated during SHDLC session establishment. The validity of the negotiated window size starts with completing a successful session establishment and ends with the interface deactivation or with a new SHDLC session re-establishment. The sliding window size may be lower than the default value due to limited resources. In consequence, an endpoint may want to ask the other endpoint to lower the sliding window size. The RSET frame may carry a configuration field in order to change the sliding window size (down to 2). If the default size (in case of an RSET command without configuration field) or the size provided is too large at a RSET frame reception, the receiver shall not acknowledge it. Instead, the receiver shall send a RSET frame with an appropriate sliding window size (which is lower than the window size offered by the other endpoint). An endpoint shall obey to window size reconfiguration if the requested window size is lower than its default configuration. It acknowledges the new size with a UA frame. SREJ support is negotiated in the same way. The RSET frame may carry a configuration field in order to indicate the capability of the endpoint to support this frame.

10.5.1

RSET frame payload

The RSET frame has 2 optional bytes in order to provide the endpoint window size and capabilities. The number provided for the endpoint size shall be between 2 to 4 inclusive. In case this RSET frame is sent in response to a received RSET frame, the endpoint size value shall be lower than the previously provided value. The second optional byte may be sent after the window size by the endpoint in order to indicate support of optional endpoint capabilities. If it is absent, the default values apply. RSET

Window size

Endpoint capabilities

1111 1001

nnnn nnnn

b8...b1

8 bits

8 bits

8 bits

2

nnnn nnnn

4

Figure 10.2: RSET frame payload Table 10.4: Bit coding of optional endpoint capabilities Bit 1

Default value 0

2 to 8

000000

Description Support of Selective Reject S-frame (SREJ) 0: Not supported (default) 1: Supported RFU

ETSI

Release 7

10.5.2

33

ETSI TS 102 613 V7.3.0 (2008-09)

UA frame payload

The UA frame carries no payload.

10.6

SHDLC context

The SHDLC context is defined by constant values such as the timeouts and the sliding window size as well as a number of variables as defined below.

10.6.1

Constants



w: Sliding window size. w = 4 by default This value is not actually constant because it may be reduced at link establishment. However, up to the next reset of the SHDLC session, it never changes.



T1: Acknowledge time. T1 <= 5 ms In context of streaming, the frames shall be acknowledged within T1 to avoid that the traffic stops. The T1 value is bound to the w value . The current value is computed for w = 4. If the value is reduced to w" then T1 is changed to T1" = T1 x w" / w.



T2: Guarding/transmit time. T2 > T1. T2 >= 10 ms If the frames are not acknowledged after a time period, an endpoint shall retransmit these frames. This value defines the time to wait. T2 is unaffected by modifications of w.



T3: Connection time. T3 <= 5 ms Used at link establishment, retry to setup link if the targeted endpoint did not answer with an UA frame to a RSET frame. T3 is unaffected by modifications of w.

10.6.2

Variables

These three variables are modulo 8 and hold sequence numbers. •

N(S): Sequence number for emission. Used in I Frames. Incremented after emission of the frame.



N(R): Next sequence number for reception. Used in I and S type frames. During full duplex data transmission or by emission of a S type frame, all received frames with a sequence number lower than N(R) are acknowledged.



DN(R): Lowest unacknowledged sequence number. Acknowledgements are outstanding for frames between DN(R) and N(S).

To know if a frame is in the window, sequence numbers are compared using modulo 8. The definition used for X <= Y < Z modulo 8 is as follows: •

If X <= Z then the equation to calculate is: X <= Y < Z



Otherwise the equation to calculate is: Y >= X or Y < Z

10.6.3

Initial Reset State

The following initial states shall apply in every endpoint after successful link establishment: •

N(S) = N(R) = DN(R) = 0.

ETSI

Release 7

34

ETSI TS 102 613 V7.3.0 (2008-09)

10.7

SHDLC sequence of frames

10.7.1

Nomenclature Frame Boundaries

Frame with Information

Frame without Information

Transmission error

Figure 10.3: Frames representation I N(S), N(R)

Information frame: RR N(R)

Receive Ready:

Receive and Not Ready:

RNR N(R)

SREJ N(R)

REJ N(R)

Selective Reject:

Reject: RSET

Reset (no payload):

RSET

Reset (with payload): WS4

Figure 10.4: Frames type description

10.7.2

Link establishment with default sliding window size

An endpoint establishing an SHDLC link shall initiate link establishment by sending a RSET frame. If the SHDLC frame exchange on the link enters into an error condition which can not be recovered by other SHDLC means, an endpoint may also reset and re-establish the link by sending a RSET frame. All buffered frames (received out of order or stored in the retransmission queue) shall be discarded. The upper layer shall be informed of the link reset. If the target is ready, it shall answer with a UA frame. The link is established after receiving this acknowledgment. Before link establishment, all frames except RSET from other endpoint shall be discarded. The connection timeout is required in order to detect failure and restart the operation. In this example, both endpoints work with the default window size and the UICC does not send a RSET frame because it received a RSET frame first and agreed on the default window size. RSET

RSET

Connection timeout

CLF: UA

Unlimited time UA

UICC:

Figure 10.5: Link establishment restart after UA loss

ETSI

I0,0

Release 7

35

ETSI TS 102 613 V7.3.0 (2008-09)

Simultaneous resets are handled gracefully. After both endpoints send UA frames, link is established using the default window size. RSET

UA

RSET

UA

I0,0

Unlimited time

CLF:

UICC:

Figure 10.6: Link establishment with crossover RSET frames

10.7.3

Link establishment with custom sliding window size

If the UICC has a smaller window size than the CLF, it ignores the received RSET frame. The CLF sees the customized RSET frame, changes its window configuration to 2 and sends an UA frame to establish the link. UA

RSET

I0,0

Unlimited time

CLF: WS4 RSET

UICC: WS2

Ignore the received RSET. Request a smaller sliding window size.

Figure 10.7: Link establishment with sliding window size of 2 In case of RSET frames crossover, the mechanism still works. Change to a lower sliding window size. UA Unlimited time

RSET

CLF: WS4

I0,0

RSET

UICC: WS2

Ignore the received RSET.

Figure 10.8: Link establishment with sliding window size of 2 and RSET frames crossover In case of frame loss, the link establishment restarts and link configuration is finally completed. RSET

Connection timeout

CLF: WS4

UA

RSET WS4

RSET

RSET

WS2

WS2

UICC:

Figure 10.9: The RSET frame from the UICC is lost UA

RSET

UA

CLF: WS4 RSET

UICC: WS2

Connection timeout

RSET WS2

Figure 10.10: The UA from the CLF is lost and the connection timeout allows restarting the link configuration

ETSI

Release 7

10.7.4

36

ETSI TS 102 613 V7.3.0 (2008-09)

Data flow

Once the link is established, both endpoints may exchange data. The CLF sends a stream of data. The UICC has no data to send. So, the piggyback mechanism is not used (Frames are acknowledged using information frames going in the opposite way). The UICC shall acknowledge frame reception regularly in order to avoid traffic stop. An acknowledge timeout is used in order to send RR frames to the CLF. The timeout starts at the first received packet after the previous acknowledgement (other RR frame or piggybacking). If the UICC sends information frames (not shows here), the acknowledge timeout shall be stopped as piggybacking will acknowledge received frames. I0,0

I1,0

I2,0

I3,0

I4,0

I5,0

I6,0

I7,0

I0,0

I1,0

CLF:

acknowledge timeout

UICC:

RR3

acknowledge timeout

RR6

RR1

acknowledge timeout

Figure 10.11: One way data flow with RR frames acknowledgement The acknowledge timeout shall not be too long to avoid throughput degradation. Otherwise, the sending endpoint will be waiting for the destination to become ready. This diagram shows what happens with a sliding window size of 4 and a timeout value that is too large. Traffic is suspended I0,0

I4,0

I3,0

I5,0

I6,0

CLF: RR4

acknowledge timeout

UICC:

Figure 10.12: One way data flow with too long a time for acknowledgement In this example, I-Frames flow in both ways. Piggybacking is used to acknowledge received frames during I-Frames crossover. Because of last packets crossover, both endpoints use acknowledge timeout to detect when to send a RR frame after traffic ends. I0,0

I1,0

I2,0

I3,0

I4,1

CLF:

I0,2

I1,3

UICC:

Acknowledge timeout I2,4

RR3

Acknowledge timeout

RR5

Figure 10.13: Piggybacking and timed acknowledgement

10.7.5

Reject (go N back)

When a frame gets lost in the stream, the destination (here the UICC) will see a gap in the received frame numbers. If SREJ is not supported or if several frames got lost, the destination shall send a REJ frame as soon as possible in order to restart the stream at the first missing frame.

ETSI

Release 7

37

ETSI TS 102 613 V7.3.0 (2008-09)

Retransmissions CLF:

I0,0

I1,0

I2,0

I0,2

UICC:

4,1

I3,0

I3,3

I

I1,3

I2,3

I4,4

I3,3

REJ3

RR5

acknowledge timeout

UICC saw frame 4 before frame 3. Figure 10.14: Piggybacking with reject frame after mismatching sequence number

10.7.6

Last Frame loss

Each frame shall have a guarding/transmit timeout in order to retransmit frames if the destination does not notice a loss. When the last frame is lost, the destination endpoint will not be able to detect it. A RR frame shall be sent to acknowledge the last frame but a lost frame will never be requested for retransmission by the destination endpoint by using a reject mechanism. Retransmission I0,0

I1,0

I2,0

I3,0

I4,1

Transmit timeout

CLF: I0,2

I1,3

I4,3

I2,4

acknowledge timeout

UICC:

RR5

Figure 10.15: Last frame loss in piggybacking situation The acknowledgment by the CLF of the last frame sent from the UICC with a frame RR3 is not shown in the figure but shall be sent by the CLF before the acknowledge timeout. Figure 10.16 shows the same behaviour when the destination endpoint do not send any traffic (i.e. no piggybacking).

Retransmission I0,0

CLF:

I1,0

I2,0

acknowledge timeout

UICC:

I3,0

I4,0

RR3

Transmit timeout

I4,0

RR4

acknowledge timeout

acknowledge timeout

Figure 10.16: Last frame loss in one way data flow

10.7.7

Receive and not ready

Receive-not-ready (RNR) acknowledges an I-frame, as with RR, but also asks the peer endpoint to suspend transmission of I-frames. Stop sending frame I0,0

I1,0

I2,0

I3,0

I4,0

Resume traffic

I5,0

I6,0

CLF:

UICC:

acknowledge timeout

RR3

RNR4

RR6

Figure 10.17: Stop and resume traffic at UICC request

ETSI

I7,0

RR5

Release 7

38

ETSI TS 102 613 V7.3.0 (2008-09)

The RR frame that follows an RNR frame shall be retransmitted every 5 to 20 ms until a new I frame is received. This avoids deadlock situations that could occur if an RR frame that is sent to resume the traffic gets lost. If the entity that received the RR has no more data to send, it shall send an I-frame with empty information field to signal the proper reception of the RR frame.

10.7.8

Selective reject

Selective reject (SREJ) is used to request retransmission of just a single frame. I0,0

I1,0

I2,0

I3,0

I4,1

I3,3

I5,2

CLF: I0,2

I2,3

I1,3

UICC:

SREJ 3

I3,3

acknowledge timeout

RR6

UICC saw frame 4 before frame 3.

Figure 10.18: One frame loss in stream The acknowledgment by the CLF of the last frame sent from the UICC with a frame RR4 is not shown in the figure but shall be sent by the CLF before the acknowledge timeout.

10.8

Implementation model

All calculations on sequence numbers in this clause are done modulo 8.

10.8.1

Information Frame emission

N (S) >= DN (R)+window

Send I

YES

W ait

,

N (S ) N (R )

N(S) = N(S) + 1

Set T2 for this fram e

Deactivate T1

Figure 10.19: Information frame emission.

ETSI

Release 7

10.8.2

39

ETSI TS 102 613 V7.3.0 (2008-09)

Information Frame reception

Receive a frame I ,

X Y

Corrupted ?

YES

Discard

X is different than N(R) ?

YES

Send REJ

T1 is active ?

YES

N(R)

Set T1

Process frame I

N(R) = N(R) + 1

DN(R) < Y <= N(S)

YES

Deactivate all T2 for frames DN(R) to Y-1

DN(R) = Y

Figure 10.20: Information frame reception If support for Selective Reject S-frames was negotiated for the link and X is exactly one higher than N(R), a SREJN(R) shall be sent instead of the REJN(R), the received I-frame shall be buffered and Y shall be evaluated as defined above. Once the frame with X = N(R) is received, the buffered I-frame shall also be processed.

ETSI

Release 7

10.8.3

40

ETSI TS 102 613 V7.3.0 (2008-09)

Reception Ready Frame reception

Receive a frame RRY

DN(R) < Y <= N(S)

YES

Deactivate all T2 for frames DN(R) to Y-1

DN(R) = Y

Figure 10.21: RR frame reception

10.8.4

Reject Frame reception

Receive a frame REJY

DN(R) < Y <= N(S)

YES

Deactivate all T2 for frames DN(R) to Y-1

DN(R) = N(S) = Y

Retransmit frames starting from N(S)

Figure 10.22: REJ frame reception

ETSI

Release 7

10.8.5

41

ETSI TS 102 613 V7.3.0 (2008-09)

Selective Reject Frame reception

Receive a frame SREJY

DN(R) < Y <= N(S)

YES

Deactivate all T2 for frames DN(R) to Y-1

DN(R) = Y

Retransmit frame Y

Figure 10.23: SREJ frame reception

10.8.6

Acknowledge timeout

Timeout of T1

Transmit RR N(R)

Figure 10.24: Acknowledge timeout

ETSI

Release 7

10.8.7

42

ETSI TS 102 613 V7.3.0 (2008-09)

Guarding/transmit timeout

Timeout of T2 for frame X

Resend I

X,N(R)

Set T2 for this frame

Figure 10.25: Guarding/transmit timeout

11

CLT LLC definition

11.1

System Assumptions

Void

11.2

Overview

The CLT LLC is used to exchange data based on SWP physical layer between the CLF and the UICC. The CLF acts as a bridge, which composes/removes the type specific RF-frame encapsulation, but keeps the type-specific error detection code, which is managed by the UICC except where specified otherwise. A minimum set of administrative commands is specified as well. A CLT session is defined as the sequence of frames based on CLT LLC.

11.2a •

The CLT LLC supports transport of data for ISO/IEC 14443-3 [3] Type A based card emulation protocols. -



Supported RF protocols Initialization (anticollision and selection) of RF protocols is performed by the CLF without UICC involvement. The CLF possesses all information necessary.

The CLT LLC supports transport of data for the initialization commands of ISO/IEC 18092 [8] 212/424 kbps passive mode based card emulation protocols. -

NOTE:

The UICC provides initialization data to the CLF, which performs RF protocol initialization. In the present document, other RF protocols are not specified in detail, but are not excluded from being operated via CLT, as there are (e.g.) ISO/IEC 14443-2 [2] and ISO/IEC 14443-3 [3] Type B based schemes, as long as the maximum RF frame length (including error detection code) of the supported RF protocol does not exceed the transport capability of a single CLT frame and the CLF supports the proper RF protocol initialization.

ETSI

Release 7

11.3

43

ETSI TS 102 613 V7.3.0 (2008-09)

CLT Frame Format

For CLT LLC frame format see figure 9.5. The CLT PAYLOAD may contain data transferred from or to the RF side of the CLF, furthermore referenced as DATA_FIELD. The structure of the DATA_FIELD shall either be "byte aligned" or retrieved from ISO/IEC 14443-3 [3] Type A standard frame format, furthermore referenced as "Type A aligned". For Type A aligned structure, meaningless bits in the last byte of the CLT PAYLOAD shall be padded with 0. See clause 11.5.1. for interpretation rules and an example. The CLT CMD shall indicate the type of data in the DATA_FIELD and may include additional administrative commands exchanged between the CLF and the UICC, referenced as ADMIN_FIELD. The interpretation of the DATA_FIELD and the ADMIN_FIELD is linked to the entity which has submitted the CLT frame (either the UICC or the CLF).

Figure 11.1: Typical examples for CLT frames with DATA_FIELD present

ETSI

Release 7

44

11.4

ETSI TS 102 613 V7.3.0 (2008-09)

CLT Command Set

Table 11.1 gives the coding of the CLT CMD field. Table 11.1: Contents of CLT_CMD Bit

Value

5 0 1 4 to 1 0000 1000 1001

Other Values 0000 0001 0010

Other Values

NOTE:

Meaning Structure of DATA_FIELD in CLT PAYLOAD Data structure Type A aligned (see clause 11.5.1) Data structure is byte aligned ADMIN_FIELD Interpretation of ADMIN_FIELD sent by the CLF to the UICC: No administrative command CL_PROTO_INF(A): The CLF was selected in ISO/IEC 14443-3 Type A [3] technology (see clause 11.5.3.1) CL_PROTO_INF(F): The CLF forwards initialization data according to ISO/IEC 18092 [8] 212/424 kbps passive mode (see clause 11.5.3.2) RFU Interpretation of ADMIN_FIELD sent by the UICC to the CLF: No administrative command CL_GOTO_INIT: Requests transition of the CLF to initial state of the RF protocol initialization sequence (ISO/IEC 14443-3 [3]) CL_GOTO_HALT: Requests transition of the CLF to “HALT” state of the RF protocol initialization sequence (ISO/IEC 14443-3 [3]) RFU

Independent from the content of the ADMIN_FIELD, CLT frames may provide a DATA_FIELD.

11.5

CLT Frame Interpretation

11.5.1

CLT frames with Type A aligned DATA_FIELD

For CLT frames with Type A aligned DATA_FIELD, the bit count shall be retrieved implicitly from the byte length of the CLT PAYLOAD, where the interpretation rule depends on the direction the frame is transferred. For CLT frames sent from the CLF to the UICC the following table shall apply: Table 11.2: Bit length calculation of Type A aligned frame (direction CLF to UICC) Size [bytes] of CLT PAYLOAD 0 1 2 3 …4 to 8… 9 10 11 …12 to 17… 18 19 20 …21 to 26… 27 28 29

Number of RF bits interpreted as DATA_FIELD by the UICC Invalid 7 (starting from LSB) 9 18 (continue similar way) 72 Invalid 81 (continue similar way) 144 Invalid 153 (continue similar way) 216 Invalid 225

Remark

1 RF byte + 1 parity bit 2 RF bytes + 2 parity bits 8 RF bytes + 8 parity bits 9 RF bytes + 9 parity bits 16 RF bytes + 16 parity bits 17 RF bytes + 17 parity bits 24 RF bytes + 24 parity bits 25 RF bytes + 25 parity bits

For CLT frames sent from the UICC to the CLF the following table shall apply:

ETSI

Release 7

45

ETSI TS 102 613 V7.3.0 (2008-09)

Table 11.3: Bit length calculation of Type A aligned frame (direction UICC to CLF) Size [bytes] of CLT PAYLOAD 0 1 2 3 …4 to 28… 29

Number of RF bits interpreted as DATA_FIELD and thus sent to the PCD by the CLF 0 4 (starting from LSB) 9 18 (continue similar way) 225

Remark

Interpretation rule see clause 11.5.2 1 RF byte + 1 parity bit 2 RF bytes + 2 parity bits 25 RF bytes + 25 parity bits

Below, the CLT frame layout transporting 4 RF bytes + 4 parity bits is shown as an example:

Figure 11.2: Example for a Type A aligned CLT frame

11.5.2

Handling of DATA_FIELD by the CLF

Due to the nature of RF protocols, the information exchange on RF side is half-duplex, where the PCD sends a command and the PICC sends normally a response, but also may not respond to erroneous frames or to certain commands. In the architecture described in the present document, the response or the condition not to respond shall be evaluated by the UICC. This condition shall be reported to the CLF by means of a CLT frame without a DATA_FIELD. The resulting data exchange flow for ISO/IEC 14443-3 [3] based card emulation protocols is as follows: •

After the CLF has received an RF frame, a CLT frame with all RF data in the DATA_FIELD shall be composed and sent to the UICC. See clause 11.5.3.1 for different handling of the first frame after RF protocol initialization



After reception of a CLT frame from the UICC, the CLF shall transmit the received data via RF if the CLT frame included a DATA_FIELD, if no DATA_FIELD was present then no data shall be transmitted via RF.

The data exchange flow for ISO/IEC 18092 [8] 212/424 kbps passive mode card emulation protocols is described in clause 11.5.3.2.

ETSI

Release 7

11.5.3 11.5.3.1

46

ETSI TS 102 613 V7.3.0 (2008-09)

Handling of ADMIN_FIELD CL_PROTO_INF(A)

With this ADMIN_FIELD, the CLF shall informs the UICC about the presence of an ISO/IEC 14443-3 [3] Type A based card emulation RF protocol to be processed in CLT mode. In this case, CL_PROTO_INF(A) shall be sent by the CLF to the UICC after every successful ISO/IEC 14443-3 [3] Type A RF protocol initialization. Following actions shall be taken by the CLF after it has sent the "SAK" as per ISO/IEC 14443-3 [3] Type A: •

The CLF shall verify the correctness of the next received RF frame.



If the error detection code is correct and the RF frame is a Type A standard frame as per ISO/IEC 14443-3 [3] with CRC_A appended, and the first byte is not 'E0', the CLF shall compose a CLT frame with ADMIN_FIELD CL_PROTO_INF(A) and shall attach the received RF data as DATA_FIELD. The RF-type specific error detection code shall not be included and the DATA_FIELD shall be coded in "byte-aligned" manner. -

NOTE: -

If the first byte is equal to 'E0' (command "RATS" as per ISO/IEC 14443-4 [4]), then the CLF shall continue ISO/IEC 14443-4 [4] processing using a higher level protocol out of scope of the present document, no CLT frame shall be sent to the UICC. For protocols according to ISO/IEC 18092 [8] 106 kbps passive mode, the sequence containing the command code 'D400' (ATR_REQ) is treated in a similar way. If the length of the RF data exceeds the maximum size of the DATA_FIELD, no CLT frame shall be sent to the UICC.

The following actions shall be taken by the UICC on receiving a CLT frame with ADMIN_FIELD CL_PROTO_INF(A): •

The contents of the DATA_FIELD shall be evaluated by the UICC. -

If the contents of the DATA_FIELD is a valid command for one of the RF protocols supported by the UICC, the UICC shall compute the response and send it to the CLF within a CLT frame.

-

If the contents of the DATA_FIELD is equal to ISO/IEC 14443-3 [3] command "HALT", the UICC shall reply with a CLT frame with the ADMIN_FIELD CL_GOTO_HALT.

-

In any other case, the UICC shall send a CLT frame with the ADMIN_FIELD CL_GOTO_INIT.

11.5.3.2

CL_PROTO_INF(F)

With this ADMIN_FIELD command, the CLF shall inform the UICC about the presence of a ISO/IEC 18092 [8] 212/424 kbps passive mode based card emulation protocol, for which the initialization data shall be provided by the UICC via CLT as described below. A CLT frame with the ADMIN_FIELD CL_PROTO_INF(F) shall be sent by the CLF to the UICC after every reception of an anticollision command ("POLLING REQUEST" command) from RF side if the CLF is configured to do so. This information is retrieved from higher application layers. In this case, the following actions shall be taken by the CLF: •

When the CLF has received the initialization command as defined in ISO/IEC 18092 [8] for 212/424kbps passive mode ("POLLING REQUEST", command code '00'), it shall forward the received RF data (including the LEN and RF CRC field) to the UICC encapsulated as byte aligned DATA_FIELD in a CLT frame with the ADMIN_FIELD CL_PROTO_INF(F).

ETSI

Release 7



47

ETSI TS 102 613 V7.3.0 (2008-09)

On reception of a CLT frame with ADMIN_FIELD (0000)b, the CLF shall interpret the DATA_FIELD as initialization response ("POLLING RESPONSE", Command Code '01', including the LEN and RF CRC field), and send it out on RF side according to the initialization procedure as defined in ISO/IEC 18092 [8] for 212/424kbps passive mode.

NOTE:

According to ISO/IEC 18092 [8], the initialization response ("POLLING RESPONSE") is received by the initiator after a waiting time of 2.417 ms (512 x 64 / 13,56 MHz) within one of the allowed time slots. Each time slot has a duration of 1.208 ms (256 x 64 / 13,56 MHz). The CLF randomly selects one of the available time slots indicated by the PCD within the anticollision command.

The following actions shall be taken by the UICC on receiving a CLT frame with ADMIN_FIELD CL_PROTO_INF(F): •

The contents of the DATA_FIELD shall be evaluated and the ISO/IEC 18092 [8] 212/424 kbps passive mode specific error detection code (RF CRC) and length (LEN byte) shall be verified. -

In case the error detection code (RF CRC) and the LEN byte are correct and the received DATA_FIELD does not match with the applications available on the UICC, the UICC shall send a CLT frame without a DATA_FIELD to the CLF within 1150 µs.

-

In case the error detection code and the LEN byte are correct and the received DATA_FIELD matches the application available on the UICC, the UICC shall respond with an CLT frame containing the ISO/IEC 18092 [8] 212/424 kbps passive mode initialization response frame ("POLLING RESPONSE", including the LEN and RF CRC field) encapsulated in the DATA_FIELD within 1150 µs.

-

In case an error with respect to ISO/IEC 18092 [8] 212/424 kbps passive mode is detected, the UICC shall send a CLT frame without a DATA_FIELD to the CLF within 1150 µs.

Figure 11.3 shows a CLT frame containing an ISO/IEC 18092 [8] 212/424 kbps passive mode based RF frame.

Figure 11.3: ISO/IEC 18092 [8] 212/424 kbps passive mode data in a CLT frame (example) In order to explain the byte arrangement of ISO/IEC 18092 [8] based frame data within a CLT LPDU, an example of an RF frame containing three data bytes and the RF CRC is shown in figure 11.4.

ETSI

Release 7

48

ETSI TS 102 613 V7.3.0 (2008-09)

Figure 11.4: ISO/IEC 18092 [8] 212/424 kbps passive mode byte arrangement in a CLT frame (example)

11.5.3.3

CL_GOTO_INIT and CL_GOTO_HALT

With these ADMIN_FIELD contents, the UICC shall inform the CLF about a necessary transition to initialization state with respect to the initialization state diagram on RF side. This may occur either in case of an error or if a dedicated transition command (e.g. "HLTA") was decoded by the UICC. In ISO/IEC 14443-3 [3] Type A, the CLF has to support two initialization branches, the corresponding actions are outlined in table 11.4. Table 11.4: Reasons and actions for CL_GOTO_INIT and CL_GOTO_HALT

The UICC decodes an error send CL_GOTO_INIT The UICC decodes a HLTA command send CL_GOTO_HALT

The CLF was selected from IDLE state (via "READY/ACTIVE" states) Transition of the CLF to ISO/IEC 14443-3 [3] "IDLE" state Transition of the CLF to ISO/IEC 14443-3 [3] "HALT" state

11.6

CLT Protocol Rules

11.6.1

Rules for the CLF

The CLF was selected from HALT state (via "READY*/ACTIVE*" states) Transition of the CLF to ISO/IEC 14443-3 [3] "HALT" state Transition of the CLF to ISO/IEC14443-3 [3] "HALT" state

The following rules apply for the CLF: •

In order to open a new CLT session, the CLF shall send a CLT frame with ADMIN_FIELD set to CL_PROTO_INF(A) or CL_PROTO_INF(F) to the UICC.



During a CLT session, on reception of a corrupted SWP frame the CLF shall maintain the CLT LLC layer.

ETSI

Release 7

11.6.2

49

ETSI TS 102 613 V7.3.0 (2008-09)

Rules for the UICC

The following rules apply for the UICC: •

The UICC shall not send a CLT frame before having received a CLT frame with ADMIN_FIELD set to CL_PROTO_INF(A) or CL_PROTO_INF(F)



The UICC shall interpret a received CLT frame with ADMIN_FIELD set to CL_PROTO_INF(A) or CL_PROTO_INF(F)as condition to open a new CLT session



During a CLT session, the UICC shall ignore a corrupted SWP frame



During a CLT session, the UICC shall ignore received CLT frames if at least one of the following conditions apply: -

the ADMIN_FIELD contains a value which is reserved for future use (see table 11.1)

-

the length of the DATA_FIELD indicated for a Type A aligned CLT frame is invalid (see table 11.2)

12

Timing and performance

12.1

SHDLC Data transmission mode

When in SHDLC mode as defined in clause 10 SHDLC LLC definition, the CLF shall be able to send multiple data frames over the SWP link to the UICC, the format and management of this data is out of the scope of the present document. The CLF shall transmit frames to the UICC in a timely fashion and shall ensure that the time from receipt of the last RF bit to the end of the transmission of the last SWP frame shall be less than TCLF,shdlc = 500 us. Where: the last RF bit is the end of the last pause transmitted by the PCD (see ISO/IEC 14443-3 [3], applies for Type A); and the end of the transmission of the last SWP frame is the end of the last bit of EOF on signal S1. When receiving response data from the UICC the CLF shall be capable of concatenating multiple frames into a single RF transmission and shall ensure that the time between the first bit of the first frame over SWP to the start of the first bit of RF data shall be less than TCLF,shdlc = 500us. Where: the first bit of the first frame over SWP is the start of the first bit of the SOF on signal S2; and the start of the first bit of RF data is the first modulation edge within the start bit (see ISO/IEC 14443-3 [3], applies for Type A). NOTE 1: The CLF and UICC have the responsibility to ensure that no delays in SWP data cause a break in RF transmission. NOTE 2: The above timings presume error free communications over SWP

ETSI

Release 7

50

ETSI TS 102 613 V7.3.0 (2008-09)

TPICC

RF PCD - CLF SWP CLF - UICC

RF CLF- PCD TCLF,shdlc

TCLF,shdlc

SWP CLF - UICC

SWP UICC - CLF

SWP UICC - CLF

SWP CLF - UICC

SWP UICC - CLF

UICC Processing time

t

Figure 12.1: SHDLC transmission timings

12.2

CLT data transmission mode for ISO/IEC 14443 Type A

12.2.1

CLF processing delay when receiving data from the PCD

The CLF receives RF data and sends data over SWP to the UICC. The processing delay by the CLF is defined as: The time between receipt of the last bit of the RF data block and last data bit sent over SWP where: the last bit of the RF data block is the end of last pause transmitted by the PCD (see ISO/IEC 14443-3 [3]); and the last data bit sent over SWP is the end of the last bit of EOF on signal S1. This processing delay is designated as TCLF,receive. The CLF shall deliver the received RF data block as DATA_FIELD within exactly one CLT frame. In the case where the incoming RF data block exceeds the length limit of CLT LLC, an error on the RF side or wrong RF protocol type shall be assumed and proper error handling shall be executed (see NOTE 1). NOTE 1: If the length of the incoming RF data exceeds the maximum size of the DATA_FIELD, then the CLF may send to the UICC either a CLT frame with an incorrect CRC or an incorrect EOF or an empty CLT frame. NOTE 2: The CLF may start data transmission over SWP after having received a complete RF data block or may start data transmission over SWP while still receiving RF data (pipelining).

ETSI

Release 7

12.2.2

51

ETSI TS 102 613 V7.3.0 (2008-09)

CLF processing delay when sending data to the PCD

The CLF receives data over SWP from the UICC and modulates it onto the RF. The processing delay by the CLF is defined as: The time between the receipt of the first bit sent over SWP and the first bit sent to the PCD. Where: the first bit sent over SWP is the start of the first bit of the SOF on signal S2; and the first bit sent to the PCD is the first modulation edge within the start bit (see ISO/IEC 14443-3 [3]). In the case where no DATA_FIELD in the CLT frame is present (see clause 11.5.2), the processing delay by the CLF is defined as the time between the receipt of first bit sent over SWP from UICC to CLF and the time when the CLF shall be ready to receive the start bit of the next RF data block. This processing delay is designated as TCLF,transmit. The UICC shall deliver the RF data block as DATA_FIELD within exactly one CLT frame. The CLF shall deliver the received RF data within exactly one RF data block. Within a CLT session, on reception of a CLT frame with a DATA_FIELD present, the CLF may start sending data to the PCD after having received a complete CLT frame (non-pipelining) or may start sending data to the PCD while still receiving data over SWP (pipelining). In both cases, if the CRC is not correct, the CLF shall follow the rules given in clause 11.6.1 and in case of non-pipelining, the CLF shall not modulate the RF-field.

12.2.3

Timing values for the CLF processing delay

The total processing delay in the CLF shall not exceed TCLF,delay: TCLF,delay = TCLF,receive + TCLF,transmit The maximum value for TCLF,delay is calculated as: TCLF,delay = 210 µs + (15 µs per received byte of RF data) + (15 µs per sent byte of RF data) NOTE:

In the formula ISO/IEC14443-3 [3] start bits, parity bits and stop bits are not included.

ETSI

Release 7

52

ETSI TS 102 613 V7.3.0 (2008-09)

TPICC

RF PCD - CLF

RF CLF- PCD TCLF,receive

TCLF,transmit

SWP CLF - UICC

SWP UICC - CLF

UICC Processing time

NOTE:

t

SWP CLF-UICC and SWP UICC-CLF represent the time taken to transmit the data over SWP and are included in the TCLF,receive and TCLF,transmit times.

Figure 12.2: CLF transmission timings The CLF and UICC should take care to ensure that processing delays do not comprise overall transactions times of commands and ensure that response PICC to PCD frame delay times can be achieved. NOTE:

In figure 12.2 TPICC represents a time equivalent to the total processing time of a Contactless card and is used to demonstrate the relationship between a card emulated by a CLF/UICC pair and a real card. Using the above diagram and the example of a typical ISO/IEC 14443 type A read command where the command from the PCD is 2 bytes long plus a CRC and the response is 16 bytes long plus a CRC then we would see: TCLF,delay = TCLF,receive + TCLF,transmit = 540 µs TPICC =540 µs plus the processing time of the UICC

12.2.4

Timing value for the CLF processing delay (Request Guard Time)

If the PCD sends a REQA or WUPA to the CLF during a CLT session, the CLF forwards the REQA or WUPA encapsulated in a CLT frame to the UICC (DATA_FIELD length 1 byte). The UICC may respond with a CLT frame with the ADMIN_FIELD CL_GOTO_INIT and no DATA_FIELD present. For this situation, the Request Guard Time (ISO/IEC 14443-3 [3]) has to be respected. The maximum value for TCLF,delay is: T(max)CLF,delay = 190 µs NOTE:

UICC and a CLF operating in CLT may be in the states ACTIVE or ACTIVE* (named as PICC states in ISO/IEC 14443-3 [3]). A REQA/WUPA sent by the PCD will force a transition to the PICC states IDLE or HALT (with no response from the CLF to the PCD). A subsequent REQA/WUPA will restart the collision resolution process. In some implementations, the PCD deliberately forces this error condition in order to exit the authenticated state of the PICC.

ETSI

Release 7

12.3

53

ETSI TS 102 613 V7.3.0 (2008-09)

CLT data transmission mode for ISO/IEC18092 212kbps/424kbps passive mode

The CLF processing delay in this transmission mode is limited by the UICC processing time as defined in clause 11.5.3.2 and the Single Device Detection at 212kbps and 424kbps as defined in ISO/IEC 18092 [8] NOTE:

Compliance to the Single Device Detection at 212kbps and 424kbps as per ISO/IEC 18092 [8] is within the responsibility of the CLF, and is achieved by balancing its internal processing time and the SWP bit rates properly.

ETSI

Release 7

54

Annex A (informative): (Void)

ETSI

ETSI TS 102 613 V7.3.0 (2008-09)

Release 7

55

ETSI TS 102 613 V7.3.0 (2008-09)

Annex B (informative): Change history The table below indicates all changes that have been incorporated into the present document since it was placed under change control. Date 2007-10

2008-01

2008-04

Meeting SCP #34

SCP #35

SCP #37

Plenary Doc SCP-070505

CR 001

Rev -

SCP-070505

002

-

SCP-070505 SCP-070505

003 005

-

SCP-070505

006

-

SCP-070505

007

-

SCP-070505

009

-

SCP-070505

010

-

SCP-080023

011

-

SCP-080043

013

1

SCP-080023

014

-

SCP-080023

015

-

SCP-080023

016

-

SCP-080023

017

-

SCP-080213 SCP-080213

004 018

3 -

SCP-080213

019

-

SCP-080213

020

-

SCP-080213

021

-

SCP-080213

022

-

SCP-080213 SCP-080213

023 024

-

SCP-080213

025

-

SCP-080238 SCP-080239 SCP-080248

026 027 028

1

Change history Cat Subject/Comment F Clarification of text in section 10.6.1. Workaround in order not to use the term “timeout” and rather refer to min or max values. Reason is that the UICC has no strict notion of time and therefore cannot enforce fixed timeout values. F Collection of editorial corrections – CR presented as category D but deemed category F by Plenary without reissue due to modification in table-embedded normative note F Creation and time of existence of sliding window size F Defines proper behaviour for RR frame transmission and retransmission after an RNR frame was received in order to avoid failure of the SHDLC protocol. C Clarification of bit duration times – Removal of the 295ns value. New optional minimum set to 590ns. C Clarification of the SWP resume by the slave procedure. Removal of redundant figure. Text leading to interoperability issues changed. C Clarification of the duration of the high and low states of the S1 signal in order to have the intended 25/75 ratio. F Clarification of the conditions of use of the RSET signal. D Editorial corrections of SWP interface activation – Figures in section 6.2.3 modified F Clarification of I-frame reception process – Clarification of the use and processing of SREJ S-frame. F Refinement of clause11 (CLT LLC definition) Clauses have been renumbered compared to CR in order no to break earlier references to the present document. C Clarification of interface activation and LLC interworking – Several steps are clarified and a section about LLC interworking is added C Clarification of the timing budget for the CLF. Additionally, the Request Guard Time is relaxed. C Clarification of CLT data transmission mode. Removal of redundant text and correction of unclear and inconsistent text. F Clarification of identity check mechanism F Clarification of the consequences of a link re-establishment F Correction of figure 10.16 due to erroneous frame numbering D Removal of informative Annex A which was thought to introduce misleading interpretations of clause 11. F Clarification on wakeup in order to avoid the possibility of a protocol deadlock F Clarification on contact vs. interface states and transitions. Removal of overlap and addition of clearer distinction between transitions and states. F Clarification of CLF processing delay F Clarifications in section 6.2.3.2 by adding some missing timing information and clarification of the layout. F Correction of the characteristic of S1-V(OL). Deletion of negative currents from the conditions. D Correction of note and grammatical errors D Correction of note C Clarification on bit stuffing Editor's note: incorrect CR number in SCP-080248. This should be 028 instead of 027.

ETSI

Old New 7.0.0 7.1.0

7.0.0 7.1.0

7.0.0 7.1.0 7.0.0 7.1.0

7.0.0 7.1.0 7.0.0 7.1.0

7.0.0 7.1.0

7.0.0 7.1.0 7.0.0 7.1.0 7.0.0 7.1.0 7.0.0 7.1.0

7.0.0 7.1.0

7.0.0 7.1.0 7.0.0 7.1.0

7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0

7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0 7.1.0 7.2.0

Release 7

Date 2008-07

56

Meeting SCP #38

Plenary Doc SCP-080361 SCP-080362

CR 029 031

Rev 1 1

ETSI TS 102 613 V7.3.0 (2008-09)

Change history Cat Subject/Comment F Correction of the condition for S2 switching F Correction of SHDLC flowcharts

ETSI

Old New 7.2.0 7.3.0 7.2.0 7.3.0

Release 7

57

History Document history V7.0.0

November 2007

Publication

V7.1.0

February 2008

Publication

V7.2.0

June 2008

Publication

V7.3.0

September 2008

Publication

ETSI

ETSI TS 102 613 V7.3.0 (2008-09)