ESCOLA DE ENSINO TECNICO DO ESTADO DO PARÁ

FRANCISCO DAS CHAGAS RIBEIRO DE AZEVEDO - CACAU

CURSO TECNICO EM ADMINISTRAÇÃO DE REDES

CAMILLY LUIZY CABRAL DE ARAÚJO

CARINE VITÓRIA SANTIAGO CARDOSO

KAIANE DE MELO SIMÕES

MARIA CAROLINE BRAGA COELHO

PAMELA BEATRIZ CORRÊA DA CONCEIÇÃO

PROF: EDILSON MELO

PROTOCOLO DE COMUNICAÇÃO LLC

PROTOCOLO DE COMUNICAÇÃO SNAP

BELÉM 2023
 INTRODUÇÃO

Coisas em que você deve pensar

- Como é que os nós vão determinar os seus endereços?

para o mestre isto é fácil: ele receberá um endereço definido. Os

escravos devem receber endereços de uma forma previsível, para que seja
repetível. Idealmente ligado a algumas características de hardware.

- Estrutura da embalagem

Você usará sempre a mesma quantidade de bytes de dados? Isto

permitirá um timing mais determinístico, e uma implementação mais fácil, etc.

- Detecção de erros

Que algoritmo de detecção de erros deve ser escolhido?

Por favor note que o byte SYNC não está incluído no cálculo do
checksoum.

O CRC é capaz de reconhecer erros, e idealmente até corrigi-los (para

uma menor quantidade de erros).

- Comprimento total do pacote

HTH recomenda manter os pacotes pequenos (< 40 bytes) em mídias

como linha de energia, RF ou IR para um melhor desempenho.

- Bandeiras de protocolo específico (PFB)

Estes poderiam ser utilizados numa implementação especializada do

seu protocolo, permitindo-lhe mudar alguma lógica de aplicação dentro deste, e
utilizar os dados como dados reais. (por exemplo, os bits PFB poderiam definir
qual comando você quer que o nó execute, e os dados poderiam ser a carga
útil necessária para os comandos individuais). ou você poderia empacotar o
comando + dados completamente nos dados, e apenas usar o SNAP para
transporte, endereçando & assegurando que o pacote chegue sem erros.
 LOGICAL LINK CONTROL (LLC)

É uma das duas subcamadas de protocolo de rede DLL (Data Link

Layer) dentro do modelo de comunicação de dados OSI (Open System
Interconnection). O LLC está localizado na área DLL superior da Camada OSI 2
acima da Camada Física (PHY) da Camada OSI 1.

O LLC é padronizado como IEEE 802.2 pelo Instituto de Engenheiros

Elétricos e Eletrônicos (IEEE).

A interface de multiplexação LLC inclui os seguintes recursos de

protocolo de rede:

Operação de rede multiponto

Troca de mídia de rede unificada

Controle de fluxo

Identificação de protocolo de linha, como SDLC (Synchronous Data Link

Control)

Atribuição de número de sequência de quadros

Rastreamento de confirmação

Hoje, o LLC é usado apenas por seu recurso de multiplexação.

Protocolos modernos da Camada de Transporte, como TCP ou outros
protocolos da camada de aplicativo, são usados para gerenciamento de fluxo
de rede de origem e destino.

Um protocolo não IEEE 802 pode ser distribuído entre as camadas LLC
e Media Access Control (MAC), como o High-Data Data Control Control (HDLC)
da Cisco.

O protocolo de comunicação LLC (Logical Link Control) é um protocolo

da camada de enlace de dados do modelo OSI que lida com a comunicação
entre dispositivos em uma rede. Ele fornece serviços de controle de fluxo,
controle de erro e endereçamento lógico para garantir uma comunicação
confiável e eficiente. O LLC trabalha em conjunto com o protocolo MAC (Media
Access Control) para fornecer uma interface entre a camada de rede e o meio
físico da rede. O LLC é responsável por dividir os dados recebidos da camada
de rede em quadros, adicionar cabeçalhos e trailers para controle de fluxo e
controle de erro, e transmitir esses quadros para a camada física para
transmissão através do meio físico. Ele também lida com a retransmissão de
quadros perdidos ou corrompidos, garantindo assim a integridade dos dados
transmitidos. Em resumo, o protocolo LLC desempenha um papel crucial na
comunicação confiável entre dispositivos em uma rede, fornecendo serviços
essenciais para garantir uma transmissão eficiente e segura dos dados.
 PROTOCOLO DE COMUNICAÇÃO SNAP

S.N.A.P. é um protocolo de comunicação entre vários hosts conectados.

Ele fornece:

- endereçamento

- bandeiras

- pedido deck/nak

- detecção de erros (diferentes métodos de detecção de erros

disponíveis)

Pode ser executado em diferentes mídias, incluindo RS485. É otimizado

para uma pequena área de trabalho (computação limitada, recursos de
memória), mas escalável, dependendo das suas necessidades.

Basicamente, se você quiser conectar vários sistemas de computação e

as aplicações rodando neles, por exemplo um Raspberry Pi e vários
microcontroladores Atmel sobre suas respectivas UARTs, usando RS485 como
mídia, você quer algo para embrulhar seus dados, entregá-los aos hosts
corretos, receber reconhecimentos de que os dados foram recebidos
corretamente, etc. É para isto que serve o SNAP. É de certa forma uma
alternativa, por exemplo, ao protocolo Modbus.

O SNAP foi desenvolvido pela HTH, High Tech Horizon, uma empresa
da SWEDEN.

A página inicial do protocolo é: http://www.hth.com/snap/

Para comunicar usando o protocolo, você deve obter uma identificação

de fornecedor, para a qual você pode aplicar com HTH gratuitamente. Eles
pedem que você inclua um PDF do protocolo SNAP, ou um link para seu web-
site http://www.hth.com/snap/ com os aplicativos/produtos. O vendor id NÃO
está incluído nos bytes de protocolo reais falados na sua aplicação. Portanto,
você pode avaliar primeiro o protocolo e, em seguida, usar a avaliação como
implementação real, sem necessidade de alterações.
 Aqui está a lista de identificações de fornecedores atualmente
registrados:

http://www.hth.com/snap/vidlist.html

Aqui está um link diretamente para a folha de dados:

http://www.hth.com/filelibrary/pdffiles/snap.pdf

Algumas propriedades básicas do SNAP

- protocolo binário

- conjunto de recursos escaláveis, dependendo da sua aplicação

- funciona com comunicação síncrona e assíncrona (= por exemplo,

UART)

- grátis para uso comercial e privado. Requer identificação gratuita do

fornecedor para identificação comercial.

A comunicação entre os nós é feita sob a forma de pacotes. Vamos

discutir um pacote de exemplo, que usa algumas das características do SNAP:

fonte: Documentação SNAP, exemplo de um simples pacote SNAP

preâmbulo: O preâmbulo é opcional, pode usar quaisquer caracteres

desde que não sejam o byte de sincronização, SYNC.

- SYNC: byte único com a seguinte estrutura: 01010100, indica o início

do pacote

- HDB2, HDB1: Os bytes de definição de cabeçalho HDB2 e HDB1

definem quanto tempo será o pacote e quais funcionalidades serão utilizadas.

- DAB1: Byte de Endereço de Destino

- SAB1: Endereço de origem Byte

- DB1: Byte de Dados 1 - a carga útil para a sua aplicação

- CRC2: byte alto de CRC-16

- CRC1: byte baixo de CRC-16

endereço 0 é reservado como endereço de transmissão e não deve ser

usado para mais nada. (DAB / SAB)
 Nota: os dispositivos que surgem no meio das comunicações podem
sincronizar-se em um "regular" 01010100 na posição errada (onde não se
pretendia dizer como SYNC). Portanto, deve ser usado um checksum, para que
o dispositivo possa reconhecer que os dados "não cabem", e ele deve
continuar ouvindo para o próximo pacote, começando com o 01010100. (Isto é
necessário para proteger contra mudanças de quadros). Obviamente o
dispositivo irá descartar todos os bytes antes de receber o primeiro 01010100,
já que não recebeu o pacote completo.

Bytes de definição do cabeçalho

O SNAP é construído de uma forma modular e extensível. Você pode

definir (DD) endereços de destino com comprimento de 0 - 3 bytes no DAB,
bytes de endereço de destino. Com um endereço de destino de 3 bytes (DD =
11), você receberá até 16 777 215 nós endereçáveis. Com um endereço de
destino de 1 byte (DD = 01), usado no exemplo acima, você poderá endereçar
255 endereços.

O mesmo é válido para o comprimento de endereço de origem (SS) nos

bytes de endereço de origem (SAB). No exemplo SS = 01 para endereços de 1
byte.

PFB: comprimento do byte específico do protocolo. 0 - 3 bytes, como

acima (PP). No exemplo PP = 00. Esta característica ainda não está
implementada no SNAP, e, portanto, deve ser definida como 0, como no
exemplo. Uma implementação especializada do SNAP provavelmente poderia
fazer algo com eles (por exemplo, contador de pacotes, etc) - veja a
documentação do SNAP para algumas ideias.