Bienvenido al Blog de Altronics Chile

¿Cuántos Nodos Soporta un Gateway LoRaWAN®?

¿Cuántos Nodos Soporta un Gateway LoRaWAN®?

LoRaWAN® puede ayudarte a comunicar tus dispositivos IoT con Internet. LoRaWAN® es una tecnología de red inalámbrica de bajo consumo y largo alcance que permite conectar miles de nodos finales a través de una o varias puertas de enlace o gateways. Estas puertas de enlace son dispositivos que tienen un módulo de transmisión (concentrador) LoRa y que redirigen la información entre Internet y los nodos que se comuniquen con ellos y viceversa.

Pero, ¿cuántos nodos se pueden conectar a un Gateway LoRaWAN®? La respuesta no es sencilla, ya que depende de varios factores, como la frecuencia de envío de datos de los nodos, la longitud de los paquetes, el factor de dispersión (Spreading Factor), la intensidad de la señal, la tasa de transmisión (Data Rate) y el tipo de chip del gateway. Sin embargo, se pueden hacer algunos cálculos aproximados basados en el valor teórico y el valor real.

El valor teórico es el número máximo de paquetes de datos que puede recibir un gateway por día, dividido entre el número de paquetes que envía cada nodo por hora. Por ejemplo, si un gateway está equipado con un chip SX1301, puede recibir hasta 1.5 millones de paquetes por día. Si cada nodo envía un paquete por hora, entonces el número máximo de nodos que puede soportar el gateway es 1,500,000 / (24*1) = 62,500.

El valor real es mucho más complicado, ya que depende de la longitud de los datos que envía cada nodo y del factor de dispersión que utiliza. El factor de dispersión es un parámetro que determina la velocidad y la robustez de la transmisión LoRa. A mayor factor de dispersión, menor velocidad y mayor robustez. La longitud de los datos que se pueden enviar varía según el factor de dispersión y la intensidad de la señal. Por ejemplo, si el factor de dispersión es 7 y la intensidad es -137 dBm, se pueden enviar hasta 51 bytes por paquete. Si el factor de dispersión es 12 y la intensidad es -117 dBm, se pueden enviar hasta 11 bytes por paquete.

Por lo tanto, para calcular el valor real del número de nodos que puede soportar un gateway, hay que tener en cuenta la longitud total de datos que envía cada nodo por día y dividirla entre la longitud máxima que se puede enviar por paquete según el factor de dispersión y la intensidad. Luego hay que multiplicar el resultado por la frecuencia de envío y dividirlo entre el número máximo de paquetes que puede recibir el gateway por día.

En general, se puede decir que cuantos más datos envíe cada nodo y más bajo sea el factor de dispersión, menor será el número de nodos que podrá soportar un gateway. Por el contrario, cuantos menos datos envíe cada nodo y más alto sea el factor de dispersión, mayor será el número de nodos que podrá soportar un gateway.

Según algunos ejemplos prácticos, en el caso de The Things Network (TTN), una plataforma abierta para construir redes LoRaWAN, un gateway puede dar servicio a unos 1000 nodos.

Cómo Optimizar el Consumo de Batería en Dispositivos LoRaWan®

Cómo Optimizar el Consumo de Batería en Dispositivos LoRaWan

Existen muchos factores que determinan la duración de la batería en dispositivos LoRaWAN® y si no los conocemos, podemos enfrentar la frustración de haber consumido toda la carga en un período mucho menor que el ofrecido por el fabricante. Este artículo tiene el fin de detallar estos factores y entregar consejos para fomentar las buenas prácticas y mejorar la experiencia del usuario con esta tecnología.

Entre los factores principales que identificamos y que pueden incidir significativamente en la duración de la batería de un dispositivo LoRaWAN®, tenemos los siguientes:

  • Potencia de Transmisión (Transmission Power)
  • Spreading Factor (Factor de Dispersión)
  • Data Rate (Tasa de Transmisión)
  • Intervalo de Transmisión
  • Configuración de banda equivocada
  • Selección de Plan de Frecuencia
  • Retransmisiones
  • Altura de Instalación de Antenas (Zona de Fresnel)
  • Calidad y Tipo de Cables y antenas
  • Sensores Externos
  • LBT (Listen Before Talk – Escuchar Antes de Hablar)
  • Nodo sin enlace con el servidor de red LoRaWAN®

Utilizaremos intencionalmente algunos términos en español y otros en inglés porque creemos que se entenderá mejor.

Este artículo utiliza como ejemplo el caso de nodos marca Dragino.

Potencia de Transmisión (Transmission Power)

Comenzamos con el punto más obvio, que es la potencia de transmisión. En el caso de LoRaWAN®, existen regulaciones en diferentes zonas geográficas que limitan la potencia máxima de transmisión. Por ejemplo, en Europa, el límite es 14dBm (25mW) para uplink de datos. Para Norteamérica, el límite es 20dBm (100mW).

En general, la mayoría de los nodos LoRaWAN® permiten configurar la potencia de transmisión y en caso de usar una potencia fija, podríamos establecerla en el nivel justo y necesario para llegar de manera estable a la distancia que queremos alcanzar. Si la potencia es insuficiente, el equipo no recibirá confirmación de la recepción de los mensajes de uplink y realizará una o más retransmisiones. Esto afectará negativamente al consumo de energía del equipo. Por otra parte, si la potencia de transmisión es excesiva, estaremos desperdiciando energía y descargando la batería de manera prematura.

En el caso en que el nodo LoRaWAN® tenga activo el Adaptive Data Rate – que para equipos marca Dragino se activa con el comando AT+ADR=1 -  el servidor LoRaWAN se encargará de asignarle de forma dinámica al nodo los parámetros de potencia, data rate y spreading factor.

En el caso de asignar la potencia de transmisión de forma manual, podemos utilizar el comando AT+TXP=X, donde X es un valor entre 0 y 5 (0:MAX, 5:MIN).

La máxima potencia de transmisión se establece con el comando AT+TXP=50

Spreading Factor

En LoRaWAN® existen parámetros regionales que establecen combinaciones válidas de Data Rate, Spreading Factor y Dwell Time. Es un asunto un poco complejo, pero ya viene implementado por el fabricante y no es necesario conocerlo con demasiado detalle para los fines que se plantean en este artículo. Lo importante es que existe un compromiso entre el Spreading Factor, el alcance de la señal, el consumo de energía, la duración de la transmisión y el ancho de banda (data rate). Si queremos llegar a grandes distancias, tendremos que utilizar un Spreading Factor mayor (por ejemplo SF12) y eso implicará que tendremos un Data Rate menor, que la transmisión durará más tiempo y que el consumo de energía será mayor.

Cuando utilizamos un Data Rate Bajo (Spreading Factor Alto), normalmente podemos transmitir 11 bytes de datos en cada uplink y cuando utilizamos un Data Rate Alto (Spreading Factor Bajo) podemos transmitir hasta 51 bytes en cada uplink.

En la siguiente tabla se aprecia cuanto tiempo de transmisión necesitamos según el Spreading Factor utilizado:

Spreading Factors

En equipos marca Dragino que utilizan el plan de frecuencia AU915, se puede usar el comando AT+DWELLT=0 para establecer un Dwell Time compatible con Data Rates bajos (Spreading Factor Alto). Esta es la configuración que utilizaríamos cuando necesitamos llegar a grandes distancias. Por otra parte, cuando no necesitamos llegar a distancias tan grandes, pero sí necesitamos un ancho de banda mayor, utilizaremos el comando AT+DWELLT=1       . Si queremos establecer manualmente el Data Rate, tendremos que desactivar el Adaptive Data Rate con el comando AT+ADR=0 y luego establecemos el Data Rate con el comando AT+DR=X, donde X es un valor entre 0 y 5.

Data Rates

Normalmente no tenemos un comando que permita establecer de forma directa el Spreading Factor debido a que éste se deduce automáticamente de los otros parámetros ya mencionados. Al utilizar Adaptive Data Rate, este parámetro se establecerá de forma automática. Al utilizar Data Rate manual, el Spreading Factor dependerá del Data Rate que hayamos escogido y del Dwelt Time que hayamos configurado.

 

Data Rate (Tasa de Transmisión)

Tal como se indicó en el punto anterior, el Data Rate no es un parámetro independiente, sino que está relacionado con otros parámetros regionales y físicos que lo limitan. Podemos usar Data Rate automático (Adaptive Data Rate), que se asigna de forma dinámica desde el servidor de Red LoRaWAN® y también podemos establecer un Data Rate establecido manualmente. Esto se debe seleccionar según el ancho de banda requerido y distancia que se quiere alcanzar. Se podría determinar de forma empírica, mediante pruebas o simulando con algún software apropiado. Obviamente, en la mayoría de los casos será más fácil utilizar Adaptive Data Rate.

Desde el punto de vista de consumo de energía, es mejor utilizar un Data Rate más alto (Spreading Factor Menor), porque el tiempo de transmisión será más corto y eso incidirá directamente en la duración de la batería.

 

Intervalo de Transmisión

Se recomienda que - dentro de lo posible - el intervalo de transmisión entre cada Uplink no sea menor que 5 minutos, porque en caso contrario no lograremos una duración de batería de varios años.

Para optimizar la duración de la batería, es necesario que el dispositivo se mantenga durante el mayor tiempo posible en estado de “Deep Sleep”. Si establecemos un tiempo de Uplink demasiado bajo (por ejemplo, un minuto), el equipo no tiene tiempo suficiente para “dormirse” y volver a despertar. Si el equipo está apagándose y encendiéndose con demasiada frecuencia, esto significará un consumo de energía mayor que lo normal.

Para decidir cuál es el intervalo de transmisión apropiado, deberemos considerar los requerimientos de la aplicación y simular las condiciones mediante la planilla Excel proporcionada por Dragino para estos fines.

Se recomienda revisar las recomendaciones de Dragino al respecto.

La planilla Excel nos permite hacer una predicción de la duración de la batería en diferentes escenarios (por ejemplo, usando diferentes Data Rates o Spreading Factors).

 

Configuración de banda equivocada

Si el plan de frecuencia y/o la subbanda de transmisión no están configurados correctamente, el nodo estará transmitiendo y retransmitiendo en canales de frecuencia que no son escuchados por el Gateway LoRaWAN. Cada retransmisión implicará un gasto innecesario de tiempo, energía y uso del espectro de frecuencia disponible. Para entender mejor este punto es recomendable revisar este artículo que publicamos anteriormente:

El Error Más Cómún de Los que se Inician en LoRaWAN®

AU915

Tanto TTN (The Things Network) como los Gateways marca Dragino utilizan la subbanda 2 por defecto (la que está marcada en amarillo en la tabla anterior).

El nodo LoRaWAN® Dragino viene configurado por defecto con AT+CHE=0, lo que implica que  estará haciendo saltos de frecuencia en los 64 canales disponibles para uplink, pero el Gateway sólo escuchará en los 8 canales de la subbanda 2. Para evitar este problema se debe configurar el nodo con el comando AT+CHE=2 para que sólo transmita en el grupo de canales de la subbanda 2.

 

Selección de Plan de Frecuencia

Las ondas electromagnéticas de frecuencias más bajas tienen un alcance mayor y una capacidad de penetración también mayor que las ondas de frecuencias más altas. Por ejemplo, si tenemos dos transmisores de la misma potencia, uno trabajando en la banda de los 433 Mhz y el otro en la banda de los 915 Mhz, el primero llegará a distancias mucho mayores que el segundo y tendrá mayor capacidad de atravesar obstáculos.

En el caso de redes LoRaWAN® no tenemos muchas posibilidades de jugar con este parámetro porque los planes de frecuencia ya están definidos para cada ubicación geográfica.

https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country/

La banda de frecuencia también incide en el consumo de energía necesario para llegar a una distancia determinada, pero en estos casos no dependerá de nosotros, sino que dependerá de la ubicación geográfica de la aplicación.

 

Retransmisiones

Se mencionó en puntos anteriores que las retransmisiones son algo indeseado porque provocan un gasto de energía adicional. Se pueden producir retransmisiones por muchas razones, entre otras:

  • Interferencia debida a una densidad muy alta de nodos por unidad de superficie transmitiendo en los mismos canales.
  • Enlace muy pobre con pérdida de paquetes.
  • Servidor LoRaWAN® inalcanzable.
  • Parámetros de autenticación incorrectos.
  • Gateway LoRaWAN® inalcanzable.
  • Otros

En caso de notar que un nodo está haciendo muchas retransmisiones, Dragino recomienda revisar esta publicación.

 

Altura de Instalación de Antenas (Zona de Fresnel)

Si tenemos un enlace muy débil, lo podemos mejorar aumentando la potencia de transmisión. En el caso de aumentar la potencia, se verá afectado el consumo de energía y la duración de la batería – y esto no es lo que queremos -. Para mejorar el enlace, lo ideal es recurrir a otras variables que no requieran aumentar el consumo de energía. Por ejemplo, podríamos aumentar la ganancia de las antenas o elevar la altura de instalación de las antenas.

Un enlace débil podría tener como causa lo que se conoce como Zona de Fresnel:

Zona de Fresnel

En términos muy simples podemos decir que una parte de la señal se pierde o se absorbe en la tierra (u otros obstáculos) y esto se puede evitar aumentando la altura de instalación de las antenas. Si necesitamos simular o saber cuál sería la altura suficiente para obtener un buen enlace, podemos utilizar herramientas de software como por ejemplo Radio Mobile. Incluso existe una versión online de Radio Mobile, para evitar lo engorroso de la instalación.

A mayor distancia del enlace, mayor será la altura requerida de las antenas.

 

Calidad y Tipo de Cables y antenas

Tal como se indicó en el punto anterior, es preferible utilizar otras variables para mejorar la calidad de un enlace, antes que aumentar la potencia de transmisión. La calidad de los cables, conectores y antenas que utilicemos tiene una incidencia importante en las pérdidas de potencia que se generan en cada componente que conforma un sistema inalámbrico. Por ejemplo, para la conexión de la antena, se recomienda utilizar cable LMR400 debido a sus bajas pérdidas (para largo de cable hasta 15 metros).

 

Sensores Externos

Muchos nodos LoRaWAN® permiten la conexión de sensores externos e incluso permiten suministrar alimentación para el funcionamiento de estos. Esto se debe tener en consideración al momento de calcular la duración de la batería porque es un consumo adicional que no necesariamente aparecerá en las especificaciones del fabricante.

 

LBT (Listen Before Talk – Escuchar Antes de Hablar)

Algunos nodos LoRaWAN® implementan una característica conocida como LBT o Listen Before Talk. Esta característica se trata de que el nodo verifique antes de transmitir, si ya existe otro nodo transmitiendo en este momento en ese mismo canal de frecuencia. Si el nodo verifica esa condición, saltará a otro canal de frecuencia para evitar la colisión y posterior retransmisión, optimizando el uso de batería. Esta característica es relevante cuando tenemos una densidad muy alta de nodos por unidad de superficie y con un intervalo de transmisión relativamente alto. Para explicarlo un poco mejor, imaginemos el caso en que existan 1000 nodos en un kilómetro cuadrado y transmitiendo cada 5 minutos cada uno. La probabilidad de colisiones y retransmisiones será bastante alta. Como contraparte, pensemos en la misma aplicación, pero con cada nodo transmitiendo un dato casa 2 horas. En este caso, la probabilidad de colisiones será mucho menor y no tendría mucha importancia contar con la característica LBT. Si el Gateway escucha en 8 canales, y cada equipo está transmitiendo 12 veces por día, tendremos 12000 uplinks repartidos en 24 horas (=> 1500 uplinks diarios por canal). Si los datos llegaran a intervalos fijos y uniformes, tendríamos un uplink cada 57,6 segundos. Esto nos permite hacernos una idea del porcentaje de ocupación del espectro en el tiempo.

 

Nodo Sin Enlace con el Servidor de Red LoRaWAN®

Este último punto es uno de los más importantes. Se trata de que si encendemos/energizamos un nodo LoRaWAN®, éste intentará hacer un “Join Request” para unirse al servidor de red LoRaWAN®. Si el servidor de red está inalcanzable o apagado, el nodo seguirá reintentando unirse y no podrá cumplir con su ciclo/intervalo de transmisión. No podrá entrar al estado de Deep Sleep para ahorrar batería. La consecuencia de esto es que la batería del nodo se agotará en un tiempo mucho menor que el esperado. Si el Gateway LoRaWAN® no está encendido o es inalcanzable por el nodo, también ocurrirá lo mismo.

Entonces, la recomendación es que nunca dejemos encendido un nodo LoRaWAN® si es que este no está dentro del radio de cobertura del Gateway y con conectividad hacia el servidor de red LoRaWAN®.

Durante la implementación de una red LoRaWAN, debemos procurar que el servidor de red y el Gateway estén operativos antes de encender los nodos. También debemos crear el nodo (ingresar las credenciales) en el servidor de red, porque el “Join Request” no será exitoso si no lo hemos hecho y esto provocaría constantes retransmisiones y algo consumo de energía.

 

Glosario de Términos

Dwell Time:

Dwell time es el tiempo necesario para transmitir un mensaje LoRaWAN. En algunas regiones se configura un dwell time máximo permitido para limitar el tiempo de transmisión, normalmente 400 ms. El dwell time depende del ancho de banda, el factor de dispersión y el tamaño del paquete. El dwell time también afecta al tiempo de salto (hop time), que es el intervalo mínimo entre dos transmisiones consecutivas en el mismo canal.

Spreading Factor:

El spreading factor (SF) es un parámetro de la modulación LoRa que controla la velocidad de transmisión de datos. El SF determina el número de chirps por símbolo, que es una medida de la redundancia de la señal. Un SF mayor implica más chirps por símbolo, lo que reduce la velocidad de datos, aumenta el tiempo en el aire, mejora la sensibilidad del receptor y amplía el alcance de la comunicación. Un SF menor implica menos chirps por símbolo, lo que aumenta la velocidad de datos, reduce el tiempo en el aire, disminuye la sensibilidad del receptor y reduce el alcance de la comunicación. 

.

El Error Más Cómún de Los que se Inician en LoRaWAN

El error más común de los que se inician en la tecnología de redes LoRaWAN.

Quienes se inician en la tecnología de redes LoRaWAN® se suelen enfrentar a problemas que no parecen tener una explicación evidente y pueden perder muchas horas e incluso días tratando de descubrir el oriden del problema.

En este artículo vamos a hablar acerca del problema más común que enfrentan los newbies cuando están poniendo en marcha su primera red LoRaWAN.

La mayoría de los Gateways LoRaWAN sólo pueden escuchar en 8 canales de frecuencia al mismo tiempo (algunos pueden escuchar 16 o más). Los nodos LoRaWAN por defecto hacen saltos pseudoaleatorios de frecuencia y transmiten en todos los canales que conforman el plan de frecuencia seleccionado. Por ejemplo, el plan de frecuencia AU915 tiene 64 canales para Uplink.

AU915

Entonces el problema es que el nodo transmite datos en muchos canales que no están siendo escuchados y eso hace que tenga que gastar energía innecesaria retransmitiendo paquetes que no llegan a destino. El usuario no entiende porqué al principio parecía que el nodo estaba transmitiendo correctamente y luego dejaron de llegar paquetes de datos.

Según lo que se muestra en la siguiente imagen, en la configuración del Gateway se selecciona una Subbanda de 8 canales y por lo tanto el Gateway sólo escuchará paquetes de datos en esos 8 canales.

Subbanda

Para que todos los paquetes sean escuchados y no tengan que ser retransmitidos, se debe cambiar la configuración de cada nodo, de tal manera que sólo transmita en esa misma sub-banda de 8 canales. En el ejemplo presentado, estamos usando la Subbanda número 2, entonces debemos configurar los nodos para que transmitan en esa misma subbanda.

En el caso de los nodos Dragino esto se logra enviando el siguiente comando AT al nodo:

AT+CHE=2

Al enviar ese comando AT de configuración, el nodo comenzará a trabajar en modo de 8 canales y dejaremos de perder paquetes de datos.

Política de Comentarios

En este sitio no se permiten insultos. Lo primero es el respeto. Tampoco aceptaremos palabras ofensivas o despectivas.

Aplicación SDN Zerotier con Router Altronics-201

Acceso remoto a cualquier dispositivo con Zerotier y Router Altronics

Zerotier es una solución SDN (Software Defined Networking). Gracias a esto se puede crear redes virtuales (similar a lo que se hace con una VPN), pero con la gran ventaja de que en este caso las conexiones son P2P (Peer to Peer), entonces todo el tráfico de red corre directo entre los equipos involucrados, sin pasar a través de un servidor. Todas las comunicaciones son seguras y cifradas. Otra ventaja es que las configuración es mucho más fácil y rápida si la comparamos con el caso de las VPN’s. Este router viene con Zerotier preinstalado y preconfigurado. Si usted ya tiene una red Zerotier configurada, sólo necesita ingresar el Network ID de la red a la que se quiere conectar en la sección Servicios->Zerotier.

Descripción de la imagen

Cabe destacar que se puede ingresar más de un Network ID, entonces se puede estar conectado a varias redes de forma simultánea.

Ejemplo de Aplicación con Zerotier

Supongamos que usted necesita instalar su router en un sitio remoto, para lograr acceso desde cualquier parte a los equipos que instalará detrás del router.

Supongamos que dejamos el Router con la siguiente dirección IP por el lado de la LAN: 192.168.1.1 Y podríamos conectar una x cantidad de equipos a los puertos LAN de router. En caso que necesitemos más puertos, será necesario instalar uno o más switches Ethernet. Los equipos que conectaremos en el lado de la LAN tendrán direcciones IP 192.168.1.x. Por ejemplo podríamos tener:

  • Un PLC con dirección IP 192.168.1.4
  • Una HMI con dirección IP 192.168.1.6
  • Una cámara con dirección IP 192.168.1.2
  • Otros

El router podrá salir a Internet a través del puerto WAN o a través de la red celular. En caso necesario se puede instalar y configurar el paquete Multiwan de Openwrt para gestionar balanceo de carga o reglas en caso de falla de la conexión a Internet. Para continuar con nuestra aplicación es necesario crear una red en la plataforma de gestión de redes Zerotier. Para esto debemos ingresar a: https://my.zerotier.com El servicio Zerotier proporciona de manera gratuita la plataforma de gestión para un máximo de 50 equipos. Esto debe ser suficiente para la mayoría de las aplicaciones porque los equipos que están detrás del router no cuentan. Por ejemplo podríamos tener 32 routers, cada uno con 250 equipos detrás. En tal caso tendríamos una red con un total de 1600 equipos que podrían comunicarse entre sí, sin tener que pagar nada por el sistema de gestión. Para redes de más de 50 equipos, consulte los precios en el sitio web de Zerotier. ¿Porqué es gratis? La respuesta es que debido a que las conexiones entre los equipos son Peer to Peer, no estamos sobrecargando a los servidores de Zerotier con el tráfico de nuestras redes. Por ejemplo, sería imposible tener una red de VPN de estas características y que sea gratis, porque en tal caso todo el tráfico pasaría a través del servidor. Cabe mencionar aquí que Zerotier proporciona aplicaciones cliente gratuitas para la mayoría de los sistemas operativos:

  • Windows
  • Linux
  • Apple Macintosh
  • iOS (Iphone, iPad, iPod Touch)
  • Android
  • Otros

También se proporciona una librería para su integración con los lenguajes de programación más populares. Este es el aspecto actual de la página de ingreso al sistema de gestión de redes de Zerotier:

Descripción de la imagen

Para entrar al portal, se puede ingresar con cualquier cuenta de Google existente o se puede crear una cuenta de forma gratuita registrándose. Una vez dentro del portal, se debe ingresar a la sección “Networks” y crear una nueva red.

Descripción de la imagen

A la red recién creada se le puede asignar un nombre para que sea fácil de identificar. Luego se debe dar click sobre el nombre de la red para ingresar a su configuración y tomar nota del “Network ID” que es el identificador único de cada red.

Descripción de la imagen

El Network ID se debe ingresar en la configuración Zerotier del Router, tal como se explicó en el punto anterior, para que el router sepa que debe conectarse a esta red. Tenemos que saber que la red Zerotier utilizará para su implementación un rango de direcciones IP que no pueden ser las mismas que se están utilizando para el lado de la LAN del router. Es recomendable que marquemos la opción IPv4 Auto-Assign from Range. Podemos especificar un rango o escoger uno de los que se ofrecen como casos típicos. En el caso de nuestro ejemplo estamos utilizando el rango de direcciones IP desde 192.168.191.1 hasta 192.168.192.254.

En General, con la versión gratuita de Zerotier, se debe seleccionar una red con máscara de subred /24 (255.255.255.0), porque en tal caso no se permite una red más amplia. Por ejemplo las redes que se muestran marcadas a continuación con un óvalo de color rojo, serían válidas:

Descripción de la imagen

Otra opción importante es la de “Access Control”. Si escogemos la opción “None (Public Network)”, cualquiera que conozca el Network ID se podrá conectar a esta red. Por otra parte, si escogemos “Certificate (Private Network)”; será necesario autorizar explícitamente a cada participante de la red. Cabe mencionar que el sistema de gestión permite establecer reglas avanzadas para limitar el tráfico entre los participantes de la red. Las demás opciones de configuración se pueden dejar tal como vienen por defecto. En algunos casos es necesario reiniciar el router para que los cambios se hagan efectivos. En la misma página de configuración de red de la plataforma de gestión de My.zerotier.com, debemos bajar hasta la sección “Members” y debe aparecer el nuevo nodo de red que es nuestro router recién configurado.

Descripción de la imagen

Se debe autorizar al cliente para que pueda conectarse efectivamente y obtener una dirección IP.

Descripción de la imagen

Descripción de la imagen

Una vez que el cliente ha sido autorizado, debe tardar unos pocos segundos en mostrar su dirección IP. Lo único que falta para que nuestra aplicación funcione, es que le indiquemos al sistema de gestión de redes de Zerotier que de aquí en adelante la red con direcciones IP 192.168.1.x será accesible a través del router, que en este caso tiene asignada la dirección 192.168.191.109. En esta misma sección en la que se autoriza al cliente, se le puede asignar un nombre para identificarlo fácilmente y también se le puede cambiar manualmente la dirección IP en caso que queramos darle otra. Ahora debemos volver a la parte superior de la página e ingresar la ruta de red, para que todos los participantes la tomen en cuenta.

Descripción de la imagen

En este caso estamos declarando que toda la red 192.168.1.x será accesible a través de la IP 192.168.191.109. Esta última es la IP que el sistema le asignó al router dentro de la red virtual Zerotier. A partir de ahora, podremos acceder al router y a los dispositivos de la red LAN del router con cualquier dispositivo que se conecte a la misma red. Por ejemplo un cliente Windows o Android con la aplicación Zerotier.