ES2543018T3 - Método de gestión de dispositivo, software mediador y plataforma, dispositivo y sistema de comunicaciones de máquina a máquina - Google Patents
Método de gestión de dispositivo, software mediador y plataforma, dispositivo y sistema de comunicaciones de máquina a máquina Download PDFInfo
- Publication number
- ES2543018T3 ES2543018T3 ES11777207.9T ES11777207T ES2543018T3 ES 2543018 T3 ES2543018 T3 ES 2543018T3 ES 11777207 T ES11777207 T ES 11777207T ES 2543018 T3 ES2543018 T3 ES 2543018T3
- Authority
- ES
- Spain
- Prior art keywords
- resource
- access
- demand
- order
- platform
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
Abstract
Un método de gestión de dispositivo, que comprende: la recepción (S21), por un software mediador, middleware, instalado en una plataforma de comunicaciones máquina a máquina, M2M, en una demanda de caso a un recurso enviada por una aplicación de comunicaciones M2M utilizando una interfaz de acceso a recursos, en donde la demanda de acceso a un recurso comprende: un identificador uniforme de recurso, URI, que se utiliza para indicar una posición de memorización de un recurso de datos de un objeto de gestión, MO, al que se realiza el acceso y el recurso de datos de objeto MO accedido se crea en la plataforma de comunicaciones M2M y corresponde a información de objeto MO en un dispositivo de comunicaciones M2M y el identificador URI es asignado al recurso de datos de objeto MO al que se tiene acceso; la conversión (S22), por el software mediador instalado en la plataforma de comunicaciones M2M, en función de un mapeado de correspondencia preestablecido entre la demanda de acceso del recurso de datos de objeto MO y una orden de gestión de dispositivo, DM, de la demanda de acceso a un recurso en una orden de gestión DM correspondiente así como la determinación (S22) en función del mapeado de correspondencia preestablecido entre el recurso de datos de objeto MO y la información de objeto MO, de la información de objeto MO correspondiente al recurso de datos de objeto MO al que se tiene acceso; y el envío (S23) por el software mediador instalado en la plataforma de comunicaciones M2M, de la orden de gestión DM a un dispositivo objetivo que corresponde al identificador URI con el fin de gestionar la información de objeto MO correspondiente al recurso de datos de objeto MO al que se tiene acceso, en donde el dispositivo objetivo es un dispositivo de comunicaciones M2M.
Description
15
25
35
45
55
65
E11777207
17-07-2015
DESCRIPCIÓN
Método de gestión de dispositivo, software mediador y plataforma, dispositivo y sistema de comunicaciones de máquina a máquina
CAMPO DE LA INVENCIÓN
La presente invención se refiere al campo de la comunicación y en particular, a un método de gestión de dispositivo, un software mediador middleware y una plataforma de comunicación máquina a máquina (Machine-to-Machine Communications, M2M), un dispositivo y un sistema.
ANTECEDENTES DE LA INVENCIÓN
M2M es una aplicación basada en la red y un servicio que utiliza la interacción máquina a máquina inteligente como la base. Insertando un módulo de comunicaciones cableada o inalámbrica y una lógica de procesamiento de aplicación en el interior de una máquina, se pone en práctica la comunicación de datos sin intervención humana, cumpliendo de este modo, los requisitos basados en la información de usuario para aspectos tales como la supervisión de máquinas, órdenes y planificación así como la medición y recogida de datos. La Figura 1 ilustra una arquitectura de sistema M2M típica. Varios terminales de M2M (tales como un sensor y un micro-controlador) están conectados directamente o a distancia utilizando una pasarela M2M a una plataforma de servicio M2M, de modo que varias aplicaciones de M2M (tales como lectura de contadores medidores de electricidad y tráfico inteligente) adquieran datos recogidos por los terminales M2M o realicen funciones de control y gestión a distancia sobre los terminales M2M utilizando las capacidades de servicio proporcionadas por las plataformas de servicio M2M.
La gestión de dispositivos a distancia es una función importante del sistema M2M. Actualmente, las tecnologías de gestión de dispositivos a distancia basadas en la red de área amplia incluyen principalmente la especificación de gestión de dispositivo (Device Management, DM) definida por la denominada Alianza Móvil Abierta (Open Mobile Alliance, OMA). Es capaz de poner en práctica una gestión a distancia de dispositivos M2M mediante la utilización de datos de objeto de gestión (Management Object, MO) en dispositivos M2M (incluyendo la pasarela M2M y el terminal M2M). Los sistemas DM existentes proporcionan funciones de plano de gestión auxiliar y son relativamente independientes de los procesos de aplicación de servicios diarios de usuarios de terminales. Después de encontrar un fallo del terminal, un usuario inicia un proceso DM (a modo de ejemplo, marcaciones del número de servicio del cliente). A continuación, el servicio al cliente
o administrador realiza una tarea DM controlando un servidor de gestión de dispositivo (DM Server, DMS). Sin embargo, cuando el número de dispositivos M2M es muy grande, y con frecuencia no están atendidos, las aplicaciones de M2M suelen necesitar supervisar de forma activa y detectar fallos y problemas de dispositivos M2M y realizar la actualización y mantenimiento correspondiente. Por lo tanto, la plataforma de M2M necesitar utilizar funciones DM tales como una capacidad de servicios públicos y abrir una interfaz de acceso uniforme a las aplicaciones M2M, con lo que se pone en práctica la gestión de dispositivo extremo a extremo y las aplicaciones de servicios pertinentes.
El documento D1 (US2009/191031) da a conocer una solución en la que el procesamiento de la operación de XDM para acceder a un documento XML en una base de datos u otro depósito de datos mediante la conversión de la demanda de XCAP de información en dicho depósito de datos, desde un cliente, a una demanda de base de datos, de modo que la demanda de base de datos pueda utilizarse para el servicio.
El documento D2 (US2009/204578) da a conocer una solución de gestión de dispositivo de OMA por intermedio de la que el servidor puede especificar qué atributos deben seleccionarse en el dispositivo móvil en un parámetro de un identificador URI objetivo de la orden de Obtención denominada Get y en qué formato deben reenviarse los datos de gestión de dispositivo como otro parámetro del URI de objetivo de la orden Get.
El documento D3 (US2009/144434) da a conocer un método para una negociación de capacidades del dispositivo por intermedio de un identificador URI para especificar la capacidad del dispositivo a negociarse y para supervisar el documento completo, algún segmento, un elemento específico o un valor de propiedad.
SUMARIO DE LA INVENCIÓN
La presente invención da a conocer un método de gestión de dispositivo, un software mediador y una plataforma de M2M, un dispositivo y un sistema, para conseguir la finalidad de que las aplicaciones de M2M accedan a capacidades DM de diferentes plataformas de comunicaciones M2M utilizando una interfaz de acceso a un recurso uniforme. Las soluciones concretas son como sigue:
Un método de gestión de dispositivo que incluye:
la recepción, por un software mediador instalado en una plataforma M2M, de una demanda de acceso a un recurso enviada por una aplicación de M2M utilizando una interfaz de acceso a un recurso, en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recurso URI que se utiliza para indicar una posición de memorización de un recurso de datos de objeto de gestión MO accedido y el recurso de datos de objeto MO accedido se crea en la
15
25
35
45
55
65
E11777207
17-07-2015
plataforma M2M y corresponde a la información de objeto MO en un dispositivo M2M y el identificador URI se asigna al recurso de datos de MO accedido;
haciendo referencia al mapeado preestablecido entre la demanda de acceso a un recurso del recurso de datos de objeto MO y una orden DM de gestión de dispositivos, la conversión por el software mediador instalado en la plataforma M2M, de la demanda de acceso a un recurso en una orden DM correspondiente y la determinación, en conformidad con la relación de mapeado de correspondencia preestablecida entre el recurso de datos de objeto MO y la información de MO, estando la información de MO en correspondencia con el recurso de datos de MO accedido; y
el envío por el software mediador instalado en la plataforma M2M, de la orden DM a un dispositivo objetivo correspondiente al identificador URI para gestionar la información de MO correspondiente al recurso de datos de MO accedido, en donde el dispositivo objetivo es el dispositivo de comunicaciones M2M.
Una plataforma de M2M que tenga un software mediador, en donde el software mediador comprende:
una unidad de recepción de demanda de acceso a un recurso, configurada para recibir una demanda de acceso a un recurso enviada por una aplicación M2M utilizando una interfaz de acceso a un recurso, en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recurso URI que se utiliza para indicar una posición de memorización de un recurso de datos de objeto de gestión MO accedido y recurso de datos de MO accedido se crea en la plataforma M2M y corresponde a la información de objeto MO en un dispositivo M2M y el identificador URI se asigna al recurso de datos de MO accedido;
una unidad de conversión de orden de control, configurada para referirse a un mapeado de correspondencia preestablecido entre la demanda de acceso a un recurso del recurso de datos de MO y una orden DM, para convertir la demanda de acceso a un recurso en su orden DM correspondiente y para determinar, en función del mapeado de correspondencia preestablecido entre el recurso de datos de MO y la información de MO, la información de MO correspondiente al recurso de datos de MO accedido; y
una unidad de envío de orden de control, configurada para enviar la orden DM un dispositivo objetivo correspondiente al identificador URI para gestionar la información de MO correspondiente al recurso de datos de MO accedido, en donde el dispositivo objetivo es el dispositivo M2M.
Un sistema de comunicaciones máquina a máquina M2M, que incluye: un dispositivo M2M y una plataforma M2M que tienen un software mediador, en donde:
el software mediador está configurado para: recibir una demanda de acceso a un recurso envida por una aplicación de M2M utilizando una interfaz de acceso a un recurso, en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recurso URI que se utiliza para indicar una posición de memorización de un recurso de datos de objeto de gestión MO accedido y el recurso de datos MO accedido se crea en la plataforma M2M y corresponde a la información de objeto MO en el dispositivo M2M y el identificador URI se asigna al recurso de datos de MO accedido; para hacer referencia al mapeado de correspondencia preestablecido entre la demanda de acceso a un recurso del recurso de datos de MO y una orden DM, para convertir la demanda de acceso a un recurso en su orden DM correspondiente y para determinar, en conformidad con el mapeado de correspondencia preestablecido entre el recurso de datos de MO y la información de MO, la información MO correspondiente al recurso de datos de MO accedido y para enviar la orden DM a un dispositivo objetivo correspondiente al identificador URI para gestionar la información de MO correspondiente al recurso de datos de MO accedido; y
el dispositivo de comunicaciones M2M está configurado para recibir y ejecutar la orden DM, para obtener datos de resultados y para reenviar los datos de resultados al software mediador.
A partir de las soluciones técnicas, puede deducirse que el método de gestión de dispositivo dado a conocer por la presente invención utiliza una interfaz de acceso a un recurso uniforme para conectar aplicaciones de M2M a la plataforma M2M, de modo que las aplicaciones de M2M puedan acceder a la gestión DM de diferentes plataformas M2M, con lo que se pone en práctica la gestión de dispositivo extremo a extremo y las aplicaciones de servicio relacionadas.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para describir, con mayor claridad, las soluciones técnicas de la presente invención, a continuación se describen, de forma concisa, los dibujos adjuntos requeridos para ilustrar la presente invención. Evidentemente, los dibujos adjuntos descritos a continuación son solamente algunas formas de realización de la presente invención.
La Figura 1 es un diagrama estructural esquemático de un sistema de comunicaciones M2M típico dado a conocer en una primera forma de realización de la presente invención;
15
25
35
45
55
65
E11777207
17-07-2015
La Figura 2 es un diagrama de flujo de un método de gestión de dispositivo dado a conocer en una forma de realización de la presente invención; Las Figuras 3A y 3B son diagramas de flujo de otro método de gestión de dispositivos dado a conocer en una forma de realización de la presente invención;
La Figura 4 es un diagrama de flujo de otro método de gestión de dispositivos dado a conocer en una forma de realización de la presente invención;
La Figura 5 es un diagrama de flujo de otro método de gestión de dispositivos dado a conocer en una forma de realización de la presente invención;
La Figura 6 es un diagrama de flujo de un método para establecer una relación de mapeado de correspondencia entre un recurso de datos de MO y la información de MO dado a conocer en una forma de realización de la presente invención;
La Figura 7 es un diagrama de flujo de otro método para establecer una relación de mapeado de correspondencia entre un recurso de datos de MO y la información de MO dado a conocer en una forma de realización de la presente invención;
La Figura 8 es un diagrama estructural esquemático de un software mediador dado a conocer en una forma de realización de la presente invención;
La Figura 9 es un diagrama estructural esquemático de otro software mediador dado a conocer en una forma de realización de la presente invención;
La Figura 10 es un diagrama estructural esquemático de una unidad de envío de orden de control según se representa en la Figura 8 o en la Figura 9;
La Figura 11 es otro diagrama estructural esquemático de una unidad de envío de orden de control que se ilustra en la Figura 8 o en la Figura 9;
La Figura 12 es un diagrama estructural esquemático de un sistema de comunicaciones M2M dado a conocer en una forma de realización de la presente invención; y
La Figura 13 es un diagrama estructural esquemático de otro sistema de comunicaciones M2M dado a conocer en una forma de realización de la presente invención.
DESCRIPCIÓN DETALLADA DE LAS FORMAS DE REALIZACIÓN DE LA INVENCIÓN
A continuación se describen las soluciones técnicas de la presente invención, de forma clara y completa, haciendo referencia a los dibujos adjuntos de las formas de realización de la presente invención. Evidentemente, las formas de realización descritas son algunas formas de realización de la presente invención y no todas las formas de realización de la presente invención.
La presente invención da a conocer un método de gestión de dispositivos. En este método, se consigue la finalidad siguiente: las aplicaciones de M2M acceden a las plataformas M2M utilizando una interfaz de acceso a un recurso para poner en práctica una gestión DM diferente.
La interfaz de acceso a un recurso de comunicaciones citada en la presente invención puede ser cualquier interfaz de protocolo de acceso basada en recursos, a modo de ejemplo, una interfaz de HTTP (HyperText Transfer Protocol, transferencia de hipertexto), una interfaz de XCAP (XML Configuration Access Protocol, un protocolo de acceso de configuración XML) y una fax extendida sobre la base de una interfaz de protocolo de acceso basado en recursos ya existente. La presente invención no está limitada a la aplicación de este método en un sistema M2M y el método puede aplicarse también en otros sistemas de comunicaciones.
Los modos de puesta en práctica específicos son como sigue:
Un proceso de puesta en práctica de un método de gestión de dispositivos dado a conocer en la presente invención se ilustra en la Figura 2 e incluye las etapas siguientes:
Etapa S21: Recibir una demanda de acceso a un recurso utilizando una interfaz de acceso a un recurso, en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recurso URI que se utiliza para indicar una posición de memorización de un recurso de datos de MO accedido.
Durante la puesta en práctica de este proceso, los recursos de datos de MO correspondientes a la información de datos de MO en dispositivos M2M necesita establecerse por anticipado en conformidad con la especificación de TNDS (Serialización de un árbol y descripción) de DM, en donde los recursos de datos de MO pueden ser recursos de protocolo de acceso a configuración de XML (XML Configuration Access Protocol, XCAP) XCAP o puede ser también recursos de
15
25
35
45
55
65
E11777207
17-07-2015
datos de otros tipos y luego, el acceso a los recursos de datos de MO se pone en práctica utilizando un método de acceso a un recurso correspondiente a recursos de datos y una interfaz de acceso a un recurso establecida utilizando este método. Los recursos de MO pueden ser objeto de mapeado de correspondencia con una plataforma M2M o un dispositivo de M2M y las posiciones de los recursos de MO se determinan utilizando identificadores URIs. La demanda de acceso a un recurso puede recibirse por un software mediador separado de la plataforma y dispositivo que recibe la demanda enviada por una aplicación de M2M y reenviada por la plataforma o la demanda de acceso a un recurso puede recibirse por un software mediador que está instalado en la plataforma que recibe la demanda procedente de una aplicación de M2M o la demanda de acceso a un recurso puede recibirse también por un software mediador que está instalado en un dispositivo que recibe la demanda reenviada y un software mediador instalado en la plataforma o reenviada por la plataforma después de que el software mediador está instalado en la plataforma o la propia plataforma reciba la demanda. El caso específico depende de las necesidades reales.
Etapa S22: Convertir, en conformidad con la relación de mapeado de correspondencia preestablecida entre la demanda de acceso a un recurso del recurso de datos de MO y una orden DM, la demanda de acceso a un recurso del recurso de datos de MO en su orden DM correspondiente y para determinar, en conformidad con la relación de mapeado de correspondencia preestablecida entre el recurso de datos de MO y la información de MO, de la información de MO correspondiente a los datos MO accedidos.
Una aplicación de M2M envía una demanda de aplicación de recursos utilizando la interfaz de acceso a un recurso y el objeto a accederse por la aplicación de M2M es datos de recurso de MO. Sin embargo, lo que se necesita realmente es controlar la información de MO correspondiente a los datos de recursos de MO. Por lo tanto, la demanda de acceso a un recurso necesita convertirse, en conformidad con el mapeado de correspondencia establecido entre una orden DM y una demanda de acceso a un recurso que se establece por anticipado, en la orden DM que es reconocible para información de datos de MO con el fin de poner en práctica la gestión y utilización de la información de MO.
Las interfaces de acceso a un reconocimiento en la técnica anterior incluyen: una interfaz de HTTP y una interfaz de XCAP. La interfaz de XCAP proporciona solamente un conjunto básico de métodos de demanda de acceso a un recurso, incluye tres tipos de demandas: GET, PUT y DELETE, que indican las operaciones de adquisición, sustitución o adición y supresión correspondiente a recursos XCAP correspondientes, respectivamente. Con el fin de que una orden DM existente pueda ponerse en mapeado de correspondencia con una demanda de XCAP correspondiente, necesita extenderse todavía más un método de XCAP. A modo de ejemplo, se realiza la extensión utilizando un protocolo de HTTP para obtener una demanda de acceso a un recurso extendida. Los tipos de demanda de acceso a un recurso incluyen: una demanda de ejecución, una demanda de copia, una demanda de la denominada operación atómica, una demanda de operación atómica secuencial, una demanda de información asíncrona, una demanda de una operación de grupo de dispositivos en múltiples dispositivos en el sistema, una demanda de operación condicional y una demanda de operación condicional combinada, con el fin de permitir la puesta en práctica de las operaciones correspondientes en los recursos de datos de MO. El software mediador determina, utilizando los datos incluidos en la demanda de acceso a un recurso, el tipo de la demanda que necesita utilizarse actualmente para acceder a los datos de MO y luego, convierte la demanda en una demanda DM correspondiente al tipo de la demanda.
Además, la presente invención establece un mapeado de correspondencia entre la información de MO por anticipado para convertirla en un recurso de datos de MO, a modo de ejemplo, un recurso de XCAP, de modo que una demanda de acceso a un recurso pueda actuar directamente sobre el recurso y luego, se pone en práctica una operación de orden DM sobre la información de MO en conformidad con la relación de mapeado de correspondencia entre la demanda de acceso a un recurso y la orden DM y la relación de mapeado de correspondencia entre la información de MO y el recurso de XCAP.
Etapa S23: Enviar la orden DM a un dispositivo objetivo correspondiente al identificador URI para gestionar la información de MO correspondiente a los datos de MO accedidos.
La orden DM convertida se envía a un dispositivo objetivo correspondiente al recurso de datos de MO accedido. Este proceso puede completarse utilizando el protocolo de especificación de gestión de dispositivo (Device Management, DM) definido por la denominada alianza móvil abierta (Open Mobile Alliance, OMA) entre el servidor de gestión de dispositivos DMS y el cliente de gestión de dispositivo DMC en el dispositivo objetivo en la técnica anterior o puede completarse también utilizando una interfaz de acceso a un recurso, a modo de ejemplo, una interfaz de XCAP o de HTTP. Después de recibir la orden, el dispositivo objetivo ejecuta la orden para gestionar la información de MO correspondiente, con lo que se pone en práctica la función de gestión de dispositivo.
En el método de gestión de dispositivo dado a conocer en la forma de realización, la información de MO sobre un dispositivo de comunicaciones M2M se pone en relación de mapeado de correspondencia para su conversión en un recurso de datos de MO y utilizando la relación de correspondencia preestablecida entre las demandas de acceso a un recurso y las órdenes DM, una aplicación de M2M externa puede acceder y controlar la información de MO utilizando una interfaz de acceso a un recurso, con lo que se consigue la finalidad de que la aplicación de M2M gestione los dispositivos distantes utilizando una interfaz uniforme abierta.
15
25
35
45
55
65
E11777207
17-07-2015
En esta forma de realización, después de que se envíe la orden DM, el dispositivo puede recibir satisfactoriamente la orden DM, generar datos de resultados después de ejecutar la orden DM y reenviar los datos de resultados para indicar que un proceso de gestión satisfactorio está completo. A modo de ejemplo, se supone que el tipo de la demanda de acceso a un recurso es GET y se adquieren los datos de ejecución del dispositivo objetivo. Después de que el dispositivo ejecute una orden DM correspondiente, los datos de resultados son los datos de ejecución del dispositivo objetivo. Por supuesto, el dispositivo puede también no recibir satisfactoriamente la orden DM. En este caso, la aplicación M2M puede continuar enviando la demanda de acceso a un recurso después de que no se reciba ningún mensaje de retorno dentro del tiempo preestablecido o puede finalizar también la operación. El modo de puesta en práctica específico depende de un escenario operativo de aplicación.
El método dado a conocer en la forma de realización precedente puede ser una operación realizada por un software mediador que se separa desde una plataforma y un dispositivo para realizar la comunicación entre la plataforma y el dispositivo o puede ser también una operación realizada por un software mediador de plataforma que está instalado en la plataforma y un software mediador de dispositivos que está instalado en el dispositivo mediante cooperación mutua para poner en práctica la finalidad precedente. Los modos para poner en práctica el método consisten ambos en: convertir una demanda de acceso a un recurso enviada por una aplicación de M2M en una orden DM, y la diferencia radica solamente en que los procesos de puesta en práctica específicos están en conformidad con los diferentes casos operativos. A modo de ejemplo, cuando el recurso de datos de objeto MO accedido en la demanda de acceso a un recurso enviada por una aplicación de M2M se memoriza en la plataforma, con el fin de que la demanda de acceso a un recurso sea más adecuadamente convertida en una orden DM, el software mediador de la plataforma puede realizar la comunicación entre la plataforma y el dispositivo utilizando otro método de gestión de dispositivos dado a conocer en esta forma de realización para gestionar el dispositivo. Esta forma de realización utiliza una interfaz de acceso a un recurso XCAP, a modo de ejemplo, para realizar una conexión entre la aplicación de M2M y el software mediador. El proceso se ilustra en las Figuras 3A y 3B e incluye las etapas siguientes:
Etapa S31: Un software mediador de plataforma recibe una demanda de acceso a un recurso enviada por una aplicación de M2M utilizando una interfaz de acceso a un recurso XCAP, en donde la demanda de acceso a un recurso incluye un identificador uniforme de recurso URI que se utiliza para indicar una posición de memorización de un recurso de datos de objeto MO accedido.
Etapa S32: Determinar la posición de memorización del recurso de datos de objeto MO accedido en función del identificador URI; si la posición de memorización es una plataforma, ejecutar la etapa S33a; si la posición de memorización es un dispositivo, ejecutar la etapa S33b.
Etapa S33a: Convertir, en conformidad con la relación de mapeado de correspondencia preestablecida entre la demanda de acceso a un recurso del recurso de datos de objeto MO y una orden DM de gestión de dispositivos, la demanda de acceso a un recurso de datos de MO en su orden DM correspondiente, determinar, en conformidad con la relación de mapeado de correspondencia preestablecida entre el recurso de datos de objeto MO y la información de MO, la información de objeto MO correspondiente a los datos de MO accedidos y ejecutar la etapa S34.
La posición de memorización es la plataforma. El software mediador de plataforma convierte la demanda de acceso a un recurso del recurso de datos de objeto MO en la orden DM y determina la información de objeto MO correspondiente a los datos de MO accedidos.
Etapa S33b: Reenviar la demanda de acceso a un recurso a un software mediador de dispositivo para su proceso. Puesto que la posición de memorización es un dispositivo, en esta forma de realización, la demanda de acceso a un recurso se reenvía al software mediador de dispositivos para convertir la demanda en la orden DM de forma más adecuada, de modo que el software mediador de dispositivos complete las operaciones posteriores. El proceso de operación específico se describe a continuación con más detalle.
Etapa S34: Determinar si una sesión DM entre un servidor DMS y un DMC en un dispositivo objetivo existe o no; si existe la sesión entre el servidor de gestión DMS y el dispositivo objetivo, ejecutar la etapa S35a; si no es así, ejecutar la etapa S35b.
En conformidad con esta forma de realización, una sesión entre el servidor DMS y el DMC en el dispositivo objetivo se utiliza para enviar la orden DM. Por ello, necesita determinarse si existe ya una sesión DM entre ambos.
Etapa S35a: Enviar la orden DM al DMC en el dispositivo objetivo utilizando la sesión DM actual.
Etapa S35b: Enviar una orden de control de sesión de DM al servidor DMS para controlar el DMS para establecer una sesión DM con el DMC del dispositivo objetivo.
El DMC del dispositivo de M2M no ha establecido todavía una sesión DM con el servidor DMS y el servidor DMS recibió instrucciones para enviar un mensaje de notificación de DM al DMC con el fin de establecer la sesión DM entre el servidor DMS y el DMC. Esta forma de realización no restringe el proceso de establecer una sesión a la que fue descrita
15
25
35
45
55
65
E11777207
17-07-2015
en la etapa S35b. Análogamente, se pueden utilizar otra soluciones en tanto que se pueda establecer la sesión entre el servidor DMS y el DMC.
El DMC envía un mensaje de establecimiento de sesión DM al servidor DMS en conformidad con el mensaje de notificación de DM recibido siguiendo los requisitos de la especificación del protocolo OMA-DM en la técnica anterior, en donde el mensaje incluye información de dispositivo de M2M (DevInfo) necesaria, a modo de ejemplo, una identidad de dispositivo M2M dev1, para indicar que la sesión de DM entre el servidor DMS y el DMC en el dispositivo M2M ha sido establecida.
Etapa S36: Enviar la orden DM al DMC del dispositivo objetivo utilizando la sesión de DM establecida.
El servidor DMS envía una orden DM correspondiente a un DMC objetivo, a modo de ejemplo, para indicar que el servidor DMS adquiere, en el dispositivo M2M, la información de MO objetivo correspondiente a los datos de MO accedidos.
Etapa S37: Recibir datos de resultados generados y reenviados por el DMC del dispositivo objetivo después de que el DMC del dispositivo objetivo ejecute la orden DM, con el fin de gestionar la información de MO correspondiente a los datos de MO accedidos.
El DMC ejecuta la función y operación de DM correspondiente en conformidad con el mensaje de orden DM recibido siguiendo los requisitos contenidos en la especificación del protocolo OMA-DM en la técnica anterior y reenvía los datos de resultados de la ejecución al servidor DMS, a modo de ejemplo, información específica sobre el MO objetivo en el dispositivo de comunicaciones M2M. El DMS envía los datos de resultados de ejecución de DM desde el DMC al software mediador de plataforma.
Etapa S38: Reenviar los datos de resultados.
El software mediador de plataforma reenvía los datos de resultados a una parte demandante de acceso a un recurso, a modo de ejemplo, la aplicación de comunicaciones M2M.
Un proceso de envío de una orden de control de MO estableciendo una sesión DM se añade a esta forma de realización. En un sistema de comunicaciones M2M, en la técnica anterior, una interfaz estándar que esté basada en la especificación del protocolo OMA-DM y que pueda utilizarse para establecer la sesión DM puede existir ya entre un servidor DMS y un DMC. Por lo tanto, en esta forma de realización, la interfaz estándar se reutiliza, existiendo la necesidad de establecer solamente una conexión entre la aplicación de M2M y una plataforma M2M y luego, la conexión de sesión DM establecida utilizando la interfaz estándar se utiliza para enviar la orden de control de MO con lo que se asegura que la aplicación de M2M gestione un dispositivo distante utilizando una interfaz uniforme abierta sin necesidad de cambiar la relación de interfaz en el sistema existente.
En esta forma de realización, para evitar la carga de costes innecesarios debido al mantenimiento de la sesión cuando no existe ninguna orden DM, después de que se envíe completamente una orden DM, si existe una orden DM posterior dentro de un periodo de sesión preestablecido puede determinarse además; si existe una orden DM posterior, continuar la ejecución; si no existe una orden DM posterior, cerrar la sesión.
Conviene señalar que, después de que se reenvíe la demanda de acceso a un recurso en la forma de realización precedente hacia el software mediador de dispositivo (en la etapa S33b), el software mediador de dispositivo ejecuta también un proceso de ejecución similar al proceso precedente, es decir: convierte la demanda de acceso a un recurso en una orden DM y determina la información de MO correspondiente al recurso de datos de MO. Además, el software mediador de dispositivos ejecuta consecuentemente otras operaciones relacionadas, con lo que se pone en práctica la coordinación mutua con el software mediador de la plataforma en la plataforma y se realiza la comunicación entre la plataforma y los dispositivos. De este modo, se realiza la finalidad de que la aplicación de M2M gestione los dispositivos utilizando la plataforma. El proceso específico se ilustra en la Figura 4 e incluye las etapas siguientes:
Etapa S41: Recibir la demanda de acceso a un recurso reenvía por el software mediador de plataforma.
Etapa S42: Convertir, en conformidad con la relación de mapeado de correspondencia preestablecida entre la demanda de acceso a un recurso del recurso de datos de MO y la orden DM la demanda de acceso a un recurso de los datos de MO en su orden DM correspondiente y determinar, en conformidad con la relación de mapeado de correspondencia preestablecido entre el recurso de datos de MO y la información de MO, la información de MO correspondiente a los datos de MO accedidos.
Etapa S43: Enviar la demanda de acceso a un recurso al DMC del dispositivo objetivo para gestionar la información de MO correspondiente a los datos de MO accedidos.
Enviar la orden DM al DMC del dispositivo objetivo en donde está ubicado el software mediador de dispositivos.
15
25
35
45
55
65
E11777207
17-07-2015
Etapa S44: Recibir datos de resultados que se reenvían después de que el DMC del dispositivo objetivo ejecute la orden DM.
El DMC ejecuta la orden DM para procesar la información de MO, obtiene datos de resultados y reenvía los datos de resultados al software mediador de dispositivos.
Etapa S45: Reenviar los datos de resultados al software mediador de plataforma. Conviene señalar que, cuando el software mediador de dispositivos procesa la demanda de acceso a un recurso, las etapas S43 y S44 en el proceso ilustrado en la Figura 4 son un procedimiento interactivo entre los módulos internos del dispositivo objetivo y la etapa S45 es un procedimiento interactivo entre el software mediador de dispositivos y el software mediador de plataforma. Solamente después de recibir los datos de resultados reenviados, el software mediador de plataforma reenvía los datos de resultados a la aplicación de M2M que envía la demanda. Estos últimos son diferentes del procedimiento interactivo entre el software mediador de plataforma y el software mediador de dispositivo y el procedimiento interactivo entre el software mediador de plataforma y la aplicación de M2M, que se ilustran en las etapas S36 a S38 en la Figura 3.
Puede deducirse que, en el método de control de datos dado a conocer en esta forma de realización, diferentes procedimientos de procesamiento se utilizan en función de las diferentes posiciones de memorización de recursos de datos MO accedidos. Es decir, cuando el recurso de datos de MO accedido se memoriza en la plataforma, es el software mediador de plataforma el que ejecuta la conversión de la orden DM, la determinación de la información de MO y el procedimiento de envío; cuando el recurso de datos de MO accedido se memoriza en el dispositivo, es precisamente el software mediador de dispositivos que el ejecuta la conversión de la orden DM, la determinación de la información de MO y el procedimiento de envío. La finalidad es permitir al software mediador de plataforma o al software mediador de dispositivos utilizar más adecuadamente la relación de mapeado de correspondencia preestablecida entre la demanda de acceso a un recurso de datos de MO y la orden DM y utilizar el mapeado de correspondencia entre el recurso de datos de MO y la información de MO para encontrar la información de MO gestionada.
Por supuesto, esta forma de realización no restringe los procedimientos del procesamiento precedentes. La posición de memorización del recurso de datos de MO accedido puede no considerarse y el dispositivo para ejecutar la conversión de orden relacionada y el envío puede establecerse en función de las condiciones reales.
El proceso de otro método de gestión de dispositivos dado a conocer en una forma de realización de la presente invención se ilustra en la Figura 5. El proceso utiliza también un software mediador de plataforma a modo de ejemplo y también utiliza una interfaz de acceso a un recurso XCAP para establecer una conexión entre una aplicación de M2M y una plataforma de M2M. En este momento, se establece también un software mediador de dispositivo en un dispositivo. El proceso incluye las etapas siguientes:
Etapa S51: Recibir una demanda de acceso a un recurso utilizando la interfaz de recurso XCAP, en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recurso URI que se utiliza para indicar una posición de memorización de un recurso de datos de MO de objeto de gestión accedido.
Etapa S52: Convertir, en conformidad con la relación de mapeado de correspondencia preestablecida entre la demanda de acceso a un recurso del recurso de datos de MO y una orden DM, la demanda de acceso a un recurso de datos de MO en su orden DM correspondiente y determinar, en función del mapeado de correspondencia preestablecido entre el recurso de datos de MO y la información de MO, la información de MO correspondiente a los datos de MO accedidos.
Etapa S53: Encapsular la orden DM en conformidad con un protocolo de interfaz de HTTP.
Encapsular la orden DM en conformidad con el protocolo de interfaz HTTP basado en el recurso entre la plataforma M2M y un dispositivo para cambiar su soporte, realizando de este modo la transferencia de la orden DM entre la plataforma y el dispositivo. La interfaz de HTTP en esta forma de realización puede ser también un protocolo de interfaz XCAP básico correspondiente a una demanda de acceso a un recurso XCAP básica o puede ser también un protocolo de interfaz XCAP extendido correspondiente a una demanda de acceso a un recurso de XCAP extendida. El protocolo de interfaz de XCAP extendido puede corresponder a la extensión para la demanda XCAP en la forma de realización ilustra en la Figura 2 o la extensión del protocolo de XCAP básico en conformidad con otros métodos.
Etapa S54: Enviar la orden DM encapsulada a un dispositivo objetivo.
Enviar la orden DM encapsulada que se obtiene después de la conversión, al dispositivo objetivo correspondiente al recurso de datos de MO accedido. Después de recibir la orden DM que está encapsulada en conformidad con el protocolo de HTTP, el software mediador de dispositivo realiza un análisis sintáctico para un formato que sea reconocible para el DMC en el dispositivo objetivo, a modo de ejemplo, un formato de especificación de protocolo OMA-DM y luego, lo envía al DMC, de modo que el DMC pueda reconocer y ejecutar la orden DM para obtener datos de resultados.
Etapa S55: Recibir los datos de resultados generados y reenviados por el dispositivo objetivo después de que ejecute la orden DM.
15
25
35
45
55
65
E11777207
17-07-2015
Etapa S56: Reenviar los datos de resultados.
Reenviar los datos de resultados a una parte demandante de acceso a un reconocimiento, a modo de ejemplo, la aplicación de M2M.
En el método de gestión de dispositivos dado a conocer en esta forma de realización, se añade un procedimiento para encapsulación de la orden DM. Esta forma de realización es aplicable a un escenario operativo en donde ninguna interfaz de comunicación independiente entre el DMS y el DMC se desarrolla en el sistema existente. En este caso, no necesita establecerse ninguna conexión por separado entre el servidor DMS y el DMC para enviar la orden DM. En cambio, la orden DM se encapsula utilizando el protocolo de interfaz de HTTP entre la plataforma M2M y el dispositivo, de modo que la orden puede transferirse directamente entre la plataforma M2M y el dispositivo. Por lo tanto, la interfaz de comunicación entre la plataforma M2M y el dispositivo se reduce y la puesta en práctica es fácil y cómoda desde el punto de vista objetivo.
Una forma de realización de la presente invención da a conocer un método para establecer una relación de mapeado de correspondencia entre un recurso de datos de MO y la información de MO. En esta forma de realización, el recurso de datos de MO correspondiente a la información de MO se establece en la plataforma M2M. Su proceso se ilustra en la Figura 6 e incluye las etapas siguientes:
Etapa S61: Describir la información de MO en el DMC utilizando un documento XML.
En primer lugar, describir la información de MO en el dispositivo M2M utilizando un documento de XML en conformidad con la especificación de DM TNDS. Utilizando el método dado a conocer en la especificación de DM TNDS, el árbol operativo de MO en cualquier dispositivo M2M puede describirse utilizando un documento de XML, en donde cada nodo de MO en el árbol operativo de MO correspondiente a un elemento en el documento de XML, mientras que los subnodos y atributos de un modo de MO puede describirse utilizando atributos de subelementos de XML correspondientes.
Etapa S62: Crear, en la plataforma M2M, un recurso de datos de MO correspondiente a la información de MO y asignar un identificador URI al recurso.
Para crear el documento de XML que se utiliza para describir el objeto MO en el dispositivo de M2M en un tipo de recurso de datos en el dispositivo de M2M o la plataforma M2M, el recurso de datos de MO es un recurso XCAP, o un recurso de otros tipos. Un identificador URI relacionado con el dispositivo M2M o la plataforma M2M necesita asignarse al documento XML, a modo de ejemplo, http://example.com/dev1/dm. De este modo, el MO objetivo y sus atributos en el dispositivo de M2M especificado pueden accederse utilizando una sub-ruta del URI, a modo de ejemplo, http://example.com/dev1/dm/TargetMO. Por lo tanto, crear un recurso de MO raíz correspondiente al dispositivo M2M y establecer un identificador URI para dicho dispositivo. A modo de ejemplo, utilizar http://domainl/dev1/dm como un URI raíz y luego, establecer un mapeado de correspondencia de la información sobre cada nodo MO específico en el dispositivo M2M para hacerlo ser un sub-recurso de MO bajo el URI raíz. Además, componentes (tales como elementos y atributos) en un documento son creados en los sub-recursos correspondientes y se asignan los URIs correspondientes, es decir, sub-rutas del URI raíz. De este modo, una demanda de acceso a un recurso puede direccionarse a la granularidad fina de cada nodo de información de MO.
Para poner en práctica la función de gestión de dispositivos utilizando un método de acceso a un recurso, una orden OMA DM necesita ser objeto de mapeado para hacerla ser un método de acceso a un recurso correspondiente. Es decir, establecer un mapeado de correspondencia entre una orden DM correspondiente a la información de MO y una demanda de acceso a un recurso correspondiente al recurso de datos de MO. Para una demanda de acceso a un recurso y una orden DM que puedan realizar la misma operación, el mapeado de correspondencia entre ambos puede establecerse directamente para satisfacer la finalidad siguiente: El resultado de dar respuesta, por el recurso accedido, a la demanda de acceso a un recurso es el mismo que el resultado de la recepción, por la información de MO correspondiente, de la orden de control DM correspondiente a la demanda de acceso son los mismos. Sin embargo, una orden DM y una demanda de acceso a un recurso no están en un mapeado de correspondencia estricto del tipo ‘uno a uno’, un método para la extensión de una demanda de recurso se requiere además para una orden DM que no puede directamente ser objeto de mapeado de correspondencia para proporcionar una operación de gestión de dispositivos y una función que no estén soportadas por un sistema DM existente. A continuación se toma, a modo de ejemplo, un método XCAP para describir el procedimiento de extensión.
Para definir el método de demanda de XCAP que se utiliza para acceder al recurso, en conformidad con la especificación de XCAP, necesita definirse la información siguiente:
Identificador ID único de aplicación (Application Unique ID, AUID): a modo de ejemplo, etsi-m2m-dm.
Tipo de medios de recursos (tipo MIME): en conformidad con la especificación de DM TDNS, puede ser la aplicación/vnd.syncml.dmtnds+xml, o la aplicación/vnd.syncml.dmtnds+wbxml;
10
15
20
25
30
35
40
45
E11777207
17-07-2015
Espacio de denominación de documento por defecto: a modo de ejemplo, urn:etsi:m2m:xml:ns:dm
Gramática y sintaxis de XML: puede hacerse referencia a las normas sobre la gramática y sintaxis en la especificación de DM TNDS;
Restricción de la validez: puede hacerse referencia a la especificación de DM TDNS y la especificación de MO específica;
Política de acceso: puede hacerse referencia a la especificación de DM TDNS y el estado de puesta en práctica de una MO específica;
Convenio de denominación: la ruta raíz al URI del recurso de MO es http://<domain>/<entity>/dm en donde <dominio> indica el dominio inicial base del sistema de comunicaciones M2M, <entidad> indica una identidad única del dispositivo de M2M o la plataforma M2M y “dm” es una cadena de caracteres fija; de este modo, las aplicaciones de M2M pueden acceder flexiblemente a recursos de XCAP que estén en diferentes posiciones y se utilizan para describir la MO en conformidad con este convenio.
En la técnica anterior, la especificación de XCAP proporciona solamente tres métodos: GET, PUT y DELETE, que significan adquirir, sustituir o añadir y suprimir recursos XCAP, respectivamente. Los requisitos de las órdenes DM no se pueden cumplir completamente. Por lo tanto, se requiere además alguna extensión para el método XCAP. Puesto que el método XCAP existente está basado en la tecnología de HTTP, la presente invención extiende el método XCAP introduciendo un método de HTTP POST para realizar el mapeado de correspondencia de todas las órdenes DM. El método de puesta en práctica se describe en la tabla 1. La tabla 1 es una tabla de mapeado de correspondencia entre las órdenes DM y los métodos XCAP.
Tabla 1
- Orden DM
- Método XCAP/HTTP Descripción
- <Add>
- PUT/POST Para añadir un nodo MO
- <Delete>
- DELETE Para suprimir un nodo MO y su sub-árbol objetivo.
- <Get>
- GET Para adquirir el valor, sub-árbol o estructura de subárbol de un nodo MO.
- <Replace>
- PUT Para actualizar el valor de un nodo MO
- <Results>
- Cuerpo de mensaje Para transmitir los datos de contenidos de retorno en el mensaje de respuesta
- <Exec>
- POST (cmd=exec) Para ejecutar un MO ejecutable
- <Copy>
- POST (cmd=copy) / GET + PUT Para replicar dígitos entre nodos de los elementos del árbol operativo.
- <Atomic>
- POST (cmd=atomic) Para combinar múltiples operaciones en una operación atómica
- <Sequence>
- POST (cmd=sequence) Para ejecutar una operación atómica en una secuencia requerida
- <Alert>
- POST (cmd=alert) Para informar de un evento operativo asíncrono
Más concretamente, las órdenes DM <Add>, <Delete>, <Get> y <Replace> pueden ser todas ellas directamente mapeadas en correspondencia con los métodos XCAP existentes, incluyendo PUT, DELETE y GET, en donde la orden <Add> puede ponerse en práctica utilizando un método PUT o un método POST. El método PUT actúa sobre el URI correspondiente al nodo MO objetivo o su atributo, mientras que el método POST actúa sobre el URI correspondiente al nodo matriz del atributo o nodo MO objetivo. La orden DM <Results> se utiliza habitualmente para transmitir el contenido del resultado de la orden <Get> y puede incluirse en el cuerpo del mensaje del mensaje de respuesta XCAP.
La orden de DM <Exec> suele actuar sobre un nodo MO ejecutable y se utiliza para dar instrucciones al DMC para ejecutar una tarea u operación de gestión de dispositivos específica determinada. Esta forma de realización utiliza el método POST e incluye el parámetro cmd=exec que actúa sobre el URI (a modo de ejemplo, htttp://example.com/dev1/dm/TargetMO) correspondiente al nodo de MO precedente para realizar el método de operación de gestión de dispositivos basado en recursos que proporciona la misma función, a modo de ejemplo:
POST http://example.com/dev1/dm/TargetMO?cmd=exec
La orden DM <Copy> se utiliza para copiar el contenido en un nodo MO origen a un nodo MO objetivo. Esta forma de realización utiliza el método POST e incluye el parámetro cmd=copy que actúa sobre el identificador URI (a modo de ejemplo, htttp://example.com/dev1/dm/TargetMO) correspondiente al nodo MO objetivo precedente e incluye el identificador URI (a modo de ejemplo, htttp://example.com/dev1/dm/SourceMO) del nodo MO origen en el cuerpo del
15
25
35
45
55
65
E11777207
17-07-2015
mensaje para poner en práctica el método de operación de gestión de dispositivos basado en recursos y proporciona la misma función, a modo de ejemplo:
POST htttp://example.cor/dev1/dm/TargetMO?cmd=copy
Tipo de contenido: …
Longitud de contenido: …
<SourceURI> htttp://example.com/dev1/dm/SourceMO</SourceURI>
Ahora bien, la orden DM <Copy> puede ponerse en práctica, además, utilizando una combinación de los métodos GET y PUT, es decir, el contenido del nodo MO origen se adquiere utilizando el método GET y luego el contenido adquirido es objeto de escritura para el nodo MO objetivo utilizando el método PUT.
Las órdenes DM <Atomic< y <Sequence> se utilizan ambas para realizar operaciones combinadas de las diversas órdenes DM precedentes y un atributo atómico necesita garantizarse, es decir, si una orden DM no puede ejecutarse, falla la operación completa. La diferencia es que la orden <Atomic> no tiene una restricción para la secuencia de ejecución de varias órdenes DM mientras que la orden <Sequence> requiere que varias órdenes DM se ejecuten en una secuencia listada. Esta forma de realización, utiliza el método POST e incluye el parámetro cmd=atomic o cmd=sequence que actúa sobre el identificador URI (a modo de ejemplo, htttp://example.com/dev1/dm) correspondiente al nodo de MO raíz en el dispositivo objetivo e incluye varias órdenes DM en el cuerpo del mensaje en donde cada orden se describe utilizando un elemento <Cmd> para poner en práctica el método de operación de gestión de dispositivos basado en recursos que proporciona la misma función, a modo de ejemplo:
POST htttp://example.com/dev1/dm?cmd=atomic
Tipo de contenido:…
Longitudinal de contenido:….
<Atomic>
<Cmd> GET http://example.com/dev1/dm/TargetMO</Cmd>
<Cmd> DELETE http://example.com/dev1/dm/TargetMO</Cmd>
</Automic>
Ahora bien, en la forma de realización precedente, el mismo parámetro puede utilizarse también en el método POST, a modo de ejemplo, cmd=trans y las órdenes DM <Atomic> y <Sequence> se distinguen utilizando el elemento de <Atomic> o <Sequence> en el cuerpo del mensaje.
La orden DM <Alert> se utiliza por el DMC para proporcionar información de evento operativo asíncrona al DMS. Esta forma de realización utiliza el método POST, incluye el parámetro cmd=alert que actúa sobre el identificador URI (a modo de ejemplo, htttp://example.com/dev1/dm) que se utiliza, de forma dedicada, a recibir eventos operativos asíncronos en el DMS y describe el tipo o código del evento operativo (a modo de ejemplo, SERVER-INITIATED MGMT (1200)) y/o URI (a modo de ejemplo, http://example.com/dev1/dm/SourceMO) correspondiente al MO origen para poner en práctica el método de operación de gestión de dispositivos basado en recursos que proporciona la misma función, a modo de ejemplo:
POST htttp://example.com/dms1/dm?cmd=alert
Tipo de contenido: …
Longitud de contenido: …
<Event> SERVER-INITIATED MGMT (1200) </Event>
<Source>http://example.com/dev1/dm/SourceMO</Source>
Ahora bien, el método POST puede utilizarse todavía más, el parámetro cmd=alert que actúa por separado sobre el identificador URI (a modo de ejemplo, htttp://example.com/dms1/dm/1200) que se utiliza para recibir eventos operativos asíncronos de diferentes tipos o códigos en el servidor DMS y/o el URI (a modo de ejemplo, http://example.com/dev1/dm/SourceMO) correspondiente al MO origen en el cuerpo del mensaje que se describe para
15
25
35
45
55
65
E11777207
17-07-2015
poner en práctica el método de operación de gestión de dispositivos basado en recursos que proporciona la misma función, a modo de ejemplo:
POST htttp://example.com/dms1/dm/1200?cmd=alert
Tipo de contenido:…
Longitud de contenido:…
<Source>http://example.com/dev1/dm/SourceMO</Source>
Sobre la base de los métodos proporcionados en la forma de realización precedente, todas las operaciones y funciones de gestión de dispositivos para el dispositivo MO en el OMA DM existente pueden ponerse en práctica utilizando la manera de acceso de interfaz basada en recursos.
Por supuesto, además del método precedente, la presente invención da a conocer, además, el método siguiente:
En la especificación de M2M formulada por el ETSI (European Telecommunications Standars Institute, Instituto Europeo de Normas para Telecomunicaciones) cualquier dispositivo M2M o plataforma M2M y las capacidades de servicio proporcionadas por el dispositivo M2M o por la plataforma M2M pueden abstraerse como recursos y tener un identificador uniforme de recursos, es decir, URI. Además, múltiples recursos pueden crear además un recurso de grupo y se identifican, de forma única, por una identidad de grupo común, es decir, un URI de grupo. Por lo tanto, cuando múltiples dispositivos M2M crean un grupo, esta forma de realización puede crear además un mismo recurso de MO los múltiples dispositivos M2M en un recurso de MO virtual del grupo y luego, en conformidad con el método de gestión de dispositivos en cualquiera de las formas de realización precedentes, realizar operaciones de gestión de dispositivos por lotes para todos los dispositivos M2M en el grupo utilizando operaciones de acceso sobre el recurso MO del grupo.
Más concretamente, suponiendo que los dispositivos M2M 1, 2 y 3 tienen el mismo nodo MO y se crean por separado los siguientes recursos de MO utilizando el método de la primera forma de realización:
http://example.com/dev1/dm/TargetMO
http://example.com/dev2/dm/TargetMO
http://example.com/dev3/dm/TargetMO
Además, se supone que los dispositivos M2M, 1, 2 y 3 pertenecen a un grupo group1 cuyo grupo URI es:
http://example.com/group 1
A continuación, en conformidad con el método en esta forma de realización, el recurso de MO virtual del grupo puede crearse:
http://example.com/group1/dm/TargetMO
Al ejecutar los métodos XCAP correspondientes para el recurso de MO de grupo, las operaciones y funciones de gestión de dispositivos por lotes tales como recuperar, sustituir, suprimir y añadir pueden ponerse en práctica para el mismo nodo MO objetivo de todos los dispositivos M2M 1, 2 y 3. A modo de ejemplo:
GET http://example.com/group1/dm/TargetMO
Ello significa la demanda de la adquisición de información sobre el nodo MO objetivo en todos los dispositivos en el grupo. A continuación, la función de gestión de dispositivos o el software mediador correspondiente que recibe este método XCAP adquiere la información de MO objetivo en los dispositivos M2M 1, 2 y 3 por separado y reenvía el resultado resumen a la parte demandante del método de XCAP.
Además, al extender el método XCAP precedente y/o los parámetros incluidos en el cuerpo del mensaje, la aplicación de M2M puede incluir, además, las condiciones de ejecución para el método de acceso cuando se realiza el acceso utilizando una interfaz de gestión de dispositivos basada en recursos. La operación de gestión de dispositivos correspondiente se ejecuta solamente cuando se cumplen las condiciones de ejecución.
Cuando las diversas condiciones de ejecución solamente se utilizan para una operación de gestión de dispositivos separada, pueden incluirse en los parámetros de línea de orden en los métodos XCAP correspondientes. A modo de ejemplo, se supone que se utiliza MO para actualizar el software denominado firmware del dispositivo 1 que se crea como el recurso http://example.com/dev1/dm/firmare y un parámetro de condición minVer se define para indicar un número de versión mínimo, indicando man un fabricante y mode indica un modelo de producto. Cuando necesita
15
25
35
45
55
65
E11777207
17-07-2015
ejecutarse una operación de actualización del firmware para el dispositivo en conformidad con las condiciones, debe ejecutarse el método XCAP basado en recursos siguiente: PUT http://example.com/dev1/dm/firmware?minVer=1.0&man=huawei&mode=cdma Tipo de contenido: … Longitud de contenido: …
{NewFirmwarelmage} Este método indica que la operación de actualización de firmware correspondiente se ejecuta solamente cuando el número de versión del firmware del dispositivo 1 no es más pequeño que “1.0”, el fabricante es “huawei” y el modelo es “cdma”, en donde el nuevo paquete de firmware {NewFirmwarelmage} se transmite por el cuerpo del mensaje de este método. De este modo, la función de gestión de dispositivos o el software mediador que recibe este método XCAP sustituirá la aplicación de M2M para adquirir primero la información tal como el número de versión de firmware, el fabricante y el modelo del producto del dispositivo objetivo y para comparar con respecto a las condiciones incluidas en el método de XCAP y ejecutar las operaciones de actualización de firmware posteriores si se cumplen todas las condiciones. De esta manera, se impide el inconveniente siguiente: la aplicación de M2M necesita adquirir información relacionada mediante la invocación de métodos tales como GET múltiples veces por anticipado y comparar con respecto a las condiciones locales antes de que pueda actualizar el firmware del dispositivo utilizando el método PUT.
Además, cuando se utilizan las diversas condiciones de ejecución para múltiples operaciones de gestión de dispositivos, las condiciones pueden incluirse como guiones denominados scripts en los cuerpos de mensaje de los métodos XCAP correspondientes. A modo de ejemplo:
POST http://example.com/dev1/dm/firmware?cmd=sequence Tipo de contenido: ... Longitud de contenido: ... <Secuencia> <Cmd> GET http://... </Cmd> <Composición condiciones="AND"> <minVer> 1.0 </ minVer> <man> huawei </ man> </Condiciones> <Acciones> <Cmd> PUT http://... </Cmd> <Cmd> DELETE http://... </Cmd> </Acciones> <Composición condiciones="OR">...</Condición> <Acciones> ...</Acciones> </Secuencia> Cada grupo de condiciones se describe utilizando un elemento denominado <Condiciones> que incluye sub-elementos
de condiciones específicos, a modo de ejemplo, <minVer> indica un número de versión mínimo, <man> indica un fabricante y <mode> indica un modelo de producto. La relación de combinación tal como “o” (OR) o “y” (AND) entre condiciones puede describirse utilizando el atributo de composición del elemento de <condiciones>. Las operaciones de gestión de dispositivos correspondientes se describen utilizando un elemento denominado <Acciones> que incluye vario sub-elementos <Cmd> que se utilizan para describir métodos de gestión de dispositivos basados en recursos específicos. Además, los métodos XCAP que se ejecutan de forma incondicional pueden existir, los cuales se describen utilizando el elemento <Cmd> distinto al elemento <Condiciones>.
15
25
35
45
55
65
E11777207
17-07-2015
Por intermedio de la mejora precedente, las demandas de acceso a un recurso pueden incluir: parámetros de dispositivos correspondientes al recurso de datos de MO accedido, tal como el número de versión precedente, fabricante y modelo, para realizar el control sobre los datos MO de dispositivos que cumplen los parámetros, lo que hace que las demandas de acceso a un recurso sean más adecuadas y facilitando el control de datos correcto y sin inconvenientes.
Utilizando el método de gestión de dispositivos basados en recursos en donde se pueden transmitir condiciones, el procedimiento de operación realizado por aplicaciones de M2M para realizar la gestión de dispositivos puede simplificarse en gran medida. Además, puede entenderse que esta forma de realización proporciona solamente algunos ejemplos de todas las ejecuciones posibles y sus combinaciones. Cualquier nodo de MO definido en las especificaciones de OMA DM existentes, su información de atributos y la información relacionada pueden todas ellas extenderse como condiciones de ejecución utilizando los métodos dados a conocer en esta forma de realización.
Esta forma de realización no restringe el procedimiento para crear recursos de MO, que pueden ser que los registros del software mediador de dispositivos, utilizando un protocolo basado en recursos, la información de MO mantenida por el DMC como recurso de datos de MO en el software mediador de plataforma o bien, puede ser también que el DMC en el dispositivo M2M proporcione la información de MO mantenida por el DMC para el servidor DMS utilizando una interfaz de protocolo entre el servidor DMS y el DMC en el sistema DM en la técnica anterior y el servidor DMS registra la información de MO como recursos de datos de MO en el software mediador de plataforma; o bien, puede ser también que el software mediador de dispositivos utilice un protocolo de acceso a recursos entre el software mediador de plataforma y el software mediador de dispositivos para proporcionar información de MO mantenida por el DMC para el servidor DMS y el DMS registra la información de MO como recursos de datos de MO en el software mediador de plataforma.
Esta forma de realización no restringe la extensión de solamente el protocolo XCAP. Análogamente, otros protocolos de acceso a recursos pueden extenderse para satisfacer la misma finalidad.
La forma de realización de la presente invención da a conocer otro método para establecer una relación de mapeado de correspondencia entre un recurso de datos de MO y la información de MO. Este método establece el recurso de datos de MO en un dispositivo M2M. Su proceso se ilustra en la Figura 7 e incluye las etapas siguientes:
Etapa S71: Describir información de MO en un DMC utilizando un documento XML de lenguaje de marcado extensible.
Etapa S72: Crear, en el dispositivo M2M, un recurso de datos de MO correspondiente a la información de MO y asignar un identificador URI al recurso, en donde el recurso de datos de MO es un recurso XCAP de protocolo de acceso de configuración XML.
En general, cuando se asigna un identificador URI a un recurso de datos de MO creado en el dispositivo, el URI puede asignarse directamente como en esta etapa o bien, puede asignarse cumpliendo una regla preestablecida, a modo de ejemplo, utilizando el URI del dispositivo como la parte básica del URI para el recurso de datos de MO. Un software mediador de plataforma puede determinar, entonces, en conformidad con el URI, que el recurso de datos de MO está localizado en el dispositivo y en consecuencia, puede reenviar una demanda de acceso a un recurso correspondiente al URI a un dispositivo objetivo correspondiente.
Una aplicación de M2M puede demandar también el acceso, en conformidad con la regla preestablecida, a un URI para un recurso de datos de MO que esté relacionado con el dispositivo objetivo pero no existe, lo que da lugar a un fallo en el acceso. En este caso, con el fin de que la aplicación de M2M y/o plataforma M2M puedan encontrar correctamente los recursos de MO locales registrados en el dispositivo M2M, los recursos de datos de MO locales registrados en el software mediador de dispositivo pueden anunciarse para el software mediador de plataforma. Por lo tanto, esta forma de realización puede incluir, además, la etapa siguiente:
Etapa S73: Enviar, a la plataforma, un anuncio que indique que el recurso de datos de MO está disponible.
Anunciar el recurso de datos de MO en la plataforma M2M. El método de realización específico para el procedimiento de anuncio puede ser un método de acceso a un recurso XCAP o cualquier otro método conocido en la técnica anterior.
La presente invención da a conocer además, un software mediador que puede poner en práctica los métodos de gestión de dispositivos precedentes. Una de sus estructuras se ilustra en la Figura 8, incluyendo: una unidad de recepción de demanda de acceso a un recurso 81, una unidad de conversión de orden de control 82 y una unidad de envío de orden de control 83, en donde:
La unidad de recepción de demanda de acceso a un recurso 81 está configurada para recibir una demanda de acceso a un recurso utilizando una interfaz de acceso a un recurso de una aplicación externa (esta forma de realización adopta una aplicación de M2M como una descripción a modo de ejemplo), en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recursos URI que se utiliza para indicar una posición de memorización de un recurso de datos MO de objeto de gestión accedido.
15
25
35
45
55
65
E11777207
17-07-2015
La unidad de conversión de orden de control 82 está configurada para: convertir, en conformidad con la relación de mapeado de correspondencia preestablecida entre la demanda de acceso a un recurso del recurso de datos de MO y una orden DM, la demanda de acceso a un recurso del recurso de datos de MO en una orden DM correspondiente y determinar, en conformidad con la relación de mapeado de correspondencia preestablecida entre el recurso de datos de MO y la información de MO, la información de MO correspondiente a los datos de MO accedidos.
La unidad de envío de orden de control 83 está configurada para enviar la orden DM a un dispositivo (es decir, un dispositivo objetivo) correspondiente al URI para gestionar la información de MO correspondiente al recurso de datos de MO accedido.
La información de MO en el dispositivo de M2M es objeto de mapeado de correspondencia para hacerla ser un recurso de datos de MO. El software mediador prestable la relación de mapeado de correspondencia entre la demanda de acceso a un recurso y la orden DM, de modo que una aplicación de M2M pueda acceder y controlar la información de MO utilizando una interfaz de acceso a recursos, con lo que se asegura que la aplicación de M2M gestione un dispositivo distante utilizando una interfaz uniforme abierta.
La Figura 9 ilustra otra estructura del software mediador dada a conocer en una forma de realización de la presente invención. El software mediador incluye una unidad de recepción de demanda de acceso a un recurso 91, una unidad de conversión de orden de control 92, una unidad de envío de orden de control 93, una unidad de recepción de dato de resultados 94 y una unidad de envío de datos de resultados 95, en donde:
Las funciones de la unidad de recepción de la demanda de acceso a un recurso 91, la unidad de conversión de orden de control 92 y de la unidad de envío de orden de control 93 son esencialmente las mismas que las que tenían las unidades con los mismos nombres que se ilustran en la Figura 8 y por ello no se describen aquí de nuevo.
La unidad de recepción de datos de resultados 94 está configurada: para recibir datos de resultados generados y reenviados por un dispositivo objetivo después de que el dispositivo objetivo ejecute la orden DM.
La unidad de reenvío de datos de resultados 95 está configurada para reenviar los datos de resultados a un extremo emisor (a modo de ejemplo, una aplicación de M2M) de una demanda de acceso a un recurso.
Mientras se asegura que una aplicación externa (a modo de ejemplo, la aplicación de M2M) gestione un dispositivo distante utilizando una interfaz uniforme abierta, esta forma de realización añade, además, un mecanismo de realimentación de resultados para facilitar la gestión de dispositivos.
Una estructura de la unidad de envío de orden de control 83 o de la unidad de envío de orden de control 93 precedentes se ilustra en la Figura 10, incluyendo: una unidad de determinación 1001, una unidad de establecimiento de sesión 1002 y una unidad de envío 1003, en donde:
La unidad de determinación 1001 está configurada para determinar si existe, o no, una sesión entre un servidor de gestión DMS y el dispositivo objetivo.
La unidad de establecimiento de sesión 1002 está configurada para adquirir un resultado de determinación de la unidad de determinación 1001, y cuando el resultado de la determinación indica que no existe la sesión entre el servidor DMS y el DMC del dispositivo objetivo, controlar el DMS para establecer una sesión con el dispositivo objetivo.
La unidad de envío 1003 está configurada para enviar una orden DM al dispositivo objetivo utilizando la sesión establecida entre el DMS y el DMC del dispositivo objetivo.
La unidad de envío de orden de control, dada a conocer en esta forma de realización, puede determinar primero un estado de conectividad (es decir, si se establece una sesión o no) entre el servidor DMS y el dispositivo objetivo y para establecer una sesión cuando no exista la sesión, asegurando que la orden DM pueda enviarse adecuadamente al dispositivo objetivo.
Una estructura de la unidad de envío de orden de control 83 precedente o de la unidad de envío de orden de control 93 se ilustra en la Figura 11, incluyendo: Una unidad de determinación 1101, una unidad de establecimiento de sesión 1102, una unidad de envío 1103 y una unidad de determinación de procedimiento de sesión 1104, en donde:
Las funciones de la unidad de determinación 1101, de la unidad de establecimiento de sesión 1102 y la unidad de envío 1103 son esencialmente las mismas que las que tenían las unidades con las mismas denominaciones ilustradas en la Figura 10 y por ello no se describen aquí de nuevo.
La unidad de determinación de procedimiento de sesión 1104 está configurada para determinar si existe, o no, una orden DM posterior dentro de un periodo de sesión preestablecido después de que la unidad de envío 1103 envíe completamente una orden DM; si existe una orden DM posterior, dar instrucciones a la unidad de determinación 1101
15
25
35
45
55
65
E11777207
17-07-2015
para continuar su trabajo; si no existe una orden DM posterior, enviar información que proporciona instrucciones para cerrar la sesión, dando instrucciones al servidor DMS para cerrar la sesión con el DMC en el dispositivo objetivo.
La unidad de envío de orden de control, dada a conocer en esta forma de realización, puede evitar un coste de sobrecarga innecesario manteniendo una sesión cuando no exista ninguna orden DM posterior.
Además, la unidad de envío de orden de control puede añadir, además, una unidad de encapsulación sobre la base de la representación de la Figura 10 o de la Figura 11, que está configurada para encapsular, en conformidad con un protocolo preestablecido, la orden DM para enviarse por la unidad de envío 1003 o la unidad de envío 1103.
El software mediador dado a conocer en esta forma de realización puede ser un aparato separado de una plataforma M2M y de un dispositivo o puede ser también un aparato integrado en la plataforma M2M o dispositivo. Además, sus funciones pueden dividirse dependiendo de diferentes escenarios operativos de aplicación y las funciones que están estrechamente relacionadas con la plataforma o dispositivo se establecen por separado en el software mediador de plataforma sobre la plataforma y el software mediador de dispositivo sobre el dispositivo. El software mediador utiliza una interfaz de acceso a un recurso, tal como una interfaz XCAP, de modo que la aplicación de M2M externa pueda controlar los recursos de MO utilizando una demanda de acceso a un recurso y convertir el control sobre los recursos de MO en el control sobre la información de MO en el dispositivo. De este modo, la aplicación de M2M puede gestionar un dispositivo distante utilizando una interfaz uniforme abierta.
Esta forma de realización no restringe la estructura de la unidad de envío de orden de control. Otras estructuras pueden utilizarse en conformidad con las condiciones reales.
Para el procedimiento de trabajo específico del software mediador dado a conocer en esta forma de realización, puede hacerse referencia a las formas de realización del método precedente. Por ello, el procedimiento no se describe aquí de nuevo.
Además, la presente invención da a conocer, además, un sistema de comunicaciones M2M. Una de sus estructuras se ilustra en la Figura 12, incluyendo un software mediador 1201 y un dispositivo M2M 1202, en donde:
El software mediador 1201 está configurado para ejecutar las operaciones siguientes:
Recibir una demanda de acceso a un recurso utilizando una interfaz de acceso a recursos de una aplicación externa (a modo de ejemplo, una aplicación M2M), en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recursos URI que se utiliza para indicar para una posición de memorización de un recurso de datos de MO de objeto de gestión accedido; para convertir, en conformidad con el mapeado de correspondencia preestablecido entre la demanda de acceso a un recurso del recurso de datos de MO y una orden DM, la demanda de acceso a un recurso del recurso de datos de MO en una orden DM correspondiente y para determinar, en conformidad con el mapeado de correspondencia preestablecido entre el recurso de datos de MO y la información de MO, la información de MO correspondiente a los datos de MO accedidos; y para enviar la orden DM a un dispositivo objetivo correspondiente al identificador URI para gestionar la información de MO correspondiente a los datos de MO accedidos.
El dispositivo M2M 1202 está configurado para recibir y ejecutar la orden DM, para obtener los datos de resultados y para reenviar los datos de resultados al software mediador 1201, de modo que el software mediador 1201 reenvíe los datos de resultados a la aplicación externa que envía la demanda de acceso a un recurso.
La estructura del software mediador 1201 puede ser según se ilustra en la Figura 8 o en la Figura 9.
El software mediador 1201 en esta forma de realización, puede ser un aparato independiente que funcione con el dispositivo M2M para realizar operaciones de gestión de dispositivos o puede establecerse, además, en el dispositivo M2M como un componente del dispositivo M2M y funcionar con el DMC del dispositivo M2M para realizar operaciones de gestión de dispositivos. Puede deducirse que, cuando solamente se requiere la gestión de dispositivos, el sistema M2M dado a conocer en esta forma de realización puede no tener una plataforma M2M.
Además, para la diferencia entre los software mediadores en esta forma de realización, existen además otras diversas formas de estructura. La Figura 13 ilustra el sistema M2M con otra estructura. Este sistema incluye: una plataforma M2M 1301 y un dispositivo M2M 1302, en donde la plataforma M2M tiene un servidor DMS 1303 y un software mediador de plataforma 1304 y el dispositivo M2M 1302 tiene un DMC 1305 y un software mediador de dispositivo 1306, en donde:
El software mediador de dispositivos y el DMC de cliente de gestión de dispositivos del dispositivo M2M puede adoptar un diseño separado y el software mediador de dispositivos está conectado al DMC utilizando una interfaz de acceso local abierta por el DMC; o bien, el software mediador de dispositivos y el DMC adoptan un diseño integrado; además, o el software mediador de dispositivos y el servidor DMS adoptan un diseño integrado y el software mediador de dispositivos está conectado al DMC utilizando una interfaz de acceso de protocolo OMA-DM.
15
25
35
45
55
65
E11777207
17-07-2015
El software mediador de plataforma y el servidor DMS en la plataforma M2M pueden adoptar un diseño integrado o bien, el software mediador de plataforma y el DMS en la plataforma M2M o separados de la plataforma M2M están conectados utilizando una interfaz de acceso local abierta por el servidor DMS. Esta forma de realización no restringe una relación de conexión entre el software mediador de plataforma/software mediador de dispositivos y otros componentes en el sistema. La forma de conexión específica puede establecerse según se requiera en conformidad con las condiciones reales.
En esta forma de realización, el software mediador de plataforma 1304 y el software mediador de dispositivos 1306 cooperan para realizar las funciones del software mediador en el sistema que se ilustra en la Figura 12. El procedimiento operativo de este sistema es como sigue:
El software mediador de dispositivos 1306 envía la información de MO sobre el dispositivo M2M descrita en la forma de un documento XML al software mediador de plataforma por anticipado, y crea la información de MO como un recurso de datos de MO en el software mediador de plataforma. El software mediador de plataforma 1304 recibe la demanda de acceso a un recurso enviada por la aplicación de M2M, encuentra el dispositivo objetivo correspondiente en conformidad con el URI en la demanda de acceso a un recurso, convierte la demanda de acceso a un recurso utilizando un mapeado de correspondencia preestablecido entre la demanda de acceso a un recurso MO y la información de MO en una orden DM, determinar la información de MO correspondiente a los recursos de datos de MO accedidos en conformidad con el mapeado de correspondencia preestablecido entre los datos de recursos de MO y la información de MO, controla el servidor DMS 1303 para establecer una sesión DM entre el servidor DMS 1303 y el DMC 1305 utilizando el protocolo de interfaz OMA-DM y envía la orden DM utilizando la sesión al DMC 1305 para su ejecución. A continuación, los datos de resultados después de la ejecución se reenvían al software mediador de plataforma 1304. El software mediador de plataforma 1304 lo reenvía a la aplicación de M2M.
Conviene señalar que, en otras formas de realización, el servidor DMS y el DMC no están directamente conectados y la sesión entre ambos se pone en práctica en la comunicación entre el software mediador de plataforma que conecta el servidor DMS y el software mediador de dispositivo que conecta el DMC.
Los dispositivos M2M en cada una de las formas de realización precedentes pueden ser varios dispositivos y aparatos, tales como sensores, microcontroladores, terminales móviles o fijos y pasarelas, que soportan las capacidades de gestión de dispositivos distantes, mientras que las aplicaciones de M2M pueden ser diversas aplicaciones personales o industriales relacionadas con la comunicación máquina a máquina, tales como la lectura de un medidor de electricidad y tráfico inteligente.
Se entiende fácilmente que las soluciones dadas a conocer en la presente invención pueden desarrollarse, además, realmente en otros sistemas de comunicaciones que necesitan poner en práctica la gestión de dispositivos utilizando protocolos de interfaz de acceso a recursos, pero no están restringidos al campo de las aplicaciones M2M.
Conviene señalar que en la plataforma M2M y el dispositivo que tienen los software mediadores anteriormente descritos en esta forma de realización del sistema están en su totalidad cubiertos por el alcance de protección de la presente invención.
Todas las formas de realización describen la presente invención utilizando el método progresivo. Cada forma de realización describe solamente la diferencia con respecto a otras formas de realización. Para las partes similares entre todas las formas de realización, puede hacerse referencia a las partes pertinentes. El aparato dado a conocer en la forma de realización está relacionado con el método dado a conocer en las formas de realización y por lo tanto, se describe en dichas formas de realización. Para la parte asociada puede hacerse referencia a la descripción en las formas de realización del método.
Un experto en esta técnica puede observar, además, que las unidades, algoritmos y etapas en cada realización ejemplo que se describe en las formas de realización públicas de la presente invención pueden ponerse en práctica mediante hardware electrónico, programas informáticos de ordenador o una de sus combinaciones. Para describir claramente la capacidad de intercambio del hardware y del software, la composición y las etapas de cada realización ejemplo se suelen describir en conformidad con las funciones en la descripción precedente. Si estas funciones se ejecutan, o no, utilizando hardware o software depende de las aplicaciones específicas y de las restricciones de diseño de las soluciones técnicas. Un experto en esta técnica puede utilizar diferentes métodos para poner en práctica las funciones descritas para cada aplicación específica. Sin embargo, dicha puesta en práctica no debe considerarse más allá del alcance de la presente invención.
Las etapas de los métodos o algoritmos descritos en las formas de realización públicas de la presente invención pueden ponerse en práctica directamente mediante hardware, módulos de software ejecutados por el procesador o una combinación de ambos. El módulo de software puede instalarse en una memoria de acceso aleatorio (RAM), una memoria de solamente lectura (ROM), memoria ROM eléctricamente programable, memoria ROM eléctricamente borrable y programable, registro, disco duro, disco móvil, CD-ROM o cualquier otra forma de soporte de memorización conocido para el dominio técnico.
E11777207
17-07-2015
La descripción precedente dada a conocer en las formas de realización permite a un experto en esta técnica poner en práctica o utilizar la presente invención. Múltiples modificaciones a estas formas de realización son evidentes para un experto en esta técnica. El principio general definido en la presente invención puede ponerse en práctica en otras formas de realización de la presente invención.
Claims (8)
- 5152535455565REIVINDICACIONES1. Un método de gestión de dispositivo, que comprende:la recepción (S21), por un software mediador, middleware, instalado en una plataforma de comunicaciones máquina a máquina, M2M, en una demanda de caso a un recurso enviada por una aplicación de comunicaciones M2M utilizando una interfaz de acceso a recursos, en donde la demanda de acceso a un recurso comprende: un identificador uniforme de recurso, URI, que se utiliza para indicar una posición de memorización de un recurso de datos de un objeto de gestión, MO, al que se realiza el acceso y el recurso de datos de objeto MO accedido se crea en la plataforma de comunicaciones M2M y corresponde a información de objeto MO en un dispositivo de comunicaciones M2M y el identificador URI es asignado al recurso de datos de objeto MO al que se tiene acceso;la conversión (S22), por el software mediador instalado en la plataforma de comunicaciones M2M, en función de un mapeado de correspondencia preestablecido entre la demanda de acceso del recurso de datos de objeto MO y una orden de gestión de dispositivo, DM, de la demanda de acceso a un recurso en una orden de gestión DM correspondiente así como la determinación (S22) en función del mapeado de correspondencia preestablecido entre el recurso de datos de objeto MO y la información de objeto MO, de la información de objeto MO correspondiente al recurso de datos de objeto MO al que se tiene acceso; yel envío (S23) por el software mediador instalado en la plataforma de comunicaciones M2M, de la orden de gestión DM a un dispositivo objetivo que corresponde al identificador URI con el fin de gestionar la información de objeto MO correspondiente al recurso de datos de objeto MO al que se tiene acceso, en donde el dispositivo objetivo es un dispositivo de comunicaciones M2M.
- 2. El método según la reivindicación 1, que comprende, además:la recepción de datos de resultados generados y reenviados por el dispositivo objetivo después de que el dispositivo objetivo haya ejecutado la orden DM; yel reenvío de los datos de resultados para dar respuesta a la demanda de acceso a un recurso.
-
- 3.
- El método según la reivindicación 1 o 2, en donde un procedimiento para el envío de la orden de gestión DM al dispositivo objetivo comprende:
la determinación de si existe una sesión entre un servidor de gestión, DMS y el dispositivo objetivo; si existe la sesión entre el servidor de gestión DMS y el dispositivo objetivo, el control del servidor DMS para enviar la orden DM al dispositivo objetivo utilizando la sesión; si no existe la sesión entre el servidor de gestión DMS y el dispositivo objetivo, el envío de una orden de control de sesión al servidor DMS para controlar el DMS para establecer una sesión con el dispositivo objetivo y para enviar la orden DM al dispositivo objetivo utilizando la sesión establecida. -
- 4.
- El método según cualquiera de las reivindicaciones 1 a 3, en donde un tipo de demanda de acceso a un recurso comprende: una demanda de acceso a un recurso de base, en donde los tipos de la demanda de acceso a un recurso de base comprenden: una demanda de recuperación, una demanda de sustitución y una demanda de supresión.
-
- 5.
- El método según cualquiera de las reivindicaciones 1 a 4, en donde los tipos de la demanda de acceso a un recurso comprenden, además: una demanda de acceso a un recurso extendida utilizando un protocolo por enlace de hipertexto, en donde los tipos de la demanda de acceso a un recurso extendida comprenden: una demanda de ejecución, una demanda de copia, una demanda de operación atómica, una demanda de operación atómica secuencial, una demanda de informe asíncrono, una demanda para una operación de un grupo de dispositivos, una demanda de operación condicional y una demanda de operación condicional combinada.
-
- 6.
- Una plataforma de comunicaciones máquina a máquina, M2M, que tiene un software mediador, middleware, en donde el software mediador comprende: una unidad de recepción de demanda de acceso a un recurso (81), configurada para recibir una demanda de acceso a un recurso enviada por una aplicación de M2M utilizando una interfaz de acceso a un recurso, en donde la demanda de acceso a un recurso incluye: un identificador uniforme de recurso, URI, que se utiliza para indicar una posición de memorización de un recurso de datos de objeto de gestión, MO, accedido y el recurso de datos de objeto MO accedido se crea en la plataforma M2M y corresponde a la información de acceso MO en un dispositivo de M2M y el identificador URI se asigna al recurso de datos de acceso MO accedido;
una unidad de conversión de orden de control (82), configurada para convertir, en conformidad con el mapeado de correspondencia preestablecido entre la demanda de acceso a un recurso del recurso de datos de objeto MO y una orden DM de gestión de dispositivos, la demanda de acceso a un recurso en una orden DM correspondiente y para determinar, en conformidad con el mapeado de correspondencia preestablecido entre el recurso de datos de objeto MO y la información de objeto MO, con la información de MO correspondiente al recurso de datos de objeto MO accedido; y19una unidad de envío de orden de control (83), configurada para enviar la orden DM a un dispositivo objetivo correspondiente al identificador URI para gestionar la información de objeto MO correspondiente al recurso de datos de objeto MO accedido, en donde el dispositivo objetivo es el dispositivo M2M.5 7. La plataforma de comunicaciones M2M según la reivindicación 6, en donde el software mediador comprende, además:una unidad de recepción de datos de resultados (94), configurada para recibir datos de resultados generados y reenviados por el dispositivo objetivo después de que el dispositivo objetivo ejecute la orden DM; y10 una unidad de reenvío de datos de resultados (95), configurada para reenviar los datos de resultados a un extremo emisor de la demanda de acceso a un recurso. - 8. La plataforma de comunicaciones M2M según la reivindicación 6 o 7, en donde la unidad de envío de orden de 15 control, comprende:una unidad de determinación (1001), configurada para determinar si existe, o no, una sesión entre un servidor de gestión DMS y el dispositivo objetivo;20 una unidad de establecimiento de sesión (1002), configurada para controlar el servidor DMS para establecer una sesión con el dispositivo objetivo cuando no existe la sesión entre el servidor DMS y el dispositivo objetivo; yuna unidad de envío (1003), configurada para enviar la orden DM al dispositivo objetivo utilizando la sesión establecida.25 9. Un sistema de comunicaciones máquina a máquina, M2M, que comprende: un dispositivo de comunicaciones M2M y una plataforma de comunicaciones M2M que tiene un software mediador, en donde:el software mediador está configurado para: recibir una demanda de acceso a un recurso enviada por una aplicación de M2M utilizando una interfaz de acceso a un recurso, en donde la demanda de acceso a un recurso incluye: un 30 identificador uniforme de recursos, URI, que se utiliza para indicar una posición de memorización de un recurso de datos de objeto de gestión, MO, accedido y el recurso de datos de objeto MO accedido se crea en la plataforma M2M y corresponde a la información de objeto MO en el dispositivo M2M y el identificador URI se asigna al recurso de datos de objeto MO accedido; para convertir, en función del mapeado de correspondencia preestablecido entre la demanda de acceso a un recurso del recurso de datos de objeto MO y una orden de gestión de dispositivo, DM, la demanda de35 acceso a un recurso en una orden DM correspondiente y para determinar, en conformidad con el mapeado de correspondencia preestablecido entre el recurso de datos de objeto MO y la información de MO, la información de objeto de MO correspondiente al recurso de datos de objeto MO accedido y para enviar la orden DM a un dispositivo objetivo correspondiente al identificador URI para gestionar la información de objeto MO correspondiente al recurso de datos de objeto MO accedido; y40 el dispositivo de comunicaciones M2M está configurado para recibir y ejecutar la orden DM, para obtener datos de resultados y para reenviar los datos de resultados al software mediador.
- 10. El sistema según la reivindicación 9, en donde el software mediador comprende: un software mediador de45 plataforma establecido en la plataforma M2M y un software mediador de dispositivo establecido en el dispositivo M2M y el software mediador de plataforma y el software mediador de dispositivo cooperan para poner en práctica las funciones del software mediador.505520
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2010105058782A CN102136933B (zh) | 2010-09-30 | 2010-09-30 | 设备管理方法、中间件及机器通信平台、设备和系统 |
| CN201010505878 | 2010-09-30 | ||
| PCT/CN2011/074272 WO2011137788A1 (zh) | 2010-09-30 | 2011-05-18 | 设备管理方法、中间件及机器通信平台、设备和系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2543018T3 true ES2543018T3 (es) | 2015-08-14 |
Family
ID=44296594
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES11777207.9T Active ES2543018T3 (es) | 2010-09-30 | 2011-05-18 | Método de gestión de dispositivo, software mediador y plataforma, dispositivo y sistema de comunicaciones de máquina a máquina |
| ES15157070.2T Active ES2625781T3 (es) | 2010-09-30 | 2011-05-18 | Método de gestión de dispositivo, programa informático intermedio y plataforma de comunicaciones máquina a máquina, dispositivo y sistema |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES15157070.2T Active ES2625781T3 (es) | 2010-09-30 | 2011-05-18 | Método de gestión de dispositivo, programa informático intermedio y plataforma de comunicaciones máquina a máquina, dispositivo y sistema |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US9331953B2 (es) |
| EP (2) | EP2914022B1 (es) |
| CN (1) | CN102136933B (es) |
| DK (1) | DK2914022T3 (es) |
| ES (2) | ES2543018T3 (es) |
| HU (1) | HUE025644T2 (es) |
| PT (1) | PT2523528E (es) |
| WO (1) | WO2011137788A1 (es) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102790781B (zh) * | 2011-05-17 | 2015-10-28 | 南京中兴新软件有限责任公司 | 一种中间件、带行业应用中间件的m2m系统及其应用方法 |
| US8682851B2 (en) * | 2011-11-01 | 2014-03-25 | Google Inc. | Device specific folders for bookmark synchronization |
| CN103200209B (zh) | 2012-01-06 | 2018-05-25 | 华为技术有限公司 | 成员资源的访问方法、群组服务器和成员设备 |
| US8953478B2 (en) * | 2012-01-27 | 2015-02-10 | Intel Corporation | Evolved node B and method for coherent coordinated multipoint transmission with per CSI-RS feedback |
| CN103297468B (zh) * | 2012-02-29 | 2017-12-01 | 华为技术有限公司 | 针对群组资源的操作方法、群组服务器 |
| FI125254B (en) * | 2012-07-17 | 2015-08-14 | Arm Finland Oy | Method and device in a network service system |
| CN103596117B (zh) * | 2012-08-13 | 2017-12-15 | 华为终端（东莞）有限公司 | 发现机器对机器业务的方法、设备及系统 |
| US8938731B2 (en) * | 2012-10-24 | 2015-01-20 | Telefonaktiebolaget L M Ericsson (Publ) | Cost optimization for firmware updates for globally mobile machine-to-machine devices |
| CN103781100B (zh) * | 2012-10-26 | 2019-08-13 | 中兴通讯股份有限公司 | 终端外设的策略控制方法和装置 |
| CN103944950A (zh) * | 2013-01-22 | 2014-07-23 | 中兴通讯股份有限公司 | 基于tnds的终端设备固件优化方法、客户端及系统 |
| ES2735021T3 (es) | 2013-02-20 | 2019-12-13 | Huawei Tech Co Ltd | Método y dispositivo de activación de operación para comunicaciones máquina a máquina |
| US20140337753A1 (en) * | 2013-05-07 | 2014-11-13 | Brian McKellar | System and method for editing the appearance of a user interface |
| WO2014181941A1 (ko) * | 2013-05-09 | 2014-11-13 | 전자부품연구원 | 개방형 ｍ２ｍ 시스템 및 그의 리소스 관리와 인터페이스 방법 |
| CN104427457B (zh) * | 2013-08-20 | 2019-05-10 | 中兴通讯股份有限公司 | 面向m2m应用和网络的业务平台接口装置及方法 |
| CN104579889B (zh) * | 2013-10-16 | 2018-03-09 | 华为技术有限公司 | 一种用于调用网络功能的方法及装置 |
| CN103561014A (zh) * | 2013-10-29 | 2014-02-05 | 深圳创维数字技术股份有限公司 | 一种资源访问处理方法及控制服务器 |
| EP3054625B1 (en) * | 2013-10-31 | 2021-09-01 | Huawei Technologies Co., Ltd. | M2m data query and scheduling method, query and scheduling device and system |
| WO2015080401A1 (ko) * | 2013-12-01 | 2015-06-04 | 엘지전자 주식회사 | 무선 통신 시스템에서 특정 리소스의 관리를 위한 방법 및 장치 |
| CN105025459B (zh) * | 2014-04-24 | 2020-06-16 | 中兴通讯股份有限公司 | 一种资源通告方法和系统、本地cse以及远程cse |
| CN105100002B (zh) * | 2014-05-05 | 2019-05-07 | 中兴通讯股份有限公司 | 属性的操作方法及装置 |
| EP3998758B1 (en) * | 2014-06-18 | 2024-03-20 | Intelligent Platforms, LLC | Apparatus and method for interactions with industrial equipment |
| KR101964532B1 (ko) | 2014-07-18 | 2019-04-01 | 콘비다 와이어리스, 엘엘씨 | 복수의 디바이스들 상에서 복수의 명령들의 실행을 허용하는 것에 의해 강화되는, m2m 시스템에서의 서비스 레이어와 관리 레이어 사이의 동작들 |
| KR20170074861A (ko) * | 2014-10-27 | 2017-06-30 | 엘지전자 주식회사 | 무선 통신 시스템에서 제어 메시지의 동작을 보장하기 위한 방법 및 이를 위한 장치 |
| CN105610880B (zh) * | 2014-11-10 | 2020-06-16 | 中兴通讯股份有限公司 | M2m通信架构、信息交互方法及装置 |
| US20160380904A1 (en) * | 2015-06-25 | 2016-12-29 | Trifectix, Inc. | Instruction selection based on a generic directive |
| WO2017014381A1 (ko) * | 2015-07-17 | 2017-01-26 | 엘지전자 주식회사 | 무선 통신 시스템에서 자원의 동기를 유지하기 위한 방법 및 이를 위한 장치 |
| US10797935B2 (en) * | 2015-09-02 | 2020-10-06 | Convida Wireless, Llc | Methods and apparatus for enhancing native service layer device management functionality |
| US10637678B2 (en) | 2015-09-24 | 2020-04-28 | Intel Corporation | Facilitating portable, reusable, and shareable internet of things (IoT)-based services and resources |
| CN108027739A (zh) | 2015-09-25 | 2018-05-11 | 英特尔公司 | 共享iot资源的异构分布式运行时代码 |
| US10693962B1 (en) * | 2015-12-18 | 2020-06-23 | EMC IP Holding Company LLC | Language and mechanism for modeling and exporting storage platform topologies, attributes, and behaviors |
| CN106919550B (zh) | 2015-12-25 | 2021-09-07 | 华为技术有限公司 | 一种语义验证的方法和装置 |
| US20170187831A1 (en) * | 2015-12-29 | 2017-06-29 | Itron, Inc. | Universal Abstraction Layer and Management of Resource Devices |
| US10129852B2 (en) * | 2016-06-01 | 2018-11-13 | Lg Electronics Inc. | Method for broadcasting to unspecified entity in wireless communication system and device for the same |
| US10298996B2 (en) | 2016-08-18 | 2019-05-21 | At&T Intellectual Property I, L.P. | Satellite TV user community smart device monitoring and management |
| CN109997114B (zh) * | 2016-10-07 | 2023-09-29 | 康维达无线有限责任公司 | 用于通用互通和可扩展性的服务层资源管理 |
| CN108089450B (zh) * | 2016-11-23 | 2021-04-27 | 阿里巴巴集团控股有限公司 | 智慧建筑控制方法、装置及系统 |
| CN108206992B (zh) * | 2017-12-05 | 2022-07-15 | 中兴通讯股份有限公司 | 一种多播组信息的传递方法、装置和系统 |
| CN108199952A (zh) * | 2018-01-08 | 2018-06-22 | 赵宇航 | 一种基于社交软件的信息发送方法及装置 |
| CN108494598A (zh) * | 2018-03-27 | 2018-09-04 | 北京邦邦共赢网络科技有限公司 | 一种应用服务的配置方法和装置 |
| CN109190969B (zh) * | 2018-08-29 | 2021-06-11 | 山东矩阵软件工程股份有限公司 | 称重设备管控方法、系统、称重设备管理中间件及介质 |
| CN112422376A (zh) * | 2020-10-15 | 2021-02-26 | 招商华软信息有限公司 | 非标准化设备自动化接入云平台的方法、电子设备、存储介质 |
| CN112566819B (zh) * | 2020-11-20 | 2022-09-16 | 华为技术有限公司 | 一种访问io设备的方法及装置 |
| CN115426335B (zh) * | 2021-05-13 | 2023-10-27 | 中移(上海)信息通信科技有限公司 | 一种信息交互方法、装置、设备及系统 |
| CN113656484A (zh) * | 2021-08-31 | 2021-11-16 | 平安医疗健康管理股份有限公司 | 数据库的访问系统及方法、装置、电子设备、存储介质 |
| CN115174386B (zh) * | 2022-06-30 | 2023-06-16 | 中国联合网络通信集团有限公司 | 配置访问策略应用方法、uicc、终端及系统 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8762547B2 (en) * | 2005-04-29 | 2014-06-24 | Sap Ag | Shared memory implementations for session data within a multi-tiered enterprise network |
| US7966402B2 (en) * | 2005-06-28 | 2011-06-21 | Hewlett-Packard Development Company, L.P. | Switch to selectively couple any of a plurality of video modules to any of a plurality of blades |
| US20070093243A1 (en) | 2005-10-25 | 2007-04-26 | Vivek Kapadekar | Device management system |
| CN101047707A (zh) * | 2006-03-30 | 2007-10-03 | 华为技术有限公司 | 发起设备能力信息协商的方法及系统 |
| DE602007006779D1 (de) * | 2006-04-20 | 2010-07-08 | Ibm | Einrichtungsverwaltungssystem zum fernzugang zu endgeräten |
| US8862746B2 (en) * | 2006-05-17 | 2014-10-14 | Sonim Technologies, Inc. | Systems and methods for integrating applications on user equipment utilizing special URI control messages |
| CN101083537B (zh) * | 2006-05-31 | 2011-10-05 | 华为技术有限公司 | 一种实现设备管理的方法、装置和系统 |
| EP2025095A2 (en) | 2006-06-08 | 2009-02-18 | Hewlett-Packard Development Company, L.P. | Device management in a network |
| US7860851B2 (en) * | 2008-01-30 | 2010-12-28 | Oracle International Corporation | Tiered processing for XDM and other XML databases |
| US20090204578A1 (en) * | 2008-02-12 | 2009-08-13 | Microsoft Corporation | Targeted queries using an oma dm protocol |
| JP5178539B2 (ja) * | 2008-04-04 | 2013-04-10 | キヤノン株式会社 | 情報処理装置、情報処理装置の制御方法、セッション管理システム並びにプログラム |
| US8886772B2 (en) * | 2008-07-31 | 2014-11-11 | Koninklijke Kpn N.V. | Method and system for remote device management |
| EP2192807B1 (en) * | 2008-12-01 | 2012-10-03 | Vodafone Holding GmbH | Access control for M2M ("machine-to-machine") devices in a mobile communication network |
| CN101477535B (zh) * | 2008-12-30 | 2011-06-08 | 华为技术有限公司 | 网页页面的显示方法、请求的处理方法、装置和系统 |
| CN101730123A (zh) * | 2009-12-22 | 2010-06-09 | 中兴通讯股份有限公司 | M2m平台系统、汇接终端以及终端控制方法 |
| US9037730B2 (en) * | 2010-02-19 | 2015-05-19 | Telefonaktiebolaget L M Ericsson (Publ) | Apparatuses and methods for handling machine-to-machine communications |
| US8942191B2 (en) * | 2010-05-03 | 2015-01-27 | Mformation Software Technologies Llc | Providing dynamic group subscriptions for M2M device communication |
| US9009810B2 (en) * | 2010-05-28 | 2015-04-14 | Nokia Corporation | Method and apparatus for providing reactive authorization |
| US8312128B2 (en) * | 2010-07-30 | 2012-11-13 | Hewlett-Packard Development Company, L.P. | Identification of management information base object identifiers supported by a managed device |
-
2010
- 2010-09-30 CN CN2010105058782A patent/CN102136933B/zh active Active
-
2011
- 2011-05-18 WO PCT/CN2011/074272 patent/WO2011137788A1/zh active Application Filing
- 2011-05-18 EP EP15157070.2A patent/EP2914022B1/en active Active
- 2011-05-18 DK DK15157070.2T patent/DK2914022T3/en active
- 2011-05-18 ES ES11777207.9T patent/ES2543018T3/es active Active
- 2011-05-18 PT PT117772079T patent/PT2523528E/pt unknown
- 2011-05-18 ES ES15157070.2T patent/ES2625781T3/es active Active
- 2011-05-18 HU HUE11777207A patent/HUE025644T2/en unknown
- 2011-05-18 EP EP20110777207 patent/EP2523528B1/en active Active
-
2013
- 2013-04-01 US US13/854,797 patent/US9331953B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP2523528A4 (en) | 2013-04-17 |
| ES2625781T3 (es) | 2017-07-20 |
| EP2914022A1 (en) | 2015-09-02 |
| EP2523528A1 (en) | 2012-11-14 |
| US9331953B2 (en) | 2016-05-03 |
| CN102136933A (zh) | 2011-07-27 |
| CN102136933B (zh) | 2013-08-28 |
| EP2914022B1 (en) | 2017-03-08 |
| US20130219064A1 (en) | 2013-08-22 |
| DK2914022T3 (en) | 2017-06-06 |
| HUE025644T2 (en) | 2016-04-28 |
| PT2523528E (pt) | 2015-09-01 |
| EP2523528B1 (en) | 2015-04-22 |
| WO2011137788A1 (zh) | 2011-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2543018T3 (es) | Método de gestión de dispositivo, software mediador y plataforma, dispositivo y sistema de comunicaciones de máquina a máquina | |
| KR101950122B1 (ko) | 경량 기기 간 프로토콜을 디바이스 관리 프로토콜과 상호연동하기 | |
| Silva et al. | Management platforms and protocols for internet of things: A survey | |
| JP6342014B2 (ja) | サービスイネーブラ機能 | |
| TWI612838B (zh) | 用以致能使用不同通訊協定之裝置間之通訊的系統、方法及／或設備 | |
| ES2528280T3 (es) | Método, equipo y sistema para adquirir y proporcionar información de configuración de función CPE | |
| CN113542365B (zh) | 基于多场景应用的端边物联网平台架构 | |
| KR102094041B1 (ko) | IoT 단말 간 실시간으로 자율적인 상호작용을 위한 RDF 그래프 기반의 Semantic 엔진을 구비한 시스템 | |
| US20220109980A1 (en) | Template-based registration | |
| WO2021068959A1 (zh) | 数据处理方法和装置 | |
| US20220103634A1 (en) | Device registration mechanism | |
| TWI540861B (zh) | 管理系統與管理方法 | |
| KR101399800B1 (ko) | 인스턴스 호스팅을 위한 서비스 제공 방법 및 서비스 제공 시스템 | |
| KR20210128096A (ko) | 사물인터넷 플랫폼 간 연동 방법 및 장치 | |
| US11438230B2 (en) | Template-based registration of devices | |
| US20220021741A1 (en) | Electronic device subscription | |
| Montanari et al. | Rest assured, we manage your microgrid | |
| Cucore | Internet of Things Proof of Concept |