Comprendre l’anti-collision en RFID/NFC
Qu’est-ce que l’anti-collision ?
La plupart des systèmes RFID, y compris les cartes sans contact à 13,56 MHz et le NFC, reposent sur le principe RTF (Reader Talk First) : le lecteur envoie périodiquement des trames de recherche, et chaque carte présente dans son champ y répond en transmettant son identifiant.
Mais que se passe-t-il lorsque deux cartes — ou plus — sont présentes en même temps dans le champ du lecteur ? Elles répondent simultanément à la trame de recherche : c’est la collision. Sauf cas très particuliers, le lecteur est alors incapable de décoder la réponse.
Le mécanisme d’anti-collision résout ce problème : il permet au lecteur de savoir précisément combien de cartes se trouvent dans son champ, et d’obtenir, l’une après l’autre, l’identifiant de chacune. Le nom est un peu trompeur : il ne s’agit pas d’empêcher la collision — elle a déjà eu lieu lorsque le mécanisme s’active — mais au contraire de la résoudre, en faisant répéter leur réponse aux cartes, mais de manière non simultanée.
Les différentes méthodes de résolution
Plusieurs méthodes permettent de résoudre une collision.
La partie A de la norme ISO 14443 repose sur un principe bien adapté aux cartes à logique câblée : les cartes répondent de manière synchrone, et le lecteur est capable de déterminer précisément sur quel bit se produit la première collision. Il génère alors une nouvelle trame de recherche indiquant le début de la réponse qu’il a reçue, en fixant aléatoirement ce bit de collision à 0.
S’il n’y a que deux cartes, celle dont le bit vaut 1 ne répond pas, et le lecteur peut recevoir l’identifiant complet de la première carte. Il génère ensuite une nouvelle trame en fixant le bit à 1 pour obtenir l’identifiant de la seconde carte. S’il y a davantage de cartes, il suffit de répéter ce mécanisme autant de fois que nécessaire pour explorer l’ensemble des identifiants présents.
La partie B de la norme ISO 14443 repose sur un principe plus simple à implémenter en logiciel. Dans sa première trame de recherche, le lecteur annonce un nombre de créneaux temporels (slots). Chaque carte choisit aléatoirement le numéro de créneau dans lequel elle répondra, ce qui réduit la probabilité de collision. Si une collision se produit malgré tout dans un créneau, le lecteur demande aux cartes dont il a déjà obtenu l’identifiant de rester silencieuses, puis génère une nouvelle trame de recherche, jusqu’à résoudre toutes les collisions.
Enfin, la norme ISO 15693 repose sur un principe hybride entre les deux précédents. Comme pour le type B, l’anti-collision s’appuie sur des créneaux, mais le numéro de créneau choisi par la carte n’est pas aléatoire : il correspond à une partie de son identifiant. Comme pour le type A, le lecteur réalise une exploration en profondeur en annonçant la longueur d’identifiant qu’il connaît déjà, ce qui revient à faire défiler la portion d’identifiant que les cartes utilisent pour choisir leur créneau.
Même si les lecteurs qui intègrent ces algorithmes les exécutent très rapidement, l’anti-collision représente toujours un temps de traitement supplémentaire par rapport à une situation sans collision. Ce temps reste heureusement imperceptible pour un utilisateur humain — c’est tout l’intérêt de l’anti-collision dans de nombreuses applications.
Un lecteur qui prend en charge l’anti-collision peut, sous le contrôle d’une application, sélectionner la « bonne » carte parmi plusieurs. Pour un lecteur de contrôle d’accès par exemple, l’utilisateur peut présenter son portefeuille contenant sa carte de transport, une ou deux cartes de paiement, le badge d’accès à son immeuble et sa carte d’accès à l’entreprise. L’anti-collision permet au système de contrôle d’accès de tester l’authenticité de chaque carte, une par une, jusqu’à trouver celle qui ouvre la porte — un vrai gain d’ergonomie pour l’utilisateur.
Quand l’anti-collision n’est pas souhaitable
Certains cas rendent l’anti-collision peu pertinente, voire proscrite par principe.
C’est le cas d’un terminal de paiement : un utilisateur possédant plusieurs cartes bancaires doit choisir explicitement celle avec laquelle il souhaite payer. Si une collision est détectée, le terminal refuse la transaction et invite l’utilisateur à résoudre lui-même la situation.
C’est aussi le cas des lecteurs sans contact conformes au standard PC/SC pour la connexion à un ordinateur. Le PC/SC a été conçu pour les cartes à contact et repose sur le principe d’une seule carte insérée dans le lecteur : il ne peut pas gérer la présence simultanée de deux cartes sans contact sur un même lecteur. Un lecteur sans contact PC/SC peut implémenter l’anti-collision via des mécanismes propriétaires, mais dans une implémentation respectueuse du standard, il ne présentera aux applications que la première carte détectée.