Rede interna: por onde começamos?

Devemos acreditar em algumas afirmativas quando pensamos na rede interna de comunicação de uma edificação:

• Não há uma solução única;
• Não há solução milagrosa;
• Qualidade, barato/caro, relação benefício/custo, IoT, automação, integração, prédio inteligente, etc, são conceitos que precisam ser discutidos e entendidos antes de se falar em quais serão as escolhas;
• Não se engane. Escolha no máximo duas metas entre: "barato", "rápido" e "bom" (barato e rápido não é bom, bom e barato não é rápido, bom e rápido é caro);
• A "melhor solução" é sempre eleita a partir de uma matriz multidimensional de compromissos: requisitos do proprietário, principalmente em relação aos recursos e ao conforto desejados, adequação da edificação à sua missão, grau de colaboração da rede interna com o negócio, normas técnicas, custo, entre outros;
• As dimensões dessa matriz não são variáveis independentes. Todas nos levam, inevitavelmente, à dimensão "custo" e as relações entre elas não são lineares nem simples.

Ao contratar a elaboração do projeto da rede interna de uma edificação, a primeira pergunta a ser feita deve ser "como a energia elétrica será distribuída?"

Basicamente temos três alternativas:

·  Instalação elétrica convencional: não possui qualquer automação. Os quadros  elétricos alimentam circuitos de iluminação e tomadas, sem qualquer controle automatizado.

·  Instalação elétrica automatizada com distribuição em baixa tensão alternada (110 ou 220 volts). Os circuitos podem ser interrompidos ou dimerizados, conforme  o projeto;

·    Instalação elétrica automatizada para a iluminação, com distribuição em baixa tensão contínua (40 a 60 volts) com sensoriamento (iluminação, temperatura e movimento), e baixa tensão alternada (110 ou 220 volts) para as tomadas. Haverão dois tipos de circuitos: AC (corrente alternada) e DC (corrente contínua);

Ao se escolher a primeira opção, estaremos praticamente eliminando a automação do projeto da rede interna, obviamente, uma vez que a iluminação e as tomadas são o principal foco da automação. Mas é possível que ainda seja desejada alguma automação de outros subsistemas, como motores, controle de acesso, sonorização, etc. Esta alternativa é a que tem os menores custos de implantação e manutenção.

Ao se escolher a segunda opção, abrimos um leque de possibilidades para controlar o fornecimento de energia na edificação. Atualmente a diferença do custo de implantação desta para a primeira alternativa é pequena - diria que fica entre  10 e 20%. Considerando que uma instalação elétrica custa cerca de 5% do valor da obra, estamos falando de 0,5 a 1% de acréscimo no custo global da obra para se obter uma edificação automatizada. A desvantagem aqui é a manutenção, que pode ser um pouco mais cara. Minha recomendação é que a escolha, entre as duas primeiras alternativas, grosso modo, seja pela segunda. Esta é uma abordagem simplificada. Naturalmente há outros aspectos envolvidos.

A terceira alternativa consiste em enviar energia para as luminárias utilizando um cabo de rede comum (categoria 5e ou 6) e enviar/receber comandos da luminária por esse mesmo cabo de rede. A tecnologia para alimentar dispositivos remotos pelo cabo de rede já está padronizada desde 2003 e é conhecida como PoE (Power over Ethernet). Leia artigo  PoE e a alimentação pelo cabo de rede

A tecnologia de alimentar luminárias por cabo de rede também está sendo chamada de "teto inteligente" (smart ceiling) e iluminação PoE (PoE lighting). Desta forma as luminárias seriam conectadas diretamente a switches de rede com capacidade de PoE, ou um sistema similar. Os padrões estão caminhando para se conseguir enviar 100 W pelo cabo de rede, mas atualmente, o padrão 802.3at consegue alimentar tranquilamente uma luminária de LED com até 25 W. Alguns fabricantes de luminárias estão desenvolvendo LEDs mais eficientes, o que leva a edificação mais perto de um projeto "à prova de futuro", mais verde, mais flexível. Entretanto, a terceira alternativa ainda possui um custo elevado e falta padronização de mercado. Leia artigo Quarta Geração de Iluminação Elétrica: O Fim do Quadro Elétrico

O custo desta alternativa pode ultrapassar o dobro da anterior. O principal benefício é que teremos uma malha de sensores, em geral dois ou três sensores (temperatura, iluminação e movimento) por luminária, que ajuda a mapear o que está acontecendo na edificação e, portanto, reduz ainda mais o consumo de energia, colabora com o sistema de segurança, e envia informações de ocupação dos ambientes. Apesar de apresentar algumas vantagens que não temos na alternativa anterior, resta saber se o benefício vale o acréscimo de custo a ser pago.

Uma das vantagens da automação é fornecer flexibilidade à edificação, capacidade de se comportar de diferentes formas, inclusive coletando não só parâmetros de máquinas (medidores e sensores), mas também dos humanos (indicadores de opinião dos usuários da edificação), que alimentarão o cérebro da automação para transformar a edificação em um ambiente mais agradável, útil e econômico.

De qualquer forma, a pergunta não deve ser respondida de pronto. É um assunto a ser pensado juntamente com o proprietário.

A Internet das coisas médicas e a rede interna

Qual a relação entre a IOT (Internet Of Things), ou Internet das coisas, a medicina e a rede interna de comunicação de uma edificação?

IOT é a denominação de uma rede de comunicação de dados em que dispositivos, sensores, processadores e atuadores, se comunicam sem fio, entre si e com outros pontos de acesso em rede como os Access Points da rede WiFi. 

Sem entrar no mérito se o nome traduz corretamente o que "IOT" significa, sabemos que a Internet é apenas um recurso que pode ser alcançado pelos dispositivos da rede interna da edificação, com ou sem IOT.

Mais popularmente, IOT é um sistema de comunicação, principalmente entre "coisas pequenas", como: celular com o relógio de pulso, sensor de pressão preso ao corpo com o celular,  etc, que podem também ter acesso à rede WiFi da edificação e, portanto, ganhar o mundo via Internet.

Conceitos como "casa inteligente", "loja inteligente", "cidade inteligente", "veículos conectados", "automação residencial", "BAN" (Body Area Network) ou rede de comunicação corporal, sensoriamento de indicadores da saúde, sensoriamento da atividade do corpo, estão intimamente ligados ao conceito genérico de IOT, obviamente, uma vez que vários dispositivos devem se comunicar.

Já há algum tempo em que se fala que a IOT vai transformar a sociedade. Especialmente, a medicina, tem muito a ganhar com essa onda, e todos nós agradecemos.

Atualmente há uma total dependência do paciente em se deslocar até as edificações médicas para consulta, diagnóstico e tratamento.

Dispositivos presos aos corpos dos pacientes, com capacidade de monitoramento, processamento e comunicação, já são uma realidade.

Por exemplo, um dispositivo fabricado pela Quell (https://www.quellrelief.com), ilustrado na figura, que se instala no corpo, associado ao seu aplicativo próprio para smartfone, executa sessões de terapia neurológica para combater dores crônicas associadas a doenças diversas, tais como diabetes, por meio de estímulos neurológicos intensivos em alta frequência (entre 50 e 100 Hz). 

Segundo o fabricante,  a eletroterapia envia estímulos à medula espinhal, cujo efeito analgésico bloqueia a dor e provoca alívio generalizado, não apenas em uma parte específica do corpo, inclusive durante o sono. O dispositivo corporal se comunica com o smartfone normalmente por BLE (Bluetooth Low Energy). O aplicativo instalado no smartfone controla as sessões eletroterápicas, coletando indicadores corporais, ajustando a intensidade, etc, que podem ser compartilhados pela rede WiFi da edificação ou mesmo via conexões 3G/4G, para monitoramento remoto do paciente.

Outros dispositivos executam funções de forma programada, monitorada e controlada, como os monitores de glicose, aplicadores de insulina para diabéticos, sensores de queda para idosos e até desfibriladores automáticos para portadores de deficiência cardíaca com risco de infarto.

Quanto à comunicação entre o dispositivo e nosso aparelho celular, que faz parte da BAN ou rede de comunicação corporal, tende a ser via BLE, também conhecida por Bluetooth Smart, protocolo que opera na faixa de 2,4 GHz, com taxa de transmissão de até 1 Gbps e alcance até 20 metros. Presente na maioria dos smartfones juntamente com o Bluetooth comum, o BLE possui estratégia de transmissão de dados diferente do Bluetooth comum, inclusive com menor demanda de potência.

Nos ambientes hospitalares, onde a  banda de 2,4 GHz é também ocupada pelos rádios da rede WiFi, é preciso atenção no projeto para evitar interferências. O aspecto "segurança" deve ser levado em consideração no projeto, podendo ser reforçado com medidas adicionais.

A comunicação sem fio, característica básica da IOT, pode lançar mão de outros protocolos. Em especial temos o NFC (Near-Field Communication), ou comunicação em campo próximo, cujo alcance vai até 10 cm. Sua aplicação é distinta do BLE. No caso da rotina hospitalar, serve para coletar dados aproximando o leitor, que pode ser um celular, do dispositivo corporal preso ao corpo do paciente, podendo ainda apresentar resultados, processados pelo aplicativo, em função desses dados, agilizando sobremaneira o atendimento. 

Este protocolo também é interessante para transferência de dados gerais entre dispositivos, apenas pela aproximação deles, como um pagamento, por exemplo, com segurança, desde que nenhum outro dispositivo esteja a menos de 10 cm dos dois dispositivos em comunicação.

A possibilidade de comunicação entre esses pequenos dispositivos e a rede interna da edificação, saindo para a Internet, é que muda tudo. A possibilidade de monitoramento e diagnóstico remoto, em tempo real, permite um grande avanço, tanto na medicina preventiva como no tratamento de doenças crônicas, levando boa parte dos pacientes do hospital para casa.

Uma edificação, erguida para servir por um tempo de 50 anos ou mais,  deve estar equipada com uma rede interna capaz de atender as demandas de IOT para, no mínimo, os próximos 15 anos sem precisar de qualquer alteração de sua infraestrutura e estar preparada para sofrer modificações e ampliações nos próximos 50 anos, mas que sejam minimamente invasivas.

A afirmação do parágrafo anterior é válida para qualquer tipo de edificação, entretanto, como um hospital é muito mais sensível a obras em seu interior e essas obras devem ser evitadas a todo custo, é bom começar com um projeto adequado da sua rede interna de  comunicação, que considere, entre outros aspectos, a massificação do uso de IOT.

A conclusão é que IOT, na forma mais avançada que possamos imaginar hoje, apesar de parecer futurismo, é uma realidade quando se fala em projeto de rede interna. A tendência de vestirmos esses pequenos dispositivos que querem se comunicar com seus controladores e monitores humanos, para o nosso bem, espero, é nítida.

Facebook e o switch Wedge 100

Com o título "Wedge 100: Mais aberto e mais versátil que nunca " O Facebook acaba de anunciar em seu site a segunda geração de seu switch e que continua focando a evolução de seus data centers com base no projeto OCP - Open Compute Project, do qual já falei aqui duas vezes (Microsoft, Facebook e o switch de rede e Switch Facebook), e informa que a especificação do switch Wedge 100, a segunda geração de switches desenvolvida pelo projeto, foi aceita pelo OCP.

Segundo o Facebook, o switch Wedge 100 é elemento chave na constante evolução dos seus data centers.

Wedge 100 é uma evolução do Wedge 40. É um switch "top-of-rack" com 32 portas de até 100 Gbps que utiliza ASICS  Tomahawk produzidos pela Broadcom e sua linha de produção deve iniciar até o final deste ano.

O "switch de dados" é de fato o elemento chave em qualquer rede interna, principalmente quando se fala de data center, onde a taxa de transmissão é o calcanhar de Aquiles. Para atender a todas as requisições dos usuários, o datacenter não pode economizar "velocidade".

O projeto OCP, iniciado há cerca de seis anos, está mudando o paradigma do hardware de rede de forma semelhante ao que aconteceu com o Linux: um código aberto que pode ser alterado e utilizado por quem quiser.

Bem, conhecemos a história do Linux e sabemos que ele não matou a Microsoft, mas que o projeto OCP está tirando o sono dos grandes players da indústria de equipamentos de rede, isso é certo.

Microsoft, Facebook e o switch de rede

Não resta dúvidas quanto à importância do "switch de dados" em uma rede interna, já que ele é o concentrador dos fluxos de dados vindos dos diversos dispositivos ligados em rede. Seu "QI", se é que  posso utilizar esse termo, ou seja, sua capacidade de identificar os pacotes de dados que recebe, entender suas prioridades e necessidades (grau de importância e urgência sobre outros tipos de pacotes, taxa máxima admitida para perda dos pacotes, largura de banda necessária, tempo máximo de latência, etc.), atender aos requisitos e encaminhar os pacotes aos respectivos destinos, é parte integrante do QI da infraestrutura de rede.

 A idéia deste blog não é atuar na arena do futurismo, mas esse movimento, com a participação do Facebook e agora recebendo adesões de peso, não poderia deixar de ser comentado.

Em Junho de 2014 publiquei o artigo "Switch Facebook", quando comentei sobre o projeto OCP - Open Compute Project, lançado em 2012 pelo Facebook.

Então, não poderia deixar de comentar sobre o anúncio, divulgado esta semana, de que a Microsoft decidiu se juntar ao Facebook no projeto OCP e abrir o  código fonte de seu pacote de software denominado SONiC[1] -  Software for Open Networking in the Cloude, desenvolvido em conjunto com as empresas Arista, Broadcom, Dell e Mellanox.

O projeto OCP ganhou força.

O switch foi picado e recebeu o vírus do Linux. Seu DNA está sujeito a mutações importantes.

Essa decisão é uma ameaça aos planos dos fabricantes tradicionais de switch, principalmente a Cisco, o maior deles. A expectativa dos engenheiros de rede é que eles repensem sobre a questão da produção de equipamentos com inteligência proprietária versus a plataforma aberta do projeto OCP, sob pena de perderem mercado.

As operações em nuvem (Cloude Computing) vem ganhando espaço nas infraestruturas de rede das corporações, o que exige taxas de transmissão cada vez mais altas, mais segurança e requisitos de padronização das plataformas do software de controle das comunicações.

Correndo em paralelo, as operações Big Data e as redes das coisas (IoT - Internet of Things) estão, juntamente com os fluxos de vídeo (video streams), cada vez mais, gerando volumes de informações que devem circular pelas redes internas, pelas redes externas e, parte disto, com destino a data centers.

Esses aspectos, além de nos fazerem pensar mais à frente, pois temos projetos em nossa mãos, pedem uma infraestrutura de rede que seja flexível e de rápida adequação a novos requisitos a fim de reduzir os riscos (baixo desempenho, perda de investimento).

A adesão da Microsoft ao OCP visa facilitar a entrada e a implantação de seus produtos para computação em nuvem em ambientes com diversas plataformas de infraestrutura de rede e switches de fabricantes diversos.

A padronização sempre foi uma questão fundamental no avanço das redes. Hoje mais do que nunca. Os fabricantes passaram a considerar estratégico participar de associações de elaboração de normas, bem como formar grupos de colaboração para definir normas que eliminem problemas de interconexão.

A dianteira tecnológica obtida por um fabricante está cada vez menor e mais volátil. Portanto, mais do que nunca é preciso estar na frente, como naquela história em que dois amigos, na mata, ouviram o rugido de um leão. Um deles, ao ver que o amigo resolveu calçar o tênis, perguntou se ele pretendia correr mais do que o leão. A resposta foi que ele só pretendia correr um pouco mais do que o amigo.

SDN - Software Defined Networking, ou "operação em rede definida por software", é um conceito recente, cujo objetivo é estabelecer equipamentos de rede (principalmente switches e roteadores) cujas características possam ser definidas por software, de forma padronizada, permitindo assim a rápida adequação do hardware às demandas de tráfego e, consequentemente, uma infraestrutura de rede mais flexível e eficiente. O conceito, portanto, se aplica a redes locais e de longa distância.

O SONiC é um pacote de software baseado em Linux, originalmente preparado para rodar sob a distribuição Debian, aderente ao conceito SDN, com funcionalidades de camada 3 (Layer 3, roteamento), que permite utilizar a mesma pilha de firmware (software de controle de hardware) em switches de vários fabricantes, em conjunto com a SAI (Switch Abstraction Interface)[2], um API definido em linguagem C para comando de circuitos integrados de comutação (ASICs), utilizados pelos switches.

Os switches passaram por algumas mudanças de paradigma ao longo dos anos, desde sua concepção, quando ainda eram chamados de "bridge". Uma delas foi o rompimento da barreira da camada 2 (Layer 2), incorporando funcionalidades da camada 3. Agora, acho que podemos considerar que está em curso mais uma mudança de paradigma: o hardware padronizado e aberto, com suporte a um sistema de gerenciamento global. O sinal é a padronização que está sendo patrocinada pelo projeto OCP, reforçado pela adesão do SONiC.

A figura 1 é uma tentativa de ilustrar a evolução da padronização na comunicação de dados, dividindo-a em três eras.

A primeira era é a dos mainframes, dos grandes fabricantes, como IBM e Fujitsu, com todos os elementos proprietários. Tem como características principais, além do domínio absoluto de um fabricante sobre a solução, a dificuldade em interconectar sistemas  de fabricantes diferentes e a "lenta" evolução tecnológica.

Fig. 1: Evolução da padronização na comunicação de dados

Era	Hardware	Sistema Operacional	Protocolo camadas 1 e 2	Protocolo camada 3	Protocolo de Roteamento	Protocolo de gerência
1	proprietário	proprietário	proprietário	proprietário	proprietário	proprietário
2	proprietário	proprietário	Ethernet	IP	OSPF	proprietário
3	proprietário	proprietário	Ethernet	qualquer	qualquer	OpenFlow
	aberto	aberto	Ethernet	qualquer	qualquer	OpenFlow

Na segunda era, a força dos protocolos Ethernet e IP (suite completa) facilitaram bastante a interconexão das redes, porém, além  do hardware e do software, os protocolos de gerenciamento continuaram proprietários, persistindo a grande dificuldade em configurar a rede toda de forma holística.

Apesar de haver protocolos de roteamento, abertos e disponíveis, como o OSPF, estes não possuem capacidade de atuar nas tabelas de roteamento dos roteadores e switches de forma adequada a partir de uma visão geral da rede, sendo impraticável o combate eficaz aos congestionamentos em determinados nós da rede, uma vez que a distribuição do tráfego é aleatória e foi agravada recentemente pela proliferação dos dispositivos móveis e sistemas em nuvem.

Outra dificuldade existente é o projeto da rede e o teste de validação de sua configuração que muitas vezes, por exigir um esforço enorme de laboratório e ajuste de configurações se torna praticamente inviável levando a implantação a se arrastar mais do que seria desejável.

Uma das ideias intrínsecas do SDN é que os equipamentos switches e roteadores possuam uma camada de software de gerenciamento que opere como um driver para o software de gestão da rede, que permita receber informações de roteamento, obviamente colhidas com visão holística, envie informações de tráfego e troque requisitos de rede  com o sistema de gerenciamento.

Outro aspecto desejável par o SDN é que ele consiga reservar partições da sua capacidade de transmissão (banda disponível em bits por segundo) para rodar um sistema em rede de forma  independente do que está em produção e sem interferir nele. Similar a uma VLAN. Assim, outros protocolos podem ser testados ao vivo (on the fly) como alternativas ao OSPF ou até mesmo ao IP, por exemplo. Este aspecto deve acelerar sobremaneira o desenvolvimento de novas soluções de roteamento em rede.

Baixar a versão em PDF

---

[1] O código fonte do SONiC está disponível em GitHub

[2] Switch Abstraction Interface

Sonorização de vários ambientes pequenos

Os usuários de pequenos ambientes, como salas de recepção de clínicas e escritórios, quartos de hotel e hospital, salas de espera, pequenas salas de reunião, salas de aula, salas de terapia e massagem, entre outros, são sistematicamente punidos com um som de baixa qualidade alimentados diretamente pelos alto-falantes da TV ou, quando muito,  por um sistema pouco flexível.

Ao desenhar a sonorização de uma edificação que possui vários ambientes pequenos e que podem ser ligados ao sistema geral de sonorização, como por exemplo as salas de espera de uma clínica médica, cada uma com uma TV, o projetista já começa com um dilema: será que coloco um  amplificador em cada local? Se não colocar, o som da TV ficará horrível. Se colocar,  como vou regular o volume e como vou abaixar o volume  para permitir que os avisos sejam inteligíveis?

Se você pensar na sonorização de quartos de hotel, o problema é parecido mas não é igual: como faço para que o hóspede possa ouvir o som da TV com  fones de ouvido para não  incomodar a esposa que quer dormir? Como conectar o próprio celular ou iPad do hóspede para gerar um  som de qualidade no aposento? e se o hóspede quiser apenas ouvir uma rádio ou música ambiental? e se for requisito do hotel que os aposentos possuam alto-falantes para receberem avisos em caso de incêndio ou outro incidente?

Bem, assim poderíamos elencar outros ambientes pequenos e suas particularidades, que devem ser tratadas pelo projetista para dar a solução desejada pelo proprietário. É comum encontrar vários tipos de ambientes pequenos em uma mesma edificação: salas de reunião, salas de espera, etc. A conexão, ou não, desses ambientes ao sistema central de sonorização é um aspecto importante do projeto.

Se o leitor é um projetista de sistemas de áudio, tenho certeza que já se deparou com essa questão.

Há várias soluções para se desenhar um sistema de mini ambientes sonorizados, com qualidade e custo adequado. O problema é que isso não é feito, por diversas razões. Uma delas é o custo de uma solução correta e flexível. Outra é a dificuldade de instalação e manutenção dessas soluções. Por essas e outras razões, alguns projetistas entregam os pontos e partem para uma solução "meia-boca", cujo  custo, perda na qualidade e baixa flexibilidade possam ser aceitos pelo proprietário. Se não houver interesse do proprietário pela qualidade e flexibilidade provavelmente a solução será deixar a TV com seu som original. Aliás, é comum encontrar essas TVs mudas ou gerando ruído (considerando que ruído é tudo aquilo que não se deseja ouvir).

Mas esse sofrimento tem cura.

Acaba de chegar um remedinho moderno, sem efeitos colaterais e mais eficiente dos que já estão disponíveis aos projetistas de sonorização de rede interna.

A Rhox (tel. 061-3051-5800), distribuidor da Rane, fabricante de equipamentos de som para profissionais, com sede nos Estados Unidos, acaba de lançar no Brasil o dispositivo RAD26, específico para essas aplicações.

O RAD26 é um pequeno dispositivo remoto de áudio digital, do tamanho aproximado de um espelho de interruptores comuns (4x4) que pode ficar instalado na parede e se conecta fisicamente ao processador central de áudio da edificação por meio de um cabo de rede.

Fig. 1: Painel do dispositivo RAD26

O dispositivo possui uma conexão digital com o processador central pela qual ele pode receber dois canais de áudio e enviar dois canais de áudio.

O painel frontal permite que o usuário selecione a fonte de áudio desejada e controle o volume.

Além dos canais de áudio remoto, o dispositivo possui entradas e saídas locais. Assim, a saída da TV, um celular e um microfone  podem ser ligados a ele. O dispositivo possui também um amplificador interno de 8 Watts que pode sonorizar o ambiente local sem ter que instalar um amplificador específico para isso, uma saída para fone de ouvido e duas saídas de linha que podem, opcionalmente, ser utilizadas para ligar a um amplificador externo, caso o ambiente precise de mais potência.

A figura 2 mostra o diagrama do RAD26.

Fig. 2: Diagrama do dispositivo RAD26

Como se isso não fosse o bastante, o dispositivo possui 3 entradas lógicas que podem servir como sensores para o sistema central, indicando, por exemplo, se a porta ficou aberta, e 3 saídas lógicas, que podem servir para acionar um projetor, abaixar/levantar uma tela de projeção, apagar uma luz, etc. Essas portas podem também ser conectadas ao sistema de automação predial.
Para obter o artigo completo na versão PDF:

http://www.fabiomontoro.com.br/artigos-2/

Padrão de comunicação na rede interna

Praticamente toda a comunicação de dados na parte cabeada das redes internas, atualmente, segue o consolidado padrão "Ethernet", baseado em codificação digital em banda base, desenvolvido e publicado pelo Instituto dos Engenheiros Elétricos e Eletrônicos dos Estados Unidos, IEEE (Institute of Electrical and Electronics Engineers, Inc.), batizado de IEEE 802.3.

O IEEE é uma associação de profissionais, fundada em janeiro de 1963, pela fusão de duas associações americanas com foco em engenharia elétrica, existentes na época. Já começou com 150 mil associados. Hoje é a maior associação profissional do mundo, com mais de 400 mil associados em mais de 160 países.

O padrão Ethernet especifica vários formatos de comunicação de dados, usando par trançado de cobre, cabo coaxial e fibra óptica, com taxas de transmissão que variam de 1 Mbps a 100 Gbps. Foi desenvolvido ao longo do tempo, com a contribuição de vários profissionais, em um processo de convergência consensual, com reuniões de discussão e votação, até culminar em uma versão final, aprovada, que segue para publicação. A versão atual é a de 2012 (IEEE 802.3-2012), composta de 6 partes, num total de 3.748 páginas:

Parte	Assunto	Quantidade de páginas
1	Introdução	634
2	Comunicação a 100 Mbps	780
3	Comunicação a 1 Gbps	358
4	Comunicação a 10 Gbps	732
5	Ethernet na 1ª milha	844
6	Eficiência energética	400

Além da norma principal, que é a 802.3, o IEEE vem emitindo outras, que tratam de assuntos específicos, relacionados à comunicação Ethernet. Por exemplo:

Norma	Data	Assunto
IEEE 802.3z	1998	Gigabit Ethernet
IEEE 802.3ab	1998	1000BaseT
IEEE 802.3ac	1998	VLAN
IEEE 802.3ad	2000	Link agregation
IEEE 802.3ae	2002	10 Gbps Ethernet
IEEE 802.3af	2003	PoE   15 W
IEEE 802.3at	2009	PoE   30 W
IEEE 802.3bt	Em elaboração	PoE 100 W
IEEE 802.3ah	2004	Ethernet 1ª milha
IEEE 802.3av	2009	EPON 10 Gbps sobre fibra óptica
IEEE 802.3ba	2010	Ethernet 40 e 100 Gbps em cobre
IEEE 802.3bm	2015	Ethernet 40 e 100 Gbps em fibra
IEEE 802.3bn	Em elaboração	EPoC - EPON sobre cabo coaxial
IEEE P802.3bs	Em elaboração	400 Gbps Ethernet

A  norma 802.3, em sua edição de 2012 incorporou todas as normas anteriores, como a IEEE 802.3u (100 Mbps, chamada de Fast Ethernet), IEEE 802.3x (operação Full duplex e controle de fluxo), IEEE 802.3z (1000 Mbps, chamada de Gigabit Ethernet), IEEE 802.3ae (10 Gbps), IEEE 802.3ah (Acesso Ethernet ou Ethernet na Primeira Milha), IEEE 802.3ba (40 e 100 Gbps). Então, as normas anteriores a 2012 não serão mais mantidas como documentos individuais. Apesar de terem sido incorporadas pela edição de 2012 da IEEE 802.3, ainda é comum encontrar esses padrões citados em folhetos de equipamentos. A rigor, a partir de 2012, os fabricantes deveriam mencionar as cláusulas da norma 802.3-2012, que seus equipamentos atendem.

Da mesma forma que para a parte cabeada, a parte sem fio da rede interna segue padrões ditados pelo IEEE, mais especificamente a série 802.11, que vem aumentando a taxa de transmissão, com previsão de passar de 20 Gbps em 2018, como ilustra a figura.

  

 A demanda futura por altas taxas de transmissão de dados deve ser considerada durante os projetos das redes internas. Tentar apenas  prever uma rede wireless com alta taxa de transmissão não é suficiente. A parte cabeada da rede, que dá suporte à parte sem fio (wireless), deve receber a devida atenção. A rede wireless é mais fácil de ser substituída por uma nova geração, já que depende de equipamentos ativos, considerando, claro, que o cabeamento suporte a mudança.

A próxima figura mostra o desenho feito por Robert Metcalfe, inventor do Ethernet, que foi um dos slides quando apresentou pela primeira vez sua invenção, em junho de 1976, na Conferência Nacional de Computação (National Computer Conference).