MX2015000560A - Sistemas y metodos para la distribucion de datos dentro de una red de malla. - Google Patents

Abstract

Se proporcionan sistemas y métodos para distribuir una actualización de firmware dentro de una red de malla. En una implementación, un sistema de distribución de actualización de firmware comprende un proveedor de servicios de utilidad, que está configurado para proporcionar servicios de utilidad a una pluralidad de clientes, una pluralidad de medidores, y una pluralidad de nodos. Cada medidor está configurado para medir los datos de uso de la utilidad de un cliente respectivo. Los nodos están configurados para transmitir los datos de uso de la utilidad desde la pluralidad de medidores hasta el proveedor de servicios de utilidad. Cuando al menos uno de los medidores está programado para recibir una actualización de firmware, el proveedor de servicios de utilidad está configurado para reenviar la actualización de firmware a al menos uno de la pluralidad de nodos. El al menos un nodo está configurado para recibir y almacenar la actualización del firmware y, después de almacenar la actualización del firmware, se configura además remitir la actualización de firmware para al menos uno de la pluralidad de medidores.

Description

SISTEMAS Y MÉTODOS PARA LA DISTRIBUCION DE DATOS DENTRO DEUNA REDDE MALLA ANTECEDENTES Normalmente, los medidores de servicios públicos (por ejemplo, medidores de gas, medidores de agua, medidores de electricidad, etc.) se leen de forma manual por los lectores de medidores que son empleados o contratistas de los distintos proveedores de servicios públicos. La lectura manual del medidor representa un costo significativo para un proveedor de servicios públicos típico. Sin embargo, con el advenimiento de la teenología inalámbrica, incluyendo la creación de redes de malla, los proveedores de servicios públicos han buscado métodos y sistemas de lectura remota de medidores de agua e incluso el control remoto de válvulas de suministro de agua.

La Infraestructura de Medición Avanzada (AMI por sus siglas en inglés) o Gestión de Medición Avanzada (AMM por sus siglas en inglés) son sistemas que miden, recopilan y analizan datos de servicios públicos usando dispositivos de medición avanzada, como medidores de agua, medidores de gas y medidores de electricidad. Además de medir los diversos servicios públicos, los dispositivos de medición avanzada también se configuran con circuitos de comunicación, que permiten a los dispositivos de medición transmitir y recibir los datos a través de la red de AMI. En una configuración típica, un dispositivo avanzado de medición (por ejemplo, un medidor de agua avanzado) mide y recopila datos de uso (por ejemplo, los datos de consumo de agua) en las instalaciones del cliente. El dispositivo de medición a continuación, utiliza una interfaz de comunicación para transmitir datos a un nodo matriz sobre la red de malla, a menudo en respuesta a la petición del nodo matriz de dicha información. Los datos de los medidores se pueden transmitir sobre la red de malla a un colector asociado con el proveedor de servicios públicos. De este modo, los proveedores de servicios públicos pueden remotamente “leer” los datos de consumo del cliente, para propósitos de facturación.

BREVE DESCRIPCIÓN La presente divulgación se refiere en general a redes de malla y más específicamente a sistemas y métodos para distribuir datos incluyendo actualizaciones de firmware) dentro de las redes de malla. De acuerdo con una implementación, un sistema para la distribución de actualizaciones de firmware (bloque de instrucciones de máquina), comprende un proveedor de servicios públicos que está configurado para proporcionar servicios públicos a una pluralidad de clientes. El sistema también incluye una pluralidad de medidores y una pluralidad de nodos intermedios, en donde cada medidor está configurado para medir los datos de consumo del servicio público, de un cliente respectivo. Los nodos intermedios están configurados para transmitir los datos de consumo del servicio desde la pluralidad de medidores hasta el proveedor de servicios públicos, a través de la red de malla. Cuando al menos uno de los medidores (o al menos uno de los nodos intermedios) está programado para recibir una actualización de firmware, el proveedor de servicios públicos está configurado para reenviar la actualización de firmware a, al menos, uno de la pluralidad de nodos intermedios. Al menos uno de los nodos intermedios se configura para recibir y almacenar la actualización de firmware y, después de almacenar la actualización de firmware, se configura además para reenviar la actualización de firmware a al menos uno de la pluralidad de medidores.

Varias implementaciones descritas en la presente divulgación pueden incluir sistemas, métodos, características y ventajas adicionales, que pueden no estar necesariamente divulgadas expresamente en el presente documento, pero serán evidentes para un experto común en la téenica, tras el examen de la siguiente descripción detallada y los dibujos adjuntos. Se pretende que todos esos sistemas, métodos, características y ventajas se incluyan dentro de la presente descripción y sean protegidos por las reivindicaciones adjuntas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Las características y componentes de las siguientes figuras se ilustran para enfatizar los principios generales de la presente divulgación. Las características y los componentes correspondientes en las figuras pueden ser designados, haciendo coincidir los caracteres de referencia en aras de la coherencia y la claridad.

La Figura 1 es un diagrama de bloques que ilustra una red de malla AMI, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 2 es un diagrama de bloques que ilustra una porción de una red de malla AMI, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 3 es un diagrama de bloques que ilustra un sistema de distribución de firmware, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 4 es un diagrama de bloques que ilustra un nodo intermedio de una red de malla AMI, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 5 es una primera toma de pantalla que ilustra una interfaz de usuario, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 6 es una segunda toma de pantalla que ilustra la interfaz de usuario mostrada en la Figura 5, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 7 es una tercera toma de pantalla que ilustra la interfaz de usuario mostrada en la Figura 5, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 8 es una cuarta toma de pantalla que ilustra la interfaz de usuario mostrada en la Figura 5, de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 9 es una toma de pantalla que ilustra una segunda interfaz de usuario de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 10 es una toma de pantalla que ilustra una tercera interfaz de usuario de acuerdo con diversas implementaciones de la presente divulgación.

La Figura 11 es una toma de pantalla que ilustra una cuarto interfaz de usuario de acuerdo con diversas implementaciones de la presente divulgación.

DESCRIPCIÓN DETALLADA La presente divulgación describe sistemas y métodos para comunicar información dentro de una red de malla. Las redes de malla y dispositivos de red de malla se pueden utilizar con los sistemas de Infraestructura de Medición Avanzada (AMI) para la medición de datos de servicios públicos en múltiples lugares y comunicar las lecturas a un proveedor de servicios públicos. En respuesta a la recepción de los datos de servicios públicos, el proveedor de servicios públicos puede determinar la información de facturación de sus clientes. Las mediciones de servicios públicos son realizadas por diversos tipos de medidores, como medidores eléctricos, medidores de agua, de gas, etc.

En las redes de malla, los medidores están configurados para reenviar sus lecturas al proveedor de servicios públicos, ya sea de manera directa o a través de uno o más nodos intermedios. Dado que los medidores pueden estar ampliamente dispersos a través de una región, ellos a menudo requieren nodos intermedios para reenviar la información al proveedor de servicios.

Las empresas de servicios públicos, con el fin de facturar a sus clientes, deben determinar periódicamente el consumo del cliente, tomando lecturas de los medidores. Para facilitar este proceso y reducir los costos para las empresas de servicios públicos, los medidores de servicios en la presente divulgación pueden transmitir los datos de consumo de forma inalámbrica a través de una red, como una red de malla, de vuelta al proveedor de servicios públicos.

Además de transmitir la información de los medidores al proveedor de servicios públicos, de vez en cuando información puede ser transmitida desde el proveedor de servicios públicos a los medidores. Por ejemplo, cuando el proveedor de servicios determina que algunos o todos los medidores o nodos intermedios en la red de malla necesitan ser actualizados, los procesos de actualización de firmware, como se menciona en la presente descripción, pueden ser iniciados. Con la posibilidad de miles de medidores o nodos en una red de malla, es deseable minimizar la cantidad total de tráfico de comunicación a fin de permitir que el sistema funcione de manera eficiente. Además, dado que algunos medidores y/o nodos pueden ser alimentados de energía mediante baterías, minimizar el uso de los medidores y nodos puede ser deseado con el fin de prolongar la vida de las baterías. Reducir el tiempo de consumo de la batería para prolongar la duración de la batería puede, por tanto, reducir la cantidad de mantenimiento que se debe realizar en los dispositivos de medición.

Aunque la presente divulgación se relaciona con la creación de redes de malla, aquéllos que tienen conocimiento ordinario de la téenica, reconocerán que la presente divulgación se puede utilizar en otros tipos de entornos de red, tales como redes FHSS de punto a punto. Dentro de una red de malla, nodos “padre” e “hijo” pueden tener una relación predefinida basada en la jerarquía. En algunas modalidades, la red de malla no necesariamente puede tener una jerarquía firmemente establecida, pero puede permitir que los nodos identifiquen una ruta aceptable para hacia el servidor a través de cualquier número de nodos intermedios. Aunque la presente divulgación describe una relación de padre individual a múltiples hijos, debe entenderse que pueden existir múltiples padres dentro de la misma red. Además, un hijo puede tener múltiples padres. En diversas modalidades, un padre individual puede estar emparejado con un solo hijo. Como ejemplo, los nodos hijos pueden representar los medidores de servicios de los clientes individuales, mientras que un nodo padre puede representar un dispositivo principal de recogida de datos, responsable de la recogida de datos desde y del envío de datos a cada dispositivo hijo.

LA Figura 1 es un diagrama de bloques que muestra una modalidad de una red de malla AMI 10 en una configuración jerárquica. Aunque la red de malla AMI 10, típicamente puede distribuirse a través de una región geográfica, el diagrama de bloques de la figura 1 muestra una jerarquía para enfatizar las relaciones padre/hijo entre los diversos componentes. Como se ilustra, la red de malla AMI 10 incluye un proveedor de servicios públicos 12, un primer nivel de nodos intermedios 14, un segundo nivel de nodos intermedios 16, un nivel más bajo de nodos intermedios 18 y los nodos finales 20, que puede estar unida o de otra manera conectada en comunicación a medidores de servicios públicos. En algunas modalidades, los nodos intermedios pueden ser medidores en sí mismos o pueden estar integrados con o conectados a medidores. Además, los nodos finales 20 pueden además actuar como nodos intermedios para medidores adicionales. En algunas modalidades, los nodos intermedios se pueden configurar como dispositivos autónomos para ayudar en la transferencia de datos entre el proveedor de servicios públicos 12 y los nodos finales 20. La red de malla AMI 10 puede incluir cualquier número de niveles X de nodos intermedios entre el proveedor de servicios 12 y los nodos finales 20. Además, el número de niveles entre los nodos finales 20 y el proveedor de servicios 12 no es necesariamente la misma para cada medidor 20. Además, algunos de los nodos intermedios 14, 16, 18 pueden también estar configurados como nodos finales, y pueden ser capaces tanto de medir los datos de servicios públicos, como de comunicarse con los nodos intermedios de nivel inferior y/o medidores.

El proveedor de servicios públicos 12, actuando como padre, se comunica directamente con los nodos intermedios 1.1, 1.2, 1.3, ...1.a del primer nivel de nodos intermedios 14, que pueden definirse como nodos hijos con respecto al proveedor de servicios públicos 12, que se puede definir como un nodo padre. Cualquier número “a” de nodos intermedios 14 puede ser configurado en el primer nivel. Cada uno de los nodos intermedios 14 en el primer nivel, puede ser configurado como un padre para uno o más nodos intermedios 16 en el segundo nivel y comunicarse directamente con estos nodos intermedios 16. Los nodos intermedios 14 pueden tener cualquier número “b” de nodos hijos 16. En este ejemplo, el nodo intermedio 1.2 del primer nivel de nodos 14 tiene los nodos hijos 2.1, 2.2, 2.3,... 2.b en el segundo nivel de nodos intermedios 16. Esta disposición continúa por la jerarquía al nivel más bajo de nodos intermedios 18, que pueden incluir cualquier número “y" de los nodos intermedios. El nodo X.2 se ilustra con un número “z” de nodos finales 20, que se configuran como hijos del nodo intermedio X.2. Además, cada nodo hijo puede tener múltiples nodos padre; por ejemplo, el nodo 2.2 puede tener como sus nodos padre 1.1, 1.2, y 1.3. La numeración que se muestra en las distintas cajas de los nodos y medidores es meramente con fines ilustrativos para expresar números arbitrarios o varios de los niveles de nodos intermedios y números arbitrarios o varios de los nodos hijos/medidores de cada nodo intermedio.

El proveedor de servicios públicos 12, los nodos intermedios 14, 16, 18, y los nodos finales 20, de acuerdo con diversas implementaciones, pueden comprender circuitos y funcionalidad para permitir la comunicación de radiofrecuencia (RF) entre los diversos componentes. Las líneas discontinuas mostradas en la Figura 1 , por lo tanto, pueden representar los canales de comunicación de RF entre los diferentes componentes. La configuración de los componentes de la red de malla AMI 10 que se muestra en la Figura 1 es meramente una modalidad, y pueden ser utilizados dispositivos adicionales o configuraciones alternativas. La comunicación inalámbrica entre los dispositivos 12, 14, 16, 18 y 20 puede estar activas durante algunos períodos de tiempo y puede estar inactiva durante otros períodos de tiempo. De manera alternativa, cualquiera de los nodos puede conectarse entre sí a través de conexiones cableadas.

El proveedor de servicios públicos 12, o un servidor asociado con el proveedor de servicios públicos 12, pueden estar configurados para gestionar las relaciones entre los diversos nodos intermedios y medidores. En algunos casos, las relaciones padre/hijo pueden cambiar según sea necesario para distribuir más uniformemente los nodos hijos entre los padres. El proveedor de servicios públicos 12 puede mantener una tabla de nodos hijos de cada nodo intermedio y aquellos medidores asociados con los nodos intermedios de nivel más bajo 18 en una relación de hijos. En algunas modalidades, los nodos intermedios en sí mismos, pueden configurar de forma automática y/o re-configurar sus propias relaciones padre/hijo entre sí.

LA Figura 2 es un diagrama de bloques que muestra una modalidad de una porción de otra red de malla AMI 30 en una configuración jerárquica. En esta modalidad, la red de malla AMI 30 incluye un proveedor de servicios públicos 32, un primer nodo intermedio 34, un segundo nodo intermedio 36, un tercer nodo intermedio 38, un primer medidor 40, un segundo medidor 42, un tercer medidor 44, y una cuarto medidor 46. Así, como se ilustra en este ejemplo, el tercer nodo intermedio 38 está en un nivel más bajo de los nodos intermedios y se comunica directamente con los cuatro medidores diferentes 40, 42, 44, y 46. A veces, las actualizaciones de firmware se remiten a los nodos intermedios y los medidores para actualizar los nodos y los medidores, según sea necesario, en la red de malla AMI 30. En lugar de enviar a los empleados a la gran cantidad de nodos y medidores para instalar las actualizaciones de firmware, las actualizaciones de firmware se pueden comunicar electrónicamente a través de la red de malla AMI 30 de arriba hacia abajo.

Antes de que las actualizaciones de firmware se distribuyen a los nodos y los medidores, el mensaje de actualización se divide en paquetes de datos, o bloques. Por ejemplo, la actualización del firmware puede ser de aproximadamente 128 kilobytes de tamaño y cada paquete de datos puede ser de unos 100 bytes. Por lo tanto, la actualización del firmware puede dividirse en unos 1,280 paquetes de datos. En aplicaciones diferentes que distribuir actualizaciones de firmware, las redes de malla AMI 10, 30 pueden ser configuradas en una red de conjunto de sensores en la que los sensores capturan ciertos tipos de lecturas, como el flujo de agua, para crear archivos de firma acústica, que pueden ser de unos 10 kilobytes en tamaño. Estos archivos de firma acústica pueden ser divididos en paquetes de datos y se distribuyen a través de la red de malla como se ha mencionado en el presente documento.

Según una primera modalidad para la distribución de actualizaciones de firmware a los medidores (u otros tipos de datos o la distribución de archivos a través de una red de malla), la totalidad de la actualización del firmware se comunica un medidor antes de ser enviada al siguiente medidor. Este proceso se repite de forma individual para cada medidor hasta que se actualicen todos los medidores programados para la actualización. En esta primera modalidad, el proceso para actualizar el primer medidor 40 se describirá. Se debe entender que la actualización de los otros medidores implicará prácticamente los mismos pasos. En primer lugar, un primer paquete de datos de la actualización del firmware se transmite desde el proveedor de servicios públicos 32 al primer nodo intermedio 34. El primer nodo intermedio 34, a continuación transmite el primer paquete de datos al segundo nodo intermedio 36, y el segundo nodo intermedio 36 transmite el primer paquete de datos al tercer nodo intermedio 38, que es el nodo intermedio de nivel más bajo en este ejemplo. El tercer nodo intermedio 38 transmite entonces el primer paquete de datos al primer medidor 40. El primer medidor 40 almacena el primer paquete de datos y luego envía de regreso una señal de reconocimiento siguiendo la jerarquía para indicar que se recibió el paquete de datos. Esta señal de acuse de recibo se transmite al proveedor de utilidad 32 a través del tercer nodo intermedio 38, el segundo nodo intermedio 36, y el primer nodo intermedio 34. Este proceso se repite para los paquetes de datos restantes. Suponiendo que hay 1,000 paquetes de datos en una actualización de firmware, el proceso anterior se repite 1 ,000 veces. Esto significa que para cada uno de los medidores 40, 42, 44, y 46, habrá 2,000 transmisiones (es decir, 1.000 transmisiones de paquetes de datos y 1 ,000 transmisiones de señales de reconocimiento de recibo) entre el proveedor de servicios públicos 32 y el primer nodo intermedio 34. También, 2,000 transmisiones se realizarán entre el primer nodo intermedio 34 y segundo nodo intermedio 36; 2,000 entre los nodos intermedios 36 y 38; y 2,000 entre el tercer nodo intermedio 38 y el medidor respectivo. Repetidas para los cuatro medidores 40, 42, 44, y 46, habrán 8,000 transmisiones entre el proveedor de servicios 32 y el primer nodo intermedio 34; 8,000 entre el primer nodo intermedio 34 y el segundo nodo intermedio 36; 8,000 entre el segundo nodo intermedio 36 y el tercer nodo intermedio 38; y 8,000 entre el tercer nodo intermedio 38 y los medidores 40, 42, 44, y 46. Esto suma 32,000 transmisiones.

En una modalidad preferida, las actualizaciones de firmware se distribuyen de una manera en la que los nodos intermedios (es decir, el primer nodo intermedio 34, el segundo nodo intermedio 36, y el tercer nodo intermedio 38, en este ejemplo) son capaces de almacenar los paquetes de datos provenientes de su padre, hasta que se reciban todos los paquetes de datos, y luego enviar los paquetes de datos a su hijo o hijos. De acuerdo con esta modalidad, un primer paquete de datos se transmite desde el proveedor de servicios públicos 32 al primer nodo intermedio 34. El primer nodo intermedio 34 almacena el primer paquete de datos y luego envía una señal de reconocimiento de recibo de regreso al proveedor de servicios públicos 32 que indica que * el paquete de datos fue recibido. Entonces, el proceso se repite para los paquetes de datos restantes hasta que todos los paquetes de datos se han transmitido desde el proveedor de servicios públicos 32 al primer nodo intermedio 34 y el primer nodo intermedio 34 ha almacenado todos los paquetes de datos que componen la totalidad de la actualización del firmware.

Una vez que el primer nodo intermedio 34 recibe y almacena la totalidad de la actualización del firmware, el primer nodo intermedio 34 transmite el primer paquete de datos a su niño (es decir, el segundo nodo intermedio 36). El segundo nodo intermedio 36 almacena el primer paquete de datos internamente y envía una señal de reconocimiento de regreso al primer nodo intermedio 34 para indicar que se recibió el primer paquete de datos. Entonces, el primer nodo intermedio 34 repite la transmisión de los paquetes de datos restantes de la actualización del firmware hasta que se hayan recibido y almacenado, por el segundo nodo intermedio 36, todos los paquetes de datos.

Este proceso se repite entre cualesquiera otros nodos intermedios, que, en este ejemplo, incluyen el vínculo entre el segundo nodo intermedio 36 y el tercer nodo intermedio 38, hasta que la actualización del firmware se ha distribuido al nodo intermedio de nivel más bajo (por ejemplo, el tercer nodo intermedio 38, en este ejemplo). Desde este punto, el tercer nodo intermedio 38 transmite los paquetes de datos al primer medidor 40, de uno en uno y recibe señales de reconocimiento de recibo, y luego procede con la transmisión al segundo medidor 42, al tercer medidor 44, y luego el cuarto medidor 46. Durante la transferencia de paquetes de datos, el proveedor de servicios públicos 32 puede registrar una indicación de estado para cada uno de los nodos intermedios. Por ejemplo, mientras que el proveedor de servicios públicos 32 está transfiriendo paquetes de datos al primer nodo intermedio 34, el proveedor de sen/icios públicos puede registrar el estado de este nodo como que éste está en el proceso de transmisión o “activo”. Cuando la actualización del firmware se ha transferido con éxito de un nodo intermedio a un siguiente nodo intermedio, una señal puede ser enviada, recorriendo la jerarquía, al proveedor de servicios públicos 32 para indicar que el nodo intermedio ha transmitido con éxito los datos. En este punto, el proveedor de servicios públicos 32 puede registrar el estado de este nodo como que completó la transferencia. Señales similares se pueden enviar, ascendiendo la jerarquía, al proveedor de servicios públicos 32 para indicar otra información del estado de los nodos y medidores.

En esta modalidad, para la distribución de la actualización del firmware, el número de transmisiones se reduce considerablemente en comparación con la otra modalidad. Particularmente, el número de transmisión entre el proveedor de servicios públicos 32 y el primer nodo intermedio 34 se reduce a 2000, utilizando los supuestos anteriores. El número de transmisión entre el primer nodo intermedio 34 y segundo nodo intermedio 36 se reduce a 2,000; y el número de transmisión entre el segundo nodo intermedio 36 y tercer nodo intermedio 38 se reduce a 2,000. El número de transmisiones entre el tercer nodo intermedio 38 y los medidores 40, 42, 44, y 46 permanece en 8,000. Sin embargo, el número total de transmisiones en esta modalidad es 14,000, que es un reducción drástica de las 32,000 transmisiones necesarias en el ejemplo previo. Por lo tanto, al permitir que los nodos intermedios almacenen las actualizaciones de firmware, el número de transmisiones se puede reducir significativamente, reduciendo así la cantidad de energía necesaria por cada uno de los nodos y también reduciendo la cantidad de tiempo necesario para transferir cada actualización del firmware.

Cuando las actualizaciones de firmware se proporcionan en cinco nodos intermedios, por ejemplo, hay una gran diferencia en la cantidad de tiempo en que las actualizaciones de firmware se pueden implementar utilizando diferentes métodos. En el primer método en el que los paquetes de datos saltan de un nodo al siguiente, desde el proveedor de servicios al medidor, la actualización de una red de malla grande puede llevar aproximadamente 10 horas. Sin embargo, de acuerdo con el método en el que todos los paquetes de datos se transmiten desde un nodo intermedio a otro, y luego todos los paquetes de datos se transmiten desde ese nodo intermedio a uno siguiente, y así sucesivamente, a través de los cinco nodos intermedios a los medidores, el proceso de actualización puede tardar unos 20 minutos. Por lo tanto, de acuerdo con estas estimaciones, el segundo método preferido proporciona una mejora del 96% en el tiempo de actualización sobre el primer método. Esto permitirá más tiempo para otras comunicaciones, tales como la presentación normal de informes de mediciones de los medidores al proveedor de servicios públicos para mantener los datos de facturación. Además, debido a que el número total de transmisiones se reduce, la probabilidad de transmisiones fallidas (que requieren retransmisión) también se reduce, aumentando así la eficiencia global y la reducción de tiempo de transmisión.

Es posible que haya al menos dos tipos diferentes de escenarios de implementación de actualización de firmware. Un primer tipo de implementación es para redes de malla heterogeneas que pueden tener una combinación de nodos alimentados de energía a través de la línea y los que se alimentan con batería. Este también puede denominarse como una red mezclada o una red híbrida que comprende, por ejemplo, medidores eléctricos y del agua. Un segundo tipo de implementación es para redes de malla homogéneas, como las que tienen sólo un tipo de nodo, ya sea alimentado de energía por la línea o con baterías.

Cabe señalar en la Figura 2 que la transmisión de los datos puede ocurrir en dos direcciones diferentes, desde arriba hacia abajo (por ejemplo, actualizaciones de firmware) y desde abajo hacia arriba (por ejemplo, datos del sensor). En un proceso de actualización de firmware, el proveedor de servicios públicos 32 proporciona paquetes de datos, de uno en uno, al primer nodo intermedio 34, como se representa por la flecha D1. La señal de reconocimiento es enviada en la dirección de la flecha U1. Del mismo modo, la transmisión de paquetes de datos desde el primer nodo intermedio N1 al segundo nodo intermedio N2 es en la dirección D2, y las señales de reconocimiento de recibo se transmiten en la dirección U2. Entre el segundo nodo intermedio N2 y el tercer nodo intermedio N3, hay transmisiones descendentes D3 y transmisiones ascendentes U3. Entre el tercer nodo intermedio y los medidores 40, 42, 44, y 46 (asumiendo que hay tres nodos intermedios entre el proveedor de servicios públicos 32 y los medidores), hay transmisiones hacia abajo D4 y transmisiones hacia arriba U4.

Para las actualizaciones de firmware, las transmisiones ascendentes representan señales de reconocimiento. Sin embargo, para las lecturas de servicios públicos regulares, las transmisiones hacia arriba U4, U3, U2, y U1 incluyen el proceso de reenvío de los datos de medición de los medidores 40, 42, 44, y 46 ascendiendo la jerarquía de la red de malla hasta el proveedor de servicios públicos 32. Las actualizaciones de firmware pueden incluir "momentos de silencio” durante los cuales no hay transmisiones entre los componentes de la red de malla 30. A pesar de que la distribución de actualizaciones de firmware puede incluir momentos de tranquilidad, esto no debería impedir o interrumpir las transmisiones relacionadas con descargas diarias normales de mediciones de servicios públicos. En cambio, la comunicación de actualización del firmware puede interrumpirse o pausarse para permitir la comunicación de mediciones de servicios públicos. En algunas modalidades, los momentos de silencio pueden ser mezclados con momentos de silencio de las descargas normales para permitir la comunicación simultánea de mediciones de servicios y actualizaciones de firmware.

La Figura 3 es un diagrama que muestra una modalidad de un sistema 50 para iniciar una liberación de una actualización de firmware o, de otra manera, transferir grandes cantidades de datos. El sistema 50 según esta modalidad incluye una red 52, un servidor 54, un usuario 56, y un cubo 58. El cubo 58 está en comunicación inalámbrica con una pluralidad de nodos 60. El servidor 54 puede representar un servidor de computadora que está asociado con un proveedor de servicios públicos, tal como el proveedor de servicios públicos 12 mostrado en la Figura 1 o el proveedor de servicios públicos 32 que se muestra en la Figura 2. El cubo 58 también puede estar asociado con o representar el proveedor de servicios públicos y puede representar un padre de nivel superior de la jerarquía de la red de malla. El cubo 58, por tanto, puede estar configurado para distribuir actualizaciones de firmware a un primer nivel de nodos intermedios 60 para su posterior distribución a otros nodos intermedios, en última instancia, hasta el nivel del medidor.

De acuerdo con la implementación de la Figura 3, el usuario 56 pueden representar a un empleado o contratista del proveedor de servicios públicos. Por ejemplo, el usuario 56 puede ser responsable del desarrollo y/o la distribución de actualizaciones de firmware. El servidor 54 puede estar configurado para almacenar los registros de los servicios de los clientes de servicios públicos y también se puede configurar para almacenar firmware diseñado para los diversos medidores a lo largo de una red de malla. Cuando se necesita una actualización de firmware y el usuario 56 inicia la distribución de la actualización, el servidor 54 envía el mensaje de actualización adecuado a través de la red 52 al cubo 58. El cubo 58 puede entonces distribuir la actualización a los diferentes nodos intermedios según sea necesario. La actualización, a continuación, pasa a través de los diversos nodos intermedios como se ha descrito anteriormente con respecto a las Figuras 1 y 2 hasta que las actualizaciones adecuadas se distribuyen a los medidores programados para recibir las actualizaciones.

LA Figura 4 es un diagrama de bloques que ilustra una modalidad de un nodo intermedio 70, que puede representar cualesquiera o más de los nodos intermedios mostrados en las Figuras 1 y 2. En esta implementación, el nodo intermedio 70 comprende un accionador de RF 72, una pila de protocolos de red 74, un administrador de descargas 76, administrador de la actualización del firmware 78, y un sistema de archivos 80. El accionador de RF 72 es responsable de transmitir y de recibir datos de RF al padre e hijo (o hijos) del respectivo nodo intermedio 70. El accionador RF 72 obtiene datos de la pila de protocolos de red 74 y se encarga de la codificación de la capa física, comprobando la integridad y la administración de canales de RF.

La pila de protocolos de red 74 está configurada para admitir enlace, malla, y otras capas de una pila de protocolos. La pila de protocolos de red 74 puede apoyar diversos procesamientos de mensajes, el enrutamiento y la administración de enlace/conexión de RF. La pila de protocolos de red 74 y el accionador de RF 72, intercambian datos según sea necesario.

El administrador de descargas 76 puede ser el responsable de tramitar las solicitudes de la red para iniciar y/o administrar el envío de una imagen de firmware (mensaje). Más en general, cualquier archivo, no sólo archivos de imagen de firmware, puede ser empujado a traves de la red de esta manera. El gestor de descargas 76 divide el archivo en bloques más pequeños de datos o paquetes de datos, que se pueden transmitir a través de la red de malla a través de la pila de protocolos de red 74. El administrador de descarga 76 puede estar configurado para utilizar una lista pre configurada de nodos o un lista proporcionada en la propia solicitud para determinar los nodos hijo para los que ios archivos están programados para ser reenviados. El administrador de descargas 76 también puede ser responsable de enviar información de estado sobre el proceso de descarga de regreso al proveedor de servicios públicos, el cubo 58, u otro servidor. La información de estado puede estar disponible para el usuario 56 para el seguimiento de cómo la actualización del firmware u otro proceso de distribución de archivos está progresando.

El administrador de la actualización del firmware 78 puede ser responsable de la quema (es decir, transferir) del archivo recibido de imagen de firmware (actualización de firmware) a la memoria del programa local dentro del respectivo nodo intermedio 70. El proceso de la quema puede incluir el almacenamiento de archivos electrónicos en la memoria (por ejemplo, ROM, PROM, EPROM, EEPROM, etc.) o la configuración de interruptores de procesador dentro de un dispositivo de procesamiento o de control del nodo. El administrador de actualización del firmware 78 también puede iniciar la transmisión de un mensaje de “quema completada”, como una señal de reconocimiento, a través de la jerarquía para el proveedor de servicios públicos o del servidor. Este mensaje informa al usuario 56 que el respectivo nodo intermedio 70 se ha actualizado correctamente y puede estar preparado para enviar el archivo a sus respectivos hijos. El mensaje también puede incluir el nombre del archivo de imagen de firmware o el mensaje que se ha instalado, con el fin de verificar que el archivo correcto se almacena en el nodo correcto.

El sistema de archivos 80 del nodo intermedio 70 está configurado para almacenar archivos de datos (por ejemplo, paquetes de datos de actualizaciones de firmware) en la memoria no volátil (por ejemplo, DFLASH). La memoria puede ser lo suficientemente grande para almacenar sólo una actualización del firmware en un momento. En uno de los ejemplos anteriores, el tamaño de un archivo de actualización de firmware puede ser de aproximadamente 128 kilobytes; por lo tanto, la sistema de archivo 80 puede configurarse para almacenar un archivo de aproximadamente este el tamaño o levemente más grande. Después de que el archivo de actualización del firmware se ha pasado al siguiente nodo, el archivo almacenado en la memoria del sistema de archivos 80 puede no necesitarse y puede ser eliminado. Como alternativa, el archivo almacenado en la memoria del sistema de archivos 80 puede pasarse a otro nodo para actualizar el firmware de ese nodo. De lo contrario, el archivo se puede sobrescribir cuando una nueva actualización de firmware se transmite a través del nodo intermedio respectivo. Archivos pueden ser creados, leídos, escritos y borrados en el sistema de archivos 80.

En algunas modalidades, cada nodo intermedio 70 también puede estar configurado con un dispositivo de monitorización del voltaje que está configurado para supervisar el nivel de voltaje de una fuente de alimentación de energía para proporcionar alimentación al nodo respectivo. El nodo puede recibir energía de un conjunto de baterías y/o de las líneas de energía eléctrica. Si el nivel de voltaje se determina que es por debajo de un nivel de umbral predeterminado, el nodo intermedio 70 puede hacer una pausa en el proceso de reenvío mediante el accionador de RF 72 hasta que el nivel de voltaje vuelve a estar encima del nivel de umbral predeterminado.

Las Figuras 5-11 son capturas de pantalla que ilustran diversas modalidades de interfaces de usuario, que pueden ser accesibles por o asociadas con el usuario 56 se muestra en la Figura 3. Las interfaces de usuario pueden ser utilizados para permitir al usuario 56 iniciar y controlar el estado de las distribuciones de actualización de firmware. Las interfaces de usuario pueden permitir al usuario 56 ver la secuencia de pasos necesarios para una actualización de firmware y ver el estado de algunos o todos los nodos. Cabe señalar que sólo a un usuario 56 que tiene la autoridad apropiada (por ejemplo, un administrador de la empresa de sen/icios públicos) se le concede el derecho para iniciar y controlar una actualización de firmware en la red de malla.

La Figura 5 ilustra una modalidad de una interfaz de usuario 90 que muestra un mapa de una región geográfica donde los clientes pueden recibir servicios desde el proveedor de servicios públicos. Mediante el control de la pantalla del mapa, el usuario puede realizar varias funciones como el enfocar, el alejarse del enfoque, y el panorama alrededor para ver distintas zonas de la región efectiva del servicio. Como se muestra en la Figura 5, la vista de la interfaz del usuario 90 puede mostrar calles y nombres de calles. También, la interfaz del usuario 90 puede mostrar la ubicación de medidores y nodos dentro del sistema. Cuando se muestra un área deseada, el usuario puede manipular la interfaz de usuario 90 de tal manera para seleccionar una porción de los medidores y/o nodos en la pantalla de visualización. Por ejemplo, un óvalo 92 puede ser arrastrado utilizando una herramienta de arrastre (por ejemplo, ratón) en cierta forma para seleccionar los cuatro medidores que se muestran dentro del óvalo 92. Otros medidores pueden ser seleccionados para su inclusión en el grupo de nodos que está programado para recibir una actualización de firmware.

Los medidores y los nodos pueden ser designados utilizando cualquier tipo de criterios de indicación. Por ejemplo, los medidores y/o nodos pueden ser mostrados como círculos, cuadrados, u otras formas. También, diversas formas pueden designar diversos tipos de nodos o medidores. Las formas también pueden estar ilustradas utilizando diferentes colores para representar el estado particular del medidor o del nodo. Por ejemplo, un color (por ejemplo, amarillo) puede representar que dos componentes están en el proceso de transmisión de datos entre ellos. Otro color (por ejemplo, rojo) puede representar componentes que están en espera de una transmisión. Durante los procesos de reenvío que se describen en la presente descripción, los diferentes nodos pueden enviar actualizaciones de estado a través de la jerarquía al servidor (por ejemplo, el proveedor de servicios públicos). Las actualizaciones de estado, por ejemplo, pueden indicar qué nodos están actualmente involucrados en las comunicaciones de datos, qué nodos han completado con éxito las comunicaciones de datos, y qué nodos han experimentado errores de transferencia de datos. Como la secuencia de la transmisión se controla mediante actualizaciones de estado de los diversos nodos, la interfaz de usuario 90 puede estar configurada para actualizar la pantalla para mostrar un nuevo estado de los componentes. El las actualizaciones de estado se pueden realizar sobre una base periódica.

La Figura 6 es una segunda toma de pantalla que muestra la interfaz de usuario 90. Como se muestran, dos medidores 94 originalmente dentro del área seleccionada (por ejemplo, ovalo 92) se puede mostrar de una manera (por ejemplo, de color rojo) y otros dos medidores 96 en esta área pueden ser mostrados de otra manera (por ejemplo, de color amarillo). En este caso, los medidores 94 pueden estar esperando pare la transmisión, mientras que los medidores 96 están en el proceso de transmisión de datos entre los dos de ellos.

Después de una cierta cantidad de tiempo, la interfaz de usuario 90 se actualiza para mostrar la vista ilustrada en la Figura 7. En esta vista, despues de que los medidores 96 han completado su transmisión, los medidores 96 son a continuación mostrados con un nuevo estado (por ejemplo, de color verde) para indicar que la transmisión se ha finalizado. Los medidores 94 se puede mostrar en este momento en un estado para indicar que la transmisión se está produciendo entre ellos (por ejemplo, de color amarillo). Finalmente, en la Figura 8, la interfaz de usuario 90 muestra los medidores seleccionados originalmente 94 y 96 en un estado completado (por ejemplo, verde) para indicar que la transmisión se ha completado.

Por ejemplo, cuando la transmisión incluye la distribución de actualizaciones de firmware, el estado de los medidores puede verse. Cuando los medidores han recibido los archivos de firmware, su posterior procesamiento (por ejemplo, la quema en la memoria) puede ocurrir si es necesario. La interfaz de usuario 90 también puede ser configurada para indicar (por ejemplo, utilizando un color diferente) cuando una transmisión se ha intentado, pero fallado. Otro estado puede indicar que un medidor ha recibido la actualización del firmware y ha sido instruido para quemar la actualización a la memoria y aún otro estado puede indicar cuando el medidor ha quemado de hecho (es decir, transferido) la actualización en la memoria.

La Figura 9 es otra toma de pantalla que ilustra una modalidad de otra interfaz de usuario 100. La interfaz de usuario 100 puede ser mostrada al usuario 56 para proporcionar un menú de opciones que el usuario puede seleccionar 56 para iniciar la secuencia de actualización de firmware. Antes de que se muestre la interfaz de usuario 100, se puede dar una opción al usuario 56 para realizar una actualización de firmware por cualquier símbolo software adecuado, opción de menú, etc. Los medidores seleccionados (por ejemplo, los medidores seleccionados por los procesos descritos con respecto a la Figura 5) se pueden mostrar en la casilla 102 con un número de identificación y una dirección. La casilla 102 también puede mostrar el tipo de medidores, velocidad de transmisión de la instalación, y otros parámetros de los medidores seleccionados. Al seleccionar un medidor de la casilla 102 y haciendo clic en el botón Agregar 104, el usuario 56 puede seleccionar uno o más medidores, lo que la interfaz de usuario 100 puede mostrar en la casilla 106. La interfaz de usuario 100 también puede incluir una casilla de 108 Lista de Archivos, a partir de la cual un archivo de distribución se puede seleccionar. El archivo seleccionado puede ser el archivo (por ejemplo, la actualización del firmware) que debe ser distribuido a los medidores seleccionados en la casilla 106. La interfaz de usuario 100 también incluye botones de opción en cuanto a opciones de quema. Por ejemplo, un primer botón de radio 110 se puede seleccionar si se desea que el archivo se querne inmediatamente en la memoria del nodo/medidor seleccionado y un segundo botón de radio 112 puede seleccionarse si se desea que el archivo se queme en la memoria en un momento posterior. Por ejemplo, el segundo botón de radio 112 (es decir, el botón Grabar más Tarde) puede ser el predeterminado. Un mensaje puede ser enviado al nodo/medidor seleccionado para indicar si el archivo se va a grabar en la memoria ahora o más tarde. El mensaje, por ejemplo, puede ser procesado por el administrador de descargas 76 o administrador de actualización de firmware 78 ya sea para esperar para quemar en un momento posterior (hasta nuevo aviso) o para seguir adelante e iniciar un proceso de quema (grabación).

La interfaz de usuario 100 puede estar configurada para permitir al usuario ordenar los medidores que aparecen en cualquiera de la casilla 102 o la casilla 106 mediante el uso de la columna‘Tipo”. Por ejemplo, varios tipos pueden incluir DCom2, DCom3, UGM, Fax, polifásico, Singleboard, boca de riego (hidrante), y el puente. Estos tipos pueden representar diferentes tipos de medidores o nodos e incluso la ubicación de los distintos nodos situados en diferentes puntos de referencia. Las casillas 102 y 106 también pueden incluir una columna para indicar si un metro o nodo se usa con medidores eléctricos, los medidores de agua, medidores de gas, u otros tipos de medidores. Otra columna se puede incluir para indicar el número de nodos intermedios (es decir, número de saltos) entre un medidor y el proveedor de servicios públicos. En algunas modalidades, otra columna puede ser incluida para definir la ruta completa desde el proveedor de servicios públicos (por ejemplo, colector) al respectivo medidor, identificando cada uno de los nodos intermedios entre el colector y el medidor. En algunas modalidades, una columna puede ser proporcionada para identificar únicamente el nodo padre del medidor respectivo. Columnas adicionales pueden ser agregadas como se entiende por un experto en la téenica.

En algunas modalidades, ciertos tipos de nodos no pueden permitir que ciertas actualizaciones de firmware sean almacenadas o reenviadas. Por ejemplo, si un nodo (por ejemplo, uno polifásico o unidad DCom2) no tiene la capacidad de almacenar una actualización de firmware transmitida, la interfaz de usuario 100 puede ser configurada para indicar un error cuando el usuario selecciona un medidor que podría depender de tal nodo intermedio para recibir la actualización.

Además, la interfaz de usuario 100 puede ser configurada para comprobar si se está seleccionando una actualización de firmware para su transmisión a un medidor de un tipo incorrecto. Por ejemplo, un medidor de electricidad se puede seleccionar incorrectamente para una actualización que sólo podría ser diseñada para medidores de agua. Si este es el caso, se mostrará un mensaje de error y el sistema no intentará enviar el archivo a este medidor.

La Figura 10 es una toma de pantalla que ilustra una modalidad de un menú 120 de una interfaz de usuario de acuerdo con diversas impiementaciones. Con este menú 1 0, el usuario 56 puede ser capaz de filtrar por tipo, tales como Singleboard, Hidrantes, etc. Esto permite al usuario 56 seleccionar fácilmente sólo las unidades de interés que desea visualizar. Si el usuario 56 selecciona el botón “quemar (grabar) más adelante”, otro cuadro de diálogo puede aparecer al iniciar cuando el archivo se va a ser grabado y puede mostrar las unidades en espera de la autorización para iniciar la grabación. Las actualizaciones también pueden ser quemadas en la memoria cuando el usuario hace clic en el medidor particular, en una de las listas de visualización y selecciona las opciones de quema.

La Figura 11 es una toma de pantalla que ilustra una modalidad de otra interfaz de usuario 130. La interfaz de usuario 130 en esta modalidad se puede utilizar para permitir diversas funciones de control para el sistema. Por ejemplo, el usuario 56 puede ser capaz de establecer la tasa de tiempo de espera cuando la vista principal está mostrando la actualización del firmware que está siendo distribuida. Cuando el sistema está en un modo donde se muestra el estado de las actualizaciones de firmware, una‘Tasa de Tiempo de Almacenaje y Sondeo” 132 puede ser usada para establecer la cantidad de tiempo entre el sondeo de los medidores para determinar los cambios en el estado. En este ejemplo, este parámetro se fija en 5 minutos.

Hay que señalar que el lenguaje condicional, tal como, entre otros, “puede”, “podría”, a menos que se especifique lo contrario, o de otra manera entenderse dentro del contexto como se usa, está destinado para expresar que ciertas modalidades incluyen, mientras que otras modalidades no incluyen, ciertas características, elementos y/o pasos. Por lo tanto, este tipo de lenguaje condicional no está destinado, en general, para implicar que las características, elementos y/o pasos son en modo alguno necesarios para una o más modalidades particulares, o que una o más modalidades particulares necesariamente incluyen la lógica para decidir, con o sin entrada de usuario o indicación, si estas características, elementos y/o pasos se incluyen o se han de realizar en cualquier modalidad particular.

Cabe destacar que las modalidades descritas anteriormente son meramente ejemplos posibles de implementaciones, expuestas simplemente para una clara comprensión de los principios de la presente divulgación. Cualesquier descripciones de procesos o bloques en los diagramas de flujo deben ser entendidas como que representa módulos, segmentos o porciones de código que incluyen una o más instrucciones ejecutables para la implementación de funciones lógicas específicas o etapas en el proceso, e implementaciones alternativas están incluidas en que las funciones pueden no estar incluidas o ejecutadas en absoluto, pueden ser ejecutados fuera del orden mostrado o discutido, incluyendo sustancialmente, al mismo tiempo o en orden inverso, dependiendo de la funcionalidad implicada, como sería entendido por los razonablemente expertos en la téenica de la presente divulgación. Muchas variaciones y modificaciones se pueden hacer a la(s) modalidad(es) descrita(s) anteriormente sin apartarse sustancialmente del espíritu y los principios de la presente divulgación. Además, el alcance de la presente divulgación se destina a cubrir cualquiera y todas las combinaciones y sub-combinaciones de todos los elementos, características y aspectos descritos anteriormente. Todas estas modificaciones y variaciones están destinadas a ser incluidas en el presente documento dentro del alcance de la presente divulgación, y todas las reivindicaciones posibles a los aspectos individuales o combinaciones de elementos o etapas están destinados a ser soportados por la presente divulgación.

Claims (25)

REIVINDICACIONES

1. Un método caracterizado porque comprende las etapas de: a) dividir una actualización del firmware en una pluralidad de paquetes de datos, la actualización del firmware se configura para ser distribuida desde un servidor asociado con un proveedor de servicios públicos a través de una pluralidad de nodos intermedios a una pluralidad de medidores, el servidor, los nodos intermedios, y estando los medidores configurados en una red de malla; b) transmitir un primer paquete de datos de la actualización del firmware desde el servidor a un primer nodo intermedio en la red de malla; * c) almacenar el primer paquete de datos en la memoria del primer nodo intermedio; d) transmitir una primera señal de reconocimiento de recibo desde el primer nodo intermedio de regreso al servidor; e) repetir las etapas b), c), y d) para los paquetes de datos restantes de la actualización del firmware, hasta que toda la actualización del firmware se almacena en la memoria del primer nodo intermedio; f) transmitir el primer paquete de datos desde el primer nodo intermedio a un segundo nodo intermedio; g) almacenar el primer paquete de datos en la memoria del segundo nodo intermedio; h) transmitir una segunda señal de reconocimiento de recibo desde el segundo nodo intermedio de regreso al primer nodo intermedio; i) repetir las etapas f), g), y h) para los paquetes de datos restantes de la actualización del firmware, hasta que toda la actualización del firmware se almacena en la memoria del segundo nodo intermedio; j) repetir las etapas f), g), h) e i) para los nodos intermedios restantes, hasta que toda la actualización del firmware se almacena en la memoria de un nodo intermedio de nivel más bajo; k) transmitir el primer paquete de datos desde el nodo intermedio de nivel más bajo a un primer medidor; l) almacenar el primer paquete de datos en la memoria del medidor; m) transmitir una tercera señal de reconocimiento de recibo desde el primer medidor de regreso al nodo intermedio de nivel más bajo; n) repetir las etapas k), I), y m) hasta que la totalidad de la actualización del firmware se almacena en la memoria del primer medidor; y o) repetir los pasos k), I), m), y n) para los medidores restantes configurados en una relación de hijo con el nodo intermedio de nivel más bajo en la red de malla.

2. El método de acuerdo con la reivindicación 1 , caracterizado además porque las etapas de transmisión incluyen la transmisión inalámbrica de señales de radiofrecuencia.

3. El método de acuerdo con la reivindicación 1 , caracterizado además porque comprende la etapa de la quema (grabación) de la actualización del firmware en la memoria de los medidores.

4. Un sistema que comprende: un proveedor de servicios públicos configurado para proporcionar servicios públicos a una pluralidad de clientes; una pluralidad de medidores, cada medidor se configura para medir los datos de consumo del servicio, de un cliente respectivo; y una pluralidad de nodos intermedios se configuran para transmitir los datos de consumo del servicio desde la pluralidad de medidores hasta el proveedor de servicios públicos; caracterizado porque, cuando al menos uno de la pluralidad de los medidores está programado para recibir una actualización de firmware, el proveedor de servicios públicos está configurado para reenviar la actualización de firmware a al menos uno de la pluralidad de nodos intermedios; y donde al menos uno de la pluralidad de nodos intermedios se configura para recibir y almacenar la actualización de firmware y, después de almacenar la actualización de firmware, se configura además para reenviar la actualización de firmware a al menos uno de la pluralidad de medidores.

5. El sistema de acuerdo con la reivindicación 4, caracterizado además porque, al menos uno de la pluralidad de nodos intermedios, está además configurado para reenviar la actualización de firmware a al menos uno de la pluralidad de nodos intermedios.

6. El sistema de acuerdo con la reivindicación 5, caracterizado además porque la pluralidad de nodos intermedios repite el reenvío de la actualización del firmware hasta que la actualización del firmware se reenvía a un nodo intermedio de nivel más bajo en una jerarquía que comprende el proveedor de servicios públicos, los nodos intermedios, y los medidores.

7. El sistema de acuerdo con la reivindicación 4, caracterizado además porque el proveedor de servicios públicos está además configurado para dividir la actualización de firmware en una pluralidad de paquetes de datos antes de reenviar la actualización de firmware a al menos uno de la pluralidad de nodos intermedios.

8. El sistema de acuerdo con la reivindicación 7, caracterizado además porque el proveedor de servicios públicos está configurado para reenviar un paquete de datos a la vez, a al menos uno de la pluralidad de nodos intermedios.

9. El sistema de acuerdo con la reivindicación 8, caracterizado además porque en respuesta a la recepción de un paquete de datos, al menos uno de la pluralidad de nodos intermedios transmite una señal de reconocimiento de recepción de regreso al proveedor de servicios públicos.

10. El sistema de acuerdo la reivindicación 8, caracterizado además porque al menos uno de la pluralidad de nodos intermedios está configurado para almacenar la actualización de firmware de un paquete de datos a la vez.

11. El sistema de acuerdo con la reivindicación 10, caracterizado además porque al menos uno de la pluralidad de nodos intermedios se configura para reenviar la actualización de firmware a al menos uno de la pluralidad de medidores, después de almacenar la totalidad de la actualización de firmware que comprende cada uno de los paquetes de datos.

12. El sistema de acuerdo con la reivindicación 7, caracterizado además porque cada paquete de datos comprende alrededor de 100 bytes de datos y la actualización del firmware comprende alrededor de 128 kilobytes de datos.

13. El sistema de acuerdo con la reivindicación 7, caracterizado además porque cada paquete de datos comprende alrededor de 100 bytes de datos y la actualización del firmware comprende alrededor de 256 kilobytes de datos.

14. El sistema de acuerdo con la reivindicación 4, caracterizado además porque cada nodo intermedio comprende una unidad accioriadora radio frecuencia (RF) configurada para comunicarse de forma inalámbrica con al menos uno de los proveedores de servicios públicos, al menos un otro nodo intermedio, y al menos un medidor.

15. El sistema de acuerdo con la reivindicación 14, caracterizado además porque cada nodo intermedio comprende además una pila de protocolos de red, un administrador de descargas, un administrador de actualización de firmware y un sistema de archivos.

16. El sistema de acuerdo con la reivindicación 4, caracterizado además porque el proveedor de servicios públicos comprende un servidor configurado para comunicarse con un cubo concentrador a traves de una red de comunicación, el cubo configurado para reenviar la actualización de firmware a al menos uno de la pluralidad de nodos intermedios.

17. El sistema de acuerdo con la reivindicación 16, caracterizado además porque comprende un dispositivo de usuario en comunicación con el servidor a través de la red de comunicación, el dispositivo de usuario se configura para iniciar un proceso de actualización del firmware.

18. El sistema de acuerdo con la reivindicación 17, caracterizado además porque el dispositivo de usuario comprende una interfaz de usuario que permite a un usuario seleccionar al menos uno de los medidores para recibir la actualización del firmware.

19. El sistema de acuerdo con la reivindicación 18, caracterizado además porque la interfaz del usuario muestra un estado del proceso de la actualización del firmware.

20. El sistema de acuerdo con la reivindicación 18, caracterizado además porque la interfaz del usuario permite al usuario seleccionar diversos parámetros del proceso de actualización del firmware.

21. El sistema de acuerdo con la reivindicación 4, caracterizado además porque cada nodo intermedio comprende un dispositivo de monitorización del voltaje, configurado para supervisar un nivel de voltaje de una fuente de alimentación que proporciona alimentación al nodo intermedio respectivo, y en donde, si el dispositivo de monitorización del voltaje determina que el nivel de voltaje está por debajo de un nivel de umbral predeterminado, el nodo intermedio detiene el proceso de reenvío hasta que el nivel de voltaje vuelve a estar por encima del nivel de umbral predeterminado.

22. Un método para almacenar y reenviar datos, caracterizado porque comprende: recibir a partir de un primer nodo, una pluralidad de paquetes de datos, que comprende un paquete de datos; almacenar cada uno de los paquetes de datos en una memoria; enviar un reconocimiento de recibo tras recibir cada paquete de datos, de la pluralidad de paquetes de datos; y en respuesta a la recepción de un paquete final de datos del paquete de datos, y el envío de un reconocimiento final de recibido, enviar a un segundo nodo la pluralidad de paquetes de datos almacenados en la memoria.

23. El método de acuerdo con la reivindicación 22, caracterizado además porque, recibir a partir del primer nodo la pluralidad de paquetes de datos, comprende recibir los paquetes de datos de uno en uno, y en donde enviar al segundo nodo la pluralidad de paquetes de datos comprende enviar los paquetes de datos de uno en uno.

24. El método de acuerdo con la reivindicación 22, caracterizado además porque el paquete de datos es una actualización del firmware.

25. Un sistema para almacenar y reenviar datos, caracterizado porque comprende: un dispositivo de procesamiento configurado para ejecutar instrucciones lógicas; y un dispositivo de memoria en comunicación con el dispositivo de procesamiento, el dispositivo de memoria configurado para almacenar un conjunto de instrucciones lógicas que permitan el dispositivo de procesamiento: recibir a partir de un primer nodo, una pluralidad de paquetes de datos, que comprende un paquete de datos; almacenar cada uno de la pluralidad de los paquete de datos; enviar un reconocimiento de recibo tras recibir cada uno de la pluralidad de paquetes de datos; y en respuesta a la recepción de un paquete final de datos de la pluralidad de paquetes de datos, y después del envío de un reconocimiento final de recibido, enviar a un segundo nodo la pluralidad de paquetes de datos almacenados en el medio de almacenamiento.