Laboratórios de Silício executou uma implantação de rede de validação Matter-over-Thread de 200 nós para provar a escalabilidade em {hardware} comercial de IoT.
O fabricante de semicondutores anunciou a implantação física no Aliança de Padrões de Conectividade (CSA) evento inaugural do Unify. Os dados de engenharia fornecem evidências documentadas de que o padrão Matter possui a capacidade de suportar ambientes expansivos associados a edifícios comerciais, fábricas e unidades residenciais múltiplas. A indústria está levando a tecnologia além dos testes iniciais de interoperabilidade para a execução de validações físicas em verdadeira escala empresarial.
Daniel Cooley, CTO da Silicon Labs, afirmou: “A Matter está evoluindo rapidamente de uma tecnologia doméstica inteligente para uma plataforma capaz de suportar implantações muito maiores.
“Este trabalho demonstra não apenas que Matter-over-Thread pode teoricamente ser dimensionado para milhares de dispositivos, mas também como a Silicon Labs está ajudando os clientes a implantar, gerenciar e preparar essas redes para o futuro por meio de inovações que abrangem tecnologias Matter, Thread e Multiprotocolo Simultâneo.”
Arquitetura do ambiente de produção
Os engenheiros construíram a rede de validação diretamente dentro do Silicon Labs Boston Connectivity Lab e nos escritórios corporativos ao redor para avaliar o desempenho em condições do mundo actual. A equipe de implantação evitou deliberadamente uma simulação de laboratório estéril, optando por distribuir o {hardware} por um ambiente contendo forte interferência de dispositivos ativos de escritório, incluindo doze redes Wi-Fi separadas, dispositivos Bluetooth ativos e tráfego de rede Thread corporativo padrão.
O structure físico compreendia 40 clusters de conectividade distintos distribuídos por toda a instalação. Cada cluster continha seis ‘Wi-fi Starter Kits’ hospedando uma placa de rádio específica, criando uma rede mesh densa abrangendo uma distância máxima de aproximadamente 50 metros entre os nós mais distantes. Todos os dispositivos foram configurados como dispositivos Full Thread.
Embora as instalações de instalações comerciais muitas vezes misturem endpoints de borda com dispositivos de roteamento, a equipe de engenharia optou por configurar cada nó como um roteador. Essa arquitetura enfatizou deliberadamente a capacidade do sistema de processar tráfego pesado em segundo plano gerado por operações padrão de manutenção de roteamento de rede.
O {hardware} subjacente consistia em placas de desenvolvimento BRD4187C equipadas com sistemas sem fio EFR32MG24 em chips. A infraestrutura de software program foi executada com base no FreeRTOS, utilizando treze threads de sistema operacional separados para atender operações simultâneas, análise de mensagens e rotinas de segurança.
A pilha Bluetooth da Silicon Labs permaneceu ativa nos chips durante a janela de teste, mas não processou dados ativos. O controle central foi feito por meio de um dispositivo Raspberry Pi de quatro gigabytes rodando Ubuntu 22.01.2 LTS e uma implementação OpenThread Border Router.
Remediando restrições técnicas
A implementação de uma rede de 200 nós em um espaço corporativo ativo expôs diversas restrições técnicas que exigiram ajustes de engenharia.
As estratégias iniciais de implantação dependiam do Bluetooth Low Power para comissionar dispositivos individuais na estrutura da rede. Os testes revelaram limitações distintas em relação ao alcance e à capacidade do dispositivo Bluetooth Low Power ao gerenciar ciclos de configuração automatizada em massa. O intervalo de sinal localizado frequentemente fazia com que os scripts de implantação automatizados falhassem antes de estabelecer credenciais de malha em todos os nós.
Para contornar essas restrições de {hardware}, a equipe de engenharia fez a transição para uma metodologia de comissionamento na rede. Nessa estrutura de remediação, os dispositivos são primeiro anexados à estrutura de malha Thread subjacente usando um conjunto de dados de rede fornecido por meio da interface de linha de comando do OpenThread Border Router.
Uma vez anexado à malha, cada nó de {hardware} registrou uma instância do Service Registration Protocol. O sistema de implantação emitiu então um comando de comissionamento na rede, completando o registro da malha com segurança na infraestrutura Thread estabelecida, sem exigir interações Bluetooth dependentes de proximidade. Essa abordagem alterada gerou uma taxa de sucesso de comissionamento de 100% em diversas iterações de teste, com média de sete segundos por nó particular person.
Surgiu um segundo obstáculo técnico relacionado à coleta de dados e à instrumentação de latência. As fases iniciais de teste basearam-se em impressões de interface de linha de comando padrão e registro em nível de software program para rastrear velocidades de propagação de mensagens
A equipe de engenharia descobriu que o tempo de processamento native necessário para gerar logs de texto por meio da pilha de software program do dispositivo aumentava a latência da camada de aplicação em aproximadamente 50%. Essa sobrecarga distorceu a precisão das métricas de desempenho, tornando-as inadequadas para avaliar a verdadeira experiência do usuário, como o atraso exato entre o pressionamento de um botão e a mudança de estado do conjunto de luz.
Os engenheiros resolveram essa distorção de medição desativando todos os dados de registro e roteamento do Matter em nível de software program por meio da ‘Interface de rastreamento de pacotes’ física. Esta interface é um sistema de depuração em nível de {hardware} que captura tráfego de radiofrequência ao vivo e eventos de depuração internos diretamente do sistema sem fio no chip por meio de pinos de entrada-saída de uso geral dedicados.
Ao extrair dados de tempo por meio de um backchannel físico conectado a um computador host, a equipe isolou eventos de execução da camada de aplicação com precisão de microssegundos, eliminando completamente a sobrecarga de registro de software program dos dados de desempenho finais.
Métricas de desempenho empíricas
Os parâmetros de validação visavam a funcionalidade de mensagens multicast, comunicações unicast e estabilidade de rede de longo prazo sob condições reais de implantação.
Os logs de desempenho das iterações de teste de 50, 100 e 150 nós revelaram uma curva de latência altamente estável. Nesses três tamanhos de rede, a latência média da camada de aplicação permaneceu estável em aproximadamente 91 milissegundos, com 95% de todos os comandos sendo processados dentro de uma janela de 110 milissegundos em vários tamanhos de carga útil.
A curva de desempenho alterou-se visivelmente durante a transição para a rede completa de 200 nós. A latência média do aplicativo aumentou para 116,51 milissegundos para cargas úteis de 8 bytes, 125,45 milissegundos para cargas úteis de 16 bytes, 124,11 milissegundos para cargas úteis de 32 bytes e 129,76 milissegundos para cargas úteis de 64 bytes. Mais importante ainda, a latência do percentil 95 aumentou acentuadamente, lendo 320 milissegundos para 8 bytes, 350 milissegundos para 16 bytes, 330 milissegundos para 33 bytes e 340 milissegundos para 64 bytes.
A investigação dos dados brutos expôs uma explicação física distinta para esta variação de desempenho, em vez de uma falha do protocolo principal. Os scripts de implantação automatizada ativaram dispositivos sequencialmente com base na ordem dos endereços de rede. Os 50 nós finais necessários para dimensionar a rede de 150 para 200 pontos finais foram posicionados fisicamente em uma zona de corredor de esquina das instalações de Boston. Essa área estrutural possuía apenas uma única linha de visão para o andar principal do escritório, transformando a entrada do corredor em um grave ponto de congestionamento sem fio.
A infraestrutura física forçou a rede a depender de encaminhamento multi-hop e extensa inundação de pacotes para alcançar os nós isolados do corredor. Colunas estruturais de concreto dentro do espaço de escritório bloquearam ainda mais os caminhos diretos de radiofrequência, desencadeando saltos de rede adicionais para navegar pelas paredes perpendiculares. Essa restrição topológica localizada causou diretamente o pico de latência visto no ultimate da distribuição de dados.
Apesar dessas restrições físicas, a rede manteve operação contínua, demonstrando menos de 1% de perda de pacotes para tamanhos de carga padrão em um teste de estresse contínuo de três horas.
Testes unicast controlados e estabilidade a longo prazo
Para isolar a latência incremental exata introduzida pelo encaminhamento multi-hop longe da interferência de escritórios ao ar livre, os engenheiros realizaram testes unicast separados em um ambiente de laboratório controlado. Esta avaliação utilizou caixas de isolamento Ramsey STE330 ligadas condutivamente por meio de cabos coaxiais blindados para formar uma topologia fixa de vários saltos variando de um a sete saltos.
O teste unicast monitorou a latência do estabelecimento de sessão autenticada por certificado juntamente com os tempos de ida e volta do comando da camada de aplicativo. A configuração da sessão de segurança representa uma operação computacional pouco frequente, mas obrigatória, necessária antes que as mensagens do aplicativo possam prosseguir.
Dados de laboratório indicaram que a latência de configuração da sessão foi escalonada linearmente com a distância, rastreando 65 milissegundos para um único salto, 150 milissegundos em três saltos, 251 milissegundos em cinco saltos e atingindo um pico de 352 milissegundos em um período de sete saltos.
Os tempos de ida e volta da camada de aplicação seguiram uma trajetória similarmente previsível com base no tamanho da carga útil e na contagem de saltos. Uma mensagem unicast de salto único exigia uma média de 62 milissegundos para uma carga útil de 8 bytes, aumentando para 105 milissegundos para uma carga útil de 296 bytes.
A uma distância de quatro saltos, o tempo médio de ida e volta cresceu para 204 milissegundos para 8 bytes e 324 milissegundos para 296 bytes. Na distância máxima de sete saltos, o {hardware} registrou latências médias de ida e volta de 341 milissegundos para cargas úteis mínimas de 8 bytes e 473 milissegundos para cargas úteis máximas de 296 bytes.
O sistema manteve perda zero de pacotes em todas as contagens de saltos testadas durante essas avaliações unicast. O aumento gradual nos tempos de resposta decorre diretamente da sobrecarga de decodificação criptográfica padrão, da análise de pacotes dentro da camada de software program multithread e da fragmentação de transmissão exigida pela camada de rádio Thread subjacente.
Esses dados estabelecem parâmetros de implantação claros, confirmando que, embora o Matter-over-Thread lide naturalmente com grandes áreas físicas sem configurações manuais de roteamento, as decisões localizadas de structure físico e os materiais estruturais governam a capacidade de resposta ultimate da rede.
Veja também: Automação industrial impulsiona 5G privado após 2.000 implantações
Quer saber mais sobre a IoT com os líderes do setor? Confira Exposição de tecnologia IoT acontecendo em Amsterdã, Califórnia e Londres. O evento abrangente faz parte TechEx e está co-localizado com outros eventos de tecnologia líderes, incluindo Expo IA e Huge Information e o Expo Segurança Cibernética. Clique aqui para mais informações.
IoT Information é alimentado por Mídia TechForge. Discover outros eventos e webinars de tecnologia empresarial futuros aqui.