UNIVERSIDADEFEDERAL DORIOGRANDE DO NORTE CENTRO DETECNOLOGIA
PROGRAMA DEPÓS-GRADUAÇÃO EMENGENHARIAELÉTRICA
Análise de Desempenho Baseada em Simulação
de Redes WirelessHART
Marcelo Henrique Ramalho Nobre
Orientador: Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira
Dissertação de Mestrado apresentada ao
Programa de Pós-Graduação em Engenharia Elétrica e Computação da UFRN como parte dos requisitos para obtenção do título de Mestre em Ciências.
Nobre, Marcelo Henrique Ramalho.
Análise de desempenho baseada em simulação de redes WirelessHART. – Natal, RN, 2011.
71f. ; il.
Orientador:Luiz Affonso Henderson Guedes de Oliveira.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Cen-tro de Tecnologia. Programa de Pós-Graduação em Engenharia Elétrica.
1. Redes sem fio – Dissertação. 2. Simulação – Dissertação. 3. Wire-lessHART – Dissertação. 4. Network Simulator 3 – Dissertação. I. Oliveira, Luiz Affonso Henderson Guedes de. II. Universidade Federal do Rio Grande do Norte. III. Título.
Análise de Desempenho Baseada em Simulação
de Redes WirelessHART
Marcelo Henrique Ramalho Nobre
Dissertação de Mestrado aprovada em 5 de agosto de 2011 pela banca examinadora com-posta pelos seguintes membros:
Prof. Dr. Luiz Affonso H. Guedes de Oliveira (orientador) . . . DCA/UFRN
Prof. Dr. Jorge Dantas de Melo . . . DCA/UFRN
Agradecimentos
A minha família pelo apoio durante o curso. Em especial aos meus pais e aos meus irmãos.
Ao meu orientador Affonso.
Aos meus companheiros de laboratório Daniel Gouveia e Ivanovitch Silva.
A todo os colegas do LAUT.
Esta dissertação descreve a implementação de um módulo de simulação para redes WirelessHART, utilizando o simulador de redes Network Simulator 3, tendo em vista a aceitação que ambos possuem no atual contexto de pesquisa e na indústria. Para vali-dação do módulo foram implementados testes quanto a atenuação dos sinais transmitidos, probabilidade de perda pacotes (Packet Error Rate – PER), probabilidade de que uma informação produzida seja recebida no destino e duração da bateria nas estações.
Abstract
This dissertation describes the implementation of a WirelessHART networks simula-tion module for the Network Simulator 3, aiming for the acceptance of both on the present context of networks research and industry. For validating the module were imeplemented tests for attenuation, packet error rate, information transfer success rate and battery dura-tion per stadura-tion.
Sumário i
Lista de Figuras iii
Lista de Tabelas v
Lista de Abreviaturas vii
1 Introdução 1
1.1 Objetivo . . . 2
1.1.1 Objetivos Gerais . . . 2
1.1.2 Objetivos Específicos . . . 2
1.2 Estado da Arte . . . 2
1.3 Justificativa e Validação . . . 3
1.4 Estrutura do trabalho . . . 3
2 WirelessHART: Visão Geral e Camadas Inferiores 5 2.1 Histórico e escopo de utilização . . . 5
2.2 Camada Física . . . 9
2.2.1 DSSS e FHSS . . . 10
2.3 Camada de Enlace . . . 11
2.3.1 O quadro da Camada de Enlace - DLPDU . . . 13
2.3.2 Superframe . . . 15
2.3.3 Slots de tempo, links e canais . . . . 17
2.3.4 Máquinas de Estado da Camada de Enlace . . . 22
2.3.5 Escalonamento . . . 30
3 WirelessHART: Camadas Superiores 37 3.1 Camadas Superiores . . . 37
3.1.1 Camada de Rede e Transporte . . . 37
3.1.2 Roteamento . . . 38
3.2 Camada de Aplicação . . . 40
3.3 Dispositivos . . . 40
3.3.1 Dispositivo de Campo (Field Device) . . . . 42
3.3.2 Adapter . . . 42
3.3.3 Roteadores . . . 42
3.3.4 Handhelds . . . 42
3.3.5 Gateway . . . 43
3.3.6 Ponto de Acesso (Access Point) . . . . 44
3.3.7 Network Manager . . . 45
4 Módulo de Simulação para o NS-3 49 4.1 Network Simulator 3 . . . 49
4.1.1 Node . . . 50
4.1.2 Aplicações . . . 50
4.1.3 Canais . . . 51
4.1.4 Dispositivo de Rede . . . 51
4.1.5 Topology Helpers . . . 51
4.2 Arquitetura Implementada do Módulo WirelessHART para o NS-3 . . . . 52
4.2.1 Camada Física . . . 53
4.2.2 Canal . . . 54
4.2.3 Modelo de Erro . . . 54
4.2.4 Modelo de Propagação . . . 55
5 Resultados 57 5.1 Metodologia . . . 57
5.2 Resultados . . . 58
5.2.1 Topologia Estrela . . . 60
5.2.2 Topologia Linear . . . 63
5.2.3 Topologia Cluster . . . . 64
6 Conclusões 69
2.1 Comparativo de alcance e taxa de transmissão das principais tecnologias
wireless para redes industriais. . . 6
2.2 Dispositivos WirelessHART. . . 7
2.3 Descrição do PDU WirelessHART. . . 8
2.4 Arquitetura do protocolo de comunicação HART. . . 9
2.5 Comparativo entre os canais do WirelessHART e WiFi. . . 10
2.6 Utilização do FHSS e do DSSS no padrão WirelessHART. . . 11
2.7 Arquitetura da camada de Enlace do WirelessHART. . . 12
2.8 Quadro detalhado da camada de enlace do WirelessHART. . . 13
2.9 Detalhamento do campo Especificador de Endereço. . . 14
2.10 Estrutura de um endereço IEEE EUI-64. . . 14
2.11 Detalhamento do Especificador DLPDU. . . 15
2.12 Ciclo de um superframe simples de 3 slots. . . . 16
2.13 Relação entre múltiplos superframes. . . 16
2.14 Organização do tempo dentro de um slot. . . . 18
2.15 Organização das máquinas de estado da camada de enlace. . . 22
2.16 Máquina de estados TDMA. . . 23
2.17 Máquina de estados ACK. . . 27
2.18 Máquina de estados XMIT. . . 28
2.19 Máquina de estados RECV. . . 29
2.20 Topologia de exemplo para um único hop. . . . 33
2.21 Escalonamento para o exemplo de um único hop. . . . 34
2.22 Topologia de exemplo para um múltiplos hops. . . . 34
2.23 Escalonamento para o exemplo de múltip´los hops. . . . 35
3.1 Estrutura do TPDU e expansão do comando HART. . . 40
3.2 Pilha de Comunicação WirelessHART. . . 41
3.3 Organização de uma rede com um único ponto de acesso. . . 44
3.4 Organização de uma rede com mais de um ponto de acesso e ambos fornecendo clock para a rede. . . . 45
3.5 Organização de uma rede com mais de um ponto de acesso mas nem todos fornecendo clock para a rede. . . . 45
3.6 Organização do Network Manager na topologia da rede. . . 46
4.1 Diagrama de Classe da camada física do WirelessHART. . . 52
4.2 Modelo de energia . . . 54
4.3 Modelo de erro de Gilbert/Elliot. . . 55
5.1 Potência recebida X Distância. . . 59 5.2 PER para pacotes WirelessHart. . . 59 5.3 Topologia em estrela. . . 60 5.4 Probablidade de sucesso na transmissão de pacotes da fonte ao gateway
na topologia estrela. . . 61
5.5 Ackloss e PathLoss para a topologia estrela. . . . 61
5.6 Duração da bateria nas estações com probabilidades Jie e Fantacci. . . 62 5.7 Duração da bateria nas estações com probabilidades Willig Máx. e Willig
Min. . . 62 5.8 Topologia Linear. . . 63 5.9 Probablidade de sucesso na transmissão de pacotes da fonte ao gateway
na topologia linear. . . 63 5.10 Duração da bateria nas estações com probabilidades Jie e Fantacci. . . 64 5.11 Duração da bateria nas estações com probabilidades Willig Máx. e Willig
Min. . . 65 5.12 Topologia cluster. . . . 65 5.13 Probablidade de sucesso na transmissão de pacotes da fonte ao gateway
na topologia cluster. . . . 66 5.14 Duração da bateria nas estações com probabilidades Jie e Fantacci. . . 66 5.15 Duração da bateria nas estações com probabilidades Willig Máx. e Willig
2.1 Faixa de valores do Network ID e suas respectivas aplicações. . . 14
2.2 Faixa de valores do Network ID e suas respectivas aplicações. . . 19
2.3 Requisitos de escalonamento. . . 31
3.1 Requisitos de roteamento. . . 39
3.2 Funções do Network Manager. . . 47
5.1 Valores de probabilidade de erro utlizadas nas simulações. . . 58
Lista de Abreviaturas
ACK Acknowledge
ASN Absolute Slot Number
BER Bit Error Rate
CCA Clear Channel Assessment
CRC Cyclic Redundancy Check
DLPDU Data-Link Protocol Data Unit
DSSS Direct Sequence Spread Spectrum
EIRP Equivalent isotropically radiated power
FHSS Frequency Hop Spread Spectrum
ISM Industrial, Scientific and Medical
LLC Logical Link Control
MAC Medium Access Control
MIC Message Integrity Code
NIC Network Interface Cards
NS-3 Network Simulator 2
NS-3 Network Simulator 3
O-QPSK Offset Quadrature Phase-Shift Keying
OTCL Object Oriented Tool Command Language
OUI Organizationally Unique Identifier
PAN Personal Area Networks
PDU Process Data Unit
PER Packet Error Rate
SFD Start of Frame Delimiter
SOM Start of the Message
TclCl Tcl with Classes
TCP Transmission Control Protocol
TDMA Time Division Multiple Access
Capítulo 1
Introdução
Com o desenvolvimento tecnológico e consequente diminuição de custos da tecnolo-gia de comunicação sem fios, houve um aumento na preferência para que este tipo de tecnologia seja utilizada por questões tais como: economia de matéria prima dos cabos, inconveniência da presença dos cabos e a necessidade de modificar infraestruturas já ex-istentes (por exemplo, prédios históricos).
A indústria, visando estes benefícios, mostra uma tendência a implantação das redes sem fio em suas plantas. As redes para troca de informações no processo produtivo ob-tiveram um êxito notável em termos de melhora na produção e no controle desta, sendo atualmente predominantes os meios cabeados de transmissão. Isto se dá principalmente devido as características de segurança, latência e confiabilidade providos por essa tecnolo-gia cabeada. Logo uma tecnolotecnolo-gia sem fio, para ser utilizada em ambiente industrial deve atender estes mesmos requisitos. Portanto aplicações e tecnologias para redes industriais sem fio se mostram um campo fértil para a pesquisa.
Para o desenvolvimento destas tecnologias e aplicações existem duas possibilidades (que podem também ser usadas em conjunto): testes experimentais (testbeds) e simu-lação. Nos testes experimentais a infraestrutura da rede a ser avaliada é montada com componentes reais e seu desempenho medido. Embora possua os resultados mais pre-cisos, a montagem do testbed pode ser custosa tanta financeiramente quanto em termos de esforço de montagem e configuração, sendo agravado mais pelo aumento nas escala dos testes. Já simulação, embora produza resultados menos acurados quando compara-dos aos resultacompara-dos do teste experimental, pode ser realizada com menos recursos e ser facilmente escalada, o que consumiria apenas poder de processamento.
1.1
Objetivo
1.1.1
Objetivos Gerais
O objetivo deste trabalho é o desenvolvimento e validação do simulador das camadas física e de enlace do protocolo WirelessHART no simulador Network Simulator 3, de modo que este trabalho sirva de base para a implementação completa do módulo.
1.1.2
Objetivos Específicos
As metas para alcançar o êxito nesse trabalho são enumeradas a seguir.
• Projetar um módulo de simulação para o simulador NS-3;
• Implementar as características do canal de transmissão;
• Implementar as funcionalidades da camada física do WirelessHART;
• Implementar o modelo de erro pertinente para a plataforma de simulação NS-3.
1.2
Estado da Arte
Na literatura encontramos vários trabalhos que lidam com simulação do protocolo WirelessHART. Nesta seção destacaremos e analisaremos brevemente alguns deles que foram relevantes para este trabalho.
Mauro De Biasi e colaboradores em [De Biasi et al. 2008] e [Biasi 2008] produziram um simulador WirelessHART aplicado a sistemas de controle em redes. Isso foi realizado se estendendo o simulador TrueTime da ferramenta Simulink do software Matlab. O pro-tocolo MAC do WirelessHART foi implementado utilizando-se de classes C++ com suas correspondentes MATLAB MEX-interfaces. A utilização de classes C++ foi escolhida visando uma melhora na velocidade da simulação. Em [De Biasi et al. 2008] especifica-mente, o autor também faz um comparativo entre o desempenho de redes WirelessHART e redes ZigBee. Os testes foram realizados com um número fixo de pacotes perdidos. Embora o pacote esteja disponível para download o seu código não é aberto para a comu-nidade.
Kunjesh Shah [Shah et al. 2010] e colaboradores desenvolveram um simulador que, a partir da inserção de um conjunto de características dos dispositivos e dos tempos de processamento e comunicação destes, fornece uma verificação das situações de conflito na rede e incompletude do projeto. Esse simulador também foi implementado utilizando o simulador TrueTime da ferramenta Simulink do software Matlab. O simulador não foca na camada física e de rádio não implementando ruídos ou comunicação multi hop além de que a comunicação se dá apenas utilizando um canal.
1.3. JUSTIFICATIVA E VALIDAÇÃO 3
interferência se dá por um elemento comum chamado Interference Module. O erro é im-plementado a partir da coincidência de transmissões entre as redes envolvidas. A partir disso calcula-se a probabilidade de erro do pacote com base na intensidade dos sinais envolvidos.
Os trabalhos supracitados foram relevantes para o desenvolvimento deste trabalho por mostrar as possibilidades já exploradas neste tópico de pesquisa na simulação de redes.
1.3
Justificativa e Validação
O trabalho é justificado pela ausência de simuladores do WirelessHART em código aberto, embora este seja a tendência de uso nos ambientes industriais atualmente.
Os motivos para a utilização do NS-3 são: o melhor desempenho deste simulador apontado em [Weingartner & Wehrle 2009], o fato de que o NS-3 é o sucessor do NS-2 (sendo o NS-2 o padrão de aceitação em simuladores de redes) e pelo WirelessHART está sendo amplamente aceito como padrão de solução sem fio na indústria. Existe também o fato de que as implementações do WirelessHART em outros simuladores de redes ex-istentes são softwares proprietários ou não têm seus códigos fonte divulgados, enquanto nosso módulo será construído sobre a licença GNU GPLv2 do NS-3 e o código estará disponível para toda a comunidade.
Para validar o módulo WirelessHART desenvolvido no NS-3 foram realizados testes quanto a atenuação dos sinais transmitidos, probabilidade de perda pacotes (Packet Error
Rate – PER), probabilidade de que uma informação produzida seja recebida no destino
correto e duração da bateria nas estações. Cada um destes testes foi realizado em três topologias tipicamente encontradas em aplicações industriais, que seriam as topologias estrela, linear e cluster. Tais topologias serão melhor explicadas nos capítulos posteriores.
1.4
Estrutura do trabalho
Capítulo 2
WirelessHART: Visão Geral e Camadas
Inferiores
Este capítulo se destina a descrever os aspectos mais relevantes da tecnologia Wire-lessHART e que estejam associados aos desenvolvimentos desta dissertação. Assim, iremos abordar os seguintes aspectos: um breve histórico do WirelessHART e seu es-copo de utilização; uma vista mais aprofundada sobre as camadas físicas e de enlace do padrão, uma vez que estas serão mais utilizadas na implementação proposta. O Capítulo 3 mostrará uma visão sobre os elementos das camadas superiores mais relevantes para esta dissertação e uma descrição mais detalhada sobre os dispositivos que compõem a arquitetura do protocolo WirelessHART.
2.1
Histórico e escopo de utilização
A comunicação sem fio é um dos focos da pesquisa em redes industriais atualmente. Uma variedade de protocolos podem ser usados nesse ambiente: Bluetooth, WirelessHART, ZigBee, Wifi e o ISA 100.11a. Desses padrões, o ZigBee, o Bluetooth e o Wifi apresen-tam características que dificulapresen-tam o seu uso em ambientes industriais. Segundo [Song et al. 2008], o Wifi não suporta o salto entre canais e é limitado por seu consumo energé-tico. O Bluetooth é limitado por sua baixa escalabilidade e limitação topológica (podem ser interligados apenas oito dispositivos por rede em uma topologia estrela). Por fim, os dispositivos ZigBee dividem o mesmo canal e não existe a possibilidade do salto de fre-qüência, o que os torna mais vulneráveis a ruídos persistentes, como o ruído gerado por máquinas elétricas. Entretanto, o padrão WirelessHART foi desenvolvido objetivando o ambiente industrial, com foco na aplicação em medição e controle de processos. O WirelessHART e o ISA 100 são os padrões atuais da indústria e ambos utilizam o IEEE 802.15.4 na camada física. Um comparativo entres as principais tecnologias de transmis-são sem fios pode ser visto na Figura 2.1. Devemos salientar que apenas a especificação 802.11n da tecnologia WiFi possui taxa de transmissão maior que o WiMax
funcionali-Figura 2.1: Comparativo de alcance e taxa de transmissão das principais tecnologias wire-less para redes industriais.
dades, para comunicações com ou sem fios, que incluem transmissões de dados sem so-licitação, notificação de eventos, modos de transferência de dados em bloco, segurança e diagnósticos avançados. Tais diagnósticos incluem informações sobre o dispositivo, sobre o equipamento ao qual o dispositivo está atrelado e até mesmo informações do processo monitorado.
As versões mais recentes do HART (Versão 7) apresentam, entre outras característi-cas, uma inovação no sentido de implementar redes sem fio em malha através do novo protocolo de comunicação: o WirelessHART. Como na sua contrapartida cabeada, o WirelessHART tem por objetivo a comunicação com sensores e atuadores fixos, entre-tanto objetiva também equipamentos com sensores em partes com movimentos giratórios e sistemas flexíveis de manufatura. O WirelessHART aceita sistemas legados (aplicações e equipamentos HART) e reduz os custos de instalação por ser sem fios.
IEEE-2.1. HISTÓRICO E ESCOPO DE UTILIZAÇÃO 7
802.15.4 e o FHSS (Frequency Hop Spread Spectrum) para o chavemento de canais pacote a pacote.
O WirelessHART dá suporte a um conjunto de dispositivos básicos que seriam(Figura 2.2):
• Dispositivos de campo (Field Devices): Dispositivos básicos que realizam função de sensores ou atuadores.
• Roteadores (Routers): Servem para encaminhar os pacotes que trafegam na rede.
• Adaptadores (Adapters): Conectam um dispositivo HART legado (cabeado) à rede sem fio
• Handheld: dispositivos móveis utilizados por usuários.
• Pontos de Acesso (Access Points): Conectam dispositivos de campo ao Gateway.
• Gateway: Funciona como um intermediário com a aplicação (pode haver redundân-cia).
• Network Manager: Gerencia o escalonamento por divisão de tempo da rede (pode haver redundância).
Figura 2.2: Dispositivos WirelessHART.
A grande maioria das transmissões são direcionadas por algoritmos de rotas em grafos. O escalonamento é realizado de forma centralizada pelo Network Manager, baseado nas informações de roteamento vindas de toda a rede juntamente com as necessidades de cada dispositivo e de cada aplicação. O escalonamento é subdividido em pequenos intevalos de tempo denominados slots e enviado a cada dispositivo pelo Network Manager. Cada dispositivo recebe slots de acordo com sua necessidade. O Network Manager é sensível a mudanças na topologia e na demanda de banda, realizando atualizações no grafo repre-sentativo da rede e no escalonamento dos slots.
Bytes
Figura 2.3: Descrição do PDU WirelessHART.
O PDU (Process Data Unit) do protocolo wirelessHART é mostrado em sua forma completa na Figura 2.3. Devido ao foco do trabalho, detalharemos apenas os quadros da camada física e de enlace nas próximas sessões. Podemos ressaltar também que o tamanho máximo de um PDU WirelessHART é de 133 bytes.
2.2. CAMADA FÍSICA 9
Figura 2.4: Arquitetura do protocolo de comunicação HART.
Como apresentado, o WirelessHART abrange as camadas física, de enlace, de rede, de transporte e de aplicação. O funcionamento do protocolo em cada uma delas é explicado a seguir.
2.2
Camada Física
A camada Física do WirelessHART é baseada na camada física do IEEE 802.15.4-2006 2.4GHz DSSS [IEC 62591: Industrial communication networks - Wireless
commu-nication network and commucommu-nications profiles - WirelessHART 2010], tal norma define
características do rádio, métodos de troca de sinais, sensibilidade do dispositivo e a in-tensidade do sinal transmitido. A camada física do WirelessHART é um subconjunto simplificado do que é definido pelo IEEE 802.15.4-2006 com algumas modificações ou restrições. Para todo dispositivo WirelessHART:
• Só existe uma ou duas mensagens IEEE 802.15.4 por slot de tempo de 10ms (men-sagens em broadcast não têm confirmação).
• O tempo mais curto ente entre duas mensagens em um mesmo slot de tempo é de 1ms, do final da mensagem para o início da transmissão da confirmação(ACK).
• Todas as mensagens WirelessHART são mensagens IEEE 802.15.4 do tipo dados.
• Apenas a frequência de 2.4GHz é utilizada (faixa ISM de 2400-2483.5MHz).
• Apenas os canais de 11 ao 25 (numeração de canais do IEEE802.15.4 [Society 2006]) podem ser utilizados pelo padrão WirelessHART. O canal 26 não é utilizado por ser ilegal em vários locais.
• Há um espaçamento de 5Mhz entre canais adjacentes.
• A sua taxa de transmissão é de até 250 kbits/s.
• Utiliza modulação O-QPSK (Offset Quadrature Phase-Shift Keying).
As duas diferenças entre as camadas físicas do IEEE 802.15.4 e do WirelessHART seriam: No WirelessHART o canal físico é mudado a cada transmissão e que o alcance do WirelessHART é maior que o alcance do IEEE 802.15.4. O IEEE 802.15.4 é aplicado a PAN’s (Personal Area Networks) com espaço de operação de 10m, enquanto o alcance máximo do WirelessHART em ambiente aberto com visada direta pode ser de 100m. Todos os dispositivos devem manter um EIRP (Equivalent isotropically radiated power) de +10dBm (10mW)±3dB.
Uma das principais preocupações quanto à utilização do WirelessHART seria sua co-existência com as rede WiFi, uma vez que ambas as tecnologias trabalham na faixa fre-quência de 2.4Ghz [Bello & Toscano 2009]. A Figura 2.5 demonstra como se sobrepõem os canais do IEEE 802.15.4 (os utilizados pelo WirelessHART) e os canais da tecnologia WiFi (estão dispostos apenas os canais WiFi que não interferem entre si, no caso os canais 1, 6 e 11).
Figura 2.5: Comparativo entre os canais do WirelessHART e WiFi.
2.2.1
DSSS e FHSS
O padrão de modulação WirelessHART utiliza tanto o DSSS (Direct Sequence Spread
Spectrum) quanto o FHSS (Frequency Hopping Spread Spectrum) mas em níveis
difer-entes. O DSSS é aplicado para cada mensagem transmitida enquanto o FHSS é aplicado na sequência de slots de tempo, como ilustrado na Figura 2.6.
2.3. CAMADA DE ENLACE 11
Figura 2.6: Utilização do FHSS e do DSSS no padrão WirelessHART.
o DSSS, a transmissão se assemelha ao ruído branco para outros dispositivos. Podemos dizer que o WirelessHART não utiliza o DSSS sobre os 16 canais definidos, mas sim aplica o DSSS em cada canal, dividindo estes em subcanais, nos quais são espalhados os dados como mostrado na Figura 2.6 .
O FHSS não espalha a potência de transmissão dentre vários canais. Ao invés disso, o FHSS pseudo randomicamente seleciona apenas um canal dentre os vários canais disponíveis para a transmissão. O receptor salta entre os canais no mesmo padrão para que a comu-nicação seja efetuada. E assim como no DSSS, as políticas de redundância de dados impedem que a comunicação seja interrompida pela queda de apenas um canal.
O padrão WirelessHART utiliza o FHSS em um nível mais alto. Ao invés de haverem saltos entre canais a cada bit transmitido, o canal é modificado a cada mensagem. No caso, saltando a cada novo slot de tempo. O WirelessHART também utiliza um sistema de lista negra de canais (Channel Blacklisting), na qual são postos os canais notadamente ruidosos para que a utilização destes seja evitada nas próximas transmissões. A lista negra de canais é melhor explicado nas seções seguintes.
2.3
Camada de Enlace
A camada de enlace é responsável por fornecer meios confiáveis para a transmissão entre os diferentes dispositivos da rede, detectando e corrigindo possíveis erros que ven-ham a ocorrer na camada física e também por criar e gerenciar os quadros de dados [Chen et al. 2010]. Dentro desta camada são comumente definidas duas subcamadas: a Logical
Link Control (LLC) e a Medium Access Control (MAC). A subcamada LLC define os
serviços da camada de enlace enquanto a camada MAC define como o meio de transmis-são é acessado pelos diferentes dispositivos. A Figura 2.7 descreve a estrutura da camada de enlace, que consite em 6 módulos principais apresentados a seguir:
-Interfaces: A interface entre a camada MAC e física descreve o conjunto de serviços
providos pela camada física à camada MAC, e a interface entre a camada de rede e a camada MAC define os serviços fornecidos à camada de rede pela camada MAC.
funciona-Figura 2.7: Arquitetura da camada de Enlace do WirelessHART.
mento do sistema e , principalmente a marcação dos 10ms de cada slot de tempo.
-Tabelas de Comunicação: Cada dispositivo de rede mantém um conjunto de tabelas
na camada de enlace. A tabela de superframe e a tabela de links (explicadas em seções posteriores) armazenam configurações criadas pelo Network Manager. A tabela de Vizi-nhos mantém registros das estações vizinhas a um dispositivo e que podem ser alcançadas diretamente. E a tabela Graph é mantida para colaborar com a camada de rede e guardar informações sobre o roteamento de pacotes.
-Escalonador de Links: A funcionalidade do escalonador de links é a de determinar
o próximo slot de tempo que será realizado baseado na tabela do superframe e na tabela de links. O escalonador é influenciado por fatores diversos, tais como: as prioridades de transmissão, as mudanças nos links e a habilitação e desabilitação dos superframes, de modo que o Escalonador de links está em constante atualização.
-Módulo de Manuseio de Mensagens: O módulo separa em buffers diferentes os
pa-cotes da camada de rede e da camada física.
-Máquina de Estado: A máquina de estados na camada de enlace consiste de três
componentes primários: as máquinas de estados TDMA, XMIT e RECV. A máquina de estados do TDMA é responsável por executar a transação em um slot de tempo ajus-tando temporizador. As máquinas de estado XMIT e RECV lidam diretamente com os
hardwares de envio e recepção de sinais, respectivamente.
2.3. CAMADA DE ENLACE 13
tabelas explícitas como o padrão IEEE 802.15.4. Certos atributos podem ser implemen-tados na camada de enlace ou na camada de rede, especialmente os relacionados com o processo de entrada na rede. Alguns atributos podem ser acessados por ambas as camadas.
2.3.1
O quadro da Camada de Enlace - DLPDU
O quadro da camada de enlace, ou DLPDU (Data-Link Protocol Data Unit), contém todos os dados necessários para que o dispositivo envie, receba e trate pacotes em nível de camada de enlace. O seu tamanho máximo é de 133 bytes (cabeçalho mais dados). Os campos são detalhados na Figura 2.8 na sequência em que devem ser recebidos/enviados a camada de física para a transmissão.
Figura 2.8: Quadro detalhado da camada de enlace do WirelessHART.
O octeto 0x41 corresponde ao início de quadro de dados do IEEE 802.15.4. O campo Especificador de Endereços especifica o comprimento e o tipo de endereços de destino e origem como mostrado na Figura 2.9. O bits 6 e 2 desse campo especificam, respectiva-mente, se os endereços de origem e destino são endereços EUI-64 (8 octetos de tamanho) ou nicknames (endereços de 2 octetos, únicos a própria rede).
O campo Número de Sequência deve ter o mesmo valor de octeto menos significante do ASN (Absolute Slot Number)
Todas as redes WirelessHART são identificadas utilizando um número binário de 2 octetos Chamado Network ID. Os dispositivos conectados a uma rede não devem enviar pacotes diretamente para outros dispositivos em redes diferentes. O Network ID é trans-mitido em todos os DLPDUs e caso o número do dispositivo de destino não seja o do quadro, este deverá ser descartado. A faixa dos Network IDs é mostrada na Tabela 5.1 abaixo.
Figura 2.9: Detalhamento do campo Especificador de Endereço.
Tabela 2.1: Faixa de valores do Network ID e suas respectivas aplicações.
Faixa do Network ID Aplicação
00 000-32 767 (0x0000-0x7FFF) Redes Permanentes definadas por Usuário 32 768-36 863 (0x8000-0x8FFF) Redes Temporárias definadas por Usuários 36 864-57 343 (0x9000-0xDFFF) Reservado
57 344-61 439 (0xE000-0xEFFF) Redes de Desenvolvedores (não utilizadas pelo público) 61 440-65 535 (0xF000-0xFFFF) Reservado
identifica um tipo de dispositivo, e um ID de Dispositivo, que deve ser único entre todos os dispositivos de um determinado tipo.
2.3. CAMADA DE ENLACE 15
O especificador de DLPDU é mostrado em detalhes na Figura 2.11. Este especificador
Figura 2.11: Detalhamento do Especificador DLPDU.
define a prioridade do quadro, o tipo de chave de rede utilizado e o tipo do DLPDU. Algumas observações quanto a este campo seriam:
• Os bits 7 e 6 são reservados para uso futuro.
• As codificações não utilizadas do tipo do pacote são reservadas para uso futuro.
• O valor 0 da chave de rede é utilizado no processo de ingresso na rede.
O payload são os dados contidos no quadro. O Message Integrity Code (MIC) é utilizado para a autenticação do DLPDU recebido. E por fim, o campo CRC (Cyclic
Redundancy Check) que é utilizado para detectar erros em bits da transmissão. Maiores
informações sobre o MIC e o CRC podem ser encontradas em [Society 2006].
2.3.2
Superframe
baseado no seu tamanho, definido o seu período. Quando o superframe é criado, este é associado a um Graph_ID. O Network Manager utiliza esta associação para alocar slots de tempo e configurar links. O superframe é uma combinação dos canais e dos slots de tempo. O dispositivos determinam que link será usado em tempo de execução.
Figura 2.12: Ciclo de um superframe simples de 3 slots.
Cada nova instância de um superframe num determinado momento é chamada de ciclo do superframe. A Figura 2.12 mostra como os dispositivos se comunicariam em um superframe simples de 3 slots. No caso, o dispositivo A se comunica com o B no slot 0, o dispositivo B se comunica com o C no slot 1 e o slot 2 não é utilizado. O escalonamento se repete a cada 3 slots.
O tamanho dos superframes devem seguir uma cadeia harmônica, de modo que todos os períodos possa ser divididos entre si. Um exemplos de cadeias harmônicas seriam 1, 2, 4, 8, 16... e 3, 6, 12, 24... e também qualquer outro período que esteja de acordo com a expressão abnonde a e b são dois números constantes e n é um número natural qualquer.
Múltiplos superframes em uma rede
Uma rede WirelessHART pode conter vários superframes de diversos tamanhos dis-postos em paralelo no tempo. Múltiplos superframes podem ser utilizados para determinar como os diferentes grupos de dispositivos vão se comunicar ou para que a rede funcione com diferentes ciclos de trabalho. Superframes adicionais podem ser criados para atender a diferentes freqüências de transmissões, requisitos de publicação de dados, notificação de eventos e comandos da camada de aplicação. O tamanho do superframe deve ser maior que o número de canais ativos e modo que um link em um superframe tenha a chance uti-lizado em qualquer um dos canais ativos. Se o tamanho de um superframe é múltiplo do número de canais ativos, então um link utilizará sempre um mesmo canal físico.
2.3. CAMADA DE ENLACE 17
Um dispositivo de rede pode participar em mais de um superframe simultaneamente, mas nem todos os dispositivos devem participar em todos os superframes. Configurando um dispositivo para participar em múltiplos superframes de tamanhos diferentes e que se sobrepõem, possibilita estabelecer diferentes escalas de comunicação e matrizes de conectividade que funcionam simultaneamente.
Aplicações chaves, como sistemas de gerenciamento de ativos e aplicações específicas de dispositivos, geralmente requerem a transmissão de um volume de dados considerável durante curtos intervalos de tempo (medidos em minutos), que geralmente correspondem a chamadas de configuração, diagnósticos e respostas a requisições de usuários. Para que esta demanda seja suportada, superframes adicionais podem ser usados.
Superframes podem ser adicionados, removidos, ativados e desativados durante o fun-cionamento da rede. Como todos os superframes têm o mesmo tempo de início (ASN 0), o ciclo 0, slot 0 de todo superframe ocorre no início de uma época. A época para uma determinada rede é o tempo no qual o Network Manager inicializou a rede. Por causa disso, diferente slots de tempo em diferentes superframes estão sempre alinhados, mesmo que o inícios e os finais dos superframes estejam alinhados como na Figura 2.13. Como todos os superframes começam com o mesmo tempo, é sempre possível saber qual o tempo de início de um ciclo do superframe e de um slot de tempo. Um dispositivo de rede com links em múltiplos superframes pode recair sobre uma situação de definição de
link. Isto pode acontecer quando quando dois ou mais superframes com links atribuídos
coincidem no slot de tempo absoluto. Nesses casos o dispositivo deve operar no link que tem o menor número de frame_ID. As regras para a definição de link estão descritas no padrão do WirelessHART [IEC 62591: Industrial communication networks - Wireless
communication network and communications profiles - WirelessHART 2010]
2.3.3
Slots de tempo, links e canais
O protocolo WirelessHART possui algumas definições próprias e mais específicas para termos comuns na computação. Nesta seção serão explicitadas a definição de link, estrutura do slot de tempo para o WirelesHart e como é determinado qual canal a ser utilizado em uma transmissão.
O slot de tempo no WirelessHART tem a duração de 10 ms. Todas as transações devem ocorrer em slots de tempo de acordo com as restrições estabelecidas. O Clear
Channel Assessment (CCA) é avaliação de canal livre, ou seja, verifica se o canal está
livre ou não para que se realize uma transmissão. A Figura 2.14 mostra a organização do tempo em um slot para uma transação. Os símbolos que representam os valores de tempo são explicados na Tabela 2.2.
É essencial que o dispositivo WirelessHART implemente e interprete esses valores de tempo para que exista a comunicação e sincronia corretas.
Origem: O emissor espera o TsCCAOffset e então checa se o canal está livre durante
Figura 2.14: Organização do tempo dentro de um slot.
não for recebido durante o tempo TsAckWait, então a transmissão é considerada falha e se realizam as devidas ações. Caso contrário, a confirmação é recebida e processada. O ACK contém o status da recepção e dados para ajustes do relógio do dispositivo. Caso o dispositivo receptor (que enviou o ACK) não seja referência de tempo para o transmissor, os dados para ajuste de tempo são ignorados. Caso contrário, os dados são utilizados para sincronizar o relógio entre as duas estações, ajustando-se para o próximo slot.
Destino: O receptor espera pelo TsRxOffset e então começa a escutar o meio pelo
canal designado. Se nenhuma mensagem chegar durante o intervalo de tempo TsRxWait, então o slot de tempo atual é considerado como não utilizado e o receptor prossegue para o próximo slot de tempo. Caso contrário, a mensagem do transmissor é recebida e pro-cessada. O receptor prepara a mensagem de confirmação durante o intervalo de tempo TsTxAckDelay, depois do qual a confirmação é enviada. Caso o transmissor seja refer-ência de tempo para o receptor, este último irá ajustar o seu relógio baseado na diferença entre o tempo esperado de recepção da mensagem e o tempo real da chegada da mensagem (TsError), ajustando-se com o transmissor para o próximo slot.
Devido à complexidade para se interpretar a Figura 2.14, alguns comentários para facilitar o entendimento são feitos a seguir:
• A mensagem completa inclui, em sequência, quatro bytes de preâmbulo, um byte de SFD (Start of Frame Delimiter - Delimitador de Início de Frame), um byte de cabeçalho da camada física e o payload da camada física. O cabeçalho da camada física contém o tamanho do seu payload. O início da mensagem (Start of the
Mes-sage - SOM) deve ser considerado o início do preâmbulo, o receptor deve aguardar
2.3. CAMADA DE ENLACE 19
Tabela 2.2: Faixa de valores do Network ID e suas respectivas aplicações.
Símbolo Descrição
TsTxOffset Do início do slot até o início do preâmbulo da transmissão. TsRxOffset Do início do slot até quando o destino deverá começar a
escutar.
TsRxWait O maior tempo para se esperar pelo início da mensagem. Está correlacionado à quantidade de atraso de propagação entre as estações e o quanto isso pode ser tolerado.
TsError Este é a diferença entre o tempo do início real da menssagem e o tempo de início ideal percebido pelo dispo-sitivo receptor. Mostra o quanto os dispodispo-sitivos envolvidos estão fora de sincronia.
TsMaxPacket A quantidade de tempo necessária para se transmitir a maior mensagem possível.
TsTxAckDelay Tempo entre fim do recebimento da mensagem e início do ACK. O destino deve validar a mensagem recebida e gerar o ACK durante esse intervalo.
TsRxAckDelay Tempo entre o fim da mensagem até quando o transmissor esteja escutando o meio esperando pelo ACK.
TsAckWait O maior tempo a se esperar pelo início de um ACK. TsAck Tempo de se transmitir um ACK.
TsCCAOffset Do início do slot ao início do CCA .
TsCCA Tempo para se realizar um verificação de canal livre (CCA). TsRxTx TsrxTx é o tempo necessário ao rádio para chavear do modo
de recepção para o de transmissão ou vice versa.
interrupção só ocorre depois que o tamanho da mensagem seja conhecido (no nosso caso, o cabeçalho físico seja recebido), na implementação deve-se acrescentar ao limite de tempo de escuta ao meio o tempo para o recebimento do cabeçalho da camada física.
• No padrão WirelessHART, o Network Manager pode enviar a um dispositivo o co-mando 805 para cortar o CCA. Dessa maneira, o transmissor deve ainda transmitir no tempo TsTxOffset no slot de tempo. Note que o receptor não realiza CCA antes do envio do ACK.
• Se o receptor não é referência de tempo, o valor de ajuste de tempo presente no ACK não é utilizado. Entretanto, o dispositivo ainda deve seguir a especificação e enviar o TsError.
• TsRxTx é o tempo necessário ao rádio para chavear do modo de recepção para o de transmissão ou vice versa. Este valor foi retirado da norma [Society 2006] na qual se baseia o WirelessHART. Entretanto, a maioria dos chips disponíveis no mercado precisa de menos que este tempo para realizar a função. Cada dispositivo deve implementar a sua maneira, contudo, o WirelessHART requer que a mensagem seja mandada no tempo correto.
• A mensagem de confirmação é enviada no tempo TsTxAckDelay após o fim da mensagem transmitida, não em uma distância fixa do início da mensagem como pode ser sugerido pela Figura 2.14.
• Se uma referência de tempo responde, ela deve fazê-lo no tempo esperado pelo emissor, não no tempo correto. Desse modo se obtém uma melhor taxa de sucesso.
• Pela especificação, o valor do TsAck é de 823 µs baseado em transmitir 26 bytes, o tamanho completo do ACK. Entretanto, durante o processo de join o endereço do novo dispositivo deve estar no formato longo de 8 bytes, 6 bytes maior que o formato curto utilizado. Nesse caso o TsACK deverá ser de 1024 µs.
• A chave utilizada para a mensagem de confirmação deve seguir a que é usada na mensagem de dados a partir do bit de chave (Bit Network Key).
• Dois termos utilizados na especificação que se referem ao mesmo conceito são o TsTxWait e o TsRxWait.
• A implementação da pilha deve buscar atender aos pontos definidos no slot de tempo. Se ele se comportar com uma margem de mais ou menos 100 µs, a im-plementação será considerada adequada à especificação.
O link no WirelessHART representa a especificação completa de uma comunicação entre dois dispositivos adjacentes em nível MAC, contendo os parâmetros necessários para se transmitir um DLPDU por um único hop. Um link é função do par fonte e destino de transmissão; slot de tempo e channel offset atribuídos; direção da comunicação, se a transmissão é dedicada ou compartilhada, e do tipo da transmissão (recepção, transmissão ou ocioso). Os links são atribuídos a superframes com parte do processo de escalonamento [Chen et al. 2010]. Existem quatro tipos de links: normal, broadcast, join e discovery.
• O link Normal é o mais comum. A ele está associado um endereço de origem e de destino. A origem utiliza o link para transmitir a mensagem ao destino.
• O link Broadcast está associado a um dispositivo o qual é o emissor no link. Por esse link o dispositivo envia uma mensagem a todos os dispositivos em seu alcance sem confirmação de recebimento. O endereço em broadcast utilizado como destino é o 0xFFFF.
2.3. CAMADA DE ENLACE 21
• O link Discovery é um tipo especial de link criado para manter a conectividade entre os dispositivos. O propósito inicial do link Discovery é permitir aos dispositivos a descoberta de novos dispositivos. Depois de um período aleatório de tempo, o dis-positivo usa o link Discovery para enviar uma mensagem de keep-alive ao vizinho com o qual faz mais tempo que ele se comunicou. O Discovery link tem menor prioridade que os outros links no caso em que o slot de tempo é compartilhado. Se não estiver transmitindo o dispositivo escutará os links Discovery. Se a mensagem de keep-alive não for endereçada para si próprio, o dispositivo ainda irá escutar a mensagem para atualizar os dados a respeito de sua vizinhança.
Os links podem ser compartilhados de modo que vários transmissores podem competir por um link. O mecanismo de redundância está posto para dar suporte a retransmissões. Em um link compartilhado normal existe apenas um receptor e vários transmissores. Links
join são compartilhados no sentido de que vários dispositivos que ainda não entraram na
rede possam disputar a comunicação com o dispositivo que intermedia o processo. Os
links discovery também são compartilhados pois um dispositivo pode tanto competir para
transmitir em um link quanto escutar em um mesmo link. Links podem ser adicionados a um superframe ativo. Entretanto um link existente só pode ser removido em um su-perframe inativo. Um link não pode ser alterado mesmo que sua entrada seja retirada e acrescentada novamente.
A transação em um slot de tempo no WirelessHART é decrita pelo vetor: frame id, index, type, src addr, dst addr, channel offset.
• Frame id: identifica o superframe.
• Index :índice do slot no superframe.
• Type: Indica se o tipo do slot é de transmissão, recepção ou ocioso.
• Src addr e Dst addr: Respectivamente, os endereços de origem e destino da trans-missão realizada nesse slot.
• Channel Offset: Indica o canal lógico a ser usado na transação.
Para o ajuste fino da utilização dos canais, o WirelessHART utiliza a idéia da lista negra de canais(Channel Blacklist) na qual os canais com ruídos persistentes colocados na lista negra sendo evitados pelo escalonador da rede. Para manter o salto de canais (Channel Hopping), cada dispositivo mantém uma lista de canais ativos, que pode ter menos de 16 entradas devido ao blacklisting. Dados um slot de tempo e um Channel Offset, o canal real é determinado pela Equação 2.1.
ActualChannel= (ChannelO f f set+ASN)%NumChannels (2.1)
2.3.4
Máquinas de Estado da Camada de Enlace
A norma WirelessHART [IEC 62591: Industrial communication networks - Wireless
communication network and communications profiles - WirelessHART 2010] decompõe
a subcamada MAC em três componentes primários como mostrados na Figura 2.15. O funcionamento destes componentes é modelado pelas máquinas de estado:
• TDMA: especifica o funcionamento geral da subcamada MAC.
• XMIT: Coordena o funcionamento do transmissor que envia um DLPDU.
• RECV: Coordena o funcionamento do receptor que escuta um link e recebe um DPDU.
Figura 2.15: Organização das máquinas de estado da camada de enlace.
TDMA
2.3. CAMADA DE ENLACE 23
Figura 2.16: Máquina de estados TDMA.
• Gerenciar o escalonamento.
• Receber DLPDUs de outros dispositivos.
• Manter a sincronia do tempo.
O gerenciamento do escalonamento inclui a criação e manutenção dos superframes,
links e dados sobre os dispositivos vizinhos. Com decorrer do tempo e das transmissões
o escalonamento deve ser atualizado. O escalonamento de links consiste em determinar o que será feito no próximo slot e avaliar superframes ativos, links e DLPDUs a serem transmitidos.
O escalonamento determina o DLPDU a ser enviado. Todos os links de recepção devem ser atendidos por uma tentativa de recepção de DLPDU. Já que existem links que podem ser alocados para possíveis retransmissões, em geral existem mais links de recepção do que de transmissão. Uma vez que a maioria das transmissões é bem sucedida, muitos links de recepção podem ficar ociosos, não correspondendo a uma transmissão.
Estado Idle: Os seguintes eventos podem ocorrer no estado IDLE:
• Slot Timeout: a atividade mais freqüente realizada pela máquina TDMA é o evento
de Slot timeout, que indica que um slot precisa ser atendido. Se o próximo link a ser escalonado for um link de transmissão e houver um DLPDU na fila para ser transmitido, o estado da máquina deverá ir para estado Transmite (Talk). Senão, caso seja um link de recepção, então a máquina TDMA irá para o estado Escuta (Listen).
• Modificações na listas de superframes ou links do dispositivo: Isto afeta direta-mente o escalonamento. Estas mudanças implicam em revisões nas tabelas de links e podem resultar também em um diferente número de tentativas de recepção e trans-missão por segundo.
• Requisição de transmissão da camada de enlace: este evento adiciona um DLPDU a fila de transmissão do dispositivo e pode afetar o escalonamento de links.
Estado Talk: Neste estado, o dispositivo tenta transmitir o DLPDU aos seus
dispo-sitivos vizinhos. A operação deste estado é detalhada na máquina de estados XMIT. A tentativa pode resultar em sucesso ou em diversos resultados negativos.
• Uma propagação bem sucedida do DLPDU para o endereço broadcast ocorre assim que o DLPDU é transmitido. O buffer de DLPDU deve ser liberado imediatamente após o término da transmissão do DLPDU e o escalonamento de links deve ser realizado.
• Uma propagação bem sucedida do DLPDU para um endereço unicast ocorre quando um ACK válido é recebido com sucesso. Isso indica que o DLPDU foi propagado com sucesso e que o buffer deve ser liberado.
• Se o ACK contiver um código de reposta indicando erro, então o destino vizinho recusou o DLPDU. Quando isso ocorre, o DLPDU é retido no buffer e deve-se tentar uma retransmissão.
2.3. CAMADA DE ENLACE 25
• Se ocorre uma falha na transmissão na máquina XMIT, a transação é abortada e o escalonamento de link é realizado.
Com uma transmissão bem sucedida e se o endereço de destino não for broadcast, a máquina TDMA deve ir para o estado Wait for ACK (Espera ACK). Ao entrar nesse estado o temporizador RxDelay deve ser configurado para o TsRxAckDelay e o temporizador RxWait (janela de tempo para a recepção) deve ser configurado para o TsAckWait.
Estado Wait for ACK: A máquina TDMA permanece neste estado até que a máquina
RECV complete seu funcionamento. Se a máquina RECV indica que “Não Houve Re-sposta” a transação falha. Caso se trate de um link compartilhado (shared link), o Back-off_exp e o Backoff_cntr devem ser recalculados para que ser produza um tempo de
back-off aleatório antes da próxima retransmissão em um link compartilhado. Caso não se trate
de um link compartilhado, o Backoff_exp e o Backoff_cntr devem ser zerados. Por fim, depois do escalonamento de links, a máquina de estados TDMA muda para o estado Ocioso (Idle).
Caso o ACK seja recebido e contenha um código de resposta indicando sucesso, então a comunicação foi bem sucedida. Entretanto, se um código de resposta indicando erro for recebido, então o vizinho não aceitou o DLPDU. Em ambos os casos, a sincronização de relógio da rede pode ser feita pela campo Time-Ajustment do ACK de resposta do vizinho. Caso o vizinho seja referência de tempo (time-source) para o dispositivo, então o dispositivo deve ressincronizar seu relógio utilizando o campo Time-Ajustment. Se o vizinho não é referência de tempo, nenhuma atualização deve ser feita.
Receber um ACK indica que o vizinho recebeu a mensagem com sucesso e a aceitou. O buffer de DLPDU contendo o DLPDU transmitido deve ser liberado. A máquina TDMA deve mudar para o estado Idle e e realizar o escalonamento do links.
Estado Listen: Nesse estado, o dispositivo deve tentar receber o DLPDU. A operação
do estado é mostrado pela máquina RECV. A recepção de um DLPDU tem três possíveis finais:
• O destino final do DLPDU é o próprio dispositivo, sendo o DLPDU retido para ser processado pelo dipositivo.
• O destino final do DLPDU não é o próprio dispositivo, logo o DLPDU deve ser encaminhado para o próximo dispositivo em direção ao seu destino final.
• O DLPDU não é destinado a este dispositivo, então deve ser descartado.
Em todos os casos que o DLPDU é recebido, a tabela de vizinhos deve ser atualizada com as respectivas informações ou até mesmo criar-se uma nova entrada nesta tabela caso necessário. O ciclo de recepção de um DLPDU consiste na tentativa de recepção do mesmo, a validação dos dados recebidos e, caso a transmissão não seja em broadcast, a transmissão de uma resposta a um DLPDU válido recebido.
Se nenhum DLPDU for recebido durante o estado Listen, então a máquina TDMA deve escalonar os links e retornar ao estado Idle. Se uma DLPDU é recebida, então o relógio deverá ser sincronizado. TsError deve ser calculado pela diferença entre o tempo real de recebimento do DLPDU e o tempo esperado de recebimento.se o vizinho trans-missor do DLPDU for uma referência de sincronização do relógio, o dispositivo deve acertar seu relógio de acordo com o TsError medido. Se o vizinho transmissor não for uma referência deste dispositivo, nenhuma correção deverá ser efetuada.
Enquanto estiver no estado Listen e após uma recepção bem sucedida de um DLPDU, o dispositivo deve determinar se deve aceitar o DLPDU ou descartá-lo. O dispositivo aceita ou descarta um DLPDU baseado na prioridade do DLPDU, limiar de prioridade atual (Priority_threshold) e no número de buffer de DLPDU ocupados no momento no dispositivo. Se o DLPDU é aceito pelo dispositivo, consumido na camada de enlace ou encaminhado para o a camada de rede utilizando o serviço de indicação Dl-Transmit enquanto a camada de enlace deve realizar o escalonamento de links.
Uma vez que a camada de enlace tenha decidido o destino do DLPDU, a máquina TDMA sai do estado Listen de seguinte maneira:
• Se o destino do DLPDU for o endereço de broadcast, a máquina TDMA deve ir para o estado Idle.
• Se a transmissão não foi em broadcast e o DLPDU foi aceito, então o disposi-tivo deve transmitir um ACK, com o código de resposta configurado para o valor “sucesso” para o respectivo transmissor de DLPDU recebido. A máquina TDMA deve mudar para o estado Answer (responde).
• Se a transmissão não foi em broadcast e o DLPDU não foi aceito, então o dispo-sitivo deve transmitir um ACK, com o código de resposta configurado para o valor “error” para o respectivo transmissor de DLPDU recebido. A máquina TDMA deve mudar para o estado Answer (responde).
Estado Responde: O dispositivo deve copiar o Ts-Error no campo Time Adjustment do
ACK a ser transmitido. Nesse momento máquina TDMA opera a máquina de transmissão do ACK mostrada na Figura 2.17. Esta máquina ACK é inicializada para a recepção do DLPDU. O dispositivo deve copiar o valor do TsError (diferença entre o tempo real de recebimento do DLPDU e o tempo esperado de recebimento) calculado campo
Time-Adjustment do ACK.
Após a transmissão do ACK, a máquina TDMA deve realizar o escalonamento de
links e mudar para o estado Idle.
Máquina XMIT
A Figura 2.18 mostra a máquina de estados que modela o comportamento do disposi-tivo para enviar um DLPDU por um slot de tempo compartilhado ou dedicado. A máquina é iniciada para se transmitir um DLPDU.
Estado Idle: Quando à máquina XMIT, o dispositivo deve iniciar o temporizador
2.3. CAMADA DE ENLACE 27
Figura 2.17: Máquina de estados ACK.
pode utilizars-se deste tempo para construir o DLPDU, rodar o algoritmo de encriptação AES-128 e gerar o MIC para o DLPDU. A máquina de estados deve mudar para o estado “Espera o início da Tx”.
Estado Espera o início da Tx: Enquanto estiver no estado “Espera o início da Tx”, o
dispositivo deve selecionar o canal da transmissão. Quando o temporizador TxDelay se esgotar, a máquina XMIT muda de estado por uma dessas maneiras:
• Se o CCAEnable tem o valor FALSO, então o dispositivo deve requisitar o envio dos dados a camada física e ir para o estado “Envia Pacote”
• Se o CCAEnable tem o valor VERDADEIRO então o dispositivo deve requisitar CCA (clear channel assessment- confirmação de canal livre) a Camada Física e ir para o estado “Realiza CCA”.
Realiza CCA: Nesse estado o dispositivo deve esperar até que a camada física tenha
completado o CCA.
• Caso a resposta da camada seja que o canal está OCIOSO
1. A máquina XMIT deve ir para o estado “Habilitar transmissor”.
2. A camada física deve ser notificada (Requisição PH-ENABLE) para colocar o rádio em modo de transmissão.
Figura 2.18: Máquina de estados XMIT.
Estado Habilitar transmissor: Quando o dispositivo recebe o retorno da chamada
PH-ENABLE com valor Habilitado, a máquina XMIT deve mudar para o estado “Enviar pacote”. Caso contrário, e o retorno seja o valor Desabilitado, a máquina XMIT deve ser terminada sinalizando falha na transmissão do DLPDU (XMIT Failure).
Estado Enviar Pacote: Nesse estado o dispositivo deve iniciar a transmissão do pacote
utilizando a requisição de serviço PH-DATA da camada física. Quando o dispositivo receber a confirmação da camada física, a máquina XMIT de ser terminada sinalizando o
2.3. CAMADA DE ENLACE 29
Máquina RECV
A Figura 2.19 mostra a máquina de estados que modela o recebimento de DLPDUs. Esta máquina é iniciada para receber um DLPDU que está sendo transmitido por um de seus vizinhos ou imediatamente após uma transmissão de um DLPDU para o recebimento da confirmação do mesmo (ACK).
Estado Idle: Quando a Máq RECV é iniciada:
• O dispositivo deve selecionar o canal baseado no channel offset do link pelo ASN.
• O dispositivo deve requisitar à camada física que o rádio seja configurado para receber sinais (requisição PH-ENABLE a camada física).
• O dispositivo deve inicializar o temporizador RxDelay.
• A máquina RECV deve ir para o estado “Espera Inicio do Rx”.
Durante o tempo RxDelay o rádio se configura e se sincroniza com o canal certo.
Estado Espera Inicio do Rx: Quando se expira p tempo RxDelay, a máquina RECV
deve ir para o estado “Escutar Pacote”. E iniciar o temporizador RxWait.
Escutar Pacote: A máquina RECV permanece no estado “Escutar Pacote” até que
o inicio de um DLPDU seja detectado ou o temporizador RxWait expire sua contagem. Caso o RxWait se esgote a tentativa de recpeção falha e o máquina deve ser terminada indicando “Sem resposta” e o dispositivo atualiza suas estatísticas de comunicação.
Caso o delimitador esperado seja detectado, o tempo de sua chegada deve ser ar-mazenado e a máquina RECV deve ir para o estado “Recebe Pacote” de modo a receber o DLPDU.
Recebe Pacote: Quando a máquina RECV recebe a sinalização da camada física, ela
deve realizar uma avaliação inicial do DLPDU recebido. Caso o endereço do DLPDU não seja o esperado para o link, a máquina deverá ser terminada sinalizando “Sem resposta” e o dispositivo atualiza suas estatísticas de comunicação. Caso contrário, a máquina deverá ir para o estado “Validar Pacote”.
Valida Pacote: Caso não haja erros de endereçamento no DLPDU recebido, então uma
validação mais aprofundada deve ser realizada. Caso o CRC (Cyclic redundancy check) esteja incorreto o quadro da camada física foi corrompido antes ou durante a recepção. A máquina RECV deve ser terminada com o valor “Pacote Descartado” e o dispositivo atualiza suas estatísticas de comunicação.
Caso o CRC esteja correto, o MIC ( Message integrity code) deve ser calculado e checado. Caso o MIC não seja o esperado, isto pode ser indicação de um possível ataque a rede. Todavia, a recepção é considerada falha e o dispositivo deve atualizar suas es-tatísticas de comunicação e de segurança. A máquina RECV deve ser terminada com a indicação de “Pacote não aceito”.
Caso o CRC e o MIC sejam válidos a máquina RECV termina sua operação indicando o tipo de quadro recebido.
2.3.5
Escalonamento
2.3. CAMADA DE ENLACE 31
Tabela 2.3: Requisitos de escalonamento.
Função de Rede Requisito
Pressupostos O Network Manager tem uma representação do grafo da rede. Cada dispositivo de rede deve ser configurado com uma tabela de conexões. O network manager sabe a taxa de atualização de cada dispositivo. Para efeito de redundância, dados são enviados com uma transmissão e uma retransmissão por um caminho e outra retransmissão em um caminho diferente.
Restrições O número máximo de canais ativos é determinado pelo número de canais habilitados e limitado pelo blacklisting. nenhum dispositivo deve ser escalonado para escutar duas vezes em um mesmo slot. mais de um dispositivo pode transmitir para o mesmo dispositivo. Um link de
broadcast e links dedicados para cada um dos dispositivos que
escu-tam a transmissão podem coexistir. Em um caminho de múltiplos hops, o hop mais imediato é escalonado primeiro. As taxa de atualização suportadas são definidas por 2n, onde n é um valor inteiro. Por exem-plo, a taxa de atualização aceita pode ser 250ms, 500ms, 1s, 2s, 4s, 8s, 26s, 32s, 60s ou mais. Gerenciamento básico da rede e comunicação de dados publicados (publish data) não devem execeder 30% da banda disponibilizada (100slots/seg no máximo). O Network Manager leva em conta os requisitos e serviço. O escalonamento final (não contando o gateway) deve ter 50% de slots livres (ou seja, alocados para retrans-missões e escutas).
Descoberta de vizinhos O Network Manager aloca um link de descoberta comum a todos os dispositivos de rede. O temporizador de tempo de descoberta é config-urado para habilitar a descoberta.
A norma WirelessHART [IEC 62591: Industrial communication networks - Wireless
communication network and communications profiles - WirelessHART 2010] não
especi-fica um algoritmo de escalonamento, mas resume a seguinte estratégia escalonamento:
1. Estratégia de escalonamento
• Iniciando do slot 0, o channel offset é atribuído aos dispositivos .
• O dispositivo que publica dados mais rapidamente é alocado primeiro.
• O destino dos dados publicados é sempre o gateway. 2. Superframes de Dados
• O comprimento do superframe de dados é determinado pela taxa de leitura de dados.
• Se iniciando do dispositivo mais distante do gateway, um link é alocado para cada dispositivo na rota para o gateway. Um segundo slot é alocado para dar suporte a retransmissão.
• cada transmissão é escalonada com uma retransmissão alocada em outro cam-inho (caso exista um disponível).
• Um dispositivo de rede só pode estar escalonado para receber dados uma vez por slot.
• Notificações de eventos utilizam o mesmo esquema de escalonamento dos da-dos. Se houver uma operação de publicação de dados escalonada, então os eventos podem dividir o mesmo slot. Os eventos são enviados esporadica-mente. Quando um evento é enviado, pode-se usar o slot de retransmissão.
3. Superframe de Gerenciamento (Management Superframe)
• O superframe de gerenciamento tem prioridade sobre os superframes de da-dos.
• O superframe do Network Manager deve compor-se de 6400 slots conforme descrição da norma [IEC 62591: Industrial communication networks -
Wire-less communication network and communications profiles - WireWire-lessHART
2010].
• O grafo deve ser percorrido por busca em largura, iniciando do gateway, nu-merando os dispositivos de N0, N1, ... Nn.
• Todo dispositivo deve ter um slot para um DLPDU de Keep-Alive. Este slot deve ser um slot de recepção compartilhado do nó pai no grafo compartilhado. Se um dispositivo de rede não envia nenhum pacote para o seu nó pai durante o intervalo de tempo denominado Keep_alive_time, a estação deve enviar um DLPDU de Keep-Alive depois que este tempo expirar.
• Cada dispositivo deve ter 3 slots a cada 15 minutos para relatórios de estado do dispositivo.
• Cada dispositivo deve ter pelo menos 1 slot compartilhado a cada minuto para requisição/resposta. Caso esteja apto, o gateway deve alocar os recur-sos necessários para esta aplicação.
4. Comandos e respostas para gerenciamento da rede
• Os links de gerenciamento de rede devem ser compartilhados com requisição e respostas de join.
5. Comandos requisição/respostas
• Os links deve ser alocados de mesmo modo das requsições de join.
• O Network Manager aloca slots compartilhados para suportar o tráfico ad-hoc de requisição/respostas.
6. Superframe de Gerenciamento
2.3. CAMADA DE ENLACE 33
7. Superframe de Gateway
• O superframe de gateway deve ter Superframe_ID de valor 253.
• O superframe de gateway tem, no mínimo, 40 slots de duração (400ms).
• Os slots devem ser alternados entre slots de transmissão e de recepção e devem todos serem compartilhados.
8. Superframe de Propósitos Especiais
• O Network Manager deve alocar superframes para serem usados pelo gateway ou por um cliente para atender altas demandas de transmissão de dados. Isso é definido com serviço de "manutenção"ou "tranferência em bloco".
• O Network Manager deve alocar superframes para serem usados pelo dis-positivos handheld e por todos os disdis-positivos de campo para propósitos de manutenção. Este superframe é usado para fornecer conexões de alta veloci-dade para handhelds e dispositivos de campo. O Network Manager deve alo-car 4 slots por segundo (dois links em cada direção).
9. Parâmetros para otimização
• Número de hops ao gateway.
• Caminhos alternativos.
• Latência.
• Consumo de Energia
• Volume total de dados transmitidos.
Exemplo de escalonamento com um único hop
Utilizando a abordagem sugerida na definição dos superframes, os slots foram alo-cados da taxa de atualização mais rápida para a mais lenta. Assumindo que todos os sipositivos estão a 1 hop de distância do Gateway G, temos a configuração e as respecti-vas taxas de atualização da rede mostradas na Figura 2.20.
O escalonamento obtido está mostrado na Figura 2.21. Para prover suporte para re-transmissões imediatas, slots adicionais são utilizados a cada transmissão.
Figura 2.21: Escalonamento para o exemplo de um único hop.
Exemplo de escalonamento com múltiplos hops
O exemplo anterior apresentou o caso ideal no qual todos os dispositivos estão ligados diretamente (1 hop) ao gateway. Entretanto, em vários casos isso não vai ocorrer e com isso múltiplos hops devem ser utilizados.
Figura 2.22: Topologia de exemplo para um múltiplos hops.
2.3. CAMADA DE ENLACE 35
roteamento de pacotes. Além disso, se a rede estiver configurada para tal, os dispositivos podem ter várias rotas pelas quais enviar suas mensagens e slots devem ser definidos para que tais dispositivos possam rotear pacotes além dos seus próprios pacotes. Quando os
slots estão reservados para transmitir por ambos os caminhos, o segundo slot no
super-frame é utilizado apenas se nenhuma confirmação for recebida por parte do primeiro. A estrutura é mostrada na Figura 2.22 e o escalonamento resultante é mostrado na Figura 2.23. O delay do dispositivo C3 para o gateway vai de 30ms sem retransmissão para 60ms com retransmissão. Um jitter pequeno quando comparado com a taxa de atualização de 1 segundo.
Figura 2.23: Escalonamento para o exemplo de múltip´los hops.
Retransmissão para melhorar confiabilidade sendo realizada antecipadamente, leva a uma limitação na banda mesmo quando retransmissões forem desnecessárias, entretanto o WirelessHART provê recursos para se superar isso. Além da taxa de transmissão comum, os 15 canais descritos anteriormente podem ser utilizados simultaneamente, aumentando a banda em até 15 vezes [Chen et al. 2010], sendo a largura de banda efetiva do Wire-lessHART maior do que a versão cabeada do HART.
Capítulo 3
WirelessHART: Camadas Superiores
3.1
Camadas Superiores
O termo camadas superiores, no escopo do nosso trabalho, se refere às camadas de Rede, Transporte e Aplicação do modelo OSI. A camada de Rede no modelo OSI é res-ponsável pelas funções de roteamento, lidando com o endereçamento para a entrega de dados. A camada de transporte controla a transmissão de dados de maneira confiável e sincronizada entre duas estações através de controle de fluxo, fragmentação e desfrag-mentação. A camada de sessão gerencia o dialogo, conexão e sessão entre dois nós da rede. No padrão WirelessHART essas três camadas do modelo OSI são englobadas pela camada de Rede.
3.1.1
Camada de Rede e Transporte
A camada de rede do WirelessHART provê roteamento, segurança fim-a-fim e facili-dades de transporte. Essa camada também gerencia sessões de comunicações fim-a-fim com o dispositivo de destino. Existem quatro tipos de comunicação no WirelessHART:
• Request/Response: Esta é comunicação direta entre uma aplicação host e um único
dispositivo específico. O endereço de origem e destino devem ser específicos e sem ambigüidades. Todos os comandos HART especificam os dados da requisição e da resposta a serem comunicados.
• Publicação de Dados de Processo (Publishing of Process Data): os dados são pub-licados utilizando a parte da resposta do comando HART. Esta é de fato a comuni-cação da resposta.
• Broadcast: A mensagem em broadcast, destinada a todos os dispositivos da rede,
utiliza a comunicação padrão HART do Request/Response, entretanto o endereço de destino é o endereço específico de broadcast.
