BR102014003580B1 - Método para habilitar a arquitetura hierárquica de gateways para gerenciamento de dispositivos - Google Patents

Método para habilitar a arquitetura hierárquica de gateways para gerenciamento de dispositivos Download PDF

Info

Publication number
BR102014003580B1
BR102014003580B1 BR102014003580-0A BR102014003580A BR102014003580B1 BR 102014003580 B1 BR102014003580 B1 BR 102014003580B1 BR 102014003580 A BR102014003580 A BR 102014003580A BR 102014003580 B1 BR102014003580 B1 BR 102014003580B1
Authority
BR
Brazil
Prior art keywords
gateways
gateway
hierarchical architecture
device management
gwmo
Prior art date
Application number
BR102014003580-0A
Other languages
English (en)
Other versions
BR102014003580A2 (pt
Inventor
Antonio Henrique Barbosa Postal
Original Assignee
Samsung Eletrônica da Amazônia Ltda.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Samsung Eletrônica da Amazônia Ltda. filed Critical Samsung Eletrônica da Amazônia Ltda.
Priority to BR102014003580-0A priority Critical patent/BR102014003580B1/pt
Priority to US14/300,763 priority patent/US9654547B2/en
Publication of BR102014003580A2 publication Critical patent/BR102014003580A2/pt
Publication of BR102014003580B1 publication Critical patent/BR102014003580B1/pt

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/044—Network management architectures or arrangements comprising hierarchical management structures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

MÉTODO PARA HABILITAR A ARQUITETURA HIERÁRQUICA DE GATEWAYS PARA GERENCIAMENTO DE DISPOSITIVOS. A presente patente de invenção está relacionada ao campo da tecnologia das telecomunicações e é aplicável ao sistema de gerenciamento remoto composto por servidor e vários dispositivos que estão conectados através de um ou mais gateways em uma Arquitetura Hierárquica de Gateways multi-nível, com estrutura em árvore. Mais especificamente, a presente patente especifica um método que habilita uma nova funcionalidade exigida para o OMA-DM Gateway MO (GwMO): o suporte para Arquitetura Hierárquica de Gateways.

Description

Campo da Invenção
[0001] A presente patente de invenção está relacionada ao campo da tecnologia das telecomunicações e é aplicável ao sistema de gerenciamento remoto composto por servidor e vários dispositivos que estão conectados através de um ou mais gateways em uma Arquitetura Hierárquica de Gateways multi-nível, com estrutura em árvore. Mais especificamente, a presente patente especifica um método que habilita uma nova funcionalidade exigida para o OMA-DM Gateway MO (GwMO): o suporte para Arquitetura Hierárquica de Gateways.
Antecedentes da Invenção
[0002] Gateway MO V1.0 [GwMO_TS_V10] introduziu o conceito de DM Gateway (Device Management Gateway): Uma entidade que facilita a interação entre um servidor de gerenciamento e um cliente de gerenciamento, pelo menos um dos quais executa OMA-DM, em situações em que não é possível a interação direta e sem ajuda entre o servidor de gerenciamento e o cliente de gerenciamento. Os documentos citados na seção referência são incorporador por referência em sua totalidade.
[0003] GwMO V1.0 [GwMO_TS_V10] trouxe várias vantagens, se comparado com a arquitetura tradicional envolvendo apenas o Servidor DM e Cliente DM, e veio aliviar o Servidor DM de gerenciar cada Dispositivo Terminal individualmente. Graças ao GwMO V1.0, o DM Gateway apresentado é capaz de gerenciar os Dispositivos Terminais que estão atrás dele, em nome do Servidor.
[0004] As seguintes funcionalidades são cobertas pelo GwMO V1.0: - Diversos Dispositivos Terminais podem ser organizados e gerenciados em conjunto como um Grupo de Dispositivos específico. - A distribuição dos comandos DM originados pelo Servidor para vários Dispositivos Terminais que estão associados ao Gateway, conhecido como “Fanout de Comando”. O Servidor envia comandos de gerenciamento ao Gateway e o Gateway encaminha os comandos para um ou vários Dispositivos Terminais que foram pré-agrupados em um Grupo de Dispositivos específico. - Após a execução de um “Fanout de Comando”, a coleta das respostas de vários Dispositivos Terminais associados ao Gateway em uma resposta única que é enviada de volta para o Servidor, conhecido como “Agregação de Resposta”. Após o DM Gateway receber as respostas enviadas pelo(s) Dispositivo(s) Final(is), o Gateway pode notificar o Servidor sobre o status de conclusão do comando, ou pode enviar para o Servidor DM a resposta agregada do comando, gerada a partir de vários Dispositivos Terminais. - O DM Gateway é capaz de distribuir imagens de software para os Dispositivos Terminais associados àquele Gateway em nome do Servidor: o Servidor pode entregar a imagem para o Gateway e o Gateway distribui essa imagem para diversos Dispositivos Terminais especificados por um Grupo de Dispositivos.
[0005] Contudo, o GwMO V1.0 [GwMO_TS_V10], com apenas um nível de DM Gateway entre o servidor e o cliente (conforme representado na Figura 1), apresenta algumas limitações em termos de flexibilidade e escalabilidade.
[0006] O Documento de Requisito (RD) do GwMO V1.1 [GwMO_RD_V11] introduziu a definição e os requisitos para uma arquitetura multi-nível chamada Arquitetura Hierárquica. A Arquitetura Hierárquica foi definida como uma estrutura em árvore multi-nível composta por um Servidor DM, DM Gateways e Dispositivos Terminais. Um servidor DM está localizado no topo da árvore. Os Dispositivos Terminais estão localizados na folha das ramificações. Os DM Gateways em cascata em ramificações entre um servidor DM e os Dispositivos Terminais. Ele pode endereçar grandes redes com um grande número de Dispositivos Terminais de forma escalável.
[0007] Na Arquitetura Hierárquica, definida por GwMO V1.1 RD, é possível que um DM Gateway pai esteja associado a um ou mais DM Gateways filhos, além dos Dispositivos Terminais previamente definidos em GwMO V1.0.
[0008] A introdução de Arquitetura Hierárquica adicionará escalabilidade e flexibilidade à versão prévia GwMO V1.0, como a seguir:
[0009] Escalabilidade: O número máximo de Dispositivos Terminais suportados não é mais limitado à capacidade de conexões de um DM Gateway. Isso é necessário para suportar grandes redes como redes M2M (comunicação Machine-to-Machine), tais como Power-Grids envolvendo milhares ou milhões de dispositivos. Por exemplo, em uma Arquitetura Hierárquica em uma forma de árvore com 3 níveis de Gateways, onde cada um pode gerenciar 50 conexões, até 2551 (1 + 50 + 50**2) DM Gateways seriam capazes de gerenciar até 125 mil Dispositivos Terminais (50 ** 3), em nome de um único servidor DM.
[00010] Flexibilidade: topologias de gerenciamento mais convenientes podem ser projetadas com base em critérios geográficos, funcionais ou organizacionais. Exemplo: Gateways dedicados a locais específicos (por exemplo, prédio, andar de um edifício, bloco, escritório), funções específicas (por exemplo, medição do consumo de energia, segurança, sistemas de refrigeração-aquecimento) ou organização (departamento, divisão, filiais).
[00011] A fim de suportar a Arquitetura Hierárquica GwMO V1.1, o Documento de Requisito (DR) [GwMO_RD_V11] definiu os requisitos para o GwMO ser capaz de gerir Gateways filhos, além dos Dispositivos Terminais normais conforme definido em V1.0: - Capacidade de configurar Alertas de Conexão e Desconexão específicos para DM Gateways filhos. - Capacidade de configurar avisos de Alertas específicos para DM Gateways filhos. - Capacidade de configurar o provisionamentos de imagens específicas para DM Gateways filhos. - Capacidade de configurar grupos específicos para DM Gateways Filhos, necessários para “Fanout de Comandos” para DM Gateway filhos e “Agregação da Resposta” de DM Gateway filhos.
[00012] O Documento de Arquitetura GwMO V1.0 (DA) havia previamente apresentado a interface entre o DM Gateway e seus Dispositivos Terminais associados (311). Alinhado com os requisitos de AH, o Documento de Arquitetura (AD) de GwMO V1.1 [GwMO_AD_V11] (Figura 4), estendeu a interface entre DM Gateway-Dispostivo Terminal (411) para uma nova relação e interface entre Gateway pai - Gateway filho (412). Devido a estas diferenças, um DM Gateway precisa agora saber a qual tipo de dispositivo ele está associado, em seu nível imediatamente mais baixo: um Dispositivo Terminal ou um DM Gateway filho, a fim de invocar/expor a interface adequada.
[00013] A fim de cumprir com os requisitos de acordo com [GwMO_RD_V11] e com o projeto de arquitetura de acordo com [GwMO_AD_V11], há a necessidade de se diferenciar no Inventário de Dispositivos (Device Inventory) que tipos de dispositivos um DM Gateway está associado, no nível imediatamente inferior: - Um Dispositivo Terminal. - Um DM Gateway filho.
[00014] Esta diferenciação, alavancada em objetos GwMO V1.0 previamente existentes, será capaz de habilitar os requisitos e os aspectos de Arquitetura para AH levantados acima, conforme será descrito a seguir em detalhes.
[00015] O estado da técnica apresenta algumas soluções que buscam satisfazer os requisitos e arquitetura para suporte à Arquitetura Hierárquica de Gateways.
[00016] O documento de patente WO2011021865, intitulado: TECHNIQUES FOR CONTROLLING GATEWAY FUNCTIONALITY TO SUPPORT DEVICE MANAGEMENT IN A COMMUNICATION SYSTEM, da Samsung Electronics, publicado em 24 de fevereiro de 2011, apresenta técnicas e algoritmos para controlar a funcionalidade de gateway de modo a poder suportar Device Management (OMA-DM), em um sistema de comunicação que inclui um servidor de DM, um dispositivo e somente um Gateway intermediário. O documento WO2011021865 inclui muitos aspectos de gestão que foram incorporados em OMA-DM GwMO V1.0, o qual especifica uma topologia “plana”, não-hierárquica, com apenas um nível de gateway. Ele difere da presente invenção, que aborda uma estrutura multi-nível, em árvore, a Arquitetura Hierárquica de Gateways, o GwMO V1.1, que se estende V1.0 de uma forma mais flexível e escalável. Além disso, a presente invenção apresenta um método e os meios para permitir e realizar a Arquitetura Hierárquica, aproveitando funcionalidades disponíveis em GwMO V1.0.
[00017] O documento de patente US2012059924, intitulado: METHOD AND APPARATUS FOR PERFORMING DEVICE MANAGEMENT THROUGH A GATEWAY DEVICE, AND DEVICE MANAGEMENT SERVER, da Huawei, publicado em 08 de março de 2012, também é baseado em OMA-DM e em um sistema incluindo um servidor de DM, um dispositivo e somente um DM Gateway no meio. Mais especificamente do que o referido WO2011021865, o documento US2012059924 propõe um método para que o servidor DM envie uma notificação através do DM Gateway. O documento US2012059924 abrange um aspecto específico de gerenciamento de dispositivos em uma topologia “plana”, não-hierárquica, com apenas um nível de dispositivo de gateway. Ele difere da presente invenção, que aborda uma estrutura multi-nível, em árvore, a Arquitetura Hierárquica de DM Gateways, e que propõe um método para habilitar os requisitos e o projeto previstos para a Arquitetura Hierárquica de DM Gateways.
[00018] O documento de patente WO2011122816, intitulado: TECHNIQUES FOR MANAGING DEVICES NOT DIRECTLY ACCESSIBLE TO DEVICE MANAGEMENT SERVER, da Samsung Electronics, publicado em 06 de outubro de 2011, também é baseado em OMA-DM e em uma topologia plana, não- hierárquica, que inclui um servidor de DM, um dispositivo e somente um DM Gateway intermediário. Ele aborda um tema específico relacionado à manipulação de uma mudança no endereço do dispositivo. Diferentemente, a presente invenção aborda uma estrutura multi-nível, em árvore, a Arquitetura Hierárquica de Gateways, e que propõe um método para realizar os requisitos e o projeto da Arquitetura Hierárquica de Gateways, aproveitando funcionalidades disponíveis em GwMO V1.0.
[00019] O documento de patente US2013130673, intitulado: METHOD, DEVICE, AND SYSTEM FOR DEVICE MANAGEMENT, da Huawei, publicado em 23 de maio de 2013, também é baseado em OMA-DM e em somente um nível de gateway em topologia plana, não-hierárquica, incluindo um servidor DM, um dispositivo e um único gateway DM intermediário. O método está relacionado com a configuração e gestão de um Uniform Resource Locator (URL) do lado da WAN como um identificador a ser usado pelo gateway no lado da LAN. Ele difere da presente invenção, que aborda uma estrutura multi-nível, em árvore, a Arquitetura Hierárquica de Gateways, e que propõe um método para habilitar os requisitos e o design previstos para a Arquitetura Hierárquica de DM Gateways.
[00020] O documento de patente WO2012174987, intitulado: TERMINAL MANAGEMENT METHOD AND DEVICE, da Huawei, publicado em 27 de dezembro de 2012, também é baseado em OMA-DM e em somente em um nível de gateway em topologia plana, não-hierárquica, incluindo um servidor DM, um dispositivo e somente um gateway DM intermediário. Ele aborda os aspectos da gestão em lote (“batch”) de dispositivos por um gateway, semelhante ao agrupamento de dispositivos, fanout de comando DM e agregação da resposta incorporado em GwMO V1.0. Ela difere da presente invenção, que aborda uma estrutura multi-nível, em árvore, a Arquitetura Hierárquica de Gateways, e que propõe um método para habilitar os requisitos e o design previstos para a Arquitetura Hierárquica de DM Gateways.
[00021] O documento de patente US2013294285, intitulado: METHOD FOR REMOTELY MANAGING A SENSOR NETWORK TOPOLOGY AND GATEWAY, da Huawei, publicado em 07 de novembro de 2013, também é baseado em OMA-DM e em somente em um nível de gateway em topologia plana, não-hierárquica, incluindo um servidor DM, um dispositivo - chamado de “sensor” no referido documento US2013294285 - e somente um gateway DM intermediário. Ele aborda como um novo dispositivo é projetado e notifica a sua conexão com o gateway, semelhante ao mecanismo de tratamento de Alerta incorporada em GwMO V1.0, em Gateway Config MO. O Gateway Config MO é usado para manter informações sobre a manipulação de diferentes tipos de Dispositivos Terminais pelo DM Gateway, com base em grupos de dispositivos especificados. . O referido documento US2013294285 difere da presente invenção, que aborda uma estrutura multi-nível, em árvore, a Arquitetura Hierárquica de Gateways, e que propõe um método para habilitar os requisitos e o design previstos para a Arquitetura Hierárquica de DM Gateways.
[00022] 7. O documento de patente EP1365557A2, intitulado: DEVICE-SHARING SYSTEM, DEVICE ADMINISTRATION TERMINAL, GATEWAY TERMINAL, AND METHOD FOR PROVIDING A DEVICE-SHARING SERVICE, da Seiko Epson, publicado em 26 de novembro de 2003, aborda um gateway doméstico interagindo com um ou mais gateways domésticos para o gerenciamento de dispositivos, tais como impressoras ou scanners, através da internet. Mas, diferentemente da presente invenção, esses gateways não são organizados em uma Arquitetura Hierárquica multi-nível, ou em árvore, onde um Gateway pai pode gerenciar um ou mais Gateways filhos, para maior flexibilidade e escalabilidade. US2013294285, intitulado: METHOD FOR REMOTELY MANAGING A SENSOR NETWORK TOPOLOGY AND GATEWAY, da Huawei, publicado em 07 de novembro de 2013, também é baseado em OMA-DM e em somente em um nível de gateway em topologia plana, não-hierárquica, incluindo um servidor DM, um dispositivo - chamado de “sensor” no referido documento US2013294285 - e somente um gateway DM intermediário. Ele aborda como um novo dispositivo é projetado e notifica a sua conexão com o gateway, semelhante ao mecanismo de tratamento de Alerta incorporada em GwMO V1.0, em Gateway Config MO. O Gateway Config MO é usado para manter informações sobre a manipulação de diferentes tipos de Dispositivos Terminais pelo DM Gateway, com base em grupos de dispositivos especificados. . O referido documento US2013294285 difere da presente invenção, que aborda uma estrutura multi-nível, em árvore, a Arquitetura Hierárquica de Gateways, e que propõe um método para habilitar os requisitos e o design previstos para a Arquitetura Hierárquica de DM Gateways. O documento de patente EP1365557A2 intitulado: DEVICE-SHARING SYSTEM, DEVICE ADMINISTRATION TERMINAL, GATEWAY TERMINAL, AND METHOD FOR PROVIDING A DEVICE-SHARING SERVICE, da Seiko Epson, publicado em 26 de novembro de 2003, aborda um gateway doméstico interagindo com um ou mais gateways domésticos para o gerenciamento de dispositivos, tais como impressoras ou scanners, através da internet. Mas, diferentemente da presente invenção, esses gateways não são organizados em uma Arquitetura Hierárquica multi-nível, ou em árvore, onde um Gateway pai pode gerenciar um ou mais Gateways filhos, para maior flexibilidade e escalabilidade.
Sumário da Invenção
[00023] A presente patente de invenção está relacionada com o campo da tecnologia das telecomunicações e com sistemas de gestão remotos compostos de um servidor conectado a diversos dispositivos através de gateways em uma Arquitetura Hierárquica multi-nível.
[00024] Sem perda de generalidade, a presente invenção está concentrada em uma modalidade em que o protocolo de gerenciamento entre o servidor de gerenciamento, Gateways e o Dispositivo Terminal é Open Mobile Alliance Device Management [OMA-DM], padrão aberto para gerenciamento de dispositivos. Mais especificamente, baseia-se em uma área de OMA-DM, o GwMO V1.0 (Gateway Management Object V1.0) [GwMO_TS_V10] e na funcionalidade de DM Gateway introduzida por GwMO.
[00025] Alavancando-se na funcionalidade previamente existente no GwMO V1.0, o método proposto na presente invenção habilita a funcionalidade de Arquitetura Hierárquica e Arquitetura do GwMO V1.1, através da introdução de um nó adicional no Inventário MO (“Inventory MO”), o qual é residente no DM Gateway, para cada entrada do registro de dispositivo (“Record entry”), o nó de “Tipo de Componente”( ou “ComponentType”) que é capaz de diferenciar o tipo de componentes está diretamente ligado a um DM Gateway específico, no nível imediatamente mais baixo: um componente Dispositivo Terminal ou um componente DM Gateway filho. Ao mesmo tempo, essa abordagem é flexível o suficiente para distinguir as diferentes classes de Dispositivos Terminais e as diferentes classes de DM Gateways Filhos, quando necessário.
[00026] Ao permitir essa diferenciação, o nó ComponentType introduzido pela presente invenção consegue alavancar-se na funcionalidade existente, a fim de habilitar os novos requisitos de Arquitetura Hierárquica especificados no Documento de Requisitos (RD) de GwMO V1.1 definidas para Arquitetura Hierárquica no Documento de Arquitetura (AD) de GwMO V1.1 [GwMO_AD_V11]: - Capacidade de gerenciar, via comandos DM, Dispositivos Terminais e/ou DM Gateways filhos via um ou mais DM Gateways intermediários em um galho de árvore (“hierarchical tree branch”). - Capacidade de configurar alertas Connect-Disconnect específicos para DM Gateways filhos. - Capacidade de configurar avisos de Alertas DM específicos para DM Gateways filhos. - Capacidade de configurar imagens de Software específicas de provisionamento para DM Gateways filhos. - Capacidade de configurar grupos específicos para DM Gateway filhos, necessário para “Fanout de Comando” e “Agregação da Resposta” de DM Gateways filhos.
Breve Descrição das Figuras
[00027] Os objetivos e vantagens da presente invenção ficarão mais claros através da seguinte descrição detalhada de uma concretização exemplar e não limitativa a partir das figuras a seguir, em que:
[00028] A Figura 1 apresenta GatewayMO V1.0 da técnica anterior, ou seja, a topologia com apenas um nível de DM Gateway entre o servidor DM e os Dispositivos Terminais - estrutura plana.
[00029] A Figura 2 apresenta GatewayMO V1.1 que é Arquitetura Hierárquica topologia em árvore contendo vários níveis de DM Gateway entre o servidor DM e os Dispositivos Terminais. Em AH, um DM Gateway pode estar diretamente associado a diversos DM Gateways filhos e / ou Dispositivos Terminais normais, em seu nível imediatamente mais baixo.
[00030] A Figura 3 apresenta a Arquitetura de Design (AD) para GwMO V1.0, em que um componente GwMO só pode ser associado a um componente GwMO cliente. existindo, por isso, apenas um tipo de interface: a interface DM Gateway - Dispositivo Terminal (311)
[00031] A Figura 4 apresenta a Arquitetura de Design (AD) para GwMO V1.1 - Arquitetura Hierárquica -, em que um componente GwMO pode ser associado a um componente Cliente GwMO ou a um componente GwMO filho, existindo, por isso, dois tipos de interface que devem ser diferenciados: a interface DM Gateway - Dispositivo Terminal (411) e a interface DM Gateway - DM Gateway (412) .
[00032] A Figura 5 apresenta o Inventory MO - Incluindo o nó adicional ComponentType para habilitar a Arquitetura Hierárquica.
[00033] A Figura 6 apresenta o Gateway Config MO.
[00034] A Figura 7 apresenta Fanout MO que também faz parte do GwMO e reside no componente DM Gateway.
Descrição Detalhada da Invenção
[00035] Como discutido anteriormente, a Arquitetura Hierárquica de DM Gateways (AH) proposta em GwMO V1.1 é capaz de aumentar a escalabilidade e flexibilidade em relação à versão anterior GwMO V1.0 [GwMO_TS_V10]. Assim, a presente invenção fornece um método para habilitar a Arquitetura Hierárquica de DM Gateways em V1.1. Esta invenção introduz o nó adicional ComponentType na árvore de gerenciamento de dispositivo GwMO V1.0 [DM_TND] e descreve como ComponentType é capaz de habilitar AH, alavancando-se na funcionalidade previamente existente em GwMO V1.0
[00036] A fim de apoiar a Arquitetura Hierárquica, os seguintes requisitos foram levantados em GwMO V1.1, para as seguintes áreas: - HLF - Alto Nível Funcional - DI - Inventário de Dispositivos (Device Inventory) - Grupo - Grupo de dispositivos - DCIS - Configuração do Dispositivo e armazenamento de imagens (Device Configuration & Image Storage).
Figure img0001
Figure img0002
Figure img0003
Figure img0004
[00037] Segundo o Documento de Arquitetura (AD), GwMO V1.0 (Figura 3), previamente necessitava de uma interface: a interface DM Gateway - Dispositivo Terminal (311). Portanto, não existiam razões para diferenciar interfaces em V1.0, uma vez que apenas um tipo de componente era associado ao DM Gateway (302): o componente Dispositivo Terminal (303).
[00038] Alinhado com os requisitos de AH na Tabela 1, o Documento de Arquitetura (AD) de GwMO V1.1 [GwMO_AD_V11] (resepresentado na Figura 4), estendeu a interface entre DM Gateway-Dispostivo Terminal (411) para uma nova relação e a interface entre Gateway pai - Gateway filho (412).
[00039] Devido a estas diferenças, um DM Gateway precisa agora saber a qual tipo de dispositivo ele está associado, em seu nível imediatamente mais baixo: um Dispositivo Terminal (404) ou um DM Gateway filho (403), a fim de invocar/expor a interface adequada.
[00040] Em GwMO, "Inventory MO" (representado Figura 5) é usado para manter uma lista de dispositivos na rede que são gerenciados através do DM Gateway. Em GwMO, cada entrada de Dispositivo Terminal e suas informações relacionadas são armazenadas dentro da sub-árvore Records (501).
[00041] Este "Inventory MO" é atualizado quando o DM Gateway é avisado de um novo Dispositivo Terminal na rede ou o DM Gateway é avisado que um Dispositivo Terminal previamente associado não está mais presente na rede. Isso deve ser estendido para DM Gateways filhos em AH, além dos Dispositivos Terminais. Nesses casos, as entradas em Records (502) são inseridas, atualizadas ou removidas pelo GwMO Enabler.
[00042] De forma a cumprir os requisitos acima [GwMO_RD_V11] e arquitetura [GwMO_AD_V11] para AH, há a necessidade de diferenciar as entradas de ”Inventory” sobre qual o tipo de dispositivo de um DM Gateway está associado, no nível imediatamente inferior: - Um Dispositivo Terminal. - Um DM Gateway filho.
I - Definindo nó ComponentType para diferenciar o tipo de dispositivo associado a um DM Gateway
[00043] A presente invenção propõe uma abordagem simples ao introduzir um nó-folha adicional ComponentType (504) a ser adicionado em cada entrada de Inventory Records (502), e alinhado com o DeviceID nó irmão (503), que contém o identificador público do dispositivo, como a seguir:
Figure img0005
Se Arquitetura Hierárquica for suportada, o valor deste nó folha indica o tipo do componente GwMO diretamente associado a este DM Gateway:
Figure img0006
O valor deste nó pode ser usado para suportar Configuração de Funcionalidades do DM Gateway e Grupo de Dispositivos na Seção 6.2 Config MO. Se este nó estiver ausente, é assumido por default que a ComponentType é um Dispostivo Terminal “End Device” (isto é, o valor 0).
[00044] Este nó folha adicional é definido como nó opcional, assumindo valor default = 0 (ou seja, Dispositivo Terminal) quando ele está ausente, compatível com GwMO V1.0. Também foi definida como tipo inteiro, em vez de um valor booleano, por isso abre espaço para a definição de diferentes tipos de Dispositivo Terminal ou diferentes tipos de DM Gateways, por exemplo, um gateway Zigbee ou um gateway Bluetooth.
[00045] A presente invenção também irá demonstrar como a diferenciação por ComponentType nos dispositivos conectados diretamente ao DM Gateway, no nível imediatamente inferior (Dispositivo Terminal vs DM Gateway filho), alavancados pela funcionalidade previamente existente disponível em GwMO V1.0 [GwMO_TS_V10] pode habilitar os requisitos de AH descritos na Tabela 1.
II - Definindo um DeviceGroup que usará ComponentType como critério de grupamento para criar grupos específicos para DM Gateways filhos e Dispositivos Terminais
[00046] Em GwMO, o "Gateway Config MO" (representado Figura 6) é usado para manter informações sobre a manipulação de diferentes tipos de Dispositivos Terminais pelo DM Gateway, com base em grupos de dispositivos especificados.
[00047] A informação inclui a configuração necessária para: “fanouts de comando”, bootstrapping, avisos de alertas e autenticação.
[00048] Um ponto-chave é como DM Gateways podem ser agrupados. Uma vez que um servidor de DM e um DM Gateway identifiquem corretamente o grupo de DM Gateways filhos, eles podem lidar adequadamente com Alertas, Fanout de imagem, ‘Fanout de Comando” e “Agregação de resposta” da mesma forma que GwMO V1.0.
[00049] GwMO V1.0 já oferecia previamente um mecanismo flexível para definir um grupo de dispositivos, associando um GroupID (601) a um Critério (602), como a seguir:
Figure img0007
O valor deste nó especifica o identificador de grupo de dispositivos. Este valor deve ser único dentro da Árvore de Gerenciamento do DM Gateway. O valor deste nó deve ser definido pelo DM Gateway. O DM Gateway deve seguir algumas convenções de nomenclatura para os grupos de dispositivos para garantir que o identificador de grupo de dispositivos não colidam com qualquer identificador de Dispositivo Terminal.
Figure img0008
O valor deste nó folha é a expressão condição de que o servidor DM quer que o Dispositivo Terminal cumpra. O valor deste nó é definido pelo servidor DM.
[00050] A expressão é definida usando a seguinte sintaxe ABNF:
Figure img0009
Figure img0010
[00051] Ao utilizar este mecanismo flexível, podemos criar um valor GroupID específico, que representa um grupo de DM Gateways filhos e um critério com base na nova ComponentType nó. Exemplo:
Figure img0011
III - Usando GroupType definido para a realização de “Fanout de Comando” e “Agregação de Resposta” com Gateways em AH
[00052] Em GwMO, o "Fanout MO" (Figura 7) é usado para manter informações sobre a movimentação de fanout de comando DM e agregação de resposta.
[00053] Uma vez definido um grupo de dispositivo, é possível ao DM do servidor, por exemplo, ao emitir comandos fanout (702) a diversos DM Gateways filhos ao mesmo tempo, se eles pertencem ao mesmo grupo, bem como “agregação de resposta” a ser devolvida como respostas individuais de volta ao Servidor DM. Isso pode ser feito definindo o nó TargetRef (701) abaixo com o valor do DevGroup/GroupID previamente definido (601).
Figure img0012
O valor deste nó folha especifica o alvo pretendido dos comandos de DM armazenados no nó dos DMCommands. Dependendo do valor do nó 'TargetRefType', o DM Gateway irá emitir os comandos de DM para o Dispositivo Terminal alvo especificado pelo nó DeviceID no MO inventário de dispositivos, ou ele vai emitir os comandos de DM para um grupo de dispositivos especificado pelo nó groupId no “Gateway Config” MO.
[00054] Isso habilita os seguintes requisitos de gerenciamento de grupo, utilizando Fanout de comando e agregação de resposta:
[00055] GwMO-Group-002 Servidor DM deve ser capaz de gerenciar grupos de dispositivos, composto por Dispositivos Terminais e / ou DM Gateways filhos.
[00056] Uma vez que um grupo de gateways é definido, é possível ao Servidor DM enviar comandos para consultar informações sobre vários gateways simultaneamente:
[00057] GwMO-DI-007 Servidor DM deve ser capaz de consultar um DM Gateway pai para obter informações resumidas referentes a todos os DM Gateways filhos.
IV - Comando Fanout com Grupos de gateways para distribuir imagens SW específicas para Gateways em AH
[00058] Com base no mesmo mecanismo de comando Fanout, DM Server também é capaz de fornecer imagens específicas para o DM Gateway filhos, uma vez que GroupID de gateways esteja devidamente definido.
[00059] Isso habilita o seguinte requisito para provisionamento grupo:
[00060] GwMO-DCIS-005 GwMO Enabler deve fornecer um mecanismo otimizado e configurável para armazenar dados em um DM Gateway se os dados são os mesmos para Dispositivos Terminais e/ou DM Gateways filhos.
V - Configurar diferentes Alertas de DM Gateways Filhos ou Dispositivos Terminais em AH a serem notificados ao servidor DM
[00061] Em GwMO, o "Gateway Config MO" (Figura 6) também mantêm as configurações sobre alertas que devem ser encaminhadas ao DM Server com base no GroupID ao qual o dispositivo pertence.
[00062] Para configurar alertas para grupos específicos de DM Gateways filhos, a seguinte funcionalidade está disponível:
Figure img0013
Este espaço reservado grupos de nós os parâmetros de configuração para a comunicação de alertas genéricos com base em alguns critérios (por exemplo, tipo de alerta, tipo de dispositivo, ou grupo de dispositivos). Este nó deve conter o nó filho DevType ou o nó filho GroupID, mas não ambos.
Figure img0014
O valor deste nó folha especifica o GroupID, que é especificado na sub-árvore DevGroup deste MO. Este nó é mutuamente exclusiva com o seu nó irmão DevType.
[00063] Ao configurar corretamente Alertas com diferentes grupos Dispositivo Terminal e grupos de DM Gateways filhos, definindo corretamente o nó GroupID (603), DM Gateway será capaz de gerar diferentes AlertsTypes (604) para o servidor SM.
[00064] Isso habilita os seguintes requisitos para Alertas:
[00065] GwMO-DI-008: Um DM Gateway pai deve fornecer status, attached ou dettached, do DM Gateways filho registrado. - Alerta attached ou dettached fornecido por 301 (GwMO-2).
[00066] GwMO-DI-009: Um DM Gateway pai devem ser capazes de informar o servidor DM sobre os DM Gateways filhos recém-registrados - registro de alerta de Novos Gateways fornecido por 301 (GwMO-2).
VI - Gerenciar DM Gateways e Dispositivos Terminais em AH
[00067] De acordo com os requisitos, o Documento de Arquitetura (AD) do GwMO V1.1 [GwMO_AD_V11] (Figura 4), estendeu a interface previamente existente entre DM Gateway - Dispositivo Terminal (411) para um novo relacionamento entre DM Gateway pai com DM Gateway filho (412). Graças à introdução do nó adicional ComponentType, um DM Gateway será capaz de definir a que tipo de dispositivos está associado, em seu nível imediatamente mais baixo, seja um Dispositivo Terminal ou um DM Gateway filho, a fim de invocar / expor a interface correta. ComponentType = “Dispositivo Terminal” ("End Device’)": DM Gateway deve usar a interface 411 (DM Gateway - Dispositivo Terminal): - Invocar o interface de GwMO-3: por exemplo, para executar Comandos DM no Dispositivo Terminal. - Expor a interface GwMO-4: por exemplo, para receber alertas de Dispositivo Terminal. ComponentType = "DM Gateway Filho" (“Child DM Gateway”): DM Gateway deve usar interface 412 (DM Gateway - DM Gateway): - Invocar a interface de GwMO-1: por exemplo, para executar comandos DM no DM Gateway filho. - Expor a interface GwMO-2: por exemplo, para receber alertas de DM Gateways filhos
[00068] Isso habilita os requisitos abaixo relacionados a comandos DM através de interfaces Gw-Gw e Dispositivos Terminais-Gw ao longo da AH, incluindo a leitura de valores, a escrita de valores e a execução de scripts / comandos em nós específicos residentes em Gateways ou Dispositivos Terminais, conforme a seguir:
[00069] GwMO - HLF -008: Servidor DM deve ser capaz de gerenciar um Dispositivo Terminal via um ou mais DM Gateways em um galho de árvore. - Uso de 412 (GwMO -1) para roteamento de comandos entre Gw-Gw e 411 (GwMO -3) para o Gateway entregar o comando para o Dispositivo Terminal.
[00070] GwMO - HLF -009: Servidor DM deve ser capaz de gerir um DM Gateway via um ou mais outros DM Gateways em um galho de árvore. - 412 (GwMO -1) para roteamento de comandos entre Gw-Gw na árvore da AH e para entregar o comando para o DM Gateway “target”.
[00071] GwMO -DI -006: Servidor DM deve ser capaz de consultar um DM Gateway pai para obter informações específicas de um DM Gateway filho.. - Utilizando 412 (GwMO - 1) para comando de leitura.
[00072] GwMO -DI -010: Servidor DM deve ser capaz de configurar um DM Gateway pai para tanto informar ou não informar o servidor DM dos DM Gateways filhos recém- registrados. - Configuração usando 412 (GwMO -) para comando de escrita.
[00073] GwMO - DCIS -004: GwMO Enabler deve suportar a capacidade de armazenar dados do servidor DM no DM Gateway (por exemplo, entrega de pacotes para SCOMO), para a recuperação local por Dispositivos Terminais e / ou DM Gateways filhos.- Usar interface 411 (GwMO -3) para gravar imagens da DM gateway nos Dispositivos Terminais).
[00074] GwMO - DCIS -006: GwMO Enabler deve permitir ao servidor DM configurar se os dados (por exemplo, entrega de pacotes para SCOMO) podem ser armazenados em um DM Gateway para recuperação local por Dispositivos Terminais e / ou DM Gateways filhos. - Usar interface 412 (GwMO -1) para um comando de escrita para definir esta configuração.
[00075] Embora a presente invenção tenha sido descrita em conexão com certas concretizações preferenciais, deve ser entendido que não se pretende limitar a invenção àquelas concretizações particulares. Ao contrário, pretende-se cobrir todas as alternativas, modificações e equivalentes possíveis dentro do espírito e do escopo da invenção, conforme definido pelas reivindicações em anexo. Referências: 1) [OMA_DM] “OMA Device Management, Version 1.3”. Open Mobile Alliance, URL:http://www.openmobilealliance.org. 2) [DM_DICT] “OMA Device Management Dictionary”. Open Mobile Alliance, OMA-SUP-DM_Dictionary-V1_0, URL: http://www.openmobilealliance.org. 3) [DM_TND] “OMA Device Management Tree and Description, Version 1.3”. Open Mobile Alliance, OMA-TS-DM-TND-V1_3, URL: http://www.openmobilealliance.org. 4) [GwMO_TS_V10] “OMA Gateway Management Object Version V1.0 - Technical Specification”. Open Mobile Alliance, OMA-TS-GwMO-V1_0, URL: http://www.openmobilealliance.org. 5) [GwMO_RD_V11] “OMA Gateway Management Objects Version V1.1 - Requirements Document”. Open Mobile Alliance, OMA-RD-GwMO-V1_1, URL: http://www.openmobilealliance.org. 6) [GwMO_AD_V11] “OMA Gateway Management Objects Version V1.1 - Architecture Document”. Open Mobile Alliance, OMA-AD-GwMO-V1_1, URL: http://www.openmobilealliance.org.

Claims (17)

1. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, caracterizado pelo fato de que compreende: diferenciar se um tipo de Dispositivo Terminal ou um DM Gateway Filho de um dispositivo está associado a um nível imediatamente inferior de um Device Management “DM” Gateway, por meio da adição de um nó folha ComponentType em uma “árvore de dispositivo” residente em um Gateway Management Object “GwMO” “DM_TND”, e suportar a Arquitetura Hierárquica, em que um DM Gateway utiliza interfaces diferentes, dependendo se o DM Gateway está associado a um Dispositivo Terminal ou um DM Gateway filho, respectivamente, sendo que o nó folha ComponentType é adicionado a cada entrada em um Registro de Inventário Gateway (502), e é alinhado com um nó irmão DeviceID (503), que contém um identificador público do dispositivo, e o Gateway DM é capaz de fazer uso do campo ComponentType associado ao dispositivo relacionado a invocar/expor a interface correta.
2. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que um protocolo de gerenciamento entre um Server, os Gateways e o Dispositivo Terminal é um Open Mobile Alliance Device Management “OMA DM”.
3. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que é aplicado ou estendido a outras normas e protocolos para gerenciamento de dispositivo e comunicação Máquina para Máquina “M2M”.
4. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que, o novo nó folha ComponentType residente no DM Gateway é responsável pela diferenciação de que tipo de componente está associado ao DM Gateway, o qual é parte de um nível imediatamente mais baixo da Arquitetura Hierárquica, em seu nível imediatamente mais baixo, em que o novo nó folha ComponentType é capaz de assumir valores diferentes para “Dispositivo Terminal” ("End Device"), “DM Gateway filho” (Child DM Gateway) ou “Reservado”.
5. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que o nó folha ComponentType é um nó opcional, e um tipo padrão é assumido para o dispositivo filho.
6. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 5, caracterizado pelo fato de que o tipo de dispositivo filho “Dispositivo Terminal” é assumido como tipo padrão quando o nó folha ComponentType está ausente.
7. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que o nó folha ComponentType é definido como um nó do tipo Inteiro, e incluindo os valores inteiros “Reservado”, de modo a abrir espaço para uma definição de diferentes tipos de Dispositivo Terminal ou diferentes tipos de DM Gateways quando necessário.
8. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 7, caracterizado pelo fato de que Gateways não OMA-DM, assim como Dispositivos Terminais não-OMA-DM, são conectados como folhas na Arquitetura Hierárquica, e são tratados como simples Dispositivos Terminais com o DM Gateway, aos quais estes estão associados operando em Modo Adaptativo (“Adaptation Mode”).
9. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: criar grupos de dispositivos específicos (601) para Dispositivos Terminais e DM Gateway filhos, de acordo com o nó Critério (602), usando como base ComponentType, ou uma combinação entre ComponentType e outros nós de Inventory/Records.
10. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: habilitar a Arquitetura Hierárquica para os requisitos de “Grupo” e “Device Inventory” (DI) [GwMO_RD_V11], os quais estão relacionados ao “Fanout de Comandos DM” e “Agregação de resposta” com DM Gateways em Arquitetura Hierárquica através do uso de Grupos de dispositivos específicos predefinidos (601) para Dispositivos Terminais e DM Gateways filhos, em que um Servidor DM é capaz de emitir fanout de comandos (702) a diversos DM Gateways filhos ao mesmo tempo, se estes pertencerem ao mesmo grupo, bem como as respostas de agregação a serem retornadas como uma única mensagem de resposta ao Servidor DM.
11. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 10, caracterizado pelo fato de que compreende adicionalmente escrever o valor de um DevGroup previamente definido (601) em um nó TargetRef (701).
12. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que, uma vez que DevGroups são adequadamente definidos, permitir que um comando DM emitido por um DM Server seja propagado em cascata para baixo ao longo dos níveis da árvore hierárquica da Arquitetura, e através de DM Gateways intermediários, pela aplicação recursiva de um mecanismo de “fanout de comando” ao longo dos níveis da Arquitetura Hierárquica.
13. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que a resposta do comando é enviada de volta a um DM Server, e a resposta é agregada em cascata ao longo de níveis da Arquitetura Hierárquica pela aplicação recursiva de um mecanismo de “agregação da resposta” ao longo dos níveis da Arquitetura Hierárquica.
14. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente fornecer e entregar imagens ou pacotes de software específicos para DM Gateways filhos ao mesmo tempo que utiliza um mecanismo de “Fanout de Comandos DM”.
15. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que a Arquitetura Hierárquica habilita que os requisitos de “Device Inventory” (DI) [GwMO_RD_V11], referentes a lidar com diferentes Alertas DM com Gateways em Arquitetura Hierárquica usando Grupos de dispositivos específicos predefinidos (601) para Dispositivos Terminais e DM Gateways filhos por um Servidor DM, recebam alertas específicos de DM Gateways filhos, dependendo dos grupos criados com base no nó folha ComponentType.
16. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: configurar alertas específicos para diferentes grupos Dispositivo Terminal e grupos de DM Gateways filhos, por meio da configuração de um nó GroupID (603), em que o DM Gateway é capaz de enviar diferentes tipos de Alertas DM especificados em AlertsTypes (604) para DM Server, para GroupIDs diferentes.
17. Método para habilitar a Arquitetura Hierárquica de gateways para gerenciamento de dispositivos, de acordo com a reivindicação 1, caracterizado pelo fato de que, ao mesmo tempo que os Alertas DM podem ser usados para atualizar os campos de Inventário do DM Gateway, incluir o nó folha ComponentType, em função do tipo de alerta recebido, em que os Alertas DM atualizam as informações de inventário em diversos níveis de DM Gateways, à medida que os alertas DM são propagados para cima na arquitetura hierárquica, em direção a um DM Server.
BR102014003580-0A 2014-02-14 2014-02-14 Método para habilitar a arquitetura hierárquica de gateways para gerenciamento de dispositivos BR102014003580B1 (pt)

Priority Applications (2)

Application Number Priority Date Filing Date Title
BR102014003580-0A BR102014003580B1 (pt) 2014-02-14 2014-02-14 Método para habilitar a arquitetura hierárquica de gateways para gerenciamento de dispositivos
US14/300,763 US9654547B2 (en) 2014-02-14 2014-06-10 Method for enabling hierarchical architecture of device management gateways

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
BR102014003580-0A BR102014003580B1 (pt) 2014-02-14 2014-02-14 Método para habilitar a arquitetura hierárquica de gateways para gerenciamento de dispositivos

Publications (2)

Publication Number Publication Date
BR102014003580A2 BR102014003580A2 (pt) 2015-10-20
BR102014003580B1 true BR102014003580B1 (pt) 2023-03-21

Family

ID=53799117

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102014003580-0A BR102014003580B1 (pt) 2014-02-14 2014-02-14 Método para habilitar a arquitetura hierárquica de gateways para gerenciamento de dispositivos

Country Status (2)

Country Link
US (1) US9654547B2 (pt)
BR (1) BR102014003580B1 (pt)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190319815A1 (en) * 2018-04-17 2019-10-17 Flex Ltd. Distributed rules engine
CN110309560B (zh) * 2019-06-13 2020-12-22 清华大学 多层级迁移模拟方法和装置
CN110855473B (zh) * 2019-10-16 2022-11-18 平安科技（深圳）有限公司 一种监控方法、装置、服务器及存储介质
WO2023277883A1 (en) * 2021-06-29 2023-01-05 Hewlett-Packard Development Company, L.P. Production procedure device modifications
CN114285852B (zh) * 2021-12-28 2023-12-26 杭州数梦工场科技有限公司 基于多级服务平台的服务调用方法及装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060031449A1 (en) * 2004-07-01 2006-02-09 Mika Hallamaa Selection of management method
CN101146346A (zh) * 2006-09-13 2008-03-19 华为技术有限公司 设备能力信息上报方法及终端设备
WO2009021208A1 (en) * 2007-08-08 2009-02-12 Innopath Software, Inc. Workflow-based user interface system for mobile devices management
US20110010383A1 (en) * 2009-07-07 2011-01-13 Thompson Peter C Systems and methods for streamlining over-the-air and over-the-wire device management
KR20120099794A (ko) * 2009-12-28 2012-09-11 인터디지탈 패튼 홀딩스, 인크 사물 지능 통신 게이트웨이 아키텍쳐
KR101647567B1 (ko) * 2010-03-05 2016-08-10 인터디지탈 패튼 홀딩스, 인크 장치에 대한 보안을 제공하는 방법 및 장치
CN102142980B (zh) * 2010-10-27 2014-05-07 华为技术有限公司 远程管理传感网络拓扑的方法及网关
US9019909B2 (en) * 2011-12-06 2015-04-28 Nokia Corporation Method, apparatus, and computer program product for coexistence management
KR101700197B1 (ko) * 2012-08-22 2017-01-26 엘지전자 주식회사 장치 관리를 위한 노드의 주소 표현 방법 및 이를 위한 장치

Also Published As

Publication number Publication date
BR102014003580A2 (pt) 2015-10-20
US20150236889A1 (en) 2015-08-20
US9654547B2 (en) 2017-05-16

Similar Documents

Publication Publication Date Title
Datta et al. A lightweight framework for efficient M2M device management in oneM2M architecture
JP6715978B2 (ja) 軽量ｉｏｔ情報モデル
US11323316B2 (en) Device configuration method and apparatus that are based on network configuration protocol
JP7139522B2 (ja) ローカルエリアネットワーク通信方法、装置、およびシステム
US20220109743A1 (en) Framework for iot protocol identification and management
JP5805873B2 (ja) Ｍ２ｍデバイスサブスクリプションのための方法及び装置
JP6434611B2 (ja) デバイス管理プロトコルを用いるインターワーキングライトウェイトマシンツーマシンプロトコル
BR102014003580B1 (pt) Método para habilitar a arquitetura hierárquica de gateways para gerenciamento de dispositivos
KR102145741B1 (ko) 무선 통신 시스템에서 접근 제어를 위한 방법 및 장치
US20170311303A1 (en) Method for guaranteeing operation of control message in wireless communication system and device for same
EP3170284A1 (en) Enhanced operations between service layer and management layer in an m2m system by allowing the execution of a plurality of commands on a plurality of devices
JP2007525870A (ja) 装置管理システム内における管理ノードの指定
KR20150088787A (ko) 무선 통신 시스템에서 특정 리소스에 대한 정보 갱신을 위한 방법 및 장치
Chen et al. Converging MQTT resources in ETSI standards based M2M platform
US20210342163A1 (en) Methods for operation of a device, bootstrap server and network node
WO2014079019A1 (zh) 一种机器通信中群组管理的方法和装置
US20140040973A1 (en) Method for controlling initial access rights to open mobile alliance device management servers
Mijić et al. Unified iot platform architecture platforms as major iot building blocks
US11533597B2 (en) Method for processing message in M2M system and device therefor
JP2024504098A (ja) エッジコンピューティングにおける垂直アプリケーション
KR102285352B1 (ko) 이기종 IoT 장치와 IoT 플랫폼의 연동을 위한 프록시, 방법 및 상기 프록시를 포함하는 시스템
Errobidart et al. Offline domotic system using voice comands
Elsayed et al. Service discovery in heterogeneous IoT environments based on OCF/IoTivity
US12003360B2 (en) OAM functional service exposure and discovery function and data repository
WO2012004424A1 (es) Método y sistema de gestión de topologías de red en redes domésticas

Legal Events

Date Code Title Description
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: A CLASSIFICACAO ANTERIOR ERA: H04L 12/24

Ipc: H04L 12/24 (2006.01), H04L 29/08 (2006.01)

B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 14/02/2014, OBSERVADAS AS CONDICOES LEGAIS