SILICON LABS UG103.11 Software Fundamentos de Thread

Especificacións:

• Nome do produto: Thread Fundamentals
• Fabricante: Silicon Labs
• Protocolo: Thread
• Versión: Rev. 1.6
• Protocolo de rede sen fíos: rede de malla
• Estándares admitidos: IEEE, IETF

Información do produto

Thread Fundamentals é un protocolo de rede de malla sen fíos seguro desenvolvido por Silicon Labs. Admite enderezos IPv6, pontes de baixo custo con outras redes IP e está optimizado para un funcionamento de baixo consumo e con batería. O protocolo está deseñado para casas conectadas e aplicacións comerciais onde se desexa unha rede baseada en IP.

Instrucións de uso

1. Introdución aos fundamentos de Thread:
   Thread é un protocolo de rede de malla sen fíos seguro que se basea nos estándares IEEE e IETF existentes. Permite a comunicación de dispositivo a dispositivo en casa conectada e aplicacións comerciais.
2. Implementación de OpenThread:
   OpenThread, unha implementación portátil do protocolo Thread, ofrece comunicación sen fíos de dispositivo a dispositivo fiable, segura e de baixa potencia para aplicacións de edificios domésticos e comerciais. Silicon Labs ofrece un protocolo baseado en OpenThread adaptado para funcionar co seu hardware, dispoñible en GitHub e como parte do SDK Simplicity Studio 5.
3. Pertenza ao grupo de discusións:
   Unirse ao grupo Thread proporciona acceso á certificación do produto e promove o uso de dispositivos habilitados para Thread. As versións sucesoras da especificación Thread anúncianse con programas de certificación en 2022.

FAQ:

• P: Como podo descargar a última especificación de fíos?
  R: A última especificación de fíos pódese descargar enviando unha solicitude no grupo de fíos websitio en https://www.threadgroup.org/ThreadSpec.
• P: Cal é a principal vantaxetage de usar Thread en dispositivos IoT?
  R: Thread ofrece un protocolo de rede de malla sen fíos seguro que admite operacións de baixa potencia e comunicación de dispositivo a dispositivo, aumentando as taxas de adopción e a aceptación dos usuarios para os dispositivos IoT.

UG103.11: Fundamentos de fíos

• Este documento inclúe un breve antecedente sobre a aparición de
• Thread, ofrece unha tecnoloxía máisview, e describe algunhas características clave de Thread a ter en conta ao implementar unha solución Thread.
• A serie Fundamentals de Silicon Labs abarca temas que os xestores de proxectos, os deseñadores de aplicacións e os desenvolvedores deben comprender antes de comezar a traballar nunha solución de rede integrada usando
• Chips de Silicon Labs, pilas de redes como EmberZNet PRO ou Silicon Labs Bluetooth® e ferramentas de desenvolvemento asociadas. Os documentos poden usarse como punto de partida para quen necesite unha introdución ao desenvolvemento de aplicacións de rede sen fíos ou que sexa novo no ambiente de desenvolvemento de Silicon Labs.

PUNTOS CLAVE

• Introduce Thread e ofrece unha tecnoloxía superiorview.
• Describe algúns dos elementos clave de Thread, incluíndo a súa pila IP, a topoloxía de rede, o enrutamento e a conectividade de rede, a unión a unha rede, a xestión, os datos persistentes, a seguridade, o enrutador fronteirizo, a posta en servizo do dispositivo e a capa de aplicación.
• Contén actualizacións para Thread Specification 1.3.0.
• Inclúe os seguintes pasos para traballar coa oferta OpenThread de Silicon Labs.

Introdución

1. Silicon Labs e Internet das Cousas
   • A versión 4 do protocolo de Internet (IPv4) foi definida en 1981 na RFC 791, Especificación do protocolo do programa de Internet DARPA. ("RFC" significa "Request for Comments"). Usando o enderezo de 32 bits (4 bytes), IPv4 proporcionou 232 enderezos únicos para dispositivos en Internet, un total de aproximadamente 4.3 millóns de enderezos. Non obstante, a medida que o número de usuarios e dispositivos creceu exponencialmente, estaba claro que se esgotaría o número de enderezos IPv4 e existía a necesidade dunha nova versión da IP. De aí o desenvolvemento do IPv6 na década de 1990 e a súa intención de substituír a IPv4. Cun enderezo de 128 bits (16 bytes), IPv6 permite 2128 enderezos, máis de 7.9 × 1028 enderezos que IPv4 (http://en.wikipedia.org/wiki/IPv6).
   • O reto para as empresas da industria integrada como Silicon Labs é abordar esta migración tecnolóxica e, máis importante, as demandas dos clientes a medida que nos movemos a un mundo de dispositivos sempre conectado no espazo doméstico e comercial, ao que a miúdo se denomina como Internet das Cousas (IoT). A un alto nivel, os obxectivos de IoT para Silicon Labs son:
   • Conecta todos os dispositivos do espazo doméstico e comercial coa mellor rede da súa clase, xa sexa con Zigbee PRO, Thread, Blue-tooth ou outros estándares emerxentes.
   • Aproveita a experiencia da empresa en microcontroladores amigables coa enerxía.
   • Mellora os chips establecidos de baixa potencia e sinal mixto.
   • Proporcionar pontes de baixo custo aos dispositivos Ethernet e Wi-Fi existentes.
   • Activa os servizos na nube e a conectividade para teléfonos intelixentes e tabletas que promoverán a facilidade de uso e unha experiencia de usuario común para os clientes.
     A consecución de todos estes obxectivos aumentará as taxas de adopción e a aceptación dos usuarios para os dispositivos IoT.
2. Grupo de fíos
   • Grupo de fíos (https://www.threadgroup.org/) lanzouse o 15 de xullo de 2014. Silicon Labs foi unha empresa fundadora xunto con outras seis empresas. Thread Group é un grupo de educación de mercado que ofrece certificación de produtos e promove o uso de produtos de dispositivo a dispositivo (D2D) e máquina a máquina (M2M) habilitados para Thread. A pertenza ao grupo Thread está aberta.
   • A especificación do fío 1.1 pódese descargar despois de enviar unha solicitude aquí: https://www.threadgroup.org/ThreadSpec. Tamén se anunciaron versións sucesoras da especificación Thread, 1.2 e 1.3.0, con programas de certificación en 2022. A última especificación Thread de borrador 1.4 só está dispoñible para os membros de Thread.
3. Que é Thread?
   Thread é un protocolo de rede de malla sen fíos seguro. A pila Thread é un estándar aberto que se basea nunha colección de estándares existentes do Instituto de Enxeñeiros Eléctricos e Electrónicos (IEEE) e Internet Engineering Task Force (IETF), en lugar dun estándar totalmente novo (consulte a seguinte figura).
4. Características xerais do fío
   • A pila Thread admite enderezos IPv6 e ofrece conexións de baixo custo a outras redes IP e está optimizada para o funcionamento de baixo consumo/batería e a comunicación sen fíos de dispositivo a dispositivo. A pila Thread está deseñada especificamente para casas conectadas e aplicacións comerciais nas que se desexa unha rede baseada en IP e se poden usar unha variedade de capas de aplicacións na pila.
   • Estas son as características xerais da pila Thread:
   • Instalación, posta en marcha e operación sinxelas da rede: a pila Thread admite varias topoloxías de rede. A instalación é sinxela usando un teléfono intelixente, tableta ou ordenador. Os códigos de instalación do produto utilízanse para garantir que só os dispositivos autorizados poidan unirse á rede. Os protocolos sinxelos para formar e unir redes permiten que os sistemas se autoconfiguren e arranxen os problemas de enrutamento a medida que se producen.
   • Seguro: os dispositivos non se unen á rede a menos que estean autorizados e todas as comunicacións estean cifradas e seguras. A seguridade ofrécese na capa de rede e pode estar na capa de aplicación. Todas as redes Thread están cifradas mediante un esquema de autenticación da era dos teléfonos intelixentes e o cifrado Advanced Encryption Standard (AES). A seguridade utilizada nas redes Thread é máis forte que outros estándares sen fíos que avaliou Thread Group.
   • Redes domésticas pequenas e grandes: as redes domésticas varían de varios a centos de dispositivos. A capa de rede está deseñada para optimizar o funcionamento da rede en función do uso esperado.
   • Redes comerciais grandes: para instalacións comerciais máis grandes, unha única rede Thread non é suficiente para cubrir todos os requisitos de aplicación, sistema e rede. O modelo Thread Domain permite escalabilidade de ata 10,000 dispositivos Thread nunha única implementación, utilizando unha combinación de diferentes tecnoloxías de conectividade (Thread, Ethernet, Wi-Fi, etc.).
   • Descubrimento de servizos bidireccionais e conectividade: a multidifusión e a difusión son ineficientes nas redes de malla sen fíos. Para a comunicación fóra da malla, Thread ofrece un rexistro de servizos no que os dispositivos poden rexistrar a súa presenza e servizos, e os clientes poden usar consultas unicast para descubrir os servizos rexistrados.
   • Alcance: os dispositivos típicos proporcionan un alcance suficiente para cubrir unha casa normal. Deseños facilmente dispoñibles con potencia ampos lificadores amplían o rango substancialmente. Na capa física (PHY) úsase un espectro espallado distribuído para ser máis inmune ás interferencias. Para instalacións comerciais, o modelo Thread Domain permite que varias redes Thread se comuniquen entre si a través dunha backbone, ampliando así o rango para cubrir moitas subredes de malla.
   • Non hai un único punto de fallo: a pila Thread está deseñada para ofrecer operacións seguras e fiables mesmo con fallos ou perdas de dispositivos individuais. Os dispositivos Thread tamén poden incorporar ligazóns baseadas en IPv6 como Wi-Fi e Ethernet na topoloxía para reducir a probabilidade de varias particións Thread. Deste xeito, poden utilizar o maior rendemento, capacidade de canle e cobertura desas ligazóns de infraestrutura, aínda que admiten dispositivos de baixa potencia.
   • Baixa potencia: os dispositivos comunícanse de forma eficiente para ofrecer unha experiencia de usuario mellorada con anos de vida útil prevista en condicións normais de batería. Os dispositivos normalmente poden funcionar durante varios anos con pilas tipo AA utilizando ciclos de traballo axeitados.
   • Rentable: os chipsets e as pilas de software compatibles de varios provedores teñen un prezo para a súa implantación masiva e están deseñados desde o principio para ter un consumo de enerxía extremadamente baixo.
5.  OpenThread
   • OpenThread lanzado por Google é unha implementación de código aberto de Thread®. Google lanzou OpenThread para que a tecnoloxía de traballo en rede utilizada nos produtos de Google Nest estea máis dispoñible para os desenvolvedores, co fin de acelerar o desenvolvemento de produtos para casas conectadas e edificios comerciais.
   • Cunha capa de abstracción de plataforma estreita e unha pequena pegada de memoria, OpenThread é altamente portátil. Soporta deseños de sistema en chip (SoC) e coprocesador de radio (RCP).
   • OpenThread define un protocolo de comunicación sen fíos de dispositivo a dispositivo baseado en IPv6 fiable, seguro e de baixa potencia para aplicacións de edificios domésticos e comerciais. Implementa todas as funcións definidas na Especificación de fíos 1.1.1, Especificación de fíos 1.2, Especificación de fíos 1.3.0 e borrador da Especificación de fíos 1.4 (a partir da publicación deste documento).
   • Silicon Labs implementou un protocolo baseado en OpenThread adaptado para traballar co hardware de Silicon Labs. Este protocolo está dispoñible en GitHub e tamén como un kit de desenvolvemento de software (SDK) instalado con Simplicity Studio 5. O SDK é unha instantánea totalmente probada da fonte Gi-tHub. Admite unha gama máis ampla de hardware que a versión de GitHub e inclúe documentación e exampaplicacións non dispoñibles en GitHub.

Tecnoloxía de fíos rematadaview

1. IEEE 802.15.4
   • A especificación IEEE 802.15.4-2006 é un estándar para comunicacións sen fíos que define as capas sen fíos de control de acceso medio (MAC) e física (PHY) que operan a 250 kbps na banda de 2.4 GHz, cunha folla de ruta para bandas subGHz (IEEE 802.15.4. Especificación 2006-802.15.4). Deseñado coa baixa potencia en mente, XNUMX é axeitado para aplicacións que normalmente inclúen un gran número de nós.
   • A capa MAC 802.15.4 úsase para o manexo básico de mensaxes e o control da conxestión. Esta capa MAC inclúe un mecanismo Carrier Sense Multiple Access (CSMA) para que os dispositivos escoiten unha canle clara, así como unha capa de ligazón para xestionar os reintentos e o recoñecemento de mensaxes para comunicacións fiables entre dispositivos adxacentes. O cifrado da capa MAC úsase nas mensaxes baseadas en claves establecidas e configuradas polas capas superiores da pila de software. A capa de rede baséase nestes mecanismos subxacentes para proporcionar comunicacións fiables de extremo a extremo na rede.
   • A partir da especificación Thread 1.2, implementáronse varias optimizacións da especificación IEEE 802.15.4-2015 para facer as redes Thread máis robustas, sensibles e escalables:
   • Pendente de cadro mellorado: mellora a duración da batería e a capacidade de resposta dun dispositivo final con sono (SED) ao reducir o número de mensaxes que un SED pode enviar polo aire. Calquera paquete de datos que chegue dun SED (non só solicitudes de datos) pódese recoñecer coa presenza de datos pendentes próximos.
   • Keepalive mellorado: reduce a cantidade de tráfico necesario para manter unha ligazón entre un SED e un pai ao tratar calquera mensaxe de datos como unha transmisión de rede de keepalive.
   • Coordinado SampEscoita led (CSL): esta característica de especificación IEEE 802.15.4-2015 permite unha mellor sincronización entre un SED e un pai mediante a programación de períodos de transmisión/recepción sincronizados sen solicitudes de datos periódicas. Isto permite dispositivos de baixa potencia que teñen unha latencia de ligazón baixa e unha rede cunha menor probabilidade de colisións de mensaxes.
   • Proba ACK mellorada: esta función de especificación IEEE 802.15.4-2015 permite un control granular do iniciador sobre as consultas de métricas de enlace á vez que aforra enerxía reutilizando patróns de tráfico de datos regulares en lugar de mensaxes de sonda separadas.
2. Arquitectura de rede de subprocesos
   1. Arquitectura Residencial
      Os usuarios comunícanse cunha rede residencial de Thread desde o seu propio dispositivo (teléfono intelixente, tableta ou ordenador) a través dunha wifi na súa rede de área doméstica (HAN) ou mediante unha aplicación baseada na nube. A seguinte figura ilustra os principais tipos de dispositivos na arquitectura de rede Thread.

Figura 2.1. Arquitectura de rede de subprocesos
Nunha rede Thread inclúense os seguintes tipos de dispositivos, a partir da rede Wi-Fi:

• Border Routers proporciona conectividade desde a rede 802.15.4 a redes adxacentes noutras capas físicas (Wi-Fi, Ethernet, etc.). Border Routers ofrece servizos para dispositivos dentro da rede 802.15.4, incluíndo servizos de enrutamento e descubrimento de servizos para operacións fóra da rede. Pode haber un ou máis enrutadores de fronteira nunha rede Thread.
• Un líder, nunha partición de rede Thread, xestiona un rexistro de ID de enrutador asignados e acepta solicitudes de dispositivos finais aptos para enrutadores (REED) para converterse en enrutadores. O líder decide cales deben ser os enrutadores e o líder, como todos os enrutadores dunha rede Thread, tamén pode ter fillos do dispositivo. O Leader tamén asigna e xestiona enderezos de enrutadores mediante CoAP (Constrained Appli-cation Protocol). Non obstante, toda a información contida no Leader está presente nos outros Thread Routers. Polo tanto, se o líder falla ou perde a conectividade coa rede Thread, elíxese outro Thread Router, que asume como líder sen intervención do usuario.
• Os enrutadores de subprocesos ofrecen servizos de enrutamento a dispositivos de rede. Os enrutadores de fíos tamén ofrecen servizos de conexión e seguridade para os dispositivos que intentan unirse á rede. Os enrutadores de fíos non están deseñados para durmir e poden degradar a súa funcionalidade e converterse en REED.
• Os REED poden converterse nun enrutador de fíos ou nun líder, pero non necesariamente nun enrutador de fronteiras que teña propiedades especiais, como múltiples interfaces. Debido á topoloxía da rede ou outras condicións, os REED non actúan como enrutadores. Os REED non transmiten mensaxes nin ofrecen servizos de unión nin de seguridade para outros dispositivos da rede. A rede xestiona e promove dispositivos aptos para enrutadores a enrutadores se é necesario, sen interacción do usuario.
• Os dispositivos finais que non son aptos para enrutadores poden ser FED (dispositivos finais) ou MED (dispositivos finais mínimos). Os MED non precisan sincronizarse explícitamente cos seus pais para comunicarse.
• Os dispositivos de extremo soñoliento (SED) só se comunican a través do seu enrutador principal e non poden transmitir mensaxes a outros dispositivos.
• Os Dispositivos Terminais Sleepy Sincronizados (SSED) son unha clase de Dispositivos Terminais Sleepy que usan CSL de IEEE 802.15.4-2015 para manter unha programación sincronizada cun pai, evitando o uso de solicitudes de datos habituais.

Arquitectura Comercial
O modelo Thread Commercial toma os tipos de dispositivos clave para unha rede residencial e engade novos conceptos. Os usuarios comunícanse cunha rede comercial a través de dispositivos (teléfonos intelixentes, tabletas ou ordenadores) mediante Wi-Fi ou a través da súa rede empresarial. A seguinte figura ilustra unha topoloxía de rede comercial.

Figura 2.2. Topoloxía de redes comerciais

Os conceptos son:

• O modelo Thread Domain admite a integración perfecta de varias redes Thread, así como unha interface perfecta para redes IPv6 que non son Thread. O principal beneficio do dominio de subprocesos é que os dispositivos son ata certo punto flexibles para unirse a calquera rede de subprocesos dispoñible configurada cun dominio de subprocesos común, o que reduce a necesidade de planificación manual da rede ou de custosas reconfiguracións manuais cando se escala o tamaño da rede ou o volume de datos. arriba.
• Os backbone Border Routers (BBR) son unha clase de Border Router no espazo comercial que facilitan a sincronización de dominios de subprocesos de múltiples segmentos de rede e permiten a propagación de multidifusión de gran alcance dentro e fóra de cada malla individual nun dominio de subprocesos. Unha rede Thread que forma parte dun dominio máis grande debe ter polo menos un BBR "primario" e pode ter varios BBR "secundarios" para a redundancia a proba de fallos. Os BBR comunícanse entre si a través dunha columna vertebral que conecta todas as redes Thread.
• Unha ligazón backbone é unha ligazón IPv6 non Thread á que se conecta un BBR mediante unha interface externa utilizada para implementar o protocolo Thread Backbone Link Protocol (TBLP) para sincronizarse con outros BBR.
• Os dispositivos Thread nunha implementación comercial configúranse mediante dominios de fíos e enderezos únicos de dominio (DUA). O DUA dun dispositivo nunca cambia ao longo da súa vida útil como parte dun dominio Thread. Isto facilita a migración a través de diferentes redes Thread nun único dominio e asegura que os respectivos BBR facilitan o enrutamento en varias redes Thread.

Estes conceptos están ilustrados na seguinte figura:

Figura 2.3. Modelo de dominio de fíos
Non hai un único punto de falla

• A pila de fíos está deseñada para non ter un só punto de falla. Aínda que hai unha serie de dispositivos no sistema que realizan funcións especiais, Thread está deseñado para que poidan ser substituídos sen afectar o funcionamento continuo da rede ou dos dispositivos. Por example, un dispositivo final durmido require un pai para as comunicacións, polo que este pai representa un único punto de falla para as súas comunicacións. Non obstante, o dispositivo final durmido pode seleccionar outro pai se o seu pai non está dispoñible. Esta transición non debería ser visible para o usuario.
  Aínda que o sistema non está deseñado para ningún punto único de fallo, en determinadas topoloxías haberá dispositivos individuais que non teñan capacidades de copia de seguridade. Por example, nun sistema cun único Borde
• Router, se o Border Router perde enerxía, non hai medios para cambiar a un Border Router alternativo. Neste escenario, debe ter lugar unha reconfiguración do enrutador de fronteiras.
• A partir da especificación de subproceso 1.3.0, os enrutadores de fronteira que comparten unha ligazón de infraestrutura poden facilitar un punto único de falla a través dun medio diferente (como Wi-Fi ou Ethernet) mediante a utilización dun subproceso.
• Enlace de encapsulación de radio (TREL). Con esta función, redúcese a probabilidade de que se formen particións Thread entre ligazóns.

Fundamentos de IP Stack

1. Enderezo
   • Os dispositivos da pila Thread admiten a arquitectura de direccionamento IPv6 segundo se define no RFC 4291 (https://tools.ietf.org/html/rfc4291: Arquitectura de direccionamiento IP versión 6). Os dispositivos admiten un único
   • Enderezo local (ULA), un enderezo único de dominio (DUA) nun modelo de dominio Thread e un ou máis enderezos de enderezo global unicast (GUA) en función dos seus recursos dispoñibles.
   • Os bits de orde superior dun enderezo IPv6 especifican a rede e o resto especifican enderezos particulares nesa rede. Así, todas as direccións dunha rede teñen os mesmos primeiros N bits. Os primeiros
   • N bits chámanse "prefixo". O "/64" indica que este é un enderezo cun prefixo de 64 bits. O dispositivo que inicia a rede escolle un prefixo /64 que despois se usa en toda a rede. O prefixo é un ULA (https://tools.ietf.org/html/rfc4193: Enderezos de unicast IPv6 locais únicos). A rede tamén pode ter un ou máis enrutadores de fronteira que cada un pode ter ou non un /64 que se pode usar para xerar un ULA ou GUA. O dispositivo da rede usa o seu enderezo EUI-64 (64-bit Extended Unique Identifier) ​​para derivar o seu identificador de interface segundo se define na Sección 6 do RFC 4944 (https://tools.ietf.org/html/rfc4944: Transmisión de paquetes IPv6 a través de redes IEEE 802.15.4). O dispositivo admitirá un enderezo IPv6 local de ligazón configurado desde a EUI-64 do nodo como un identificador de interface co coñecido prefixo local de ligazón FE80::0/64 segundo se define no RFC 4862 (https://tools.ietf.org/html/rfc4862: Autoconfiguración de enderezos sen estado IPv6) e RFC 4944.
   • Os dispositivos tamén admiten enderezos multicast adecuados. Isto inclúe a multidifusión local de todos os nodos, a multidifusión local de todos os enrutadores, a multidifusión de nodos solicitados e a multidifusión local de malla. Coa presenza dun enrutador de fronteira de backbone nun modelo de dominio, os dispositivos tamén poden soportar enderezos de multidifusión de maior alcance se se rexistran para eles.
   • A cada dispositivo que se une á rede asígnaselle un enderezo curto de 2 bytes segundo a especificación IEEE 802.15.4-2006. Para os enrutadores, este enderezo atribúese usando os bits altos no campo de enderezos.
   • A continuación, asígnaselles aos nenos un enderezo curto usando os bits altos dos seus pais e os bits inferiores apropiados para o seu enderezo. Isto permite que calquera outro dispositivo da rede comprenda a localización do enrutamento do neno utilizando os bits altos do seu campo de enderezo.
2. 6 PAN BAIXO
   • 6LoWPAN significa "IPv6 Over Low Power Wireless Personal Networks". O obxectivo principal de 6LoWPAN é transmitir e recibir paquetes IPv6 a través de ligazóns 802.15.4. Ao facelo, ten que acomodar o tamaño máximo de cadro 802.15.4 enviado polo aire. Nas ligazóns Ethernet, un paquete co tamaño da Unidade de Transmisión Máxima (MTU) IPv6 (1280 bytes) pódese enviar facilmente como unha trama a través da ligazón. No caso de 802.15.4, 6LoWPAN actúa como unha capa de adaptación entre a capa de rede IPv6 e a capa de enlace 802.15.4. Resolve o problema de transmitir un IPv6
   • MTU fragmentando o paquete IPv6 no remitente e remontándoo no receptor.
     6LoWPAN tamén proporciona un mecanismo de compresión que reduce os tamaños das cabeceiras IPv6 enviadas polo aire e, polo tanto, reduce a sobrecarga de transmisión. Cantos menos bits se envían polo aire, menos enerxía consumirá o dispositivo. Thread fai un uso completo destes mecanismos para transmitir paquetes de forma eficiente pola rede 802.15.4. RFC 4944 (https://tools.ietf.org/html/rfc4944) e RFC 6282 (https://tools.ietf.org/html/rfc6282) describe en detalle os métodos polos que se realiza a fragmentación e a compresión de cabeceira.
3. Reenvío de capa de ligazón
   Outra característica importante da capa 6LoWPAN é o reenvío de paquetes da capa de ligazón. Isto proporciona un mecanismo de sobrecarga moi eficiente e baixo para reenviar paquetes de varios saltos nunha rede de malla. O fío usa o enrutamento da capa IP co reenvío de paquetes da capa de ligazón.
   Thread usa o reenvío da capa de ligazón para reenviar paquetes en función da táboa de enrutamento IP. Para conseguir isto, úsase a cabeceira de malla 6LoWPAN en cada paquete multi-hop (consulte a seguinte figura).
   • Figura 3.1. Formato de cabeceira de malla
   • En Thread, a capa 6LoWPAN enche a información da cabeceira de malla co enderezo curto de 16 bits de orixe e o enderezo de orixe de 16 bits de destino final. O transmisor busca o seguinte enderezo curto de 16 bits na táboa de enrutamento e, a continuación, envía a trama 6LoWPAN ao seguinte enderezo curto de 16 bits como destino. O dispositivo do seguinte salto recibe o paquete, busca o seguinte salto no
   • Táboa de enrutamento / Táboa de veciños, diminúe o reconto de saltos na cabeceira de malla 6LoWPAN e, a continuación, envía o paquete ao seguinte salto ou enderezo curto de 16 bits de destino final como destino.
   • 6 Encapsulación LowPAN
     Os paquetes 6LoWPAN constrúense co mesmo principio que os paquetes IPv6 e conteñen cabeceiras apiladas para cada funcionalidade engadida. Cada cabeceira 6LoWPAN vai precedida por un valor de envío que identifica o tipo de cabeceira (consulte a seguinte figura).
4. 6 Encapsulación LowPAN
   Os paquetes 6LoWPAN constrúense co mesmo principio que os paquetes IPv6 e conteñen cabeceiras apiladas para cada funcionalidade engadida. Cada cabeceira 6LoWPAN vai precedida por un valor de envío que identifica o tipo de cabeceira (consulte a seguinte figura).
   Figura 3.2. Formato xeral dun paquete 6LoWPAN
   O fío usa os seguintes tipos de cabeceiras 6LoWPAN:
   • Cabeceira de malla (utilizada para o reenvío da capa de ligazón)
   • Encabezado de fragmentación (utilizado para fragmentar o paquete IPv6 en varios paquetes 6LoWPAN)
   • Cabeceira de compresión de cabeceira (utilizada para a compresión de cabeceiras IPv6)
   • A especificación 6LoWPAN obriga a que se hai máis dunha cabeceira, deben aparecer na orde mencionada anteriormente. Os seguintes son os examparquivos de paquetes 6LoWPAN enviados polo aire.
   • Na seguinte figura, a carga útil 6LoWPAN está composta pola cabeceira IPv6 comprimida e o resto da carga útil IPv6.
   • Figura 3.3. Paquete 6LoWPAN que contén carga útil IPv6 con cabeceira IPv6 comprimida
   • Na seguinte figura, a carga útil 6LoWPAN contén a cabeceira IPv6 e parte da carga útil IPv6.
   • Figura 3.4. Paquete 6LoWPAN que contén a cabeceira de malla, unha cabeceira de fragmentación e unha cabeceira de compresión O resto da carga útil transmitirase en paquetes posteriores segundo o formato da seguinte figura.
   • Figura 3.5. 6LoWPAN Fragmento posterior
5. ICMP
   Os dispositivos Thread admiten o protocolo Internet Control Message Protocol versión 6 (ICMPv6) segundo se define en RFC 4443, Internet Control Message Protocol (ICMPv6) para a especificación Internet Protocol Version 6 (IPv6). Tamén admiten a solicitude de eco e as mensaxes de resposta de eco.
6. UDP
   A pila de Thread admite User DatagProtocolo ram (UDP) segundo se define en RFC 768, User DatagProtocolo ram.
7. TCP
   A pila Thread admite unha variante do protocolo de control de transporte (TCP) chamada "TCPlp" (TCP Low Power) (consulte usenix-NSDI20). Un dispositivo compatible con Thread implementa os roles de iniciador e escoita TCP como se describe en:
   • RFC 793, Protocolo de control de transmisión
   • RFC 1122, Requisitos para servidores de Internet
   • Especificación de subprocesos 1.3.0 e superior: as implementacións de TCP existentes normalmente non están sintonizadas para funcionar de forma óptima en redes de malla sen fíos e cos tamaños de cadro 802.15.4 limitados. Polo tanto, a especificación define aqueles elementos e valores de parámetros necesarios para unha implementación eficiente de TCP sobre redes de subprocesos (consulte Especificación de subprocesos 1.3.0, sección 6.2 TCP).
8. SRP
   • O protocolo de rexistro de servizos (SRP) tal e como se define no protocolo de rexistro de servizos para o descubrimento de servizos baseado en DNS utilízase nos dispositivos Thread que comezan coa especificación Thread 1.3.0. Debe existir un Rexistro de Servizos, mantido por un router de fronteira. Os clientes SRP na rede de malla poden rexistrarse para ofrecer varios servizos. Un servidor SRP acepta consultas de descubrimento baseadas en DNS e, ademais, ofrece criptografía de chave pública para a seguridade, xunto con outras melloras menores para soportar mellor os clientes limitados.

Topoloxía de rede

1. Enderezo de rede e dispositivos
   • A pila de Thread admite a conectividade de malla completa entre todos os enrutadores da rede. A topoloxía real baséase no número de enrutadores da rede. Se só hai un enrutador, entón a rede forma unha estrela. Se hai máis dun enrutador, fórmase automaticamente unha malla (consulte 2.2 Arquitectura de rede de subprocesos).
2. Redes Mesh
   • As redes de malla integradas fan que os sistemas de radio sexan máis fiables ao permitir que as radios transmitan mensaxes para outras radios. Por exampse un nodo non pode enviar unha mensaxe directamente a outro nodo, a rede de malla incrustada transmite a mensaxe a través dun ou máis nodos intermedios. Como se comenta na sección 5.3 Enrutamento, todos os nodos do enrutador da pila Thread manteñen as rutas e a conectividade entre si, polo que a malla se mantén e se conecta constantemente. Hai un límite de 64 enderezos de enrutador na rede Thread, pero non se poden usar todos á vez. Isto dá tempo para que se reutilicen os enderezos dos dispositivos eliminados.
   • Nunha rede de malla, os dispositivos finais durmidos ou os dispositivos aptos para o enrutador non se encamiñan a outros dispositivos. Estes dispositivos envían mensaxes a un pai que é un enrutador. Este enrutador principal xestiona as operacións de enrutamento dos seus dispositivos fillos.

Enrutamento e conectividade de rede

A rede Thread ten ata 32 enrutadores activos que usan o enrutamento do seguinte salto para as mensaxes en función da táboa de enrutamento. A pila Thread mantén a táboa de enrutamento para garantir que todos os enrutadores teñan conectividade e rutas actualizadas para calquera outro enrutador da rede. Todos os enrutadores intercambian con outros enrutadores o seu custo de enrutamento a outros enrutadores da rede nun formato comprimido mediante Mesh Link Establishment (MLE).

1.  Mensaxes MLE
   • As mensaxes de Mesh Link Establishment (MLE) úsanse para establecer e configurar enlaces de radio seguros, detectar dispositivos veciños e manter os custos de enrutamento entre os dispositivos da rede. MLE opera por debaixo da capa de enrutamento e usa unicasts locais e multicasts de enlace dun salto entre enrutadores.
   • As mensaxes MLE úsanse para identificar, configurar e protexer as ligazóns a dispositivos veciños a medida que cambian a topoloxía e o ambiente físico. MLE tamén se usa para distribuír valores de configuración que se comparten na rede, como a canle e o ID de rede de área persoal (PAN). Estas mensaxes pódense reenviar cunha inundación simple como especifica MPL (https://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-11: Protocolo de multidifusión para redes de baixa potencia e con perdas (MPL).
   • As mensaxes MLE tamén garanten que se teñan en conta os custos de enlace asimétrico ao establecer os custos de enrutamento entre dous dispositivos. Os custos das ligazóns asimétricas son comúns nas redes 802.15.4. Para garantir a fiabilidade da mensaxería bidireccional, é importante ter en conta os custos das ligazóns bidireccionais.
2. Descubrimento e reparación de rutas
   • O descubrimento de rutas baixo demanda úsase habitualmente en redes 802.15.4 de baixa potencia. Non obstante, o descubrimento de rutas baixo demanda é custoso en termos de sobrecarga da rede e ancho de banda porque os dispositivos transmiten solicitudes de descubrimento de rutas a través da rede. Na pila Thread, todos os enrutadores intercambian paquetes MLE dun salto que conteñen información de custos con todos os demais enrutadores da rede. Todos os enrutadores teñen información actualizada do custo da ruta a calquera outro enrutador da rede, polo que non se precisa a detección de rutas baixo demanda. Se unha ruta xa non se pode utilizar, os enrutadores poden seleccionar a seguinte ruta máis adecuada ata o destino.
   • O enrutamento aos dispositivos fillos realízase mirando os bits altos do enderezo do fillo para determinar o enderezo do enrutador principal. Unha vez que o dispositivo coñece o enrutador principal, coñece a información do custo do camiño e a información do enrutamento do seguinte salto para ese dispositivo.
   • A medida que cambia o custo da ruta ou a topoloxía da rede, os cambios propáganse pola rede usando as mensaxes de salto único MLE. O custo de enrutamento baséase na calidade da ligazón bidireccional entre dous dispositivos. A calidade da ligazón en cada dirección baséase na marxe da ligazón nas mensaxes entrantes dese dispositivo veciño. Este indicador de intensidade de sinal recibido (RSSI) entrante está asignado a unha calidade de ligazón de 0 a 3. Un valor de 0 significa un custo descoñecido.
   • Cando un enrutador recibe unha nova mensaxe MLE dun veciño, xa ten unha entrada na táboa de veciños para o dispositivo ou engádese unha. A mensaxe MLE contén o custo entrante do veciño, polo que este actualízase na táboa de veciños do router. A mensaxe MLE tamén contén información de enrutamento actualizada para outros enrutadores que se actualiza na táboa de enrutamento.
   • O número de enrutadores activos está limitado á cantidade de información de enrutamento e custo que se pode conter nun único paquete 802.15.4. Este límite é actualmente de 32 enrutadores.
3. Enrutamento
   • Os dispositivos usan o enrutamento IP normal para reenviar paquetes. Enchégase unha táboa de enrutamento cos enderezos de rede e o seguinte salto adecuado.
   • O enrutamento vectorial de distancia úsase para obter rutas a enderezos que están na rede local. Ao enrutar na rede local, os seis bits superiores deste enderezo de 16 bits definen o destino do enrutador.
   • Este pai de enrutamento é entón responsable de reenviar ao destino final en función do resto do enderezo de 16 bits.
   • Para o enrutamento fóra da rede, un enrutador de fronteira notifica ao líder do enrutador os prefixos particulares que serve e distribúe esta información como datos de rede dentro dos paquetes MLE. Os datos da rede inclúen os datos do prefixo, que é o propio prefixo, o contexto 6LoWPAN, os enrutadores de fronteira e o servidor de configuración automática de enderezos sen estado (SLAAC) ou DHCPv6 para ese prefixo. Se un dispositivo debe configurar un enderezo usando ese prefixo, contacta co servidor SLAAC ou DHCP adecuado para este enderezo. Os datos da rede tamén inclúen unha lista de servidores de enrutamento que son os enderezos de 16 bits dos enrutadores de fronteira predeterminados.
   • Ademais, nun espazo comercial cun modelo Thread Domain, un Backbone Border Router notifica ao líder do router o prefixo único do dominio que serve, para indicar que esta malla forma parte do dominio Thread máis grande. Os datos de rede para isto inclúen os datos do prefixo, o contexto 6LoWPAN e o enrutador de fronteira ALOC. Non hai marcas SLAAC ou DHCPv6 establecidas para este conxunto de prefixos, pero a asignación de enderezos segue o modelo sen estado. Ademais, tamén hai TLV de servizo e servidor que indican a capacidade de servizo "backbone" deste enrutador fronteirizo. Existe a capacidade de detección de enderezos duplicados sobre o backbone para calquera dispositivo que rexistre o seu enderezo único de dominio (DUA) co BBR. O DUA dun dispositivo nunca cambia ao longo da súa vida útil como parte dun dominio Thread.
   • Isto facilita a migración a través de diferentes redes Thread nun único dominio e asegura que os respectivos BBR facilitan o enrutamento en varias redes Thread. No backbone, utilízanse tecnoloxías de enrutamento IPv6 estándar, como IPv6 Neighbor Discovery (NS/NA segundo RFC 4861) e Multicast Listener Discovery (MLDv2 segundo RFC 3810).
   • Desígnase a un líder para que faga un seguimento dos dispositivos aptos para enrutadores que se converten en enrutadores ou para permitir que os enrutadores pasen a unha versión inferior a dispositivos aptos para enrutadores. Este líder tamén asigna e xestiona os enderezos do enrutador mediante CoAP. Non obstante, toda a información contida neste Leader tamén se anuncia periodicamente aos demais enrutadores. Se o líder sae da rede, elíxese outro enrutador que asume como líder sen intervención do usuario.
   • Border Routers son os responsables de xestionar a compresión ou expansión 6LoWPAN e de dirixirse a dispositivos fóra da rede. Os enrutadores Backbone Border son responsables de manexar MPL con encapsulación e decapsulación IP-in-IP para multicasts de maior alcance que entran e saen da malla.
   • Para obter máis información sobre Border Routers, consulte AN1256: Usando o Silicon Labs RCP co OpenThread Border Router.
4. Reintentos e recoñecementos
   • Aínda que a mensaxería UDP se usa na pila Thread, a entrega de mensaxes fiable é necesaria e completada por estes mecanismos lixeiros:
   • Reintentos a nivel MAC: cada dispositivo usa acuse de recibo MAC do seguinte salto e tentará de novo unha mensaxe na capa MAC se non se recibe a mensaxe MAC ACK.
   • Reintentos da capa de aplicación: a capa de aplicación pode determinar se a fiabilidade da mensaxe é un parámetro crítico. Se é así, pódese utilizar un protocolo de recoñecemento e reintento de extremo a extremo, como reintentos CoAP.

Unión e operación de rede

O fío permite dous métodos de unión:

• Comparte a información de posta en marcha directamente nun dispositivo mediante un método fóra de banda. Isto permite dirixir o dispositivo á rede adecuada usando esta información.
• Establece unha sesión de posta en servizo entre un dispositivo de unión e unha aplicación de posta en servizo nun teléfono intelixente, tableta ou web.
• Para unha rede comercial cun modelo de dominio Thread, un proceso de rexistro autónomo sen intervención do usuario que fornece certificados de funcionamento nos ensambladores despois da autenticación está especificado na especificación Thread 1.2. O certificado operativo codifica a información do dominio do dispositivo e permite a provisión segura da chave mestra da rede. Este modelo require un rexistrador ou
• Interface de rexistro de subprocesos (TRI) nun enrutador de fronteira troncal e facilita a comunicación cunha autoridade externa (MASA) mediante os protocolos ANIMA/BRSKI/EST. Unha rede que admite este modelo de posta en servizo chámase rede CCM.
• Para obter máis información sobre a posta en servizo das redes Thread, consulte a sección 11. Posta en servizo do dispositivo.
• O método de unión 802.15.4 que se usa con frecuencia coa bandeira de unión de permisos na carga útil da baliza non se usa nas redes Thread. Este método utilízase máis habitualmente para unir tipo botón pulsador onde non hai interface de usuario ou canle fóra de banda para os dispositivos. Este método ten problemas coa dirección do dispositivo en situacións nas que hai varias redes dispoñibles e tamén pode supoñer riscos de seguridade.
• Nas redes Thread, todas as unións son iniciadas polo usuario. Despois de unirse, complétase unha autenticación de seguranza a nivel de aplicación cun dispositivo de comisión. Esta autenticación de seguranza explícase na sección 9. Seguridade.
• Os dispositivos únense a unha rede como un dispositivo final inactivo, un dispositivo final (MED ou FED) ou un REED. Só despois de que un REED se uniu e aprenda a configuración da rede pode solicitar potencialmente converterse en un

Enrutador de fíos. Ao unirse, un dispositivo recibe un enderezo curto de 16 bits baseado no seu pai. Se un dispositivo apto para enrutador pasa a ser un enrutador de subprocesos, o líder asígnalle un enderezo de enrutador. A detección de enderezos duplicados para os enrutadores de subprocesos está garantida polo mecanismo centralizado de distribución de enderezos do enrutador que reside no Leader. O pai é responsable de evitar enderezos duplicados para os dispositivos anfitrións porque lles asigna enderezos ao unirse.

1. Descubrimento da rede
   • O descubrimento de rede é usado por un dispositivo de conexión para determinar cales son as redes 802.15.4 dentro do alcance de radio. O dispositivo analiza todas as canles, emite unha solicitude de descubrimento de MLE en cada canle e agarda as respostas de descubrimento de MLE. A resposta de descubrimento 802.15.4 MLE contén unha carga útil con parámetros de rede, incluíndo o identificador de conxunto de servizos de rede (SSID), o ID PAN estendido e outros valores que indican se a rede está aceptando novos membros e se admite a posta en servizo nativa.
   • O descubrimento da rede non é necesario se o dispositivo foi posto en servizo na rede porque coñece a canle e o ID PAN estendido para a rede. A continuación, estes dispositivos conéctanse á rede mediante o material de posta en servizo proporcionado.
2. Datos MLE
   • Unha vez que un dispositivo se conectou a unha rede, é necesaria unha variedade de información para que participe na rede. MLE ofrece servizos para que un dispositivo envíe unha unidifusión a un dispositivo veciño para solicitar parámetros de rede e actualizar os custos das ligazóns aos veciños. Cando se une un dispositivo novo, tamén leva a cabo unha resposta de desafío para configurar os contadores de marcos de seguridade, como se explica na sección 9. Seguridade.
   • Todos os dispositivos admiten a transmisión e recepción de mensaxes de configuración da ligazón MLE. Isto inclúe as mensaxes de "solicitude de ligazón", "aceptación de ligazón" e "aceptación de ligazón e solicitude".
   • O intercambio MLE úsase para configurar ou intercambiar a seguinte información:
   • O enderezo curto de 16 bits e EUI 64 longo de 64 bits dos dispositivos veciños
   • Información sobre as capacidades do dispositivo, incluído se se trata dun dispositivo final con sono e o ciclo de suspensión do dispositivo
   • A ligazón de veciño custa se hai un enrutador de fíos
   • Material de seguridade e contadores de cadros entre dispositivos
   • Custos de enrutamento a todos os outros enrutadores Thread da rede
   • Recopilación e distribución de métricas de ligazóns sobre varios valores de configuración de ligazóns
   • Nota: As mensaxes MLE están cifradas excepto durante as operacións iniciais de arranque do nodo cando o novo dispositivo non obtivo o material de seguridade.
3.  CoAP
   Protocolo de aplicación restrinxido (CoAP) segundo se define no RFC 7252 (https://tools.ietf.org/html/rfc7252: O protocolo de aplicación restrinxido (CoAP) é un protocolo de transporte especializado para o seu uso con nodos restrinxidos e redes de baixa potencia. CoAP ofrece un modelo de interacción solicitude/resposta entre os puntos finais da aplicación, admite o descubrimento integrado de servizos e recursos e inclúe conceptos clave do web como URLs. CoAP úsase en Thread para configurar enderezos locais de malla e enderezos de multidifusión requiridos polos dispositivos. Ademais, CoAP tamén se usa para mensaxes de xestión, como para obter e establecer información de diagnóstico e outros datos de rede en enrutadores Thread activos.
4. DHCPv6
   DHCPv6 tal e como se define no RFC 3315 úsase como protocolo cliente-servidor para xestionar a configuración dos dispositivos dentro da rede. DHCPv6 usa UDP para solicitar datos dun servidor DHCP (https://www.ietf.org/rfc/rfc3315.txt: Protocolo de configuración dinámica de host para IPv6 (DHCPv6)).
   O servizo DHCPv6 úsase para a configuración de:
   • Enderezos de rede
   • Enderezos de multidifusión requiridos polos dispositivos
   • Dado que os enderezos curtos son asignados desde o servidor mediante DHCPv6, non é necesaria a detección de enderezos duplicados. DHCPv6 tamén é usado por Border Routers que están asignando enderezos en función do prefixo que proporcionan.
5. SLAAC
   SLAAC (Configuración automática de enderezos sen estado) segundo se define no RFC 4862 (https://tools.ietf.org/html/rfc4862: IPv6 Stateless Address Auto-configuration) é un método no que un Border Router asigna un prefixo e, a continuación, os últimos 64 bits do seu enderezo son derivados polo router. O mecanismo de configuración automática sen estado IPv6 non require ningunha configuración manual de hosts, configuración mínima (se hai) dos enrutadores e sen servidores adicionais. O mecanismo sen estado permite que un host xere os seus propios enderezos usando unha combinación de información dispoñible localmente e información anunciada polos enrutadores.
6. SRP
   O protocolo de rexistro de servizos (SRP) tal e como se define no protocolo de rexistro de servizos para o descubrimento de servizos baseado en DNS utilízase nos dispositivos Thread que comezan coa especificación Thread 1.3.0. Debe existir un Rexistro de Servizos, mantido por un router de fronteira. Os clientes SRP na rede de malla poden rexistrarse para ofrecer varios servizos. Un servidor SRP acepta consultas de descubrimento baseadas en DNS e, ademais, ofrece criptografía de chave pública para a seguridade, xunto con outras melloras menores para soportar mellor os clientes limitados.

Xestión

1. ICMP
   Todos os dispositivos admiten mensaxes de erro do Protocolo de mensaxes de control de Internet para IPv6 (ICMPv6), así como as mensaxes de solicitude de eco e resposta de eco.
2. Xestión de dispositivos
   A capa de aplicación dun dispositivo ten acceso a un conxunto de información de diagnóstico e xestión do dispositivo que se pode usar localmente ou recompilar e enviar a outros dispositivos de xestión.
   Nas capas 802.15.4 PHY e MAC, o dispositivo proporciona a seguinte información á capa de xestión:
   • Dirección EUI 64
   • Enderezo curto de 16 bits
   •  Información de capacidade
   • ID PAN
   • Paquetes enviados e recibidos
   • Octetos enviados e recibidos
   • Paquetes caídos ao transmitir ou recibir
   • Erros de seguridade
   • Número de reintentos MAC
3. Xestión de redes
   A capa de rede do dispositivo tamén ofrece información sobre xestión e diagnóstico que se pode usar localmente ou enviar a outros dispositivos de xestión. A capa de rede proporciona a lista de enderezos IPv6, a táboa de veciños e fillos e a táboa de enrutamento.

Datos persistentes

Os dispositivos que operan no campo poden restablecerse accidentalmente ou a propósito por diversos motivos. Os dispositivos que foron restablecidos deben reiniciar as operacións de rede sen a intervención do usuario. Para que isto se faga con éxito, o almacenamento non volátil debe almacenar a seguinte información:

• Información da rede (como ID PAN)
• Material de seguridade
• Información de enderezos da rede para formar os enderezos IPv6 dos dispositivos

$Seguridade

• As redes fíos son redes sen fíos que deben estar protexidas contra ataques por aire (OTA). Tamén están conectados a internet e, polo tanto, deben estar protexidos contra ataques de internet. Moitas das aplicacións que se están a desenvolver para Thread servirán para unha ampla gama de usos que requiren longos períodos de funcionamento sen vixilancia e baixo consumo de enerxía. Como resultado, a seguridade das redes Thread é fundamental.
• Thread utiliza unha clave de toda a rede que se usa na capa de acceso multimedia (MAC) para o cifrado. Esta chave úsase para a autenticación e cifrado estándar IEEE 802.15.4-2006. A seguridade IEEE 802.15.4-2006 protexe a rede Thread de ataques no aire orixinados desde fóra da rede. O compromiso de calquera nodo individual podería revelar a clave de toda a rede. Como resultado, normalmente non é a única forma de seguridade que se usa dentro da rede Thread. Cada nodo da rede Thread intercambia contadores de fotogramas cos seus veciños mediante un apretón de mans MLE. Estes contadores de fotogramas axudan a protexer contra ataques de repetición. (Para obter máis información sobre MLE, consulte a Especificación de Thread.) Thread permite que a aplicación utilice calquera protocolo de seguridade de Internet para a comunicación de extremo a extremo.
• Os nós ofuscan tanto as súas interfaces de enderezos IP en toda a malla como os seus ID estendidos MAC ao aleatorizarlos. O stock EUI64 como asinado no nodo úsase como enderezo de orixe só durante a fase de unión inicial. Unha vez que un nodo está unido a unha rede, o nodo usa como orixe un enderezo baseado no seu ID de nodo de dous bytes ou un dos seus enderezos aleatorios mencionados anteriormente. O EUI64 non se usa como enderezo de orixe unha vez que o nodo está unido a unha rede.

A xestión da rede tamén debe ser segura. Unha aplicación de xestión de rede Thread pódese executar en calquera dispositivo conectado a Internet. Se ese dispositivo non é membro dunha rede Thread, primeiro debe establecer un Da segurotagconexión de ram Transport Layer Security (DTLS) cun enrutador de borde de fíos. Cada rede Thread ten unha frase de paso de xestión que se usa para establecer esta conexión. Unha vez conectada unha aplicación de xestión á rede Thread, pódense engadir novos dispositivos á rede.

1. 802.15.4 Seguridade
   • A especificación IEEE 802.15.4-2006 describe protocolos de acceso sen fíos e medios para PAN e HAN. Estes protocolos están pensados ​​para a súa implementación en dispositivos de radio dedicados, como os dispoñibles en Silicon Labs. IEEE 802.15.4-2006 admite unha variedade de aplicacións, moitas das cales son sensibles á seguridade. Por example, considere o caso dunha aplicación de sistema de alarma que supervisa a ocupación do edificio. Se a rede non é segura e un intruso accede á rede, pódense difundir mensaxes para crear unha falsa alarma, modificar unha alarma existente ou silenciar unha alarma lexítima. Cada unha destas situacións supón riscos importantes para os ocupantes do edificio.
   • Moitas aplicacións requiren confidencialidade e a maioría tamén necesitan protección da integridade. 802-15.4-2006 aborda estes requisitos mediante un protocolo de seguranza da capa de enlace con catro servizos de seguridade básicos:
   • Control de acceso
   • Integridade da mensaxe
   • Confidencialidade da mensaxe
   • Protección de repetición
   • A protección de reprodución proporcionada por IEEE 802.15.4-2006 é só parcial. Thread ofrece seguridade adicional mediante os apretóns de mans MLE entre os nodos comentados anteriormente para completar a protección de repetición.
2. Xestión segura da rede
   A xestión da rede tamén debe ser segura. Unha aplicación de xestión de rede Thread pódese executar en calquera dispositivo conectado a Internet. Hai dúas partes para a seguridade:
   • Seguridade no aire da que se encarga 802.15.4. Thread implementa 802.15.4-2006 nivel 5 de seguridade.
   • Redes CCM: se un dispositivo non é membro dunha rede CCM, debe establecer unha conexión cun router de fronteira backbone para obter o seu certificado de funcionamento para establecerse como parte do dominio Thread.
   • Redes non CCM: seguridade en Internet: se un dispositivo non é membro dunha rede Thread, primeiro debe establecer unha conexión segura Data-gram Transit Layer Security (DTLS) cun enrutador Thread Border. Cada rede Thread ten unha frase de contraseña de xestión que se usa para establecer conexións seguras entre dispositivos de xestión externos e enrutadores de fronteiras. Unha vez conectada unha aplicación de xestión á rede Thread, pódense engadir novos dispositivos á rede.

Router de fronteira

• Un Thread Border Router é un dispositivo que conecta unha rede sen fíos Thread con outras redes baseadas en IP (como Wi-Fi ou Ethernet) no mundo exterior a través dunha rede local doméstica ou empresarial. A diferenza das pasarelas noutras solucións sen fíos, é totalmente transparente para os protocolos de transporte e aplicación que residen por riba da capa de rede. Como resultado, as aplicacións poden comunicarse de forma segura de extremo a extremo sen ningunha tradución da capa de aplicación.
• Un enrutador de borde de fíos admite mínimamente as seguintes funcións:
  • Conectividade IP de extremo a extremo mediante enrutamento entre dispositivos Thread e outras redes IP externas.
  • Puesta en marcha de roscas externas (por example, un teléfono móbil) para autenticar e unir un dispositivo Thread a unha rede Thread.

Pode haber varios enrutadores de fronteira nunha rede, eliminando un "único punto de fallo" no caso de que un deles falle. O Border Router permite que todos os dispositivos Thread se conecten directamente aos servizos globais na nube, cando as redes empresariais executan IPv6 e IPv4, ou só IPv4.

1.  Características do enrutador de fronteiras para a comunicación fóra da malla
   • Thread pódese implementar inmediatamente nas situacións de traballo actuais, antes da transición parcial ou total a IPv6 e Thread permite a compatibilidade con IPv4 con versións anteriores usando o enderezo de rede
   • Tradución (NAT). NAT64 traduce paquetes IPv6 a IPv4 e NAT64 traduce paquetes IPv4 a IPv6. Un Thread Border Router pode funcionar como un host IPv4 na rede de área ampla (WAN), capaz de obter unha interface IPv4 e un enderezo de enrutador. Pode adquirir un enderezo mediante DHCP dun grupo de enderezos IPv4. O Thread Border Router tamén pode implementar o protocolo de control de portos (PCP) para controlar como se traducen e reenvían os paquetes IPv4 entrantes e admite mapas estáticos. A maioría das traducións de IPv4 a IPv6 (e viceversa) poden ser xestionadas polo Thread
   • Border Router, con cambios mínimos necesarios nunha rede existente.
     Ademais, os enrutadores Thread Border admiten conectividade IPv6 bidireccional con detección de veciños IPv6, anuncios de enrutadores, descubrimento de multidifusión e reenvío de paquetes.
2. Rosca sobre Infraestrutura
   • As redes Thread organízanse automaticamente en particións de rede Thread separadas cando non hai conectividade entre dous ou máis conxuntos de dispositivos. As particións de fíos permiten que os dispositivos manteñan a comunicación con outros dispositivos na mesma partición de fíos pero non con dispositivos de fíos noutras particións.
   • Thread over Infrastructure permite que os dispositivos Thread incorporen tecnoloxías de enlace baseadas en IP (por exemploample, Wi-Fi e Ethernet) na topoloxía Thread. Estas ligazóns de Thread adicionais sobre outras tecnoloxías de enlace reducen a probabilidade de que se produzan varias particións de rede de Thread, mentres que se garante a compatibilidade con dispositivos Thread 1.1 e 1.2 existentes. Estes beneficios obtéñense para calquera topoloxía de rede que inclúa polo menos dous enrutadores de fronteira conectados mediante unha ligazón de infraestrutura adxacente compartida.
   • Para obter máis información, consulte Especificación de subprocesos 1.3.0 (ou borrador de especificacións de subprocesos 1.4), Capítulo 15 (Infraestrutura de subprocesos).
3. Enrutador de bordes OpenThread
   A implementación de OpenThread dun Border Router chámase OpenThread Border Router (OTBR). Admite unha interface de malla usando un modelo RCP. Silicon Labs ofrece unha implementación (compatible con Raspberry Pi) e código fonte como parte do GSDK de Silicon Labs. Para obter máis información, consulte AN1256: Usando o Silicon Labs RCP co enrutador de bordes OpenThread.
   A documentación sobre a configuración e arquitectura do OTBR está dispoñible en https://openthread.io/guides/border-router.

Posta en servizo do dispositivo

Os dispositivos Thread encárganse nas redes Thread de diferentes xeitos, tal e como se describe nas seguintes subseccións.

1. Posta en servizo de fíos tradicional
   • Para a posta en servizo da rede de redes máis pequenas (especificación de Thread 1.1.1 ou superior), os instaladores poden utilizar a aplicación de posta en marcha de Thread que se ofrece como recurso gratuíto para dispositivos Android e iOS. Esta aplicación pódese usar para engadir facilmente novos dispositivos á rede ou reconfigurar os existentes.
   • Thread usa o Mesh Commissioning Protocol (MeshCoP) para autenticar, encargar e unir dispositivos de radio novos e non fiables a unha rede de malla de forma segura. As redes de subprocesos comprenden unha malla autónoma de dispositivos de autoconfiguración con interfaces IEEE 802.15.4 e unha capa de seguridade a nivel de ligazón que require que cada dispositivo da malla posúa a chave mestra secreta compartida actual.
   • O proceso de posta en servizo comeza cando un candidato a comisario, normalmente un teléfono móbil conectado mediante WiFi, descobre a rede Thread a través dun dos seus enrutadores de fronteira. Border Routers anuncia a súa dispoñibilidade aos Comisarios usando calquera lugar de servizo que sexa apropiado. O mecanismo de descubrimento debe proporcionar ao candidato ao comisario tanto unha ruta de comunicación como o nome da rede, porque o nome da rede úsase máis tarde como sal criptográfica para establecer a sesión de posta en servizo.
   • O candidato ao comisario, despois de descubrir a rede Thread de interese, conéctase a ela de forma segura mediante a credencial de comisionado (unha frase de acceso seleccionada por humanos para usar na autenticación). O paso de autenticación do comisario establece unha conexión segura de socket cliente/servidor entre o candidato ao comisario e un enrutador fronteirizo a través de DTLS. Esta sesión segura coñécese como sesión de comisionado. A sesión de posta en servizo utiliza o número de porto UDP asignado anunciado durante a fase de descubrimento. Este porto coñécese como Porto Comisario. A credencial utilizada para establecer a sesión de posta en servizo coñécese como chave precompartida para o comisario (PSKc).
   • A continuación, o candidato ao comisario rexistra a súa identidade co seu router fronteirizo. O líder responde aceptando ou rexeitando o Border Router como un reenviador viable para o Comisionado.
   • Tras a aceptación, o líder actualiza o seu estado interno para rastrexar o comisario activo e, a continuación, o enrutador fronteirizo envía unha mensaxe de confirmación ao candidato ao comisario informando ao dispositivo de que agora é o comisario.
   • Cando hai un comisario autorizado asociado coa rede Thread, é posible unirse a dispositivos Thread elegibles. Estes son coñecidos como Joiners antes de formar parte do
   • Rede de fíos. O Joiner crea primeiro unha conexión DTLS co Comisionado para intercambiar material de comisionado. A continuación, utiliza o material de posta en servizo para conectarse á rede Thread. O nodo considérase parte da rede só despois de completar estes dous pasos. Despois pode participar no proceso de unión para futuros nós. Todos estes pasos confirman que o dispositivo correcto se uniu á rede Thread correcta e que a propia rede Thread está segura contra ataques sen fíos e Internet. Para obter máis información sobre o protocolo de posta en servizo da malla, consulte a especificación do Thread.
2. Posta en servizo mellorada con extensións comerciais no fío 1.2
   • A Especificación de Thread 1.2 e as súas extensións comerciais permiten agora redes a unha escala moito maior, como as necesarias en edificios de oficinas, edificios públicos, hoteis ou outro tipo de edificios industriais ou comerciais. Debido a un mellor soporte de subredes, Thread Spec-ification 1.2 permite con máis facilidade miles de dispositivos nunha soa implementación, que se poden configurar manualmente, de forma autónoma e mediante funcións avanzadas de posta en servizo remota.
   • As extensións comerciais do Thread 1.2 permiten a autenticación a gran escala, a unión á rede, a itinerancia de subredes e o funcionamento baseado en identidades de confianza nun dominio empresarial. Para permitir a autenticación fiable dos dispositivos e a verificación da información de autorización, un instalador do sistema pode configurar unha autoridade de certificación empresarial para simplificar a implantación dunha rede a gran escala. Isto permítelle ao instalador configurar e manter a rede sen acceso directo aos dispositivos individuais e sen ningunha interacción directa con estes, mediante un proceso de rexistro automatizado denominado Rexistro Autónomo. A diferenza do Thread 1.1, onde o emparejamento do código de acceso do dispositivo se usa para a autenticación, as extensións comerciais do Thread 1.2 admitirán unha forma de autenticación máis escalable baseada en certificados. Unha rede empresarial pode ter un ou máis dominios Thread e cada dominio Thread pódese configurar para integrar varias redes Thread.

Capa de aplicación

Thread é unha pila de rede de malla sen fíos que se encarga de enrutar as mensaxes entre diferentes dispositivos da rede Thread descrita na sección 2.2 Arquitectura de rede Thread. A seguinte figura ilustra as capas do protocolo Thread.

Figura 12.1. Capas de protocolo de subprocesos

• Unha definición estándar dunha capa de aplicación é unha "capa de abstracción que especifica os protocolos compartidos e os métodos de interface utilizados polos anfitrións nunha rede de comunicacións" (https://en.wikipedia.org/wiki/Application_layer). En palabras máis sinxelas, unha capa de aplicación é a "linguaxe dos dispositivos", por exemploample, como un interruptor fala cunha bombilla. Usando estas definicións, non existe unha capa de aplicación en Thread. Os clientes constrúen a capa de aplicación en función das capacidades da pila Thread e dos seus propios requisitos. Aínda que Thread non proporciona unha capa de aplicación, ofrece servizos básicos de aplicación:
• Mensaxería UDP
  UDP ofrece unha forma de enviar mensaxes usando un número de porto de 16 bits e un enderezo IPv6. UDP é un protocolo máis sinxelo que o TCP e ten menos sobrecarga de conexión (por exemploample, UDP non implementa mensaxes de mantemento). Como resultado, UDP permite un maior rendemento de mensaxes e reduce o orzamento total de enerxía dunha aplicación. UDP tamén ten un espazo de código menor que TCP, o que deixa máis flash dispoñible no chip para aplicacións personalizadas.
• Mensaxería multidifusión
  Thread ofrece a posibilidade de transmitir mensaxes, é dicir, enviar a mesma mensaxe a varios nodos dunha rede Thread. Multicast permite unha forma integrada de falar cos nodos veciños, enrutadores e toda unha rede Thread con enderezos IPv6 estándar.
• Capas de aplicación que utilizan servizos IP
  Thread permite o uso de capas de aplicación como UDP e CoAP para permitir que os dispositivos se comuniquen de forma interactiva a través de Internet. As capas de aplicacións non IP requirirán algunha adaptación para traballar en Thread. (Consulte RFC 7252 para obter máis información sobre CoAP).
  • O SDK OpenThread de Silicon Labs inclúe os seguintes sampaplicacións que tamén están dispoñibles no repositorio de OpenThread GitHub:• ot-cli-ftd
  • ot-cli-mtd
  • ot-rcp (usado xunto cun enrutador de bordes OpenThread)
• Estas aplicacións pódense usar para demostrar as características dunha rede Thread. Ademais, o SDK OpenThread de Silicon Labs tamén ofrece un dispositivo final con sonoample (sleepy-demo-ftd e sleepy-demo-mtd), que mostra como usar as funcións do xestor de enerxía de Silicon Labs para crear un dispositivo de baixa potencia. Finalmente, o ot-ble-dmp sampa aplicación mostra como construír unha aplicación multiprotocolo dinámica usando OpenThread e a pila Bluetooth de Silicon Labs. Consulte QSG170: Guía de inicio rápido de OpenThread para obter máis información sobre como traballar con exampaplicacións en Simplicity Studio 5.

Próximos pasos

• O SDK OpenThread de Silicon Labs inclúe unha pila de rede OpenThread certificada e sampaplicacións que demostran o comportamento básico da rede e da aplicación. Anímase aos clientes a utilizar os s incluídosample para familiarizarse con Thread en xeral e coa oferta de Silicon Labs en particular. Cada unha das aplicacións demostra como os dispositivos se forman e se unen ás redes, así como como se envían e reciben as mensaxes. As aplicacións están dispoñibles para o seu uso despois de cargar Simplicity Studio 5 e Silicon Labs OpenThread SDK. Simplicity Studio 5 inclúe soporte para a creación de aplicacións (Configurador de proxectos) e a decodificación das mensaxes da capa de rede e da aplicación (Analizador de rede) en Thread que proporcionan información adicional sobre o funcionamento das redes Thread. Para obter máis información, consulte QSG170: Guía de inicio rápido de OpenThread.
• Para obter máis información sobre os enrutadores de borde OpenThread, consulte AN1256: Usando o Silicon Labs RCP co OpenThread Border Rout-er. Para obter máis información sobre o desenvolvemento de Thread 1.3.0 sampas aplicacións consulte AN1372: Configuración de aplicacións OpenThread para Thread 1.3.

Exención de responsabilidade

• Silicon Labs pretende ofrecer aos clientes a documentación máis recente, precisa e detallada de todos os periféricos e módulos dispoñibles para os implementadores de sistemas e software que utilicen ou teñan intención de utilizar os produtos de Silicon Labs. Os datos de caracterización, os módulos e periféricos dispoñibles, os tamaños de memoria e os enderezos de memoria refírense a cada dispositivo específico, e os parámetros "típicos" proporcionados poden variar en diferentes aplicacións. Aplicación exampOs aquí descritos son só para fins ilustrativos. Silicon Labs resérvase o dereito de facer cambios sen previo aviso na información do produto, especificacións e descricións aquí, e non ofrece garantías sobre a precisión ou integridade da información incluída. Sen notificación previa, Silicon Labs pode actualizar o firmware do produto durante o proceso de fabricación por motivos de seguridade ou fiabilidade. Tales cambios non alterarán as especificacións nin o rendemento do produto. Silicon Labs non terá ningunha responsabilidade polas consecuencias do uso da información proporcionada neste documento. Este documento non implica nin concede expresamente ningunha licenza para deseñar ou fabricar circuítos integrados. Os produtos non están deseñados nin autorizados para ser utilizados en ningún dispositivo da Clase III da FDA, aplicacións para as que se require a aprobación previa da FDA ou sistemas de soporte vital sen o consentimento específico por escrito de
• Silicon Labs. Un "Sistema de Soporte Vital" é calquera produto ou sistema destinado a apoiar ou manter a vida e/ou a saúde que, se falla, pode esperarse razoablemente que resulte en danos persoais importantes ou a morte. Os produtos de Silicon Labs non están deseñados nin autorizados para aplicacións militares. Os produtos de Silicon Labs non se utilizarán en ningún caso en armas de destrución masiva incluídas (pero non limitadas a) armas nucleares, biolóxicas ou químicas ou mísiles capaces de lanzar tales armas. Silicon Labs renuncia a todas as garantías expresas e implícitas e non se fará responsable de ningunha lesión ou dano relacionado co uso dun produto de Silicon Labs nesas aplicacións non autorizadas. Nota: este contido pode conter terminoloxía ofensiva que agora está obsoleta. Silicon Labs está a substituír estes termos por linguaxe inclusiva sempre que sexa posible. Para máis información, visite www.silabs.com/about-us/inclusive-lexicon-project

Información da marca comercial

• Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® e o logotipo de Silicon Labs®, Bluegiga®, Bluegiga Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo e combinacións dos mesmos , "os microcontroladores máis amigables coa enerxía do mundo", Redpine Signals®, WiSeConnect , n-Link, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio®, Telegesis, the Telegesis Logo®, USBXpress®, Zentri, o logotipo de Zentri e Zentri DMS, Z-Wave® e outros son marcas comerciais ou marcas rexistradas de
• Silicon Labs. ARM, CORTEX, Cortex-M3 e THUMB son marcas comerciais ou marcas rexistradas de ARM Holdings. Keil é unha marca rexistrada de ARM Limited. Wi-Fi é unha marca rexistrada de
• Alianza Wi-Fi. Todos os demais produtos ou marcas mencionadas aquí son marcas comerciais dos seus respectivos posuidores.
  • Silicon Laboratories Inc. 400 West Cesar Chavez Austin, TX 78701 USA
  • www.silabs.com

Documentos/Recursos

SILICON LABS UG103.11 Software Fundamentos de Thread [pdfGuía do usuario UG103.11 Software Fundamentos de Thread, UG103.11, Software Fundamentos de Thread, Software Fundamental, Software

Referencias

• Manual de usuario