COMUNICAÇÕES DIGITAIS

AULA 6

Prof. Amilton Carlos Rattmann

 CONVERSA INICIAL

A comunicação digital entre dispositivos foi abordada de maneira

complementar, e a camada física, responsável pela geração da versão física da
informação lógica produzida pelo dispositivo fonte, realizou a adaptação do sinal ao
meio de comunicação, criando a abstração denominada canal de comunicação. A
camada de enlace garantiu que as interferências e ruídos existentes no canal de
comunicação interferissem de forma muito atenuada no transporte das mensagens,
sinalizando e corrigindo erros ocorridos na transmissão. A camada de rede permitiu a
comunicação entre dispositivos distantes por meio de dispositivos vizinhos próximos,
repassando a mensagem encapsulada em pacotes, até atingir o dispositivo de
destino. Veremos, também, nesta aula, a camada de transporte cuja importância nas
comunicações digitais é garantir que os dispositivos mantenham comunicações com
diversos outros dispositivos ao mesmo tempo, garantindo ainda a entrega de todas as
informações transmitidas.

TEMA 1 – COMUNICAÇÃO FIM A FIM

A comunicação entre dispositivos distantes foi abordada de maneiras diferentes

em redes de comunicação. As redes que operam com circuitos virtuais já
implementavam controle fim a fim na camada de enlace e na camada de rede,
reduzindo o overhead (sobrecarga em português) de protocolo. Redes que operam
por repasse de datagrama necessitam de protocolos de transporte para garantir a
comunicação fim a fim. Veremos neste tema as soluções para controle fim a fim da
comunicação.

1.1 Circuito virtual

Os circuitos virtuais são abstrações para definir técnicas de repasse entre

dispositivos que criam uma estrutura de transporte que apresenta comportamento que
se assemelha ao comportamento de circuitos reais construídos por cabos ou fibras
ópticas, por exemplo. Embora seja um mecanismo eficiente, necessita que o controle
centralizado, que estabelece o circuito virtual, conheça todos os dispositivos da rede.
Os dispositivos utilizam uma tabela de comutação, construída pelo controle central,
para repassar as mensagens entre interfaces, até atingir o dispositivo de destino. A
tabela de comutação conduz a esse resultado, sem que o dispositivo conheça o
caminho todo. O dispositivo simplesmente executa a comutação após identificar o
2
 rótulo do circuito virtual no campo de controle da unidade de dados (cabeçalho do
protocolo) ingressado por uma interface, alterando o rótulo e despachando pela
interface indicada na tabela. A Figura 1 apresenta um processo de comutação para
uma rede composta por oito dispositivos e dois circuitos virtuais (CV1 e CV2). O CV1
estabelece a conexão entre os dispositivos “A” e “G”. O CV2 estabelece um circuito
virtual entre os dispositivos “D” e “H”. Os dispositivos “C” e “E”, por exemplo, apena
repassam a unidade de dados entre uma interface de entrada e uma interface de
saída.

Figura 1 – Rede de dispositivos operando com circuitos virtuais. O CV1 interliga os

dispositivos “A” e “G” e o CV2 interliga os dispositivos “D” e “H”

Fonte: Kurose, 2013; Tanenbaum, 2003.

A tabela de comutação dos dispositivos “C” e “E” pode ser observada na Tabela
1. O dispositivo “C”, ao receber na interface 1 uma unidade de dados com o
identificador (ou rótulo) 345, altera o valor do identificador no campo de controle da
unidade de dados para 142 e a encaminha para a interface 4. O mesmo dispositivo,
ao receber na interface 3 uma unidade de dados com o identificador 512, altera o
campo de controle da unidade de dados para o identificador 143 e a repassa para a
interface 4. O dispositivo “E” recebe pela interface 1 unidades de dados com
identificador 142 e 143 que, pelas informações contidas na tabela de comutação,

3
 altera os campos de controle para os identificadores 734 e 735, respectivamente, e as
envia para a interface 4.

Tabela 1 – Tabela de comutação dos dispositivos “C” e “E”

Dispositivo C Dispositivo E
Entrada Saída Entrada Saída
IF ID IF ID IF ID IF ID
1 345 4 142 1 142 4 734
3 512 4 143 1 143 4 735
Fonte: Kurose, 2013, p. 231.

Antes de a rede se tornar funcional para a definição dos circuitos virtuais, o

controle central precisa executar um processo de localização dos dispositivos e
definição de topologia, que essencialmente é um processo de roteamento prévio, que
é normalmente facilitado para esse tipo de rede pela definição de vizinha, realizada
na fase de ativação física da rede. Mas nada impede que o próprio processo de
roteamento faça a descoberta da vizinhança e estabeleça a topologia de forma
automática, pois depende da concepção da arquitetura da rede.
Os circuitos virtuais podem ser comutado (SVC, do inglês Switched Virtual
Circuit) ou permanente, PVC (do inglês: Permanent Virtual Circuit), que basicamente
se refere ao tempo no qual o CV permanece ativo. Os circuitos virtuais comutados
dependem de um processo de estabelecimento de conexão, no qual um dispositivo
realiza uma consulta conexão a outro dispositivo. No processo de negociação da
conexão, normalmente são definidos parâmetros para a conexão, como parâmetros
de tráfego e de qualidade de serviço. Os circuitos virtuais permanentes são
normalmente estabelecidos de forma manual no entre dispositivo. Caso os
dispositivos necessitem de uma conexão de supervisão (Figura 2) entre um elemento
de controle, esta poderia ser estabelecida de forma permanente na criação da rede
ou na inclusão de um novo dispositivo na rede.

4
 Figura 2 – Estabelecimentos de PVCs de supervisão entre dispositivos e controle
centralizado

Fonte: Kurose, 2013; Tanenbaum, 2003.

Vários protocolos operam com circuitos virtuais. Como exemplo, podem ser
citados os protocolos Frame Relay e ATM, que são protocolos de camada 2 e operam
com circuitos virtuais. Outro exemplo é o X.25, que, sendo um protocolo de camada
3, opera com circuitos virtuais comutados e permanentes. O MPLS é um protocolo
considerado de camada 2,5, pois concentra sua operação entre os protocolos de
camada 2 e 3 do guarda-chuvas TCP/IP (O termo guarda-chuvas se refere a um
conjunto de protocolos que operam de forma conjunta ou são suportados por um
mesmo protocolo). O MPLS opera de forma automática na criação e desconexão de
circuitos virtuais, baseado inicialmente no roteamento e em tráfego específico
reconhecido por regras e filtros. Ele marca um caminho pelo roteamento dos primeiros
pacotes até o elemento de destino, estabelecendo um circuito virtual entre os
roteadores do caminho e evitando o roteamento, conduzindo todos os pacotes IP por
comutação e facilitando a qualidade de serviço (QoS) da rede.

1.2 Conexão fim a fim com datagrama

Os datagramas são unidades de dados independentes que mantêm em seus

campos de controle todas as informações de origem, destino e tipo de serviço,
necessárias para atingir o dispositivo de destino em uma rede. Os protocolos que

5
 operam com datagrama não dispõem de recursos para a garantia de operação fim a
fim da comunicação. A rede IP estabeleceu dois protocolos de transporte (camada 4
– Figura 3) para controlar os fluxos de pacotes entre dispositivos e para garantir a
entrega ordenada e a entrega garantida de cada fragmento da mensagem gerada pela
fonte de informações da origem. Os protocolos de transporte da rede IP diferem na
sua forma de operação e são utilizados para serviços distintos.

Figura 3 – Modelo TCP/IP

Fonte; Kurose, 2013; Tanenbaum, 2003.

TEMA 2 – PROTOCOLO ORIENTADO PARA A CONEXÃO

A qualidade de serviço é um conceito que propõe que a rede entregue ao fluxo

de dados os recursos necessários ao funcionamento adequado desse fluxo, que pode
variar entre garantia de entrega de dados, baixa latência e garantia de cadência ou
combinação delas ou outras necessidades. Parte dos recursos necessários
disponibilizados pela rede depende de uma entrega confiável dos dados, ordenados
e corretos, que são proporcionados por protocolos conhecidos como orientados à
conexão. Os protocolos orientados à conexão serão abortados neste tema.
A orientação à conexão é definida como a necessidade de um procedimento
de estabelecimento da comunicação, antes do início da fase de transferência de
dados. Após o encerramento da fase de transferência de dados, existe a necessidade
de executar um procedimento de desconexão da comunicação, conforme
esquematizado no diagrama da Figura 4.

6
 Figura 4 – Fases da comunicação – protocolo orientado à conexão

Fonte: Elaborado pelo autor.

A comunicação na camada 4 ocorre entre processos rodando em dispositivos

hospedeiros. Os dispositivos hospedeiros são dispositivos mais complexos (operando
com mais camadas), como dispositivos suportados por sistemas operacionais,
computadores de uso geral ou servidores. A camada de transporte utiliza formas de
endereçamento conhecidas como portas, que são associadas aos processos que
rodam nos dispositivos hospedeiros, com base nos quais se estabelecem as
comunicações fim a fim. Cada comunicação estabelecida na camada 4 está associada
a uma única porta de origem e a uma única porta de destino, para um fluxo específico
de dados (segmentos), conforme apresentado na Figura 5.
O processo de multiplexação na camada 4 é suportada pelo protocolo de
camada 3. A multiplexação ocorre quando, dentro de um mesmo dispositivo,
diferentes processos trocam informações com processos em outros dispositivos, ao
mesmo tempo. Essa situação é representada pelo dispositivo “A” da Figura 5, na qual
duas conexões de camada 4 ocorrem para dois processos em outros dispositivos O
protocolo de rede transporta de forma indistinta informações do processo P1 e P2,
pois se referem ao dispositivo com o mesmo endereço. Ao receber a informação da
camada 3, o protocolo de transporte é responsável por entregar corretamente os
segmentos de dados para os processos P1 e P2.

7
 Figura 5 – Multiplexação e demultiplexação na camada de transporte

Fonte: Kurose, 2013; Tanenbaum, 2003.

2.1 Protocolo TCP

O protocolo TCP é orientado para a conexão. Para tanto, utiliza vários recursos
para a garantia de entrega das informações (tornando a comunicação confiável,
mesmo sobre um protocolo não confiável), conforme descritos a seguir:

• Soma de verificação;
• Temporizador;
• Número de sequência;
• Reconhecimento;
• Reconhecimento negativo;
• Janela, paralelismo.

O campo de controle (cabeçalho) do TCP, apresentado na Figura 6, carrega os

campos necessários para suportar os recursos do protocolo e as necessidades da
camada de transporte.

8
 Figura 6 – Cabeçalho TCP

Fonte: Kurose, 2013; Tanenbaum, 2003; Darpa, 1981.

As portas de origem e destino presentes no cabeçalho são números binários

16 bits e definem as terminações de um fluxo específico de dados. Para contextualizar,
quando um acesso a uma página da internet ocorre, é estabelecida uma conexão de
transporte entre o servidor de páginas e o navegador. O servidor utiliza a porta 80
(previamente conhecida e alocada para esse processo), e o navegador utiliza a porta
34234 (próxima porta livre disponível no sistema) para o navegador. Essa conexão de
camada 4 transporta o protocolo de aplicação HTTP.

Figura 7 – Transporte confiável com controle de sequência, reconhecimento e

temporização

Fonte: Kurose, 2013.

Todos os segmentos transmitidos são numerados pelo protocolo de transporte

TCP. Os números de sequência, com 32 bits de largura, são grandes o suficiente para

9
 permitir o reconhecimento seguro em grandes volumes de dados transmitidos entre
os dispositivos e iniciam a comunicação TCP com um valor aleatório. Cada segmento
transmitido é confirmado individualmente pelo dispositivo de destino. O incremento do
contador é realizado pelos tamanhos dos blocos de dados transmitidos e confirmados,
conforme apresentado na Figura 7.
Uma temporização é definida para o limite de chegada da confirmação de um
segmento (timeout). O valor do intervalo de tempo de estouro (timeout interval) é
calculado por uma média móvel exponencialmente ponderada (MMEP), a partir da
estimativa do RTT (do inglês: round-trip time) tempo de ida dos segmentos e retorno
das confirmações dos segmentos e da variação destes tempos. As amostras recentes
atualizam o valor acumulado. Os parâmetros utilizados para o cálculo de
TimeoutInterval (1) são o EstimatedRTT e o DevRTT, definidos pelas expressões (2)
e (3), com parâmetros α = 0,125 e β = 0,25, recomendados pela RFC 6298. Pela
mesma recomendação, o valor inicial do TimeoutInterval é 1 s.

𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑡𝑡𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 = 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 + 4 ∗ 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 (1)

𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = (1 − 𝛼𝛼) ∗ 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 + 𝛼𝛼 ∗ 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 (2)
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = (1 − 𝛽𝛽) ∗ 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 + 𝛽𝛽 ∗ |𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑇𝑇 − 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸| (3)
(Kurose, 2013, p. 176; Tanembaum, 2003, p. 587; IETF, 2011)

O comportamento das amostras e do RTT estimado podem ser observados na

Figura 8. A variação da média móvel do RTT amostrado suaviza as variações
instantâneas do RTT, acompanhando a flutuação média do RTT.

10
 Figura 8 – Amostras e estimativas do RTT

Fonte: Kurose, 2013.

O segmento TCP é verificado para detectar ocorrências de erros nas

informações de controle e no campo de carga, pela implementação de um sistema de
verificação por soma. O dispositivo remetente soma todos os bits do segmento, em
palavras de 16 bits, e inclui o complemento de um resultado no campo de verificação
do cabeçalho. É importante observar que os bits de estouro gerados da soma, o “vai
um” (sum overflow), são somados aos bits menos significativos, em cada fase da
soma.
Um dos principais aspectos do TCP é a inicialização tripla que é realizada antes
de iniciar a fase de transferência de dados. O bit SYN ativo e uma numeração aleatória
de sequência são alterados no cabeçalho do segmento TCP. O destino confirma a
nova comunicação, enviando um segmento com os bits SYN e ACK, reconhece o
número de sequência e sorteia seu número de sequência para transmissão. O
dispositivo de origem reconhece o número de sequência, atualiza o contador de
sequência e ativa o bit ACK no cabeçalho, confirmando a conexão, conforme pode ser
observado na Figura 9(A). Na desconexão, uma sequência de FIN e ACK para cada
lado da comunicação confirma a desconexão do protocolo TCP, conforme observado
na Figura 9 (B).

11
 Figura 9 – Estabelecimento (A) e desconexão (B) do protocolo TCP

Fonte: Kurose, 2013.

2.2 Protocolo X.25

Embora o assunto desta aula esteja relacionado ao protocolo de transporte e à

camada 4, o objetivo para a implementação dessa camada é a comunicação confiável
fim a fim, proporcionada pela temporização, sequenciamento de informações e
confirmação de entrega. A camada 3 da pilha de protocolos TCP/IP fornece apenas a
garantia de entrega da informação que pode conter erros nos dados, grande variação
na entrega e duplicação de informações. Outros protocolos operam na mesma
camada, como NetBEUI, SCTP e DCCP ou em outras camadas. Pelo ponto de vista
da entrega confiável e dos mecanismos para esse fim, abordaremos rapidamente os
recursos empregados no protocolo X.25.
O protocolo X.25 opera na camada 3, é orientado à conexão e realiza a entrega
confiável de pacotes proporcionada por circuitos virtuais e por mecanismos de
numeração de pacotes, sistema de confirmação de entrega e janela de transmissão.
A numeração de pacotes começa em zero e avança de unidade a unidade para
cada pacote enviado, em vez do incremento de numeração ocorrer pelo total de bytes
transmitidos. A confirmação de entrega pode ocorrer pacote a pacote, dependendo da
intensidade do fluxo de dados, ou em blocos, quando vários pacotes chegam ao
destino. A confirmação da numeração do último pacote confirma todos os anteriores,
até o limite da janela de transmissão. A retransmissão não é seletiva. Caso um pacote
não seja confirmado no período da temporização de confirmação, todos os pacotes a

12
 contar do número de sequência do pacote com falha na confirmação são
retransmitidos.
A janela de transmissão determina quantos pacotes podem ser enviados sem
confirmação. Caso a janela seja cinco, até cinco pacotes podem ser transmitidos para
aguardar suas respectivas confirmações. O protocolo X.25 pode trabalhar com janela
de transmissão módulo 8, no qual até sete pacotes podem ser enviados sem
confirmação, ou módulo 128, no qual até 127 pacotes podem ser enviados sem
confirmação, utilizado apenas em conexões físicas muito confiáveis.
A temporização de timeout é fixa, mas configurável, conforme o tamanho dos
pacotes e a velocidade do enlace.
A RFC 1613 descreve o encapsulamento do X.25 sobre o protocolo IP,
proporcionando a entrega confiável entre sistemas X.25, sobre a abrangência da rede
IP.

TEMA 3 – PROTOCOLO NÃO ORIENTADO À CONEXÃO

A qualidade de serviço, como visto no tema anterior, é um conceito que propõe

que a rede entregue ao fluxo de dados os recursos necessários ao funcionamento
adequado deste fluxo. Alguns fluxos exigem garantia da entrega e dados ordenados.
Outros fluxos podem exigir baixa latência ou baixa variação na latência, mas são
robustos à perda de informações, como ocorre com tráfego de tempo real (real time),
que pode admitir perdas de até 1 % das informações sem que afete o funcionamento
do serviço, mas são muito sensíveis a atrasos. Os protocolos não orientados à
conexão são adequados para a entrega rápida de baixa latência e serão abordados
neste tema.
Os protocolos não orientados à conexão normalmente são mais simples por
possuírem menos controles. Não há necessidade de executar fases de
estabelecimento de comunicação, nem de desconexão da comunicação. Como
apresentado na Figura 10, iniciam a qualquer momento, diretamente na fase de
transferência de dados.

13
 Figura 10 – Fase de comunicação NOC

Fonte: Elaborado pelo autor.

3.1 O protocolo UDP

O UDP é um protocolo de transporte que pertence ao guarda-chuvas TCP/IP.

É não orientado à conexão e no seu cabeçalho, apresentado na Figura 11, não
existem controles de nenhuma espécie, como contadores e marcadores, apenas as
portas de origem e destino, indicador de tamanho e verificação de soma dos dados e
cabeçalho.

Figura 11 – Cabeçalho UDP

Fonte: Kurose, 2013; Tanenbaum, 2003; IETF, 1980.

Como não existem dados de controle nem estabelecimento de chamada, um

processo que receber um segmento UDP tem a possibilidade de devolver alguma
informação pela mesma porta, apenas. Para algumas aplicações, no entanto, o uso
do UDP pode ser bem conveniente. O protocolo DNS (do inglês: Domain Nam
System), utilizado na resolução de nomes, faz bom uso do UDP, pois executa uma
atividade rápida, com poucos dados e para muitos clientes simultaneamente. Sem o
processo de conexão, o servidor que executa o DNS não precisa alocar recursos de
memória para as variáveis de ambiente, nem gerenciar variáveis, e não perde tempo
14
 em uma confirmação de três vias, reduzindo espera e aumentando a eficiência do
serviço. Caso haja falha na requisição ou resposta, o sistema solicitante realiza nova
consulta em outro servidor da lista.
Entre os motivos que levam aplicativos a usar o UDP, estão:

• Melhor controle da aplicação sobre o fluxo de dados;

• Não há estabelecimento de conexão;
• Não há estado de conexão;
• Pequeno cabeçalho de pacote.

Protocolos de roteamento (RIP), gerenciamento de rede (SNMP) e fluxos de

multimídia costumam utilizar na camada de transporte o protocolo UDP. O TCP possui
controle de fluxo e congestionamento e esse seria o motivo principal por ser utilizado
no transporte multimídia, em função dos possíveis atrasos por perdas de pacotes.
Entretanto, caso o fluxo UDP fosse utilizado intensivamente na rede, poderia inundar
a internet paralisando os serviços. Por outro lado, a qualidade das redes físicas
melhorou muito, permitindo que o TCP seja utilizado no transporte multimídia com
baixíssimas taxas de retransmissão, consequentemente afetando muito pouco o fluxo
de tempo real.

TEMA 4 – PROTOCOLOS DA CAMADA DE APLICAÇÃO

Os protocolos da camada de aplicação do modelo TCP/IP agregam as

camadas de sessão, apresentação e aplicação da camada ISO/OSI, executando as
funções das três camadas na própria aplicação. Muitos dos protocolos dessa camada
são conhecidos e usados cotidianamente no mundo. Abordaremos alguns desses
protocolos neste tema.

4.1 RTP

O protocolo RTP é utilizado para transportar amostras de áudio e vídeo em

tempo real, como PCM, ACC e MP3. É definido pela RFC 3550 e é encapsulado no
protocolo UDP. O RTP não possui mecanismos que garantam a entrega das amostras,
nem a ordem na entrega e não garante o tempo.

15
 Figura 12 – Cabeçalho RTP

Fonte: Kurose, 2013; Tanenbaum, 2003; IETF, 2003.

No campo de controle (Figura 12), o protocolo RTP tem o número de sequência,

tipos de carga e marca de tempo que permite que a aceitação ou o descarte de
informações no destino por atraso na entrega da informação, por exemplo. O protocolo
RTP ainda permite que sejam atribuídos fluxos independentes para fontes distintas,
como fluxos para microfones e outros para câmeras.
O campo Versão (V), indica a versão do protocolo; o campo P identifica
ocorrência de enchimento no pacote (padding); o campo extensão (X) indica a
ocorrência de extensão no cabeçalho; o campo CSRC counter (CC) contém a
quantidade de CSRC que acompanham o cabeçalho; no campo marker (M), sua
interpretação é definida por um perfil de aplicação; o campo payload type (PT)
identifica o tipo de payload (áudio, vídeo, imagem, texto, HTML etc.); o campo
sequence number tem valor inicial aleatório e incrementa a cada envio do pacote RTP.
O campo timestamp reflete o momento em que o primeiro byte do pacote RTP foi
mostrado. A lista dos CSRC identifica as fontes (SSRC) que contribuíram para a
obtenção dos dados contidos no pacote com esses identificadores.

4.2 HTTP

O protocolo HTTP é o protocolo de transferência de hipertexto (no inglês:

HyperText Transfer Protocol) e proporciona a transferência de dados que faz a web
funcionar. Definido nas RFC 1945 e RCF 2616, o protocolo HTTP é executado em
dois programas: um cliente e um servidor, que conversam por meio de mensagens
HTTP. O documento transferido pode ser o arquivo HTML, uma imagem ou um objeto
que pode estar no mesmo servidor ou em outros servidores. O HTTP utiliza o protocolo
TCP na camada de transporte.
O cliente abre uma conexão TCP para o servidor (porta 80, normalmente) e
requisita os arquivos indicados por um URL: algumdepartamento.com/home.index. O

16
 servidor localiza o arquivo, transfere-o para o cliente e encerra a conexão. As
indicações de arquivos e objetos do arquivo HTML são solicitadas ao servidor por
outras conexões TCP. Caso, de fato, para cada imagem ou objeto seja aberta uma
nova conexão TCP, diz-se que o HTTP opera com conexões não permanentes. Caso
o modo de operação seja com conexões permanentes, a cada novo objeto solicitado,
uma conexão é aberta e permanece conectada. Esta última sobrecarrega,
consideravelmente, o servidor.
O HTTP funciona com requisições e respostas. O formato da requisição
genérica por ser observada na Figura 13.

Figura 13 – Requisição HTTP

Fonte: Kurose, 2013.

O formato de resposta genérica do HTTP é apresentado na Figura 14.

17
 Figura 14 – Resposta HTTP

Fonte: Kurose, 2013.

Muitos sistemas de configuração e gerenciamento de dispositivos são

implementados em HTTP/HTML, por apresentarem uma interface prática e leve.

4.3 FTP

O FTP é um protocolo de transferência de arquivos (do inglês: File Transfer

Protocol). O FTP utiliza o TCP na camada de transporte. Após um processo de
autenticação com usuário e senha, o usuário pode acessar diretórios (pastas) locais
ou remotos, enviar (comando put) ou buscar (comando get) um arquivo. O FTP utiliza
duas conexões TCP simultâneas: uma para conexão de controle, na qual as
informações de usuário, senha e diretórios são transmitidas, e outra para transferência
de dados, conforme apresentado na Figura 15.

18
 Figura 15 – Transferência de arquivos com FTP

Fonte: Kurose, 2013.

O protocolo FTP é utilizado para atualização de software em dispositivos,

transferindo o código da nova versão para memória não volátil do dispositivo.

4.4 SNMP

O SNMP é um protocolo de gerenciamento de rede (do inglês: Simple Network

Manager Protocol), através do qual a sistema de gerenciamento podem buscar ou
ajustar parâmetros da configuração. Os sistemas de gerenciamento acessam a base
de informações de gerenciamento MIB (Figura 16) (do inglês Management Information
Base), que é uma estrutura em árvore de identificadores de objetos (Figura 17),
fornecendo um caminho estruturado e organizado para acesso as variáveis de
gerenciamento, via protocolo SNMP. O protocolo SNMP utiliza o UDP como protocolo
da camada de transporte.
O sistema de gerenciamento utiliza o SNMP (RFC 3416) para realizar
requisições para o agente, contendo o caminho ou a identificação do objeto, e para
transportar informações da MIB até os sistemas de gerenciamento.

Figura 16 – Sistema de gerenciamento, agente e MIB

Fonte: Elaborada pelo autor.

19
 Muitas informações estão disponíveis na MIB de equipamentos, com erros em
interfaces, dados trafegados para dentro e para fora do dispositivo, nome atribuído ao
equipamento, endereços de rede etc., conforme apresentado na Tabela 2.

Figura 17 – Estrutura da MIB

Fonte: Kurose, 2013; Case et al., 1990.

Os objetos são endereçamos por notação decimal pontuada, que descreve o

caminho até o objeto com base na raiz da MIB, cuja demonstração é apresentada no
canto direito alto da Figura 17.

Tabela 2 – Objetos UDP da MIB

Identificador de obj. Nome Tipo Descrição

1.3.6.1.2.1.7.1 udpInDatagrams Counter32 Qtde de datagramas UDP recebidos.
1.3.6.1.2.1.7.2 udpNoPorts Counter32 Qtde de datagramas recebidos sem porta.
1.3.6.1.2.1.7.3 udpInErrors Counter32 Qtde recebidos com erro.
1.3.6.1.2.1.7.4 udpOutDatagrams Counter32 Qtde de datagramas enviados.
Fonte: Kurose, 2013.

TEMA 5 – REDES SEM FIO PARA DISPOSITIVOS

As redes sem fio têm sido utilizadas por muitos dispositivos móveis e têm se
projetado para suportar mais dispositivos, de monitoramento médico e ambiental, nos
20
 escritórios e nas indústrias, na educação e na mobilidade urbana, projetando um
crescimento exponencial na quantidade de dispositivos e novas aplicações. Neste
tema, abordaremos as redes sem fios para dispositivos, apresentando as
características principais e as diferenças com outros tipos de redes, além dos sistemas
de modulação, endereçamento, controle e, por fim, aplicação.

5.1 Bluetooth

O padrão bluetooth foi lançado em 1999 pelo grupo SIG (Special Interrest
Group), formado pelo consórcio entre Ericsson, IBM, Intel, Nokia e Toshiba. Os
dispositivos bluetooth foram desenvolvidos para operar em curto alcance, com baixo
custo e baixo consumo, basicamente como uma tecnologia para substituir cabos entre
dispositivos portáteis, como periféricos, telefones celulares, smartphones e
notebooks, com conexões de baixa velocidade. Justificada por essa aplicação, as
redes formadas por esses dispositivos são denominadas redes pessoais sem fio –
WPANs (do inglês: Wireless Personal Area Network).
Atualmente na versão 4.2, e normatizado pelo IEEE 802.15.1, os rádios dos
dispositivos bluetooth operam na faixa não regulamentada ISM (Industrial, Scientific,
and Medical), na frequência de 2,4 GHz, em modo TDM. Os time-slots definem o
tempo (625 μs) no qual o transmissor bluetooth utiliza um dos 79 canais de rádio
(Figura 18), conforme apresentado na Tabela 3, antes de mudar de forma
pseudoaleatória para outro canal. Este esquema de saltos é conhecido como
Espalhamento Espectral por Salto de Frequência FHSS (do inglês: Frequency
Hopping Spread Spectrum), apresentado na Figura 19, que melhora o desempenho
do sistema em ambiente com interferência eletromagnética, como é o caso da
operação banda ISM.

Tabela 3 – Bandas de frequência operacional

Faixa regulamentar Canais de radiofrequência (RF)

2,400 – 2,4835 GHz f = 2402+k MHz, para k = 0 ... 78
Fonte: Elaborado pelo autor.

21
 Figura 18 – Canais de rádio bluetooth BR/EDR

Fonte: Elaborado pelo autor com base na Tabela 3.

Figura 19 – Uso do espectro no FHSS

Fonte: Brown, 2002; Bluetooth®..., 2019. Adaptado: <https://www.extremetech.com/computing/73472-

homerf-20this-year-is-crucial/4>. Baseado em: <https://microchipdeveloper.com/wireless:ble-link-layer-
channels>.

Existem dois modos de operação dos sistemas bluetooth: Taxa Básica BR (do
inglês: Basic Rate) e Baixa Energia LE (do inglês: Low Energy). Os dois modos
trabalham da mesma forma, o que inclui:

• Descoberta de dispositivos;
• Estabelecimento de conexão;
• Mecanismos de conexão.

O sistema de taxa básica inclui controle de acesso de mídia alternativo (MAC),

modo opcional de Taxa de Dados Aprimorada EDR (do inglês Enhanced Data Rate)
e extensões de camada física (PHY). O sistema de taxa básica oferece conexões
síncronas e assíncronas com taxas de dados de 721,2 kbps para Taxa Básica, 2,1
Mbps para Taxa de Dados Aprimorada e operação de alta velocidade de até 54 Mbps
com o 802.11 AMP. O sistema LE, por outro lado, inclui recursos para produtos com

22
 menor consumo de corrente, menor complexidade e menor custo. O sistema LE
também foi projetado para casos de uso e aplicações com taxas de dados e ciclos de
trabalho mais baixos.
São definidos dois modos de modulação. Na taxa básica, é usada a modulação
FM binária e modelada para minimizar a complexidade do transceptor. No modo de
taxa de dados melhorada, é utilizada a modulação PSK com duas variantes, conforme
apresentado na Tabela 4:

Tabela 4 – Modos de modulação do rádio bluetooth

Modo de operação Taxa de símbolo Modulação Taxa de bit

Taxa básica 1 Msps GFSK 1 Mbps
Taxa melhorada 1 Msps π/4-DQPSK 2 Mbps
Taxa melhorada 1 Msps 8DPSK 3 Mbps
Fonte: Elaborado pelo autor.

O modo de operação LE, assim como o modo BR/EDR, utiliza a banda ISM em
2,4 GHz. Emprega um transceptor de salto de frequência FHSS para combater a
interferência e o desvanecimento. A rádio LE usa uma modulação binária de
frequência para reduzir a complexidade do transceptor. A taxa de símbolo é de 1
Msps, suportando taxa de bits de 1 Mbps.
O LE emprega dois esquemas de acesso múltiplo: acesso por divisão de
frequência (FDMA) e por divisão de tempo (TDMA). São utilizados 40 canais físicos
(Figura 20), separados por 2 MHz, no esquema FDMA, dos quais três são usados
como canais de publicidade e 37 como canais de dados. Utiliza-se um esquema de
polling baseado em TDMA, no qual um dispositivo transmite um pacote em um tempo
predeterminado e um dispositivo correspondente responde com um pacote após um
intervalo predeterminado.

23
 Figura 20 – Canais BLE

Fonte: Brown, 2002. Adaptado de: <https://www.extremetech.com/computing/73472-homerf-20this-

year-is-crucial/4>.

O modo de operação geral do Bluetooth é mestre-escravo (master/slave), no

qual um dispositivo assume a função de mestre e controla a piconet, agregando até
sete dispositivos. Outros dispositivos poder ser aceito na mesma piconet com oito
dispositivos, mas devem permanecer estado estacionário (parker). As redes podem
ser maiores interligando piconets através de dispositivos escravos comuns a duas
redes, formando uma topologia difusa, a scatternet, conforme pode ser visto na
Figura 21. Uma piconet pode suportar até 255 dispositivos estacionados (no inglês:
parkers).

24
 Figura 21 – Topologia bluetooth com interligação de Piconet formando redes difusas,
denominadas scatternets

Fonte: National Instruments, 2006. Baseado em:

<http://download.ni.com/evaluation/rf/intro_to_bluetooth_test.pdf (figura 12)>.

5.2 ZigBee

A rede ZigBee é uma rede pessoal sem fio padronizada pelo IEEE, sob código
802.15.4. Sua aplicação foca em dispositivos com menor consumo de energia, taxas
mais baixas de transmissão e baixo custo, fornecendo, entretanto, grande autonomia
para dispositivos que operam à bateria. Sensores de iluminação e temperatura para
aplicações domésticas, interruptores de parede do sistema elétrico residencial e
dispositivos de segurança são todos muito simples, trocam poucas informações e não
precisam de grande velocidade para uma operação satisfatória, sendo ideais para
operação em rede ZigBee.
Os dispositivos ZigBee operam em faixas de transmissão digital de 20, 40, 100
e 250 kbps, em redes totalmente conectadas, em malha (no inglês: mesh),
estabelecendo procedimento de conexão segura através de chaves de rede. Utiliza
modulação O-QPSK (Offset QPSK) com Espalhamento Espectral por Sequência
Direta DSSS (do inglês: Direct Sequence Spread Spectrum), conforme apresentado
na Figura 22. Possui 16 canais de 2 MHz de largura (Figura 23) e alcance de até 300
m em visada direta.

25
 Figura 22 – Uso do espectro no DSSS

Fonte: Brown, 2002. Adaptado de: <https://www.extremetech.com/computing/73472-homerf-20this-

year-is-crucial/4>.

Figura 23 – Canais ZigBee

Fonte: Padrão, S.d. Baseado em: <https://www.gta.ufrj.br/grad/10_1/zigbee/padrao.html> (figura 2 e

tabela 1).

Na versão 3.0, o sistema ZigBee opera com redes e com dispositivos legados,
em muitas áreas de aplicação que incluem dispositivos residências, de construção,
industriais, varejo e saúde.
Na rede ZigBee existem três tipos de dispositivos e um sistema de segurança
que suporta criptografia AES-128 na camada de rede e na camada de aplicação.
Dispositivos coordenadores estabelecem uma rede centralizada de controle e
segurança (Trust Center), dispositivos roteadores estabelecem rede com segurança
distribuída, e dispositivos terminais se conectam a dispositivos coordenadores ou
roteadores, conforme apresentados na Figura 24, a qual também esquematiza os
modelos das redes de segurança. Há ainda o ZigBee GPD (Green Power Device), que
opera em baixo consumo de energia. O procedimento de conexão de um dispositivo
ZigBee é, sucintamente, apresentado abaixo:
• Nó executa uma varredura de canal;
• Node seleciona um canal adequado e outros parâmetros de rede;
• Se o nó é um coordenador,
o Forma uma rede de segurança centralizada;
o Inicia a funcionalidade do Trust Center.

26
 • Se o nó é um roteador,
o Forma uma rede de segurança distribuída.

Caso um dispositivo coordenador receba uma interação de usuário, como um

botão pressionado, o dispositivo abre a rede por 180 segundos para a inclusão de
novos dispositivos. Até 65000 dispositivos podem operar na mesma rede.

Figura 24 – Modelos de segurança de rede ZigBee

Fonte: ZigBee..., S.d. Baseado em: <https://www.zigbee.org/zigbee-for-developers/zigbee-3-0/#>.

Os dispositivos ZigBee compartilham vários mecanismos de protocolo de

enlace como quadros de sinalização e confirmação, mecanismo de acesso aleatório
ao canal, detecção de portadora e alocação de canais fixo de comunicação.
A rede ZigBee, como comentado logo acima, é do tipo mesh, na qual os
dispositivos podem repassar os pacotes de informação, estabelecendo múltiplos
caminhos entre dispositivos. Os caminhos alternativos aumentam a disponibilidade da
rede diante de problemas de desconexões de elementos, que afetam a topologia
estabelecida. Os caminhos na rede ZibBee são reestabelecidos automaticamente,
conforme exemplificado no diagrama Figura 25.

27
 Figura 25 – Autorrecuperação da rede malha (mesh)

Fonte: ZigBee..., S.d. Baseado em: <https://www.zigbee.org/zigbee-for-developers/zigbee-3-0/#>.

5.3 MQTT

Normalmente as informações fornecidas pelos dispositivos como sensores, por

exemplo, é mais importante que a localização, o tipo do dispositivo ou a capacidade
de comunicação. A temperatura em um ambiente pode ser coletada,
independentemente da rede que suporta essa informação ou o caminho que está
sendo percorrido para que ela seja tornada útil. Muitas vezes, a mesma informação
de temperatura pode ser utilizada por sistemas diferentes, mas, em função do formato
de cada rede e protocolos utilizados, não consegue ser compartilhada. É nesse
sentido que ressurge a aplicação do protocolo MQTT-SN (do inglês: Message
Queuing Telemetry Transport for Sensor Network), que foi lançado originalmente pela
IBM, no final dos anos 1990 e que, no final de 2014, tornou-se padrão aberto,
despertando a atenção para suporte a sensores e atuadores IoT.
O MQTT apresenta uma solução para o problema de obtenção da informação
usando uma abordagem de comunicação centrada em dados, na qual os conteúdos
e interesses são o foco da comunicação, fornecendo um mecanismo de comunicação
que utiliza as funções genéricas de “Publicar / Assinar” (pub / sub), permitindo
escalabilidade e independência do processo de comunicação fim a fim.
Sistemas de mensagens são amplamente utilizados em redes corporativas,
principalmente devido à sua escalabilidade e suporte de topologia de rede dinâmica.
Estender o sistema de publicação / assinatura corporativo para as WSNs (do inglês:
Wireless Sensor Network) permite a integração dos sensores na rede corporativa,

28
 tornando os dados de campo coletados disponíveis para todas as aplicações
corporativas e controláveis por aplicativos empresariais.
Dispositivos sensores ou que tenham uma determinada informação se vinculam
ao broker (Figura 26), publicando a informação em um determinado tópico. Outros
dispositivos que irão processar as informações de interesse se vinculam ao broker e
assinam um determinado tópico. Quando houver publicação de um determinado
tópico, os dispositivos assinantes receber essa informação.

Figura 26 – Mecanismo de PUB/SUB do MQTT-SN

Fonte: Fischer, 2017.

O MQTT-SN foi projetado para operar de forma independente dos detalhes da

rede. Redes que forneçam um serviço de transferência de dados bidirecional entre
nós e um gateway devem ser capazes de suportar o MQTT-SN. Qualquer serviço de
rede que envie um datagrama simples de um dispositivo de origem para um dispositivo
de destino específico deve ser suficiente.

FINALIZANDO

Nesta aula, abordamos os aspectos da entrega confiável da informação. Vimos

formas de entrega confiável por comunicação de controle fim a fim e por mecanismos
de circuitos virtuais. Vimos também alguns dos mais importantes protocolos de
aplicação que possuem relação mais íntima com comunicações digitais e algumas
redes sem fio para dispositivos.

29
 REFERÊNCIAS

BLE Link Layer Roles and States. Microchip Developer Help, 2019. Disponível em:
<https://microchipdeveloper.com/wireless:ble-link-layer-roles-states>. Acesso em: 21
jul. 2019.

BLUETOOTH®. Archived Specifications. Bluetooth®, 2019. Disponível em:

<https://www.bluetooth.com/specifications/archived-specifications/>. Acesso em: 21
jul. 2019.

BLUETOOTH® Low Energy Channels. Microchip Developer Help, 2019. Disponível

em: <https://microchipdeveloper.com/wireless:ble-link-layer-channels>. Acesso em:
21 jul. 2019.

BROWN, O. HomeRF 2.0–This Year Is Crucial. Extreme Tech, 8 mar. 2002.

Disponível em: <https://www.extremetech.com/computing/73472-homerf-20this-year-
is-crucial/4>. Acesso em: 21 jul. 2019.

CASE, J. et al. RTF 1157 – A Simple Network Management Protocol (SNMP). IETF,
maio 1990. Disponível em: <https://www.ietf.org/rfc/rfc1157.txt>. Acesso em: 21 jul.
2019.

CLARK, A. S.; TRUONG, H. L. MQTT For Sensor Networks (MQTT-SN) Protocol

Specification. Version 1.2. International Business Machines Corporation (IBM), 14
nov. 2013. Disponível em: <http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-
SN_spec_v1.2.pdf >. Acesso em: 21 jul. 2019.

DARPA – Defense Advanced Research Projects Agency. Transmission control

protocol – Darpa internet program – protocol specification. Arlington, Virginia:
Information Processing Techniques Office, set. 1981.

DIGI INTERNATIONAL INC. Channels, Zigbee. Digi International Inc., 23 ago. 2018.
Disponível em:
<https://www.digi.com/resources/documentation/digidocs/90001537/references/r_cha
nnels_zigbee.htm>. Acesso em: 21 jul. 2019.

FISCHER, J. 6. Messaging with MQTT. Micropython IoT Hackathon, 2017.

Disponível em: <https://micropython-iot-
hackathon.readthedocs.io/en/latest/mqtt.html>. Acesso em: 21 jul. 2019.

IETF. RCF 3550 – RTP: A Transport Protocol for Real-Time Applications. IETF, jul.,
2003. Disponível em: <https://tools.ietf.org/html/rfc3550>. Acesso em: 21 jul. 2019.
30
 _____. RFC 6298 – Computing TCP's Retransmission Timer. IETF, jun. 2011.
Disponível em: <https://tools.ietf.org/html/rfc6298>. Acesso em; 21 jul. 2019.

_____. RFC 768 – User Datagram Protocol. IETF, 28 ago. 1980. Disponível em:
<https://tools.ietf.org/html/rfc768>. Acesso em: 21 jul. 2019.

KUROSE, J. F. Redes de computadores e a internet – uma abordagem top-down.

6. ed. São Paulo: Pearson Education do Brasil, 2013.

NATIONAL INSTRUMENTS. Introduction to bluetooth device testing from theory to

transmitter and receiver measurements. National Instruments, set. 2006. Disponível
em: <http://download.ni.com/evaluation/rf/intro_to_bluetooth_test.pdf>. Acesso em;
21 jul. 2019.

PADRÃO 802.15.4. ZigBee, S.d. disponível em:

<https://www.gta.ufrj.br/grad/10_1/zigbee/padrao.html>. Acesso em: 21 jul. 2019.

TANENBAUM, A. S. Redes de computadores. Rio de Janeiro: Elsevier, 2003.

ZIGBEE is the only complete loT solution, from the mesh network to the universal
language that allows smart objects to work together. ZigBee Alliance, S.d. Disponível
em: <https://www.zigbee.org/zigbee-for-developers/zigbee-3-0/#>. Acesso em: 21 jul.
2019.

31