Tout sur les mécanismes d'anti-collision !

Qu'est-ce que l'anti-collision ?

La plupart des systèmes RFID, dont les cartes sans-contact à 13.56MHz et le NFC, reposent sur un principe dit RTF, Reader Talk First. Lorsqu'il est en recherche de carte, le lecteur envoie périodiquement des trames de recherche et toute carte qui reçoit une trame de recherche y répond en transmettant son identifiant.

Mais que se passe-t-il lorsque deux cartes -ou plus- sont présentes dans le champ du lecteur ? Elles vont répondre en même temps à la trame de recherche ! Il y a collision des réponses. Sauf cas très particulier, le lecteur est alors incapable de décoder la réponse.

Le mécanisme d'anti-collision est là pour résoudre ce problème et permettre ainsi au lecteur de savoir précisément combien il y a de cartes dans son champ et d'obtenir un à un tous leurs identifiants.

L'appellation est trompeuse, car il ne s'agit pas à proprement parler d'empêcher la collision -qui a déjà eu lieu quand le mécanisme est activé- mais au contraire de résoudre la collision, en amenant les cartes à répéter leur réponse, mais pas simultanément.

Les différentes méthodes pour résoudre une collision

Il y a plusieurs méthodes pour résoudre la collision.

La partie A de la norme ISO 14443 repose sur un principe bien adapté aux cartes à logique câblée : les cartes doivent répondre de manière synchrone et le lecteur est ainsi capable de déterminer très précisément sur quel bit survient la première collision. Il génère alors une nouvelle trame de recherche où il indique le début de réponse qu'il a déjà obtenu correctement, dont ce bit en collision qu'il fixe arbitrairement à 0. S'il n'y a que deux cartes, celle dont ce même bit est à 1 ne va plus répondre et le lecteur va pouvoir obtenir l'identifiant complet de la première carte. Il génère alors une nouvelle trame de recherche, en fixant cette fois le bit 1 et obtient l'identifiant de la seconde carte. S'il y a plusieurs cartes, il suffit de répéter ce mécanisme autant de fois que nécessaire pour avoir exploré en profondeur l'arbre de tous les identifiants présents.

La partie B de la norme ISO 14443, elle, repose sur un principe plus facile à implémenter en soft. Dans sa première trame de recherche, le lecteur annonce un certain nombre de fenêtres temporelles ou slots. Chaque carte choisi au hasard le numéro du slot dans lequel elle va répondre, ce qui diminue la probabilité de collision.

Si une collision survient néanmoins dans un des slots, le lecteur commence par notifier à toutes les cartes, dont il a bien obtenu l'identifiant, qu'elles doivent désormais rester muettes, puis il génère une nouvelle trame de recherche et ce jusqu'à ce que le hasard ait permis de résoudre toutes les collisions.

Enfin, la norme ISO 15693 repose sur une sorte d'hybride entre les deux méthodes. Comme en type B, l'anti-collision se fait par slot, mais le numéro du slot choisi par la carte ne doit rien au hasard puisqu'il correspond à une portion de son identifiant. Comme dans le type A, le lecteur effectue une exploration en profondeur en annonçant la longueur d'identifiant qu'il connaît déjà, ce qui revient à faire glisser la portion d'identifiant que les cartes utilisent pour choisir leur slot.

Évidemment, même si les lecteurs qui intègrent ces algorithmes sont capables de les exécuter à grande vitesse, l'anti-collision représente un temps de traitement supplémentaire par rapport à l'absence de collision. Heureusement, ce temps reste imperceptible pour un humain et c'est ce qui fait l'intérêt de l'anti-collision dans beaucoup de mises en oeuvres.

Un lecteur supportant l'anti-collision est en effet capable de sélectionner -sous le contrôle d'une application- la "bonne" carte, celle qui va permettre d'accéder au service attendu par l'usager.

Par exemple, dans le cas d'un lecteur de contrôle d'accès, l'utilisateur peut présenter en vrac son portefeuille contenant une carte de transport, une ou deux cartes de paiement, le badge d'accès à son immeuble et la carte d'accès à son entreprise.

L'anti-collision va permettre au système de contrôle d'accès de tester la validité de toutes les cartes, une par une, jusqu'à avoir trouvé celle qui ouvrira la porte.

C'est un avantage indéniable en terme d'ergonomie pour l'usager.

 

Les cas où l'anti-collision n'est pas intéressante ou interdite

Il y a cependant de nombreux cas où l'anti-collision n'est pas intéressante, voire même est interdite par principe.

C'est notamment le cas dans un terminal de paiement. Un usager qui dispose de deux (ou plus) cartes de paiement doit explicitement choisir celle avec laquelle il souhaite payer. Si une collision est détectée, le terminal refuse la transaction et invite l'usager à résoudre la collision lui-même.

C'est aussi le cas pour les lecteurs sans-contact qui respectent le standard PC/SC pour la connexion à un ordinateur.

PC/SC a été conçu pour les cartes à contact, et repose donc sur le paradigme d'avoir une carte par lecteur. Il ne peut pas gérer la présence simultanée de deux cartes sans contact sur un seul lecteur.

Aussi, un lecteur PC/SC sans-contact pourra éventuellement implémenter l'anti-collision à travers des mécanismes propriétaires, mais dans une mise en oeuvre respectueuse du standard, il ne présentera aux applications que la première carte qui lui est présentée.

 

Publié le 13/11/2018