Traducido del English por IA ·
En la parte de radio tiene algo de razón. Contiki-NG sí tiene multicast IPv6 para redes RPL: dos motores, SMRF y MPL. Se activa en tiempo de compilación en el project-conf.h de los nodos y en el del border router:
/* every node and the border router */
#define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_MPL
/* for SMRF instead you also need storing mode with multicast: */
/* #define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_SMRF */
/* #define RPL_CONF_MOP RPL_MOP_STORING_MULTICAST */Donde tiene razón es en que el rpl-border-router estándar no reenvía a la malla el multicast que llega desde la red externa. Por eso el multicast tiene que originarse en el propio border router: un pequeño proceso en esa máquina que, al recibir una orden de Hermetry, envía un datagrama MPL a un grupo al que se han unido los nodos. Esto implica volver a flashear los 30 nodos con multicast habilitado, lo que en una instalación de almacén frigorífico significa una visita a la planta.Sinceramente, para 30 nodos yo descartaría el multicast. Que el border router recorra las 30 direcciones y envíe unicast con reintentos. 30 paquetes pequeños en una malla no son nada, termina en segundos, y cada nodo confirma, así que sabes quién no lo recibió. Sin reflasheo.Luego, en Hermetry: añade un comando como sampling.set con un parámetro period_s en el perfil de la pasarela, respóndelo desde ese proceso cuando todos los nodos hayan confirmado, y pon dos botones en el panel de QA. Haz que los nodos informen su periodo actual como atributo de cliente para que QA pueda ver que se aplicó.
Partly right on the radio half. Contiki-NG does have IPv6 multicast for RPL networks: two engines, SMRF and MPL. You turn one on at build time in the nodes’ project-conf.h and in the border router’s:
/* every node and the border router */
#define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_MPL
/* for SMRF instead you also need storing mode with multicast: */
/* #define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_SMRF */
/* #define RPL_CONF_MOP RPL_MOP_STORING_MULTICAST */Where he’s right is that the stock rpl-border-router does not forward multicast arriving from the outside network into the mesh. So the multicast has to originate on the border router itself: a small process on that box that, on a command from Hermetry, sends one MPL datagram to a group the nodes joined. It means reflashing all 30 nodes with multicast enabled, which on a cold store install is a site visit.
Honestly, for 30 nodes I’d skip multicast. Have the border router loop over the 30 addresses and send unicast with a retry. 30 small packets on a mesh is nothing, it finishes in seconds, and every node acks so you know who missed it. No reflash.
Then in Hermetry: add a command like sampling.set with a period_s parameter on the gateway’s profile, answer it from that process once all nodes acked, and put two buttons on the QA dashboard. Have the nodes report their current period as a client attribute so QA can see it took.