Protocolo de Routing

No protocolo de routing desenvolvido ´e definida a comunica¸c˜ao entre os diversos N´os no qual s˜ao estabelecidos caminhos para que os dados alcancem o destino.

Pretende-se que o protocolo seja eficiente do ponto de vista energ´etico possuindo tolerˆancia a falhas e que a adi¸c˜ao de N´os n˜ao afete o desempenho da rede.

Para estabelecer a comunica¸c˜ao e o encaminhamento dos dados foi definido que os N´os possuam diferentes funcionalidades. Os N´os respons´aveis pela monitoriza¸c˜ao s˜ao denominados de N´os Sensores. Depois de recolherem os dados, estes devem ser enviados a outros N´os, denominados de N´os Retransmissores, que s˜ao respons´aveis por receberem os dados dos N´os Sensores e pela retransmiss˜ao dos mesmos para outros N´os Retransmissores ou diretamente para o N´o Sink. O N´o Sink tem a responsabilidade de receber os dados desejados, sendo este o destino de todos os dados.

Consoante a estrutura de rede, o protocolo ´e classificado como Hierarchical-Based Routing pois os N´os possuem diferentes funcionalidades e apenas os N´os Retrans- missores enviam os dados ao N´o Sink, diminuindo assim o n´umero de mensagens transmitidas ao Sink. Consoante a opera¸c˜ao do protocolo, este ´e classificado como Multipath Routing Protocol, pois s˜ao utilizados diversos caminhos para que os da- dos alcancem o Sink em vez de um ´unico caminho. O protocolo pode ainda ser classificado como um protocolo Hybrid, relativamente ao modo de como a fonte encontra uma rota para o destino. O modo Hybrid utiliza caracter´ısticas dos proto- colos Proactive, pois as informa¸c˜oes de routing s˜ao mantidas em alguns N´os e utiliza caracter´ısticas dos protocolos Reactive, no qual as rotas s˜ao criadas atrav´es de um processo de descoberta de rotas.

Tolerˆancia a Falhas, Eficiˆencia Energ´etica e Escalabilidade

Como foi referido, fatores como a eficiˆencia energ´etica, tolerˆancia a falhas e esca- labilidade exercem uma forte influˆencia no tempo de vida e efic´acia de uma rede. Com isto, no protocolo de routing desenvolvido foram implementadas t´ecnicas que permitem a tolerˆancia a falhas (retransmiss˜ao de dados, envio ACK), bem como alcan¸car uma eficiˆencia energ´etica e escalabilidade.

contribui para a escalabilidade da rede, al´em de permitir uma eficiˆencia energ´etica. Na ocorrˆencia de falhas, o protocolo foi definido de maneira a assegurar a comu- nica¸c˜ao entre os restantes N´os da rede. Para tal, ´e necess´ario que existam v´arias possibilidades para a transmiss˜ao de dados. ´E de elevada importˆancia sustentar as funcionalidades da rede sem qualquer interrup¸c˜ao devido `as falhas.

Para que os diferentes N´os possam estar sincronizados relativamente aos modos de opera¸c˜ao de r´adio, estes efetuam um pedido de hora (RequestHora). Os N´os Sensores e os N´os Retransmissores enviam uma frame RequestHora, por broadcast, e o N´o Sink envia uma frame com a hora (SendHora), por broadcast, como mostra a Fig. 3.11. Deste modo, todos os N´os possuem a mesma hora, estando assim sincronizados. Na situa¸c˜ao de um N´o n˜ao receber a hora, passado um tempo definido retransmite o pedido de hora. Tanto o N´o Sink como os N´os Retransmissores podem enviar a hora. Os N´os Retransmissores s´o podem responder ao RequestHora caso j´a tenham recebido a hora enviada pelo N´o Sink.

Figura 3.11 – Sincroniza¸c˜ao dos N´os.

Depois de receberem a hora, os N´os Retransmissores efetuam o pedido de liga¸c˜ao ao N´o Sink como mostra a Fig. 3.12.

Figura 3.12 – Pedido de liga¸c˜ao ao N´o Sink.

SendRequestSink. Envia este pedido inicialmente para ter conhecimento se o Sink est´a ou n˜ao ao seu alcance. Se o Sink responder ao pedido, o Retransmissor guarda o seu endere¸co MAC possuindo assim o caminho para o N´o Sink . Caso n˜ao obtenha resposta do N´o Sink, o N´o Retransmissor efetua um pedido de liga¸c˜ao, atrav´es de uma frame NewR a um N´o Retransmissor como mostra a Fig. 3.13.

Figura 3.13 – Caminho para o N´o Sink.

• (1) - Os Retransmissores enviam o pedido de liga¸c˜ao, atrav´es de uma frame, SendRequestSink, por broadcast;

• (2) - O N´o Sink recebe apenas um pedido de liga¸c˜ao e responde, atrav´es uma frame, SendResponseR, por unicast;

• (3) - Ocorre um timeout no N´o que n˜ao obteve resposta do Sink ;

• (4) - Ap´os o timeout, desencadeia mecanismos de retransmiss˜ao do pedido de liga¸c˜ao ao Sink ;

• (5) - Como o N´o Retransmissor continua sem obter resposta, ocorre um time- out;

• (6) - Ap´os o timeout, efetua o pedido de liga¸c˜ao ao N´o Retransmissor, atrav´es de uma frame, NewR, por broadcast;

• (7) - O Retransmissor que recebe a frame reconhece que ´e um pedido de liga¸c˜ao de um Retransmissor que n˜ao tem conhecimento do caminho para o Sink e responde ao pedido de liga¸c˜ao, por unicast.

Como o objetivo ´e a entrega dos dados ao N´o Sink, ´e importante que os N´os Retrans- missores conhe¸cam o caminho para posteriormente enviarem os dados. De modo a salvaguardar a energia dos N´os, o N´o Retransmissor que n˜ao possui o caminho para o Sink envia a frame NewR no qual os N´os Retransmissores que possuem o caminho para o Sink respondem e o N´o seleciona o Retransmissor com maior RSSI. A Fig.

3.14 demonstra a situa¸c˜ao na qual recebe resposta de dois Retransmissores.

Figura 3.14 – Caminho alternativo para enviar os dados ao Sink.

• (1) - O Retransmissor que n˜ao possui o caminho para o Sink envia um pedido de liga¸c˜ao, atrav´es de uma frame, NewR, por broadcast;

• (2) - Os N´os Retransmissores que possuem o caminho para o Sink respondem, atrav´es de uma frame, por unicast;

• (3) - Nas frames recebidas est´a contido o valor RSSI de cada transmiss˜ao. O N´o compara os valores de RSSI e guarda o endere¸co MAC do Retransmissor que tiver maior RSSI.

O N´o Retransmissor depois de escolher o Retransmissor com maior RSSI, guarda o endere¸co MAC para posteriormente enviar os dados.

Quando possuem um caminho para a entrega dos dados, os N´os Retransmissores enviam um pedido de dados como mostra a Fig. 3.15.

Figura 3.15 – Pedido de dados.

• (1) - O N´o Retransmissor efetua o pedido de dados, atrav´es de uma frame, RequestData, por broadcast;

• (2) - Os N´o Sensor envia os dados, atrav´es de uma frame, SendData, por unicast;

O N´o Sensor ao receber o pedido envia os dados ao Retransmissor e guarda o en- dere¸co MAC. A Fig. 3.16demonstra a situa¸c˜ao na qual dois Retransmissores efetuam o pedido de dados.

Figura 3.16 – Sele¸c˜ao de Retransmissor para envio dos dados.

• (2) - O N´o Sensor ao receber as frames que correspondem ao pedido de dados, obt´em o valor RSSI de cada transmiss˜ao. Atrav´es deste valor, o N´o seleciona o Retransmissor que possui maior RSSI para enviar os dados. Com isto, h´a uma conserva¸c˜ao de energia.

A comunica¸c˜ao e a transmiss˜ao de dados da Fig. 3.16 ocorre sem qualquer tipo de problema. Por´em, por qualquer motivo, os N´os Retransmissores podem enviar o pedido de dados e o N´o Sensor n˜ao receber os pedidos. Neste caso, como mostra a Fig. 3.17, o N´o Sensor passado um tempo pr´e-estabelecido transmite um pedido de liga¸c˜ao para posteriormente enviar os dados.

• (1) - Os N´os Retransmissores efetuam o pedido de dados, atrav´es de uma frame, RequestData, por broadcast;

• (2) - Como o N´o Sensor n˜ao recebe nenhum pedido, ocorre um timeout; • (3) - Ap´os o timeout, o N´o Sensor efetua um pedido de liga¸c˜ao, atrav´es de uma

frame, SendRequestR, por broadcast;

• (4) - Os Retransmissores recebem o pedido de liga¸c˜ao e enviam a resposta ao pedido SendResponseS, por unicast;

• (5) - O N´o Sensor escolhe o N´o Retransmissor com maior RSSI para enviar os dados e guarda o endere¸co MAC.

De modo a todos os dados sejam enviados, como mostra a Fig. 3.18, o N´o Retrans- missor envia ao N´o Sensor a confirma¸c˜ao de rece¸c˜ao dos dados.

Figura 3.18 – Confirma¸c˜ao da rece¸c˜ao de dados.

• (1) - O N´o Sensor envia os dados ao Retransmissor selecionado;

• (2) - O N´o Retransmissor envia um Acknowledgement como confirma¸c˜ao da rece¸c˜ao de dados.

A frame enviada pelo N´o Retransmissor cont´em n˜ao s´o o Acknowledgement como tamb´em o RSSI.

Atrav´es da frame recebida do N´o Retransmissor, o N´o Sensor recebe a confirma¸c˜ao de rece¸c˜ao e tem conhecimento do valor do RSSI, Fig. 3.19.

Figura 3.19 – Utiliza¸c˜ao de comandos AT.

• (1) - O N´o Sensor envia uma frame com os dados;

• (2) - O N´o Retransmissor responde com uma frame que cont´em o ACK e o valor do RSSI;

O N´o Sensor ao receber a frame, recebe a confirma¸c˜ao de rece¸c˜ao dos dados, verifica o RSSI recebido e compara-o com outros valores. Consoante o valor do RSSI, o N´o Sensor altera a potˆencia de transmiss˜ao atrav´es da execu¸c˜ao do comando ATPL. A utiliza¸c˜ao de comandos AT, neste caso a utiliza¸c˜ao do comando ATPL (Power Level) permite a sele¸c˜ao/leitura do n´ıvel de potˆencia que o m´odulo de RF transmite a potˆencia conduzida. Este tem como objetivo alterar os n´ıveis de potˆencia, para n´ıveis mais adequados. Com isto, ´e poss´ıvel conservar energia. Para a execu¸c˜ao do comando ATPL ´e necess´ario definir os parˆametros que desejamos alterar. A Fig.

3.20 apresenta os parˆametros dispon´ıveis.

O envio do Acknowledgement por parte do Retransmissor assegura a entrega dos dados. A Fig. 3.21 demonstra a situa¸c˜ao na qual os dados n˜ao alcan¸cam o N´o Retransmissor.

Figura 3.20 – Comando ATPL, [23].

Figura 3.21 – Retransmiss˜ao de dados.

motivo os dados n˜ao chegam ao destino;

• (2) - Como a confirma¸c˜ao (ACK) n˜ao ´e recebida, ocorre um timeout; • (3) - Ap´os o timeout, o N´o Sensor retransmite os dados;

• (4) - O N´o Retransmissor recebe os dados e envia um ACK.

A retransmiss˜ao de dados ocorre quando o N´o Sensor n˜ao recebe o Acknowledgement. O N´o envia os dados, caso n˜ao receba a confirma¸c˜ao, retransmite os dados. Espera um certo per´ıodo de tempo pela confirma¸c˜ao de rece¸c˜ao. Na situa¸c˜ao de n˜ao voltar a receber o ACK retransmite pela ´ultima vez os dados. Se n˜ao obtiver qualquer resposta do Retransmissor, assume que este est´a inativo e transmite um novo pedido de liga¸c˜ao (SendRequestR) para posteriormente enviar os dados.

Para que os dados alcancem o destino, o N´o Retransmissor tem de encaminhar os dados provenientes do N´o Sensor. Este pode enviar os dados diretamente para o

Sink, caso este tenha respondido ao pedido de liga¸c˜ao, ou pode enviar para um N´o Retransmissor caso n˜ao saiba o caminho para o Sink.

A Fig. 3.22 demonstra a situa¸c˜ao em que o Retransmissor envia os dados ao Sink. Como o Sink anteriormente respondeu ao pedido de liga¸c˜ao e o N´o guardou o en- dere¸co MAC, envia os dados.

Figura 3.22 – Envio dos dados ao Sink.

• (1) - O N´o Retransmissor envia os dados ao Sink, por unicast;

• (2) - O Sink recebe os dados e envia a confirma¸c˜ao de rece¸c˜ao, por unicast. A Fig. 3.23 exemplifica a situa¸c˜ao em que o Retransmissor envia os dados ao Sink e por qualquer motivo estes n˜ao s˜ao entregues.

Figura 3.23 – Retransmiss˜ao de dados ao Sink.

• (1) - O N´o Retransmissor envia os dados ao Sink. Por qualquer motivo estes n˜ao s˜ao entregues;

• (2) - Como a confirma¸c˜ao (ACK) n˜ao ´e recebida, ocorre um timeout; • (3) - Ap´os o timeout, retransmite os dados;

• (4) - O Sink recebe os dados e envia a confirma¸c˜ao de rece¸c˜ao.

Na situa¸c˜ao de o Retransmissor n˜ao possuir o caminho para o Sink, necessita de enviar os dados ao Retransmissor selecionado anteriomente, que conhece o caminho para o Sink. Como j´a tem o endere¸co MAC do Retransmissor selecionado envia os dados, Fig. 3.24.

Figura 3.24 – Envio dos dados a Retransmissor que conhece o caminho para o Sink.

• (1) - O N´o Retransmissor envia os dados ao Retransmissor selecionado ante- riormente, por unicast;

• (2) - O Retransmissor recebe os dados e envia a confirma¸c˜ao de rece¸c˜ao, por unicast.

A Fig. 3.25 exemplifica a situa¸c˜ao em que o Retransmissor envia os dados ao Re- transmissor selecionado anteriormente e por qualquer motivo estes n˜ao s˜ao entregues.

• (1) - O N´o Retransmissor envia os dados ao Retransmissor selecionado ante- riormente. Por qualquer motivo estes n˜ao s˜ao entregues;

Figura 3.25– Retransmiss˜ao de dados a Retransmissor que conhece o caminho para o Sink.

• (3) - Ap´os o timeout, retransmite os dados;

• (4) - O Retransmissor recebe os dados e envia a confirma¸c˜ao de rece¸c˜ao.

Do mesmo modo que o N´o Sensor, o N´o Retransmissor envia os dados, caso n˜ao receba a confirma¸c˜ao, retransmite os dados. Espera uma certo per´ıodo de tempo pela confirma¸c˜ao de rece¸c˜ao. Na situa¸c˜ao de n˜ao voltar a receber o ACK retransmite pela ´

ultima vez os dados. Se n˜ao obtiver qualquer resposta do Retransmissor, assume que este est´a inativo e transmite um novo pedido de liga¸c˜ao (NewR) para posteriormente enviar os dados.

O ciclo de opera¸c˜ao dos N´os corresponde a per´ıodos de tempos fixos, ativo (listen) e repouso (sleep). O per´ıodo de tempo em que os N´os se encontram no estado ativo ´e suficiente para que se possam realizar todas as comunica¸c˜oes e transmiss˜oes de dados. Atrav´es de temporizadores foi definido o tempo que os N´os permanecem no estado ativo e no estado de repouso. Com isto e atrav´es do envio da hora pelo N´o Sink, os N´os ficam sincronizados e permanecem o mesmo tempo no estado ativo e no estado de repouso.

Os N´os inicialmente est˜ao no estado ativo, neste estado s˜ao realizadas as comu- nica¸c˜oes e a transmiss˜ao de dados. Ap´os o t´ermino do temporizador do estado ativo, os N´os entram no estado de repouso, exceto o N´o Sink que permanece sempre no estado ativo. No estado de repouso, os N´os ficam inativos, desligam o transceiver ficando apenas ativo o temporizador que, ap´os o seu t´ermino, possibilita a mudan¸ca

para o estado ativo novamente.

Ao entrarem no estado ativo, para ficarem sincronizados efetuam o pedido de hora ao Sink (Fig. 3.11). Ap´os o recebimento de hora, o pedido de liga¸c˜ao toma lugar (Fig. 3.12). Deste modo, pol´ıticas Reactive s˜ao utilizadas, no qual se procede ao descobrimento de rotas. Os N´os Retransmissores efetuam sempre o pedido de liga¸c˜ao ao N´o Sink, caso n˜ao obtenham resposta, efetuam o pedido a outro N´o Retransmissor (Fig. 3.14 ) e selecionam o Retransmissor que possuir maior RSSI para posteriormente enviarem os dados. Para que os dados sejam entregues ao N´o Sink os N´os Retransmissores necessitam de efetuar o pedido de dados (Fig. 3.15). Depois de selecionado o Retransmissor, o N´o Sensor envia os dados (Fig. 3.16). Quando os Retransmissores possuem os dados, ou enviam-nos para o N´o Sink (Fig.

3.22) caso este tenha respondido ao pedido de liga¸c˜ao anteriormenente, ou enviam- nos para o Retransmissor que conhece o caminho para o Sink e que foi selecionado anteriormenente (Fig. 3.24). Ao receber os dados do Retransmissor, este necessita de os enviar ao N´o Sink.

Posteriormente os N´os entram no estado de repouso e passado um tempo pr´e-definido voltam ao estado ativo onde o processo referido anteriormente se repete, exceto o comportamento dos N´os Retransmissores e dos N´os Sensores. Na situa¸c˜ao de o N´o Retransmissor continuar sem ter o caminho para o Sink este n˜ao volta a fazer o pedido de liga¸c˜ao a Retransmissores. Como tem o endere¸co MAC do Retransmissor para o qual enviou os dados anteriormente envia os novos dados sem fazer o pedido de liga¸c˜ao, pois sabe que aquele Retransmissor conhece o caminho para o Sink. Como os N´os Sensores tˆem o endere¸co MAC do Retransmissor para o qual enviaram os dados anteriormente n˜ao esperam pelo pedido de dados, enviam-nos ao Retransmissor selecionado sem esperarem pelo pedido de dados e sem fazerem um pedido de liga¸c˜ao. Deste modo, pol´ıticas Proactive s˜ao utilizadas, pois o N´o sabe a quem enviar os dados sem efetuar o pedido de rota.