Les mécanismes de robustesse

Les mécanismes qui sont aujourd’hui implémenté dans KNX-RF pourraient être améliorés pour

accroitre la fiabilité du système. Quelques pistes de recherche sont envisageables.

V.8.1.1.Mécanisme d’écoute de canal

Comme l’ont montré les simulations réalisées sur KNX-RF, le mécanisme d’écoute de canal LBT

n’est pas suffisant pour éviter les collisions de trames dans un scénario ou au moins deux modules ne

s’écoutent pas mutuellement (section V.6). Pour y remédier, il est intéressant de vérifier si un autre

mécanisme comme le CSMA/CA avec réservation de canal (RTS-CTS) implémenté dans ZigBee

serait en mesure d’améliorer la fiabilité du système. Le premier inconvénient qu’on pourrait relever de

la méthode d’accès CSMA/CA avec RTS-CTS est qu’il ne serait pas judicieux de l’implémenter pour

des systèmes utilisant des trames de courtes durées. De plus, bien que les trames de RTS et CTS

supplémentaires soient courtes, elles introduiraient néanmoins de la latence supplémentaire au

système, ce qui pourrait être inacceptable pour certaines applications. Plus important encore, cette

technique semble plus adaptée pour les systèmes unicast ; or KNX-RF est principalement basé sur du

multicast de données (e.g. fermeture des volets ou allumage des lampes en même temps). En effet, en

multicast, les trames CTS qui seraient transmises par un groupe de produits en réponse à un RTS reçu

en multicast, pourraient, elles aussi, subir des collisions. Ce problème a déjà été investigué dans les

travaux de Kuri et al. [126] et des solutions ont été proposés.

Pour résumé, la technique du CSMA/CA avec RTS-CTS doit être transposée sur KNX-RF et son

intérêt exploré par des simulations à l’aide d’outils comme OMNet++ ou NS2.

V.8.1.2.Délais d’accès au média et retransmissions

Avant de transmettre ou de retransmettre une trame, le protocole KNX-RF utilise une politique

d’accès dynamique à allocation aléatoire (CSMA non-persistant) mais sur un intervalle de temps

statique, c’est-à-dire qu’il tire une durée aléatoire sur un intervalle de temps [Tmin, Tmax] invariant.

Les simulations réalisées ont montré que ce délai bien qu’aléatoire n’est parfois pas suffisant, car

même après plusieurs retransmissions de la trame, celle-ci n’aboutit toujours pas à cause des

collisions. Il serait donc intéressant d’implémenter un délai d’accès au média qui s’incrémente après

chaque collision de façon linéaire (après K tentatives, T

max

= T

init

+ K*incrément) ou de façon

exponentiel (T

max

= 2

K

). Cependant, il faut veiller à ne pas dépasser les latences tolérer par les

applications.

V.8.1.3.Agilité en fréquence adaptative et retransmissions

Quand les trames sont retransmises en KNX-RF, de nouvelles fréquences dans la bande 868 MHz

sont utilisées. Le nombre de fréquence est limité à 3 en Fast et 2 en Slow et le nombre maximum de

retransmissions dans les deux cas est limité à trois. Par conséquent, il serait intéressant de savoir si une

augmentation du nombre maximum de retransmission de trames permettrait d’améliorer la fiabilité de

KNX-RF.

Par ailleurs, prévoir de nouvelles fréquences pour les sauts de fréquences permettrait au système

d’avoir plus de possibilités pour contourner les interférences. Dans la bande ISM, les quatre

sous-bandes de 868 MHz à 870 MHz sont déjà utilisées par KNX-RF. Une méthode pour augmenter le

nombre de fréquences utilisables est d’exploiter toute la bande 863-870 MHz en utilisant une

technique de modulation à étalement de spectre. La technique du FHSS pourrait être utilisée tout en

évitant les fréquences réservées à d’autres applications comme les alarmes et les communications

audio. La norme ETSI 300-220 dédiée aux applications sub-GHz prévoit cette usage. Elle spécifie

pour cela une puissance maximum de +14 dBm, un dwell time de 400 ms maximum et l’utilisation soit

d’un LBT soit d’un duty-cycle inférieur à 0,1% pour chaque canal. En revanche, ce qui est

contraignant, c’est que l’ETSI exige de faire une segmentation de la bande de 7 MHz de façon à

obtenir 47 canaux minimum pour des canaux ayant une bande supérieure à 100 kHz. Cela nécessiterait

donc d’utiliser de plus petites bandes pour les canaux KNX-RF (dont la bande varie aujourd’hui entre

250 kHz et 600 kHz) ; et pour cela il faudrait augmenter le débit de transmission. En outre, mettre en

œuvre un FHSS qui fait du saut de fréquences adaptatif - qui consiste à mettre les canaux les plus

perturbés dans une liste noire et de les réessayer plus tard - serait une solution plus efficace contre les

interférences.

Par ailleurs, la norme ETSI 300-220 prévoit également l’utilisation d’autres techniques

d’étalement de spectre comme le DSSS. Pour ces techniques, il faut utiliser soit une combinaison de

LBT et d’agilité adaptative en fréquence (AFA) soit un duty cycle. Les détails sur les largeurs de

bande préconisées, les puissances d’émission et les valeurs de duty-cycle sont détaillés dans Tableau

V-1.

Tableau V-1 : Caractéristiques de la bande 863 – 870 MHz préconisées par La norme ETSI 300 220

Sous-bande ^{Bande maximum}

occupée

Puissance maximum E.R.P

(dB) ^{Duty Cycle}

De 863 MHz

Les techniques d’étalement de spectre que ce soit le FHSS ou le DSSS ont l’inconvénient

d’être énergivores et nécessiteraient un développement hardware et software plus complexes que ce

qui a été fait jusqu’à ce jour pour KNX-RF. Néanmoins, ces pistes présentent un intérêt

non-négligeable et doivent être sujets à une recherche plus approfondie.

Une autre méthode pour disposer de plus de fréquences serait de prévoir des retransmissions sur

de nouvelles bandes de fréquences, en plus de la bande 868 MHz.

La première solution en ce sens, serait de faire du bi-bande 868 MHz/433 MHz. Les deux

bandes disponibles en 433 MHz font 990 kHz et 750 kHz chacune et la puissance d’émission (PIRE)

est limitée à +10 dBm avec un duty cycle de 10%. Les caractéristiques de ces bandes sont donc

adaptées pour des communications en KNX-RF. D’autant plus, que la portée est plus élevée en 433

MHz. Concrètement, si l’on prend l’exemple d’un récepteur en mode FAST, un nouveau

séquencement des sauts de fréquences serait le suivant : F1→F2→F1 →F3→F1→ 1ère fréquence en

433 MHz→ F1 puis 2éme fréquence en 434 MHz. Le changement de bande nécessiterait quelques

millisecondes de plus pour le synthétiseur, mais cela dépend des performances du chip radio.

La deuxième solution serait de faire du bi-bandes 868 MHz/2,4 GHz. Cette dernière bande

étant beaucoup plus large (83,6 MHz), cela serait très énergivore que d’exploiter toutes ses fréquences.

Une idée serait de faire un premier scanne de toute la bande 2,4 GHz au lancement du réseau pour

identifier les deux canaux les moins perturbés, puis les utiliser les pour les sauts de fréquences 868

MHz/ 2,4 GHz. Un exemple de séquencement de ces sauts dans le cas d’un récepteur FAST serait :

F1→F2→F1 →F3→F1→ 1ère fréquence en 2,4 GHz → F1 puis 2éme fréquence en 2,4 GHz. Idem, le

changement de bande nécessiterait quelques millisecondes de plus pour le synthétiseur, mais cela

dépend des performances du chip radio.

V.8.1.4.La correction d’erreur

Dans le protocole KNX-RF, seule la détection d’erreur est possible à travers des blocs de CRCs.

Pour un système plus fiable, un algorithme de correction d’erreur (code en bloc ou code convolutif)

pourrait être implémenté. Cependant, l’amélioration des performances se fera au détriment de la

consommation d’énergie, de la latence et de l’espace mémoire occupé. Des codes de correction

suffisamment simples et rapides doivent ainsi être privilégiés.

Dans les travaux [127], les codes en blocs BCH et Reed Solomon, ainsi que les codes convolutifs

sont comparés pour différents taux de codage. L’étude montre que les codes BCH sont les moins

complexes et les moins énergivores. Elle montre aussi que pour un BER supérieur à 10-2, le code

BCH est meilleur que le code RS, alors que pour BER inférieur à 10-2 les codes RS sont meilleurs. Le

code BCH est donc plus adaptés pour KNX-RF car le BER maximum toléré peut aller jusqu’à 10-4.

Dans d’autres travaux [128], une comparaison est réalisée entre l’ARQ (avec différents nombres

maximum de retransmissions), le code BCH et le code RS et une autre technique de correction

d’erreur appelé Hybrid-ARQ en termes de latence et de consommation d’énergie par rapport à la

capacité de correction d’erreur. La technique de l’Hybrid-ARQ consiste à combiner le mécanisme

d’ARQ avec un code de correction d’erreur ; ce qui pourrait être intéressant pour KNX étant donné

qu’il utilise déjà un mécanisme d’ARQ. Il existe deux types de HARQ : le type I et le type II [129].

Les deux sont simulés avec comme code de correction d’erreur le code BCH grâce à ses avantages. Il

ressort de cette étude que l’HARQ type II est la technique qui consomme le moins d’énergie et qui

engendre le moins de latence. Il serait donc intéressant d’explorer ce type de code pour KNX-RF en

réalisant des simulations sur MATLAB ; d’autant plus que cela permettrait d’augmenter un peu plus la

portée de KNX.

V.8.1.5.Changement de topologie réseau

Changer la topologie étoile de KNX-RF en une topologie maillée tout en gardant la même bande

de fréquences 868 MHz pourrait être utile. En effet, aujourd’hui seuls des produits KNX-RF dédiés

exclusivement à faire de la répétition sont vendus sur le marché. L’idée est de faire en sorte que les

produits radio puissent relayer eux même les trames en cas de limite de portée. Pour cela, on pourrait

imaginer un réseau ou seuls certains produits, notamment ceux alimentés sur secteur, sont configurés

pour router l’information en plus de leur tâche principale (éclairer, chauffer, etc.). Pour ce faire, un

algorithme de routage / codage réseau sera nécessaire. En revanche, cela introduira une latence

supplémentaire et une occupation plus importante de la mémoire.

Dans le document Analyse de la robustesse et des améliorations potentielles du protocole RadioFréquences Sub-GHz KNX utilisé pour l’IoT domotique (Page 159-162)