All about the anti-collision mechanisms !

All about the anti-collision mechanisms !

Abstract

You have never heard about anti-collision in an NFC/RFID context ? Now you do !

What is anti-collision ? 

Most of the RFID systems, including contactless cards at 13.56MHz and NFC, are based on the RTF principle, Reader Talk First. When it is looking for a card, the reader sends periodically research frames and every card receiving a research frame answers by transmitting its ID.

But what happens when two card -or more- are present in the readers field ? They are going to answer at the same time at the research frame ! There is an answers collision. Except in some very specific cases, the reader is not able to decode the answer.

The anti-collision mechanism is here to solve this problem and allow the reader to know precisely how many cards are in its field, and obtain, one after the other, all of their ID. The name is confusing, because it is not about preventing the collision -which has already taken place when the mechanism is activated- but on the contrary to solve the collision by making the cards repeating their answer, but not simultaneously.

The different methods to solve a collision

There are several methods to solve the collision.

The part A of the norm ISO 14443 is based on a principle well-adapted to wired-logic cards: cards should answer in a synchronic manner and the reader is able to determine precisely on which byte the first collision occurs.

It generates a new research frame where it indicates the beginning of this answer it has received, including this collision bit fixed randomly at 0.

If there is only two cards, the one of which the byte is at 1 will not answer and the reader will be able to receive the complete ID of the first card. It generates a new research frame and fixes the byte 1 and then obtain the ID of the second card. If there are many cards, you just need to repeat this mechanism as often as necessary to explore deeply all of the present ID.

The part B of the norm ISO 14443 is based on a principle that is easier to implement in soft. In its first research frame, the reader announces a number of time windows or slots. Each card chooses randomly the slot number in which it will answer, which reduces the collision probability. If a collision occurs in one of the slot, the reader begins to notify, to all the cards from which it has obtained the ID, that they should stay quiet, then it generates another research frame until it solves all the collisions.

Finally, the norm ISO 15693 is based on an hybrid between both methods. Like in type B, the anti-collision is done with the slot, but the slot number chosen by the card is not random because it fits its ID part. Like in type A, the reader realises a deep exploration by announcing the ID length that it already knows, which is the same as making swipe the ID portion that cards use to choose their slot.

Of course, even if readers integrating these algorithms are able to run them really fast, anti-collision is an additional processing time with regards to the time when there is no collision. Fortunately, this time remains slight for humans and that is the main interest of anti-collision in many implementation.

A reader supporting anti-collision is able to select -under the control of an application- the “good” card, the one that will allow the user to use the service. For example, for an access control reader, the user can show its wallet containing the transportation card, one or two payment cards, the access badge to his appartment and the access card to his company. Anti-collision will allow the access control system to try the authenticity of each card, one by one, until it founds the one that opens the door. That is an undeniable advantage in term of ergonomy for the user.

 

 

Cases where anti-collision is not interesting or forbidden

There are cases where the anti-collision is not interesting or forbidden on principle.

It is the case for a payment terminal. A user having two or more credit cards should explicitly choose the one with which he wants to pay. If a collision is detected, the terminal refuses the transaction and invites the user to solve the collision himself.

It is also the case for contactless readers respecting the PC/SC standard for the connection to a computer.

PC/SC was designed for contact cards and is based on the paradigm of having a card in the reader. It can't manage the simultaneous presence of two contactless cards on one reader. A contactless PC/SC reader will eventually implement anti-collision through proprietary mechanisms, but in a respectful implementation of the standard it will show to applications the first card presented only.



Published on 11/13/2018
Share this post
Leave a comment