Comunicações Digitais: Circuitos Virtuais

Prévia do material em texto

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 
3 
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,
 
 
4 
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. 
 
 
 
 
 
 
5 
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 
 
 
6 
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 rededepende 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. 
 
 
7 
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. 
 
 
 
 
 
8 
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. 
 
 
 
 
 
 
9 
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 
 
 
10 
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. 
 
 
 
 
 
 
 
 
 
 
 
11 
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). 
 
 
 
 
12 
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 deunidade 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 
 
 
13 
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. 
 
 
 
 
 
 
14 
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 
 
 
15 
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. 
 
 
 
 
 
16 
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 
 
 
17 
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 respostagenérica do HTTP é apresentado na Figura 14. 
 
 
 
 
 
 
 
 
 
18 
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. 
 
 
 
 
 
 
 
19 
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. 
 
 
 
20 
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 
 
 
21 
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. 
 
 
 
 
 
22 
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 
 
 
23 
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. 
 
 
 
 
 
 
 
 
24 
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). 
 
 
 
 
 
 
 
 
 
 
25 
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. 
 
 
 
 
26 
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. 
 
 
27 
• 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. 
 
 
 
 
 
 
 
28 
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, 
 
 
29 
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. 
 
 
30 
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. 
 
 
31 
_____. 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. 
 
 
 
	Conversa inicial
	TEMA 1 – comunicação fim a fim
	1.1 Circuito virtual
	TEMA 2 – Protocolo orientado para a conexão
	TEMA 3 – Protocolo não orientado À conexão
	TEMA 4 – Protocolos da camada de aplicação
	TEMA 5 – Redes sem fio para dispositivos
	FINALIZANDO
	REFERÊNCIAS
	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.