Projet LoRaWAN

Étude analytique

Nous avons étudié la procédure On-the-air activation qui permet aux end-devices de se connecter à un réseau. Pour cela, nous avons proposé un model de chaine de Markov et nous nous sommes concentré sur le calcul du délai estimé pour compléter l'activation ainsi que la consommation d'énergie. Notre étude est faite en utilisant la bande de fréquence EU863-873 MHz et notre réseau contient une seule gateway.

Modèle de chaine de Markov

Nous avons conçu le model en se basant sur les hypothèses suivantes.

• Concernant la couche physique : Nous supposons que quand un émetteur envoie un préambule, le récepteur détecte ce préambule grâce à la modulation CSS robuste qui est importante dans la conception de la couche physique de LoRaWAN. Nous supposons que quand plusieurs émetteurs envoie des préambules simultanément, le récepteur détecte que le préambule est erroné.
• Concernant la gateway : Nous considérons une seule gateway dans le réseau. Nous supposons que la gateway envoie seulement des trames de type join accept (les données envoyées par les end-devices déjà connectés au réseau ne nécessitent pas un acquittement de la gateway), et que la gateway n'envoie pas de trame durant l'envoi de la trame join request par un end-device.
• Concernant les end-devices : Nous supposons que les end-devices utilisent le débit DR0 pour la procédure de l'activation (DR0 correspond au plus petit débit qui garantit une qualité de lien plus robuste) et pour la transmission des données (pour les end-devices connectés au réseau). Nous supposons aussi que la détection du préambule dure pour la durée totale du préamble.

Modèle

La figure ci-dessus représente le modèle de chaine de Markov pour la procédure d'activation des noeuds dans LoRaWAN. Dans l'état SendReq, le noeuds envoie un join request et passe à l'état Recv 1. Dans l'état Recv 1, le noeud ouvre sa première fenêtre de réception. Si un préambule est détecté, le noeud passe à l'état Preamb 1, puis à l'état Check 1 si le préambule est correct, et puis à l'état Activated si le join accept est correctement reçu. Sinon, le noeud passe à l'état Recv 2 ou bien à l'état Wait. Cela dépend de la durée du préambule et de la trame reçu. Dans l'état Recv 2, le noeud ouvre sa deuxième fenêtre de réception et lance un processus similaire à celui de l'état Recv 1. Dans l'état Wait, le noeud attend pour une durée bien déterminée qu'il puisse réutiliser une sous-bande et passe à l'état SendReq. Finalement, une fois dans l'état Activated, le noeud est bien connecté au réseau prêt à envoyer des données.

Évaluation des performances

Nous évaluons la performance de la procédure d'activation des noeuds en termes de délai estimé et consommation d'énergie estimée.

Délai

La figure ci-dessous représente le délai en fonction de la qualité du canal α et la fénêtre de réception (γ=1 ou fenêtre RX1 ouverte). L'impact de la qualité du canal sur le délai est significative. Quand la qualité du canal est faible (α=0.9), les trames join requestet les join accept peuvent être perdues, ce qui oblige les end-devices de passer fréquemment dans l'état wait et ce qui augmente le délai. L'impact de γ, qui détermine le choix de la fenêtre est ouverte, est aussi significative sur le délai. En effet, quand γ=1, des collisions avec des transmissions d'autres end-devices peuvent être fréquentes durant la transmission d'un join request ou d'un join accept. Ces collisions obligent le end-device à passer dans l'état wait. Quand γ=0, des collisions peuvent avoir lieu durant la transmission d'un join request, mais non pas durant la transmission d'un join accept, puisque la gateway est le seul noeud autorisé à transmettre sur le canal dédié à la fenêtre RX2.

La figure ci-dessous représente le délai en fonction du nombre total de canaux et le nombre des sous-bandes. Le délai diminue avec le nombre de canaux puisque les collisions durant la transmission sont moins fréquentes quand le nombre de canaux est grand. Le délai est impacté par le nombre de sous-bandes : (i) quand le nombre de sous-bandes augmente, la durée de l'état wait diminue puisqu'elle est directement impactée par le nombre de sous-bandes, et (ii) quand le nombre de sous-bandes augmente, le trafic augmente ce qui augmente le délai. Cependant, la réduction de la durée de l'état wait est plus significative que l'occurence des collisions.

La figure ci-dessous représente le délai en fonction fu nombre de end-devicesconnectés et non connectés. Nous considérons trois scénarios : (1) aucun end-device n'est activé; (2) la moitié des end-devices sont activés; (3) tous les end-devices sont activés. Le délai augmente avec le nombre de end-devices dans le réseau pour tous les scnérios. Dans le scénario 1, le délai est presque constant puisque tous les end-devices envoient leurs join requests avec une activité de 0.1%. Donc, les collisions n'apparaissent pas souvent. Dans le scénario 2, le délai augmente significativement. En effet, les end-devices activés envoient des trames de données avec un activité de 1%. Dans ce cas, des collisions et des interférences apparaissent plus fréquemment. Le pire cas est le scénario 3. En effet, tous les end-devices envoient des trames de données et donc le délai augmente encore plus.

Consommation d'énergie

La figure ci-dessous représente la consommation d'énergie en fonction de α et γ. L'impact de la qualité du canal α sur la consommation d'énergie estimée est importante. En effet, un mauvais canal aboutit à des pertes de trames et donc oblige un noeud à passer souvent dans l'état wait dans le but d'atteindre l'état activated. La consommation d'énergie la plus remarquable quand γ=1 est dûe à la retransmission des join requests (et aux périodes d'écoute supplémentaires)

La figure ci-dessous représente la consommation d'énergie de la procédure d'activation d'un noeud en fonction du nombre de canaux et en fonction du nombre de sous-bandes disponibles. La consommation d'énergie diminue avec le nombre de canaux puisque la probabilité des collisions diminue quand le nombre de canaux par sous-bande augmente. En outre, quand le nombre de sous-bandes est grand, le noeud envoie des join requests plus souvent (puisque la durée de l'état wait dépend du nombre de sous-bandes).

La figure ci-dessous représente la consommation d'énergie en fonction du nombre de neouds (actifs et non actifs) dans le réseaux. La consommation d'énergie suit le mêm comportement que le délai puisque cela dépend du temps passé (et de l'énergie consommée) dans chaque état. Quand le nombre de noeuds actifs dans le réseau augmente, la consommation d'énergie de l'activation d'un noeud augmente. En outre, la consommation d'énergie augmente avec le nombre de noeuds dans le réseaux puisque le nombre de collusions augmente dans ce cas.