ES2893353T3 - Comunicación con dispositivos de máquina a máquina - Google Patents

Comunicación con dispositivos de máquina a máquina Download PDF

Info

Publication number
ES2893353T3
ES2893353T3 ES14776684T ES14776684T ES2893353T3 ES 2893353 T3 ES2893353 T3 ES 2893353T3 ES 14776684 T ES14776684 T ES 14776684T ES 14776684 T ES14776684 T ES 14776684T ES 2893353 T3 ES2893353 T3 ES 2893353T3
Authority
ES
Spain
Prior art keywords
data
communications
message
devices
interface
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
Application number
ES14776684T
Other languages
English (en)
Inventor
Sophie Nicole Bourne
Simone Ferrara
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone IP Licensing Ltd
Original Assignee
Vodafone IP Licensing Ltd
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
Priority claimed from GB201316370A external-priority patent/GB201316370D0/en
Priority claimed from GB201318339A external-priority patent/GB201318339D0/en
Application filed by Vodafone IP Licensing Ltd filed Critical Vodafone IP Licensing Ltd
Application granted granted Critical
Publication of ES2893353T3 publication Critical patent/ES2893353T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1668—Details of memory controller
    • G06F13/1689—Synchronisation and timing concerns
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4027—Coupling between buses using bus bridges
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/38—Transceivers, i.e. devices in which transmitter and receiver form a structural unit and in which at least one part is used for functions of transmitting and receiving
    • H04B1/3816—Mechanical arrangements for accommodating identification devices, e.g. cards or chips; with connectors for programming identification devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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
    • 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
    • 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
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/37—Managing security policies for mobile devices or for controlling mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • 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
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Medical Informatics (AREA)
  • Mathematical Physics (AREA)
  • Bioethics (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método para comunicarse entre un dispositivo gestionado y un gestor de dispositivos, comprendiendo el método las etapas de: enviar al dispositivo gestionado un mensaje a través de un primer canal de comunicaciones; e iniciar la comunicación entre el dispositivo gestionado y el gestor de dispositivos a través de un segundo canal de comunicaciones en respuesta al mensaje, en donde el primer canal de comunicaciones y el segundo canal de comunicaciones son de diferentes tipos, en donde las comunicaciones entre el dispositivo gestionado y el gestor de dispositivos a través del segundo canal de comunicaciones están suspendidas hasta que se recibe el mensaje, en donde la recepción del mensaje en el dispositivo gestionado provoca, además, que las comunicaciones entre el dispositivo gestionado y el gestor de dispositivos a través de un tercer canal de comunicaciones cesen y sean conmutadas al segundo canal de comunicaciones, en donde el tercer canal de comunicaciones es diferente al segundo canal de comunicaciones, y en donde el primer canal de comunicaciones es un canal celular y el segundo canal de comunicaciones es un canal no celular.

Description

DESCRIPCIÓN
Comunicación con dispositivos de máquina a máquina
Campo de la invención
La presente invención se refiere a un método y a un sistema para comunicarse con dispositivos y, en particular, con dispositivos de máquina a máquina.
Antecedentes de la invención
Los dispositivos gestionados y, en particular, los dispositivos de máquina a máquina (M2M - Machine two machine, en inglés) pueden ser utilizados en muchas situaciones diferentes, e incorporados en una variedad de elementos y hardware diferentes. Por lo general, estos dispositivos gestionados tendrán pocos recursos informáticos, tendrán una potencia restringida y una funcionalidad restringida. Sin embargo, se pueden desarrollar grandes redes de dispositivos gestionados de este tipo, que requieren mantenimiento, control y otras interacciones que requieren comunicación con un gestor de dispositivos.
Debido a la naturaleza de los dispositivos gestionados y a sus recursos limitados tanto en potencia como en potencial informático, a menudo es necesario mantener los dispositivos gestionados apagados, en un estado de potencia reducida o en un estado de latencia hasta que sean requeridos (por ejemplo, para proporcionar una lectura o aceptar un comando). Los dispositivos pueden estar programados para encenderse en determinados momentos o de manera intermitente. Sin embargo, si se requiere información de dichos dispositivos gestionados o si se necesita enviar información de control u otra información de gestión fuera de los horarios de funcionamiento programados, este enfoque presenta inconvenientes. Alternativamente, se puede mantener algún modo de comunicación entre los dispositivos gestionados y su gestor de dispositivos, pero esto requiere una potencia y un ancho de banda adicionales, especialmente para grandes redes de dispositivos gestionados.
Por lo tanto, se requiere un método y un sistema para comunicarse con los dispositivos gestionados que supere estos problemas.
Compendio de la invención
En este contexto, y según un primer aspecto, se da a conocer un método tal como se describe en la reivindicación 1. Según un segundo aspecto, existe un sistema como el descrito en la reivindicación 9.
En un ejemplo, se da a conocer un método para la comunicación entre un dispositivo gestionado y un gestor de dispositivos, comprendiendo el método las etapas de:
enviar al dispositivo gestionado un mensaje a través de un primer canal de comunicaciones; e
iniciar la comunicación entre el dispositivo gestionado y el gestor del dispositivo a través de un segundo canal de comunicaciones en respuesta al mensaje, en donde el primer canal de comunicaciones y el segundo canal de comunicaciones son de diferentes tipos. Por lo tanto, el dispositivo gestionado puede estar en un estado de latencia o de baja potencia hasta que se requieren comunicaciones. En este momento, el gestor del dispositivo puede enviar un mensaje de activación a través de un canal o interfaz que activa un canal o interfaz diferente para iniciar las comunicaciones. Preferentemente, el dispositivo gestionado tiene un requisito de potencia bajo o menor para el primer canal de comunicaciones que para el segundo canal de comunicaciones. Por lo tanto, este sistema puede reducir los requisitos informáticos, de potencia y/o ancho de banda, especialmente en una red de uno o más o muchos dispositivos gestionados, y la señalización entre el dispositivo gestionado y el gestor del dispositivo se puede reducir, pero permite que un gestor de dispositivos se comunique con cualquiera o con más dispositivos bajo demanda. El método puede iniciar comunicaciones entre el dispositivo gestionado y el gestor del dispositivo o alterar un canal de comunicaciones existente, por ejemplo. Los dispositivos gestionados pueden ser de un tipo que no requiera la intervención del usuario o que sea necesario para supervisar o controlar equipos no supervisados u otro hardware, por ejemplo. Por lo general, dichos dispositivos gestionados estarán habitualmente en comunicación con una red celular pero no tendrán capacidad de voz (es decir, un dispositivo gestionado no es un teléfono móvil o celular). Los canales dentro de diferentes sistemas de comunicación (tales como fijos e inalámbricos) se pueden considerar de diferentes tipos. Los canales con diferentes arquitecturas de seguridad (incluida la falta de seguridad) también se pueden considerar de diferentes tipos. Por el contrario, los canales que están dentro del mismo sistema de comunicación y tienen la misma arquitectura de seguridad (tales como 2G, 3G o 4G, o SMS/GPRS/UMTS/LTE, por ejemplo) no se consideran de diferentes tipos.
Preferentemente, el primer canal de comunicaciones puede ser un canal celular y el segundo canal de comunicaciones es un canal no celular. Los canales de comunicación celulares pueden incluir aquellos que operan en redes celulares que incluyen GSM, UMTS, LTE, 3G, 3GPP, WAP, GPRS y CDMA, por ejemplo. Por lo tanto, estos canales de comunicaciones celulares requieren un operador de red o un operador de red virtual para administrar una red de estaciones base móviles y células. Los canales de comunicación no celulares utilizan una tecnología diferente, pero pueden incluir muchos tipos diferentes. Estos pueden incluir líneas fijas (por ejemplo, PSTN), canales inalámbricos (por ejemplo, WiFi y WiMax), canales de Internet (por ejemplo, Ethernet) y otros, por ejemplo.
Preferentemente, el primer canal de comunicaciones puede ser seguro o ser utilizado para transportar un mensaje seguro.
Preferentemente, el segundo canal de comunicaciones también es seguro y tiene una arquitectura de seguridad diferente a la del primer canal de comunicaciones. Por ejemplo, el primer canal puede ser inseguro y el segundo canal puede ser seguro (y, por lo tanto, tiene una arquitectura de seguridad diferente a la del primer canal).
La arquitectura de seguridad de uno o de ambos canales puede incluir cualquiera de GBA, seguridad de portadora celular, seguridad de clave pública/privada o clave simétrica, seguridad de línea fija u otra seguridad criptográfica.
Opcionalmente, el primer canal de comunicaciones puede estar dentro de un primer sistema de comunicaciones y el segundo canal de comunicaciones está dentro de un segundo sistema de comunicaciones diferente del primer sistema de comunicaciones.
Preferentemente, el mensaje puede ser un SMS o un SMS, SMS-MT, WAP-directo (WAP-Push, en inglés) u OMA-directo (OMA-Push, en inglés) terminados en un dispositivo móvil. Los mensajes SMS pueden resultar especialmente eficaces. Se pueden utilizar otros tipos de mensajes.
Opcionalmente, el segundo canal de comunicaciones puede ser cualquiera de: protocolo de control de transmisión, TCP (Transmission Control Protocol, en inglés; protocolo de datagramas de usuario, UDP (User Datagram Protocol, en inglés; celular; inalámbrico; Wifi; WiMax; cableado; línea fija; y línea telefónica. Se pueden utilizar otros canales de comunicaciones o interfaces.
Preferentemente, las comunicaciones entre el dispositivo gestionado y el gestor del dispositivo a través del segundo canal de comunicaciones se pueden suspender hasta que se recibe el mensaje. Esto reduce aún más los requisitos de potencia y otros recursos.
Preferentemente, el dispositivo gestionado puede estar en un estado de latencia hasta que se recibe el mensaje.
Opcionalmente, la recepción del mensaje en el dispositivo gestionado puede provocar adicionalmente que las comunicaciones entre el dispositivo gestionado y el gestor del dispositivo a través de un tercer canal de comunicaciones cesen y cambien al segundo canal de comunicaciones, en donde el tercer canal de comunicaciones es diferente del segundo canal de comunicaciones. En lugar (o, además) de activar el dispositivo desde un estado de latencia, esto permite un método conveniente y eficiente para conmutar entre canales de comunicación. Por ejemplo, el dispositivo puede ser conmutado entre conexiones inalámbricas o desde o hacia una línea fija hacia o desde un modo inalámbrico. Este es un ejemplo de alteración de un canal de comunicaciones existente, pero puede haber otros. El tercer canal de comunicaciones puede utilizar más (o menos) recursos informáticos (por ejemplo, potencia, ancho de banda, etc.) en comparación con el segundo canal de comunicaciones actual. Por lo tanto, este método permite una gestión más eficiente del dispositivo y de la red de dispositivos. Es particularmente ventajoso conmutar de inalámbrico a cableado (o línea fija), ya que esto puede proporcionar un mayor ancho de banda, una mayor fiabilidad, utilización de potencia u otras mejoras.
Opcionalmente, las comunicaciones pueden ser conmutadas al tercer canal de comunicaciones desde el segundo canal de comunicaciones de manera automática. Esto puede ser un procedimiento automático o puede hacer que un usuario u otra entidad realice una conmutación manual.
Ventajosamente, el mensaje puede ser enviado al dispositivo gestionado en respuesta a: un aumento en el volumen de datos; una solicitud para enviar al dispositivo gestionado un archivo por encima de un umbral predeterminado; una solicitud de actualización de firmware o software; un aumento de la potencia eléctrica utilizada por el dispositivo gestionado por encima de un umbral predeterminado; y una disminución en la velocidad de transferencia de datos por debajo de un umbral predeterminado. El mensaje puede ser enviado o generado siguiendo otros escenarios o criterios.
Opcionalmente, el mensaje puede ser un mensaje SMS seguro. Por ejemplo, es posible que ya esté protegido mediante una arquitectura de arranque genérica, GBA (Generic Boostrapping Architecture, en inglés, información tal como las claves obtenidas mediante GBA. En otras palabras, el canal de SMS puede ser un canal de SMS seguro, en cuyo caso se puede entregar cualquier tipo de información de seguridad, por ejemplo, una clave o claves adicionales para garantizar el segundo canal de comunicaciones.
Opcionalmente, el mensaje puede ser un mensaje no seguro.
Opcionalmente, el mensaje puede ser un mensaje SMS no seguro que contenga información de inserción de arquitectura de arranque genérica, GBA. En este caso, se está utilizando un canal de SMS no seguro, por lo que la información de inserción de GBA debe ser incluida con el mensaje.
La información de GBA Directa está descrita en el documento 3GPP TS 33.223, Sección 5.2.1. La codificación está definida en la Sección 5.3.5. Véase, en particular, la tabla 5.2.1.1 y la figura 5.3.5.1 en el documento 3GPP TS 33.223 V12.0.0 (2013-12) que se puede encontrar: http://www.3gpp.org/ftp/Specs/archive/33_series/33.223/33223-c00.zip Ventajosamente, el método puede comprender, además, la etapa de confirmar la autenticidad del mensaje utilizando la información de GBA Directa, y en donde la comunicación entre el dispositivo gestionado y el gestor del dispositivo a través de los segundos canales de comunicaciones se inicia tras una autenticación satisfactoria. Esto impide la activación no autorizada de los dispositivos gestionados o la conmutación no autorizada a un canal de comunicaciones diferente de estos dispositivos gestionados.
Ventajosamente, el mensaje es un mensaje SMS, y el método puede comprender, además, la etapa de determinar si el mensaje SMS es enviado a través de un canal de SMS seguro.
Ventajosamente, el primer canal de comunicación puede ser utilizado para establecer material criptográfico (por ejemplo, una clave o claves o un secreto compartido) para garantizar el segundo canal de comunicación. Esto puede incluir la utilización de GBA, GBA Directa o uso la utilización del primer canal para enviar una clave que protege el segundo canal, por ejemplo.
Preferentemente, el dispositivo gestionado es un dispositivo de máquina a máquina, M2M. Se pueden utilizar otros dispositivos gestionados.
Preferentemente, las comunicaciones entre el dispositivo gestionado y el gestor del dispositivo se pueden originar en el dispositivo gestionado. En otras palabras, el mensaje o el mensaje de activación proviene del gestor del dispositivo, y las comunicaciones son iniciadas por el dispositivo gestionado.
Según otro ejemplo, se da a conocer un sistema para comunicarse con uno o más dispositivos gestionados, que comprende:
un gestor de dispositivos;
una primera interfaz de comunicaciones;
una segunda interfaz de comunicaciones, de tipo diferente a la primera interfaz de comunicaciones; y
lógica configurada para:
enviar a un dispositivo gestionado un mensaje utilizando la primera interfaz de comunicaciones; e
iniciar las comunicaciones entre el dispositivo gestionado y el gestor del dispositivo utilizando la segunda interfaz de comunicaciones, en respuesta al mensaje.
Preferentemente, la primera interfaz de comunicaciones puede ser una interfaz celular y la segunda interfaz de comunicaciones puede ser una interfaz no celular.
Preferentemente, la primera interfaz de comunicaciones puede ser segura, o ser utilizada para transportar un mensaje seguro.
Opcionalmente, la segunda interfaz de comunicaciones puede ser segura y tener una arquitectura de seguridad diferente a la primera interfaz de comunicaciones.
Preferentemente, la primera interfaz de comunicaciones puede estar configurada para comunicarse con un primer sistema de comunicaciones, y la segunda interfaz de comunicaciones está configurada para comunicarse con un segundo sistema de comunicaciones diferente al primer sistema de comunicaciones.
Preferentemente, la primera interfaz de comunicaciones puede ser SMS, SMS-MT, WAP-Directo u OMA-Directo. Opcionalmente, la segunda interfaz de comunicaciones puede ser cualquiera de: protocolo de control de transmisión, TCP; protocolo de datagramas de usuario, UDP; celular; inalámbrico; Wifi; WiMax; cableada; línea fija; y línea telefónica.
Opcionalmente, el sistema puede comprender, además, una tercera interfaz de comunicaciones diferente de la segunda interfaz de comunicaciones, y en donde la recepción del mensaje en el dispositivo gestionado provoca que las comunicaciones entre el dispositivo gestionado y el gestor del dispositivo que utilizan la tercera interfaz de comunicaciones cesen, y conmuten a la segunda interfaz de comunicaciones.
Los métodos descritos anteriormente pueden ser implementados como un programa informático que comprende instrucciones de programa para operar un ordenador. El programa informático puede estar almacenado en un medio legible por ordenador.
El sistema informático puede incluir un procesador, tal como una unidad central de procesamiento (CPU - Central Processing Unit, en inglés). El procesador puede ejecutar lógica en forma de un programa de software. El sistema informático puede incluir una memoria que incluya un medio de almacenamiento volátil y no volátil. Se puede incluir un medio legible por ordenador para almacenar la lógica o las instrucciones del programa. Las diferentes partes del sistema pueden estar conectadas mediante una red (por ejemplo, redes inalámbricas y redes cableadas). El sistema informático puede incluir una o más interfaces. El sistema informático puede contener un sistema operativo adecuado, tal como, por ejemplo, UNIX, Windows (RTM) o Linux.
Cabe señalar que cualquier característica descrita anteriormente puede ser utilizada con cualquier aspecto o realización particular de la invención.
Breve descripción de las figuras
La presente invención se puede poner en práctica de varias maneras y las realizaciones se describirán a continuación solo a modo de ejemplo y con referencia a los dibujos adjuntos, en los cuales:
La figura 1 muestra un diagrama esquemático de una plataforma de gestión de dispositivos a modo de ejemplo, que incluye una interfaz en dirección norte y una interfaz en dirección sur;
la figura 2 ilustra esquemáticamente un método de utilización de la interfaz en dirección norte de la figura 1;
la figura 3 muestra un diagrama esquemático de un flujo de datos utilizado para operar la plataforma de gestión de dispositivos de la figura 1;
la figura 4 ilustra esquemáticamente la interacción de diversos tipos de usuarios con la interfaz en dirección norte de la figura 1;
la figura 5 muestra un diagrama esquemático de un motor de procesamiento de la plataforma de gestión de dispositivos de la figura 1;
la figura 6 muestra un diagrama esquemático de un modelo de datos a modo de ejemplo utilizado en la plataforma de gestión de dispositivos de la figura 1;
la figura 7 muestra otro modelo de datos a modo de ejemplo;
la figura 8 muestra un diagrama esquemático de una estructura de objeto de clase a modo de ejemplo utilizada por un motor de procesamiento dentro de la plataforma de gestión de dispositivos de la figura 1;
la figura 9 muestra un diagrama esquemático de una disposición física de componentes que forman la plataforma de gestión de dispositivos de la figura 1;
la figura 10 muestra un diagrama de flujo de un proceso para activar uno o más dispositivos gestionados por la plataforma de gestión de dispositivos de la figura 1;
la figura 11 muestra un diagrama de flujo a modo de ejemplo de un proceso de envío de un SMS desde un dispositivo a la plataforma de gestión de dispositivos de la figura 1;
la figura 12 muestra un diagrama esquemático de una vista lógica de la interfaz en dirección sur de la figura 1; la figura 13 muestra una estructura de base de datos de información de gestión a modo de ejemplo, utilizada para representar los dispositivos gestionados;
la figura 14 muestra un diagrama de clases de un modelo de interfaz de dispositivo;
la figura 15 muestra un diagrama esquemático de un sistema a modo de ejemplo, para gestionar dispositivos; la figura 16 muestra un diagrama de flujo de un método a modo de ejemplo, para gestionar dispositivos;
la figura 17 muestra un diagrama esquemático de un sistema para comunicarse con uno o más dispositivos gestionados; y
la figura 18 muestra un diagrama de flujo de un método para comunicarse con dispositivos gestionados.
Cabe señalar que las figuras se ilustran por sencillez, y no necesariamente están dibujadas a escala. Las características similares están dotadas de los mismos números de referencia.
Descripción detallada de las realizaciones preferentes
El sistema se puede describir como una plataforma de gestión de dispositivos 10 (tal como se muestra en la figura 1), que puede proporcionar un conjunto básico de servicios y mecanismos que pueden ser integrados con los procesos de aplicación del cliente o usuario (que pueden ser descritos como aplicaciones verticales 20).
Las aplicaciones pueden formar parte de un dispositivo gestionado o de una plataforma de máquina a máquina (M2M), o pueden ser independientes de los mismos. La figura 1 ilustra una serie de aplicaciones verticales 20 que interactúan a través de una estructura de bus 55 de gestión de dispositivos (DM - Device Management, en inglés) con un gestor de dispositivos que también se puede describir como un proxy de aplicación de gestión de dispositivos (DMAP -Device Management Application Proxy, en inglés) 60. El DMAP 60 puede ser considerado como una habilitación tecnología que puede ser utilizada por muchas aplicaciones verticales diferentes. La aplicación vertical puede estar limitada a una plataforma web que puede activar funciones básicas de gestión de dispositivos, por ejemplo, captadores/ configuradores, gestión de firmware, etc.
La plataforma de DM 10 puede soportar múltiples categorías y tipos de aplicaciones verticales. El DMAP 60 virtualiza los dispositivos físicos para proporcionar una vista coherente de esos dispositivos físicos a la aplicación vertical del cliente o del usuario. Los mecanismos subyacentes utilizados para lograr esto pueden ser transparentes para la Aplicación Vertical, y los mecanismos, protocolos y estructuras de datos utilizados para interactuar con los dispositivos físicos pueden formar parte del funcionamiento del DMAP 60.
Tal como se ilustra esquemáticamente en la figura 3, la funcionalidad y el flujo de datos 150 de la solución de DM se pueden separar en tres componentes arquitectónicos:
1. la interfaz en dirección norte (NBi - North Bound Interface, en inglés) 160 que proporciona comunicaciones entre el DMAP 60 y las aplicaciones verticales 20. Esto se realizará a través del bus 55 de gestión de dispositivos (DM);
2. el servidor de DMAP 60;
3. Ia interfaz en dirección sur (SBi - South Bound Interface, en inglés) 170 proporciona comunicaciones y control a dispositivos de M2M físicos a través del bus de datos del dispositivo (DD - Device Data, en inglés).
Una manera alternativa de ver el modelo arquitectónico es como un componente en un entorno de arquitectura empresarial, donde las aplicaciones verticales 20 están situadas sobre el bus EA e interactúan con los dispositivos invocando servicios de arquitectura orientada a servicios (SOA - Service Orientated Architecture, en inglés) utilizando el bus de gestión de dispositivos 55.
El servidor de DMAP 60 está diseñado para ser una tecnología habilitadora, destinada a satisfacer los requisitos de muchas aplicaciones diferentes de gestión de dispositivos. Como su nombre indica, es un proxy de aplicación. Hay muchos ejemplos de aplicaciones ilustrativas que incluyen terminales de máquina a máquina 25 (M2M), dispositivos de supervisión 30, Energía 35, Armario conectados 45, ordenador ubicuo (UBI - UBiquitous Computer, en inglés) 40, Activos móviles 45, etc. La aplicación vertical 20 puede ser una aplicación web que permite al personal realizar funciones básicas de gestión de dispositivos. Además, se puede utilizar un enfoque de SaaS basado en la nube.
El DMAP 60 puede ser accesible para clientes de terceros, y puede administrar dispositivos/activos de terceros, por lo que una implementación puede tener requisitos de seguridad similares a otros tipos de proxy de aplicación. En otras palabras, se puede suponer que el DMAP 60 es un objetivo atractivo y accesible para las violaciones de la seguridad. El enfoque de seguridad que se adopta es un enfoque de defensa en profundidad, que utiliza una serie de mecanismos de seguridad a nivel de ordenador principal que, normalmente, no se utilizan en elementos de red (comprobación de integridad de archivos, escaneo de software encubridor (rootkit, en inglés), aplicación de roles de seguridad, cortafuegos a nivel de ordenador principal).
En la siguiente sección se describen cinco estructuras de bus independientes. Las matrices de conectividad y las especificaciones del cortafuegos (loD - Institute of Directors, en inglés) pueden ser correlacionadas con las mismas, pero pueden ampliarse aún más. Por ejemplo, el bus de DM 55 puede ser utilizado para comunicarse con diferentes aplicaciones verticales 20 con diferentes requisitos de seguridad. Por lo tanto, el bus de DM 55 puede separarse en múltiples vías de comunicación físicas/lógicas y con controles de seguridad adecuados en cada una.
El bus de DM 55 se puede comunicar con una aplicación web alojada por un operador que puede proporcionar acceso al DMAP 60 para su uso por parte del personal de confianza del operador. Esto se puede satisfacer con una sola conexión de VPN entre el servidor web de control (la aplicación vertical 20) y el DMAP 60. El DMAP 60 interactúa con los agentes 65, que pueden ser componentes (software y/o hardware) dentro de dispositivos gestionados o M2M.
La figura 3 ilustra esquemáticamente varios tipos de conectividad:
1) Interfaz de usuario final (flecha superior), por lo general sería una Ul basada en la web, pero podría ser cualquier mecanismo definido por las aplicaciones verticales 20.
2) Interfaces internas (flechas dos y tres desde la parte inferior) que conectan los componentes de la plataforma de aplicaciones de gestión de dispositivos. Estas pueden ser implementadas como acceso a objetos locales mediante programación. Alternativamente, se puede utilizar un entorno de tipo EJB/OSGi basado en llamadas a procedimiento remoto (RPC - Remote Procedure Calls, en inglés) y serialización para dividir estas capas en múltiples plataformas (por ejemplo, un entorno en la nube). En este ejemplo, estas interfaces se describirán mediante programación. En otras palabras, NBi 160 y el motor de procesamiento 165 de DM pueden ser ejecutadas en una sola plataforma.
3) Las interfaces externas (flechas horizontales, flecha inferior y cuarta desde la flecha inferior) pueden utilizar protocolos con conexión/sin conexión para proporcionar funciones de comunicación entre los componentes que soportan. Funcionalmente, existen cuatro tipos de interfaz externa en este ejemplo:
a. Bus de gestión de dispositivos. Proporciona comunicación mediante servicios web entre aplicaciones verticales (Equipo de cabecera - Head End, en inglés) 20 y la plataforma de gestión de dispositivos 10.
b. Bus de seguridad del dispositivo. Proporciona el conjunto completo de servicios de AAA y define los roles de usuario y las ACL de seguridad.
c. Bus de control de dispositivos. Proporciona conectividad de API (Interfaz de programación de aplicaciones - Application Programming Interface, en inglés) de gestión a una plataforma M2M. Por ejemplo, se pueden invocar activaciones por SMS (SMS-Wakeups, en inglés) a través de este bus. Base de datos del dispositivo
Se puede utilizar conectividad por cable y celular a los dispositivos. Los dispositivos gestionados por la plataforma M2M pueden soportar una portadora celular que permite la activación por SMS y la conectividad de APN. Asimismo, algunos dispositivos pueden tener una conectividad adicional por cable. La conectividad de la plataforma M2M puede ser considerada fiable, y cualquier otra conectividad debe ser tratada caso por caso, y debe ser asignada a un dominio de seguridad separado. En el diagrama no se muestran los requisitos de conectividad de operación y mantenimiento (O&M - Operation and Maintenance, en inglés). Estos pueden ser implementados localmente, o utilizar una VPN a través del bus de control de dispositivos, por ejemplo. Estos pueden incluir los protocolos DNS, NTP, SNMP, SYSLOG, SSH y Copia de seguridad (Backup, en inglés), pero se pueden soportar protocolos adicionales según sea necesario. Las aplicaciones verticales 20 son aplicaciones que interactúan con dispositivos 120, gestionan y manipulan los mismos, utilizando la plataforma de gestión de dispositivos.
Diferentes tipos de usuarios 155 pueden utilizar aplicaciones verticales con diferentes roles de seguridad, por ejemplo:
• Personal administrativo responsable de las operaciones de muchos tipos de dispositivos
• Clientes de OpCo (Empresa operativa - Operating Company, en inglés), responsables de los dispositivos propiedad de sus clientes
• Clientes que poseen dispositivos que suministran a usuarios finales para que los utilicen (para algún propósito) • Usuarios finales y personas que utilizan dispositivos 120.
La aplicación vertical 20 que utilizará un tipo particular de usuario puede variar de manera similar. Los tipos de aplicación pueden incluir, entre otros:
• Personal administrativo: supervisión y configuración de mecanismos de replicación/duplicación
• Clientes de OpCo: supervisión de la utilización con fines de facturación
• Clientes que poseen dispositivos pueden utilizar las herramientas de gestión de versiones para implementar actualizaciones de software y asegurarse de que están funcionando correctamente.
• Usuarios finales que utilizan dispositivos pueden utilizar servicios web que les permiten interactuar con los dispositivos 120 que utilizan.
Se pueden desarrollar muchas otras aplicaciones verticales 20 para satisfacer las necesidades de los mercados verticales. Un ejemplo puede incluir UBI, armarios conectados, RMCS.
Las aplicaciones verticales 20 se pueden comunicar con el DMAP 60 a través de la interfaz en dirección norte (NBi) 160. Esto también se conoce como gestión de dispositivos o bus de DM 55.
La NBi 160 puede proporcionar una interfaz de bus para comunicarse y controlar los activos M2M físicos gestionados por la plataforma de DM.
La NBi 160 puede permitir comunicaciones bidireccionales, entre las aplicaciones verticales 20 y la NBi del DMAP. Las comunicaciones pueden utilizar servicios web y las conexiones se pueden establecer mediante las aplicaciones verticales 20 a la NBi del DMAP o desde el DMAP 60 a las aplicaciones verticales 20, por ejemplo.
Las conexiones iniciadas desde DMAP a la aplicación vertical se denominan devoluciones de llamada.
Protocolo de bus de DM
La figura 2 ilustra esquemáticamente un método 80 de utilización de la NBi 160. Todos los flujos de datos a través del bus de NBi pueden operar dentro del contexto de una conexión. Una conexión puede tener el propósito de una sola solicitud/respuesta o puede abarcar múltiples ciclos de solicitud/respuesta. La parte que se conecta puede realizar autenticación AAA. Una vez autenticada, esa parte puede tener acceso autorizado a activos predefinidos bajo el control del DMAP 60. El mecanismo de AAA puede soportar las tres funciones de AAA (Autenticación, Autorización y Contabilidad - Authentication, Authorisation and Accounting, en inglés).
Las aplicaciones de gestión 85 pueden incluir registro, alertas, diagnósticos y análisis. Las aplicaciones de cliente 90 pueden incluir cualquiera de las aplicaciones verticales 20 descritas anteriormente o aplicaciones adicionales. Un bus de arquitectura de empresa 95 proporciona una interfaz entre las aplicaciones 85, 90 y el DMAP 60. Esto puede ser a través de una red interna o externa, por ejemplo. Los buses de seguridad y control de dispositivos proporcionan interfaces entre el DMAP 60 y un inicio de sesión único (SSO - Single Sign-On, en inglés) 105 y una plataforma de servicio global de datos (GDSP - Global Data Service Platform, en inglés) 108 componentes, respectivamente. Un bus de datos de dispositivo 100 puede proporcionar una interfaz entre el DMAP 60 y los dispositivos gestionados (por ejemplo, dispositivos individuales 120, otras plataformas de DM 130 o uno o más concentradores de puerta de enlace 140) sobre una o más redes de portadoras 110. Estas redes de portadoras pueden incluir redes celulares, inalámbricas o cableadas.
El DMAP 60 puede requerir una interfaz de administración para el personal de operaciones. Por ejemplo, esta puede ser utilizada para administrar los derechos de acceso para las partes en dirección norte, que luego son aplicados por AAA. Se puede incluir una interfaz de O&M, pero esto puede tratarse como un caso especial, y entrará en una zona de seguridad de O&M. Una aplicación administrativa vertical puede realizar funciones de tipo de administrador/panel. Los problemas de gestión/tiempo de espera/colas de la conexión pueden ser resueltos mediante una interfaz de captura de administración/kpi estandarizada. Los activos se pueden describir en términos de estructuras de datos, donde los controles de acceso se definen utilizando una notación basada en roles. Una conexión autenticada puede estar autorizada para tener diferentes niveles de acceso a los activos utilizando un modelo de seguridad basado en roles. Por ejemplo, este puede utilizar un modelo JSON/XML, donde tanto las solicitudes como las respuestas se describen utilizando estructuras de datos “bien formadas” (es decir, XML).
Para cumplir con los requisitos de seguridad, esta aplicación/protocolo de bus de DM puede utilizar cifrado SSL basado en mecanismos de autenticación basados en certificados. Además, las VPN se pueden utilizar adecuadamente para garantizar la separación correcta del tráfico de datos a través del Bus de DM 55. El tráfico del Bus de DM a las aplicaciones de gestión interna puede ser transmitido a través de VPN separadas, al tráfico que pasa a las aplicaciones verticales 20 de terceros en la Internet pública.
Mecanismos de acceso al bus de DM
haberse pueden soportar varios tipos de acceso:
1) API de acceso/configuración de DM: un mecanismo de API que permite a las aplicaciones de terceros realizar consultas directas y emitir comandos al DMAP 60 y obtener respuestas síncronas/inmediatas;
2) API de acceso de DM: un mecanismo de API que permite que las aplicaciones de terceros realicen consultas directas al DMAP 60 y obtengan respuestas asíncronas (se pueden utilizar dos API diferentes o una con un indicado, por ejemplo);
3) http de acceso/configuración de DM: un mecanismo de consulta de http que permite consultas web de terceros;
4) Devolución de llamada: las solicitudes asíncronas pueden devolver conjuntos de resultados de datos mediante un mecanismo de devolución de llamada XML. Esto puede ser a través de varias URL.
Pueden surgir solicitudes síncronas cuando se solicita una consulta o una acción y los resultados se pueden devolver de inmediato. Pueden surgir solicitudes asíncronas cuando se solicitan consultas y los resultados estarán disponibles en un momento posterior. La sincronización puede ser mantenida por un componente o función separada o integrada.
Solicitudes síncronas
Las solicitudes síncronas se pueden utilizar cuando el resultado o el estado de una acción resultante se conoce de inmediato. Si el estado cambia, se pueden utilizar varias consultas para sondear el estado. Si bien el sondeo es simple, puede que no sea muy eficiente.
Solicitudes asíncronas
Esto proporciona un mecanismo para tratar con condiciones o eventos cambiantes de una manera más eficiente. Cuando la acción resultante de una solicitud asíncrona genera un resultado, este resultado puede ser devuelto a una URL especificada y los datos del resultado pueden ser encapsulados utilizando una notación XML. Este tipo de solicitud se puede utilizar cuando:
• Habrá un retraso (de duración posiblemente impredecible) antes de que se pueda completar la solicitud
• Se generarán múltiples respuestas (conjuntos de resultados). Estos podrían ser implementados de manera síncrona utilizando cursores (según SQL), pero eso agrega complejidad.
• Un dispositivo envía notificaciones a la plataforma M2M (por ejemplo, excepciones o notificaciones programadas de los datos del sensor).
Las acciones que se aplicarán a dispositivos particulares o a grupos de dispositivos pueden ser almacenadas dentro de una ubicación de almacenamiento dentro de la memoria (volátil o no volátil) y, a continuación, ser sincronizadas o aplicadas al dispositivo inmediatamente o después de un período de tiempo (ya sea programado o según sea necesario en las condiciones inmediatas). Las acciones pueden ser cambiar, agregar, actualizar o eliminar un valor o atributo particular de un dispositivo u obtener datos del dispositivo.
Por lo tanto, la sincronización puede ser bidireccional.
El mecanismo de devolución de llamada también se puede utilizar para notificaciones de datos de sensores enviadas desde un dispositivo. Las alertas, los datos de los sensores, los diagnósticos y los captadores asíncronos pueden utilizar el mismo mecanismo de devolución de llamada.
Mecanismo de devolución de llamada
El mecanismo de devolución de llamada de URL puede ser implementado como un mecanismo de establecimiento, donde la acción solicitada se comunicará de nuevo a la aplicación que invoca, por medio de una URL especificada. La ventaja de este enfoque es que hace un uso muy eficiente de los recursos y se puede utilizar para describir comportamientos sofisticados de una manera sencilla.
Devolución de llamada: resultado único
Las solicitudes asíncronas se pueden utilizar cuando se solicita una sola acción y puede haber un retraso de tiempo desconocido entre la solicitud y la acción. Por ejemplo, un comando para bloquear y limpiar un dispositivo solo se puede ejecutar después de que la plataforma de DM haya establecido contacto con el dispositivo identificado. Si el dispositivo está apagado, puede que tarde algún tiempo antes de que se complete la operación (o se agote el tiempo de espera).
Devolución de llamada: resultados múltiples
Las solicitudes asíncronas se pueden utilizar cuando haya más de un resultado. Esto podría ser ningún resultado o potencialmente un número infinito de resultados. Un ejemplo puede ser una consulta de dispositivos con un nivel de señal bajo. Puede haber una cantidad variable de dispositivos que satisfagan esta solicitud y devuelvan resultados durante un período de tiempo extendido. El mecanismo de devolución de llamada proporciona un mecanismo para transferir esta secuencia de respuestas de una manera relativamente simple.
Devolución de llamada: registro de resultados y datos del sensor
Los resultados de los datos del sensor pueden ser suministrados a una aplicación de control por medio del mecanismo de devolución de llamada. La aplicación solicitante puede describir los datos de interés del sensor, las condiciones que harán que se suministre y la devolución de llamada de URL a la que pasar estos datos del sensor. Nota: Varias aplicaciones pueden ver potencialmente los mismos datos del sensor, simplemente describiendo múltiples solicitudes de devolución de llamada.
Devolución de llamada: alertas
Pueden surgir alertas cuando ocurre algún evento que necesita ser registrado y la información que describe el evento necesita ser comunicada. Una alerta puede ser el modo en que describe un elemento de activación que hará que se genere la alerta. La condición de activación podría ser simple, por ejemplo, un campo de datos tiene un valor especificado o el valor entra en un rango especificado.
Las alertas y el envío de datos de sensores se pueden implementar de la misma manera. El envío programado de datos de sensores también se puede considerar como alertas.
Se pueden especificar elementos de activación de alerta más sofisticados, con múltiples condiciones combinadas utilizando lógica booleana.
Devolución de llamada: diagnóstico
Conceptualmente, estos funcionan de manera similar a las alertas de devolución de llamada. La única diferencia será cómo se define una alerta de diagnóstico. Los diagnósticos pueden ser de interés para ayudar a las organizaciones con 1°, 2°, 3° responsabilidades de soporte de línea del Soporte técnico. Los mecanismos de diagnóstico pueden ser gestionados por aplicaciones 20 bajo el control de este tipo de Organización.
Devolución de llamada: especificación de elementos de activación/pares de acciones
Una aplicación puede solicitar actividades asíncronas (devoluciones de llamada) invocando solicitudes con la URL que describe dónde se enviarán las respuestas de datos de devolución de llamada. Las devoluciones de llamada para datos de sensores, alertas y diagnósticos pueden utilizar este mismo mecanismo y pueden realizar sus funciones especificando una devolución de llamada con una condición de activación. La condición de activación y la acción consiguiente forman un par. Esta API puede contener:
• URL de devolución de llamada: donde las devoluciones de llamada pasan datos cuando se activa el elemento de activación
• Definición XML de estructuras de datos que se pasarán a la URL cuando se active el elemento de activación
• Definición XML del elemento de activación que hará que se dispare una devolución de llamada. Esta definición de elemento de activación puede consistir en un conjunto de condiciones y relaciones booleanas entre condiciones.
• Se puede asignar un nombre para el par elemento de activación/acción, una vez que se ha definido y nombrado el par elemento de activación/acción, a dispositivos específicos o colecciones de dispositivos.
Utilización de devoluciones de llamada
Los parámetros de devolución de llamada pueden ser especificados en una única llamada a la API o, alternativamente, se pueden utilizar definiciones previamente definidas y nombradas de:
• las estructuras de datos que se pasarán en la URL;
• la especificación del elemento de activación.
En el caso de las alertas, los datos de diagnóstico y sensor y la devolución de llamada con nombre más la especificación del elemento de activación se pueden asociar con un dispositivo de una de estas tres formas a modo de ejemplo:
1) tipo de dispositivo, todos los dispositivos de un tipo específico;
2) versión del dispositivo, todos los dispositivos de una versión específica;
3) dispositivo, dispositivo por dispositivo.
Cuando los datos de instancia de un dispositivo (un término de programación que describe los objetos de datos asignados a un objeto - el objeto puede ser un objeto de dispositivo virtualizado) cambian, en primer lugar, procesará todas las devoluciones de llamada asociadas con ese dispositivo, a continuación, procesará las devoluciones de llamada especificadas en el nivel de versión del dispositivo y, finalmente, procesará las devoluciones de llamada a nivel de tipo de dispositivo. Se pueden nombrar todas las devoluciones de llamada. Una vez que se ha realizado una devolución de llamada con nombre, es posible que no se activen las devoluciones de llamada con el mismo nombre en niveles superiores (versión del dispositivo, tipo de dispositivo).
Este enfoque de utilizar estructuras de datos con nombre y elementos de activación ofrece la capacidad de modificar las estructuras de datos devueltos y los elementos de activación de manera dinámica, sin la necesidad de modificar los programas de aplicación, o incluso la necesidad de reiniciar esas aplicaciones.
Utilización de casos de ejemplo:
• Una aplicación de cliente describe una lista de elementos de activación que es un conjunto de condiciones que indican que un dispositivo está defectuoso. Estas condiciones se definen en términos de valores que indican que un dispositivo tiene un fallo específico (la lista de elementos de activación). Los valores son solo ejemplos. Se puede establecer cualquier valor y se pueden utilizar diferentes condiciones.
° Nivel de potencia < 12,
° Versión del dispositivo 2.56,
° Lectura de temperatura > 34
• Una devolución de llamada está definida en la plataforma de servicios web del cliente. Esta definición incluye: ° URL del servicio web
° Credenciales de nombre de usuario/contraseña para acceder a la aplicación del cliente
° Estructuras de datos que se comunicarán a través de la URL del servicio web
• Se crea una alerta/diagnóstico en términos de:
° Tipos de dispositivos,
° Listas de elementos de activación
° Devolución de llamada
El método de devolución de llamada puede ser el modo ventajoso de integrarse con las aplicaciones 20 del cliente. Una alternativa pueden ser los captadores síncronos que realizan un sondeo.
La última etapa en este caso de utilización puede hacer que la alerta/diagnóstico se asocie con la estructura de instancia del dispositivo que representa los tipos de dispositivo. Si ya existe una alerta/diagnóstico, se puede sobrescribir con esta nueva definición.
Este enfoque permite especificar la alerta/diagnóstico para un solo dispositivo, una colección de dispositivos en el mismo nivel de versión o todos los dispositivos de una clase de dispositivo especificada.
Un elemento de activación con nombre, definida para detectar un dispositivo con un error de hardware específico, podría ser refinada con el tiempo para activarse en diferentes circunstancias. Con el tiempo, el personal de soporte o un sistema automatizado pueden refinar el elemento de activación, por lo que es más selectivo y preciso en la identificación de un fallo, condición o criterio específico. Una vez modificada, el elemento de activación se puede activar y todas las aplicaciones que utilizan ese elemento de activación con nombre pueden comenzar a recibir devoluciones de llamada para dispositivos que coincidan con las condiciones de activación nuevas y refinadas. Este mecanismo de activación/acción permitirá al equipo de soporte crear una capacidad de diagnóstico/alerta cada vez más sofisticada mediante el perfeccionamiento con el tiempo. de los elementos de activación A medida que se diagnostican nuevos fallos o se cumplen otros criterios, los elementos de activación pueden ser definidas o redefinidas para que sean más específicas y selectivas.
De manera similar, cuando se define la alerta/diagnóstico, es posible definirla para dispositivos individuales, o dispositivos en versiones específicas, o para todos los dispositivos de un tipo específico.
La API interfaz en dirección norte puede tener uno o más de los siguientes:
• Se puede proporcionar una especificación de API que sea utilizable por terceros que utilicen la interfaz en dirección norte 160.
• El conjunto de los API puede ser ACCESO y CONFIGURACIÓN extremadamente simples con variantes asíncronas. La complejidad y el detalle pueden variar y dependen de los objetos que pueden ser ALCANZADOS y CONFIGURADOS, por ejemplo, el modelo de datos del dispositivo.
• La Interfaz en dirección norte 160 puede ser una o más de las siguientes:
° Interfaz de llamada a procedimiento remoto basado en SOAP
° Interfaz RESTful basada en http y URL de recursos
° Interfaz de servicios web utilizando SOAP
o JSON
° Otro
• Llamada a procedimiento remoto (RPC): esto puede dar como resultado un acoplamiento muy estrecho entre las aplicaciones 20 y los dispositivos virtuales que pueden formar parte de una solución de tipo de iniciativa de puerta de enlace de servicio abierto (OSGi - Open Service Gateway Initiative, en inglés).
• APi de Acceso/Configuración y Http de Acceso/Configuración. Estos dan como resultado una función similar, pero incluyen soporte para actualizaciones asíncronas.
• La estructura de devolución de llamada puede ser escalada. La NBi 160 se puede distribuir entre múltiples DMAP y múltiples verticales en dirección norte.
• La interfaz en dirección norte 160 puede actuar como una interfaz SaaS para aplicaciones verticales.
La API Acceso/Configuración o la interfaz en dirección norte 160 puede utilizar una API ofrecida a los usuarios o clientes por un servidor en la nube (por ejemplo, el servicio en la nube de Sierra Wireless). SNMP puede utilizar el mismo enfoque, pero donde las devoluciones de llamada se implementan utilizando servidores de trampas (traps, en inglés). La utilización de servicios web para comunicarse entre aplicaciones en ambas direcciones se puede utilizar para gestionar el flujo de información bidireccional entre aplicaciones compatibles con servicios web.
El servidor DMAP
El software puede estar alojado en una nube. Se pueden utilizar configuraciones de nube, principal/secundaria, proxy y de reenvío.
El proxy de aplicaciones de gestión de dispositivos 60 puede utilizar un mecanismo declarativo para describir todas las operaciones, objetos y acciones. Cada servidor de DMAP puede gestionar:
• Colecciones de dispositivos gestionados 120, que pueden ser de muchos tipos y/o versiones diferentes
• Un mecanismo de descubrimiento de dispositivos, para que los dispositivos de conexión puedan ser agregados a los estados de dispositivos gestionados (controlados por el dispositivo o por el usuario)
• Un mecanismo de registro/cancelación de registro de dispositivos, para que los dispositivos puedan ser colocados en estados alternativos
• Imágenes de firmware y las estructuras lógicas/de datos necesarias para realizar operaciones de actualización de firmware en colecciones de dispositivos de diferentes tipos y/o versiones (el servidor puede obtener imágenes de firmware de una función de NBi, por ejemplo). El modelo de datos para el dispositivo puede necesitar soportar el control de versiones del firmware. Una imagen de software puede ser considerada como un elemento en el modelo de datos, que tendrá una versión Y una función de configuración para iniciar la carga e instalar el firmware. Lo mismo se puede aplicar al software de aplicación que reside en el dispositivo.
• Imágenes de software de aplicación y las estructuras lógicas/de datos necesarias para realizar operaciones de actualización de software de aplicación en colecciones de dispositivos de muchos tipos y/o versiones diferentes. Catalogar y administrar qué software está instalado en cada dispositivo es una función de aplicación vertical de nivel superior (cabecera)
• Devoluciones de llamada y la especificación y credenciales de seguridad para que funcionen esas devoluciones de llamada
• Elementos de activación y la descripción de las condiciones o criterios de activación necesarios para que un dispositivo provoque la activación de un elemento de activación
• Asignación (Mapping, en inglés) de dispositivo/devolución de llamada/elemento de activación para soportar la generación de alertas, diagnósticos, registros y eventos de datos de sensores y datos de eventos adecuados para transferirlos a las devoluciones de llamada registradas.
La figura 4 ilustra esquemáticamente la interacción de diversos tipos de usuarios con la NBi 160 a través de uno o más buses de DM 55, para proporcionar una ruta hacia el DMAP 60 para controlar y supervisar los dispositivos 120. Los usuarios 155 pueden incluir usuarios finales 156, clientes 157 y varios OpCo 158, por ejemplo.
El motor de procesamiento 165 del servidor de DMAP puede estar limitado a un pequeño conjunto de procesos simples. Un ejemplo de implementación se muestra esquemáticamente en la figura 5. Estos pueden ser implementados como múltiples subprocesos de actividad o procesos de un solo subproceso ejecutados en secuencia. Los procesos pueden acceder a las instancias del dispositivo, y los mecanismos de sincronización pueden funcionar a nivel de instancia de dispositivo (es decir, los procesos pueden no tener ninguna visibilidad de ellos).
Instancias de dispositivo
Se puede crear una instancia de cada dispositivo físico 120 gestionado por el servidor de DM. Estos datos de instancia de dispositivo pueden contener toda la información más reciente perteneciente a un dispositivo físico 120 y pueden ser considerados como una virtualización de un dispositivo físico 120. El contenido de los datos de instancia del dispositivo puede ser referenciado utilizando la interfaz en dirección norte 160 utilizando cualquiera de los captadores/mecanismos de configuración.
Los configuradores no se limitan a establecer valores de datos, sino que también pueden soportar la capacidad de invocar comandos. Por ejemplo, una instancia de Variable de datos que representa borrar/bloquear, puede ser utilizada para soportar el mecanismo de Limpiar/Bloquear realizando una operación de establecimiento de bloqueo (o bloquear y limpiar) en la variable de instancia de dispositivo que representa limpiar/bloquear.
Los datos de instancia de dispositivo pueden tener una referencia a un objeto Clase del dispositivo (es decir, puede haber un solo objeto de datos de clase del dispositivo para cada tipo de dispositivo). Estos datos también pueden incluir referencias a un objeto Instancia de versión del dispositivo (véase la sección Instancia de versión de dispositivo).
El objeto Versión del dispositivo puede contener una estructura de datos que describe el modelo de datos utilizado por los dispositivos en el nivel de versión especificado.
Por lo tanto, una instancia de dispositivo puede tener una referencia a un objeto Versión del dispositivo que puede contener el modelo de datos utilizado por todos los dispositivos de ese tipo y versión de dispositivo. Estas estructuras y relaciones de datos pueden soportar los mecanismos necesarios para la transición de dispositivos entre versiones de firmware, por ejemplo.
Modelo de datos de instancia de dispositivo
Se puede definir un modelo de datos de dispositivo, dado el conocimiento a priori de los modelos de datos de dispositivo utilizados en los documentos TR-069 y OMA LWM2M (así como otros protocolos de ejemplo). Por lo tanto, el desarrollo posterior de adaptadores puede resultar más sencillo. Esto se asigna directamente a los modelos de datos LWM2M TR-069 y SNMP MIB. Se pueden incluir características y estructuras adicionales.
En este ejemplo, el modelo funciona en uno o más de cuatro niveles:
1) La vista de aplicaciones verticales
2) La vista de DMAP
3) La vista de protocolo (LWM2M)
4) La vista del dispositivo
Cada nivel puede tener diferentes requisitos, pero, preferentemente, se puede utilizar una única definición XML del modelo de datos del dispositivo y, a partir de la misma, se pueden generar las estructuras necesarias para los diferentes niveles (véase Herramienta de modelizado de datos del SDK (Kit de desarrollo de software - Software Development Kit, en inglés)).
Los datos de instancia de dispositivo se pueden definir mediante un modelo de datos, donde cada versión de cada dispositivo puede tener un modelo de datos asociado. Este modelo de datos puede adoptar la forma de una estructura de árbol definida en XML (por ejemplo), donde cada nodo del árbol describe un elemento de datos de un tipo específico con atributos definidos y metainformación asociada al mismo. Alternativamente, puede ser un nodo de rama en el árbol de elementos de datos.
La figura 6 muestra un diagrama esquemático de un modelo de datos 190 a modo de ejemplo. En esta figura, el protector de pantalla se muestra como un nodo hoja que describe un objeto protector de pantalla. Podría ser un tipo de cadena que contiene una referencia a un archivo que es el protector de pantalla, o podría ser del tipo Objeto grande binario (BLOB - Binary Large OBject, en inglés) y contener el contenido de datos binarios de un archivo JPG u otro archivo de imagen, por ejemplo.
El nodo Señales de llamada se muestra como un nodo de rama y, en este ejemplo, puede contener referencias a varios objetos de datos de Señal de llamada diferentes.
La metainformación del modelo de datos puede contener una serie de atributos que pueden limitar el modo en que se utilizarán los datos de la instancia del dispositivo, esto puede incluir (pero se puede extender a):
• Roles de seguridad: puede haber múltiples roles de seguridad asignados a cada elemento de datos descrito en el modelo de datos, donde los roles limitarán los derechos de acceso permitidos por diferentes actores al interactuar con los elementos de datos instanciados de un dispositivo. Los roles de seguridad se pueden heredar, lo que permite que una estructura de nodo de rama de alto nivel posea la definición de seguridad para todos los elementos de datos subordinados a la misma.
• Valores predeterminados: se pueden utilizar para la serialización y cuando se crean instancias de elementos de datos por primera vez (soportando la transición entre versiones de firmware).
• Rangos de valores válidos: se pueden utilizar para la normalización de datos (necesarios para soportar el análisis de datos)
• Validación principal/secundaria: estas pueden ser utilizadas por un desarrollador del dispositivo para definir los rangos válidos de valores que un dispositivo puede contener. Esto permite que el modelizador de datos describa los valores legales o válidos de los datos que se pueden mantener en un elemento de datos.
• Reglas de serialización: describe cómo se replicará/clonará un elemento de datos
• Reglas de puntualidad: la frecuencia con la que se debe actualizar este elemento de datos
Objetos complejos
Arquitectónicamente, el modelo de datos puede tener una estructura jerárquica. Esto se puede representar mediante un sistema de base de datos relacional, lo que significa que el desarrollador puede utilizar una base de datos, si es necesario. Sin embargo, puede ser preferente que el desarrollador diseñe un modelo de datos de manera inteligente.
El modelo de datos 190 permite al desarrollador representar colecciones de estructuras de datos relacionadas, como si fueran objetos de datos únicos. La figura 7 muestra otro modelo de datos 200 a modo de ejemplo. En este ejemplo, el objeto Listas de DM es un área de lista y hace referencia a múltiples estructuras de lista (por ejemplo, nombres de lista que tienen, cada uno, características de lista). Cada una de estas listas representa diferentes categorías de objetos de datos.
La ventaja de agrupar de esta manera colecciones de diferentes elementos de datos es que las estructuras de datos con usos similares pueden ser manipuladas conjuntamente como si fueran objetos individuales. Tal como se muestra en esta figura, se muestran tres estructuras de lista a modo de ejemplo, que tienen diferentes roles de seguridad.
Modelo de datos del dispositivo: metadatos
El modelo de datos del dispositivo permite al desarrollador describir todos los elementos de datos asociados con un dispositivo, en términos de nombres, tipos de datos, valores predeterminados y rangos de valores válidos (es decir, para la normalización, validación y optimización del procesamiento analítico).
Los modelos de datos de dispositivos pueden adoptar tres formas en este ejemplo:
• modelo de clase: donde se proporciona el modelo de datos para una clase (o tipo) de dispositivo;
• modelo de grupo: donde se proporciona el modelo de datos para una colección de dispositivos (donde la colección de dispositivos se define de alguna manera arbitraria). Téngase en cuenta que un dispositivo puede ser incluido en varios modelos de grupo; y
• modelo de instancia: donde el modelo de datos es específico para un dispositivo físico específico.
La precedencia de los modelos múltiples puede seguir el orden Clase-Grupo-Instancia, donde la instancia anula al grupo, que anula a la clase.
Además de la información del tipo de datos, el modelo de datos puede soportar otros tipos de metainformación acerca de los elementos de datos del dispositivo y las capacidades del dispositivo. Este puede incluir:
• Informativo y descriptivo. Este se puede utilizar, dicho de manera prosaica, simplemente para documentar las capacidades y comportamientos del dispositivo, y puede hacer referencia a otras fuentes de información y de documentación relevantes para el dispositivo. Tiene aplicaciones interesantes, cuando se consideran las interacciones entre diferentes tipos de dispositivos y sistemas taxonómicos para describir dispositivos. Un caso de utilización puede ser un dispositivo habilitado para una baliza electrónica (iBeacon, en inglés) (o similar), que reconoce tipos específicos de dispositivos, y cuando una baliza electrónica detecta un dispositivo que reconoce y con el que puede interactuar. Ejemplos de casos de utilización de esto incluyen la utilización en automóviles, sistemas de peaje y sistemas de estacionamiento de automóviles.
• Oportunidad. Esta información se puede utilizar para describir la importancia de un elemento de datos y la frecuencia con la que el Gestor de dispositivos debe intentar actualizar la información. Un ejemplo pueden ser las lecturas de un medidor de potencia, donde se requiere al menos una lectura del medidor en un período de 24 horas. La inclusión de atributos de metadatos de oportunidad permite que los sistemas de conectividad funcionen en conjunto con los dispositivos físicos, para automatizar las actividades de recopilación de datos y para la optimización (por ejemplo, funcionando durante tiempos de baja actividad celular). Se puede incluir metainformación adicional para describir acciones de alerta para ser invocadas en caso de que no se cumplan los requisitos de oportunidad de un elemento de datos específico.
• Control de acceso de seguridad y definiciones de roles. Estos metadatos se pueden utilizar para completar los almacenes de políticas asociados que se utilizan para proporcionar mecanismos de seguridad de control de acceso y autorización.
• Requisitos de seguridad, integridad/confidencialidad. Los requisitos de seguridad adicionales pueden requerir la utilización de metadatos para describir las reglas y actividades de gestión de la seguridad para los diferentes tipos de datos. La utilización del enfoque declarativo ofrece una solución genérica que puede cumplir con estos requisitos de seguridad. Este puede incluir:
o mecanismos de cifrado para diferentes niveles de material confidencial;
o escaneo de software malicioso (malware, en inglés) en busca de datos binarios (entrada y salida);
o mecanismos de confidencialidad a nivel de aplicación/dispositivo para tipos específicos de elementos de datos (por ejemplo, Javacard). Esto permite al desarrollador de dispositivos diseñar mecanismos que respalden la transferencia de datos y código de subprograma hacia y desde dispositivos de manera segura;
• Validación principal/secundaria: el desarrollador del dispositivo puede utilizarlas para definir los rangos válidos de valores que puede contener un dispositivo. También se pueden definir reglas de manejo de excepciones, que pueden soportar valores predeterminados y acciones de alerta.
• Derechos de publicación. Esta puede ser información de nivel superior utilizada para describir y restringir cómo se utilizan los datos del dispositivo. Esto puede ir más allá de Leer/Escribir/Eliminar y puede ser más genérico al describir cómo los elementos de datos se pueden utilizar y compartir con otros sistemas. Un caso de utilización de ejemplo sería un dispositivo de armario conectado que dispensa refrescos. Si las actividades de dispensación de un dispositivo fueran publicables, esto puede proporcionar información analítica valiosa sobre los comportamientos de la población en general. Por ejemplo, la cantidad de latas de bebidas consumidas por hora puede ser correlacionada, y ser utilizada como un predictor de cuántas hamburguesas venderá una cadena de hamburguesas en los siguientes 30 minutos. El enfoque del modelo de datos declarativos permite al usuario del dispositivo decidir si los datos del dispositivo pueden ser utilizados por terceros para respaldar estos requisitos de análisis de “mayor valor”.
• Monetización de datos con fines analíticos. El modelo declarativo permite a los usuarios de un punto de datos comprender el valor del punto de datos con fines analíticos (por ejemplo, utilizando el caso de utilización anterior de “dispensador de latas de bebidas gaseosas”). cuando se realiza un análisis, los algoritmos analíticos pueden analizar y asignar “pesos” a diferentes puntos de datos, donde el peso puede indicar el valor del punto de datos en la predicción de algún valor. El peso asignado a los elementos de datos asociados con un dispositivo de venta de latas de bebidas gaseosas podría ser alto (por ejemplo), para predecir las ventas de hamburguesas, pero bajo para predecir el precio del café en los mercados de futuros. Estos pesos se pueden utilizar para determinar el valor individual y general de un punto de datos como predictor analítico. Esto presenta una oportunidad para asignar un valor al elemento de datos y ofrecer al propietario de la información representada por el punto de datos un incentivo para revelar el elemento de datos para la utilización analítica por parte de terceros.
• Requisitos de almacenamiento/divulgación. Esto está relacionado con los metadatos de derechos de publicación, y está limitado a definir cómo y dónde se pueden archivar y almacenar los valores de un elemento de datos. Esta metainformación puede ser utilizada para controlar, gestionar, supervisar y hacer cumplir los requisitos de privacidad.
• Procesamiento de pistas y sugerencias de optimización. Se trata de información de bajo nivel que pueden utilizar los dispositivos físicos (y los autores del software que se ejecuta en esos dispositivos) para describir cómo se pueden procesar los elementos de datos. Un caso de utilización a modo de ejemplo sería una medición de la temperatura promedio durante un período de tiempo preciso (por ejemplo, una media móvil). Para calcular las medias móviles, se debe almacenar un registro de los últimos n valores capturados (donde n describe el número de valores anteriores utilizados para calcular la media móvil). Si la plataforma de gestión de dispositivos intentara hacer esto, podría necesitar muestrear continuamente la información que se promedia (lo que sería costoso en términos de conectividad e informáticos. Definir el modo en que se están agregando los elementos de datos como parte del modelo de datos declarativo, permite al desarrollador del dispositivo describir los comportamientos del dispositivo de bajo nivel que pueden ser implementados automáticamente en el dispositivo. (Esto supone que el software del agente en el dispositivo ha sido implementado para comprender estas sugerencias declarativas).
• Reglas de serialización: describen cómo se puede replicar/clonar un elemento de datos. Estas pueden ser utilizadas por mecanismos de resiliencia, para priorizar qué elementos de datos son importantes y también los mecanismos técnicos utilizados para facilitar la replicación y la clonación.
• Información de versiones. Es posible que estén soportadas actualizaciones de software y/o firmware, pero dicha actividad puede ser difícil de gestionar, especialmente durante las transiciones de versiones de software o firmware, ya que esto puede implicar cambios en el modelo de datos. Un ejemplo sería cuando se introduce un nuevo elemento de datos para la siguiente versión del firmware de un dispositivo. Los metadatos que describen este nuevo elemento de datos pueden incluir información que describa cómo se introducirá el nuevo elemento de datos y cómo se hará la transición entre lanzamientos.
• Requisitos de topología adicionales. Los modelos de datos para representar dispositivos concentradores pueden requerir la capacidad de “conectar” dispositivos de maneras impredecibles o ad hoc. Este caso de utilización involucra un enrutador móvil inalámbrico M2M conocido como Machine Link 3G (ML3G). Este es un dispositivo concentrador que proporciona conectividad Ethernet a otros dispositivos (de cualquier tipo). Potencialmente, esta conectividad podría incluir conectividad a otros dispositivos ML3G, lo que da como resultado una multitud de posibles modelos topológicos, que comprenden subredes de árbol, estrella y malla, por ejemplo. Se pueden utilizar metadatos para describir los puntos de conexión de conectividad del dispositivo, y estos puntos de conexión deben proporcionar enlaces simples a estructuras de DM equivalentes que representen un dispositivo adjunto. Este enfoque relativamente simple implica que:
° cada dispositivo de Internet de las cosas (loT - Internet of Things, en inglés) que se conecta a un ML3G puede tener su propio modelo de datos que describe el dispositivo;
° las interrelaciones lógicas de los dispositivos de conexión se pueden representar mediante enlaces bidireccionales entre los dispositivos conectados entre padres e hijos utilizando los modelos de datos de DM;
° la comunicación física de los dispositivos conectados a la plataforma de DM puede ser promediada utilizando (a través de algunos protocolos aún no definidos) el dispositivo ML3G principal.
El siguiente ejemplo de aplicación asigna listas de características a estructuras de datos de OMA-DM. En este ejemplo de aplicación, el diseñador de productos M2M ha desarrollado un dispositivo M2M para supervisar la fuente de alimentación de 12 voltios a un aparato de consumo de baja tensión. Para facilitar la utilización del dispositivo, ha creado tres listas de funciones:
• Lista-Sitio: contiene la ubicación del cliente y los detalles de contacto. Esta lista contiene información confidencial de seguridad (los detalles de los clientes), por lo que en el uso normal solo la utilizarían aplicaciones que requieran el conocimiento de los detalles de los clientes.
• Lista-Versión: contiene todos los elementos que describen la versión del software y hardware M2M. Esta lista se utilizaría normalmente cuando se realizan diagnósticos y cuando se aplican actualizaciones, parches y correcciones de software.
• Lista-Sensores: esta lista contiene datos de sensores específicos de este dispositivo.
Definición de listas de características
El diseñador del dispositivo especificará las listas de funciones soportadas por el dispositivo. Esta especificación describirá cómo se asignan los datos desde el dispositivo a las estructuras de datos de la lista de características, y esta asignación se describirá de una manera adecuada (es decir, utilizando una notación de declaración XML). Por ejemplo, la lectura de un sensor de temperatura puede ser asignada en la lista de funciones Lista-Sensores descrita anteriormente. En el ejemplo, hay dos sensores de temperatura diferentes, uno es un sensor de placa destinado a medir la temperatura del dispositivo M2M y un segundo sensor, diseñado para medir la temperatura ambiente de la habitación.
La asignación de los elementos de datos en la lista de características también puede implicar algún procesamiento de datos; en el caso del sensor de temperatura, la asignación puede implicar tomar la media de una serie de lecturas o una lectura de valor máximo. Independientemente de esto, el mecanismo permite al desarrollador del dispositivo especificar qué funciones están disponibles para diferentes aplicaciones de una manera específica para cada función.
Utilización de listas de características
Diferentes aplicaciones pueden hacer uso de diferentes listas de funciones. El ejemplo anterior describe un dispositivo con tres listas de funciones diferentes destinadas a ser utilizadas por tres tipos diferentes de aplicaciones, cada una con diferentes derechos de acceso de seguridad. Es posible que una empresa de terceros que presta un servicio que gestiona el mecanismo de actualización de firmware/software necesite acceder a las listas de versiones de cada dispositivo. Esto permite a la empresa que proporciona actualizaciones de manera inalámbrica (OTA - Over the Air, en inglés) un mecanismo para confirmar los detalles de la versión de los dispositivos que necesitan actualizaciones. La empresa de terceros no necesita saber qué significan los distintos campos en la lista de versiones. Todo lo que necesita saber es que el contenido de la lista de versiones debe coincidir con la información de la versión para una versión particular del software antes de comenzar el proceso de actualización.
El mismo enfoque se puede utilizar para diagnosticar defectos de dispositivos, la empresa que gestiona el proceso de diagnóstico de dispositivos no necesita conocer el contenido de las listas de características, todo lo que necesita es un modo de asignar los diferentes valores de la lista de características a las acciones a realizar.
Abstrayendo la identidad de los valores de los datos y lo que representan, es posible hacer uso de análisis avanzados en los datos de la lista de características, utilizando técnicas de aprendizaje automático supervisadas y no supervisadas. La organización que realiza el análisis de los datos capturados del dispositivo no necesita saber qué representan las distintas características, sino que todo lo que necesita saber es el tipo de datos y los rangos de valores. A partir de esta información, solamente, es posible identificar qué características de una lista de características son importantes para predecir tendencias y resultados futuros.
Uso de datos de series temporales en listas de características
Utilizando las listas de características a modo de ejemplo anteriores, existe una lista de características llamada Lista-Sensores. Normalmente, esto se procesará simplemente “accediendo” a los valores actuales de la lista de características. Una aplicación más avanzada de listas de características soporta el uso de datos de series temporales, mediante lo cual se crea periódicamente un elemento de lista de características (es decir, una vez cada 10 minutos).
Una estructura de datos de lista de características de varias filas (instancia) puede soportar la utilización de un conjunto de valores de lista de características. Esto proporcionaría a la aplicación un mecanismo para recopilar datos que habían sido obtenidos durante un período de tiempo.
Se puede capturar un conjunto de valores de sensor cada 10 minutos (u otro intervalo) y una aplicación CAPTARÍA” estos datos para procesarlos y analizarlos dos veces al día. Con una lista de características de varias filas, el desarrollador del dispositivo puede agregar el conjunto más reciente de valores de sensor en las listas de características de varias filas. Las aplicaciones que consultan estos datos pueden tener la capacidad de seleccionar valores individuales o rangos de valores.
Las listas de características proporcionan un mecanismo para describir cómo son asignados los datos a estructuras de datos específicas de roles. Muchos de los mecanismos para describir y acceder a estas estructuras de datos se toman prestados de la teoría de conjuntos y de la tecnología de bases de datos relacionales. Proporcionando un mecanismo declarativo para describir cómo se organizarán y dispondrán las colecciones de datos dentro de un entorno de dispositivo (por ejemplo, M2M), se simplifican las tareas involucradas en el uso de esos datos. Además de simplificar el trabajo del desarrollador de aplicaciones, también simplifica el proceso de seguridad porque, en ambos casos, las estructuras de datos de la Lista de características pueden ser utilizadas y protegidas mediante un enfoque basado en roles.
Una consecuencia de este proceso de abstracción es que ya no es necesario que las actividades de procesamiento de datos tengan conocimiento de cómo se organizan los datos, porque los datos siempre serán “entregados” de la misma manera al desarrollador de la aplicación. El desarrollador ya no necesita comprender cómo se generan los datos en el dispositivo o incluso qué representan los datos. Una salida de un sensor de temperatura es solo un número para procesar, y el procesador de esos datos no necesita saber que es una lectura de temperatura que podría indicar que un incendio está a punto de comenzar. Por el contrario, el procesador de la lectura de temperatura solo verá un número que excede un valor máximo que, a su vez, puede desencadenar un proceso de alerta adecuado para iniciar automáticamente una llamada a los servicios de emergencia.
Análisis de datos
Diferentes aplicaciones pueden hacer uso de las diferentes listas de diferentes maneras. El ejemplo de la figura 7 muestra un dispositivo con tres listas diferentes destinadas a ser utilizadas por tres tipos diferentes de aplicaciones, cada una con diferentes derechos de acceso de seguridad. Es posible que una entidad o empresa de terceros que presta un servicio que gestiona el mecanismo de actualización de firmware/software necesite acceder a las listas de versiones de cada dispositivo. Esto permitiría a la empresa o entidad que proporciona actualizaciones de manera inalámbrica (OTA) un mecanismo para confirmar los detalles de la versión de los dispositivos que necesitan actualizaciones. La empresa de terceros no necesita saber qué significan los distintos campos en la Lista de versiones. Todo lo que necesita saber es que el contenido de la Lista de versiones debe coincidir con la información de la versión para una versión particular del software antes de comenzar el proceso de actualización.
El mismo enfoque se puede utilizar para diagnosticar defectos de dispositivos, la empresa o entidad que gestiona el proceso de diagnóstico de dispositivos no necesita conocer el contenido de las listas de características; todo lo que necesita es el modo de asignar diferentes valores de la lista a las acciones a realizar, por medio de los mecanismos de devolución de llamada de activación/acción diseñados para soportar el diagnóstico de dispositivos.
Abstrayendo la identidad de los valores de los datos y lo que representan, es posible hacer uso de análisis avanzados en los datos de la lista, utilizando técnicas de aprendizaje automático supervisadas y no supervisadas, u otras analíticas, por ejemplo. La organización que realiza el análisis de los datos capturados del dispositivo no necesita saber qué representan los distintos elementos de datos. Por el contrario, todo lo que necesitan saber es el tipo de datos y los rangos de valores (disponibles a través de los mecanismos de reflexión del Modelo de datos de instancia del dispositivo). A partir de esta información, es posible identificar qué características de una lista son importantes para predecir tendencias y resultados futuros.
Actividades del SDK del modelo de datos
Los modelos de datos de dispositivos pueden contener muchas estructuras de datos complejas, relaciones y atributos, que requerirán habilidad para mantenerlos de manera precisa y correcta. Los desarrolladores pueden utilizar una herramienta de edición de modelos de datos para diseñar, desarrollar y mantener dispositivos. Esta herramienta de modelo de datos puede crear XML u otras estructuras de datos que describen las funcionalidades de un dispositivo, elementos de datos, seguridad, etc. que se pueden instanciar como parte de los objetos de instancia del modelo de datos del dispositivo.
Adicionalmente, este modelo de datos puede ser utilizado como un mecanismo para describir el procesamiento y el funcionamiento del dispositivo físico 120 y el código que se ejecuta en el mismo. Esto puede requerir que la herramienta Modelo de datos cree estructuras de datos de código que puedan utilizar los codificadores que trabajan en el dispositivo.
La figura 8 ilustra esquemáticamente una estructura de objeto de clase 210 a modo de ejemplo.
Instancias de clase del dispositivo
Los objetos Clase del dispositivo 215 pueden contener información genérica sobre un tipo de dispositivo, y su propósito es actuar como un punto de recolección para todas las actividades que se relacionan con todos los dispositivos de ese tipo.
Instancias de versión de dispositivo
Los objetos instancia de versión de dispositivo 220 pueden ser enlazados a un tipo de dispositivo y ser utilizados para contener información común a todos los dispositivos que están en ese nivel de versión. Este objeto puede encapsular la actualización del firmware/ lógica de aplicación para los dispositivos que están en transición entre niveles de versión de firmware o secuencias de niveles de versión. En este ejemplo, la gestión de firmware pasa por tres fases:
1) Cargue el firmware en el dispositivo;
2) Realice comprobaciones y cualquier otra preparación en el dispositivo antes de poner en funcionamiento el firmware; y
3) Aplique la actualización, es decir, conviértalo en el firmware actual en ejecución. Los datos específicos de esta versión pueden incluir:
1) Nombre de la versión: puede ser una cadena ASCII (una cadena ASCII terminada en nulo);
2) Referencia del firmware: referencia a una imagen binaria de firmware necesaria para llevar un dispositivo a esta versión de firmware;
3) Modelo de datos: referencia a una estructura de modelo de datos de instancia de dispositivo que describe los objetos de datos para dispositivos de esta instancia de firmware, así como también describe los elementos de datos que pueden estar asociados a dispositivos de este tipo/versión. Esta estructura de datos se puede utilizar para migrar datos de instancias de dispositivos entre diferentes versiones de firmware. Por ejemplo, esto puede ocurrir si una nueva versión de firmware soporta un objeto de datos adicional que describe la temperatura externa. La actualización del firmware puede hacer que el software del firmware cambie Y también ampliará el modelo de datos de instancia del dispositivo para incluir la nueva configuración de temperatura, elemento de datos, etc.; y 4) Enlace al objeto de la versión del siguiente dispositivo: se utiliza cuando un dispositivo debe pasar a un nuevo nivel de versión del dispositivo, el objeto de la versión del siguiente dispositivo al que se hace referencia puede describir todas las estructuras de datos necesarias para pasar al siguiente nivel de versión. Esto incluye la imagen de firmware para aplicar, todas las diferencias (adiciones, eliminaciones, cambios) entre los modelos de datos en transición entre niveles de versión.
Una ventaja de utilizar este enfoque declarativo para describir las imágenes de firmware y las diferencias de los modelos de datos, entre las imágenes de firmware, incluye la capacidad de
1) gestionar la transición de la versión de firmware que puede involucrar múltiples versiones de firmware;
2) gestionar los cambios del modelo de datos del dispositivo entre las versiones de firmware;
3) ofrecer la capacidad de revertir el proceso de transición del firmware, es decir, revertir los dispositivos a versiones anteriores; y
4) ofrecer la capacidad de soportar árboles de versiones de firmware. Esto permite aplicar diferentes versiones de firmware según los requisitos.
Relaciones de estructura de datos de dispositivo
Para un tipo de dispositivo en particular, puede haber una sola clase de dispositivo que represente a todos los dispositivos de ese tipo en particular. Alternativamente, los dispositivos de un tipo similar, pero con diferentes requisitos de versiones pueden ser representados mediante múltiples objetos Clase del dispositivo. En un ejemplo, un dispositivo puede tener requisitos de versiones significativamente diferentes, tal como un dispositivo diseñado para los mercados del idioma chino y los mercados europeos. Los dispositivos podrían ser tratados como tipos de dispositivos completamente diferentes.
El objeto Clase del dispositivo 215 tiene elementos de datos de miembros que son descriptivos del objeto Clase del dispositivo. Uno de estos miembros puede ser un enlace único a un objeto Versión del dispositivo.
El objeto Versión del dispositivo 220 encapsularía una descripción de un dispositivo específico en ese nivel de versión. Este objeto puede contener:
la imagen de firmware necesaria para llevar una versión del dispositivo a este nivel de versión;
el modelo de datos de instancia de dispositivo para el dispositivo en este nivel de versión (puede ser definido y administrado como datos XML, pero, internamente, se implementará utilizando objetos java, por ejemplo); y
un enlace al objeto de la siguiente versión (si hay uno) en la secuencia de versiones
El objeto Dispositivo 225 puede contener:
una referencia a la clase de dispositivo 215 y a la versión de dispositivo 220 del dispositivo.
una referencia a la versión objetivo a la que se deberá realizar la transición de este dispositivo.
Normalmente, esta será la versión más actualizada para el dispositivo.
Un campo de estado de la versión, que se utiliza para describir el estado de las acciones de control de versiones anteriores.
Un campo de control de versión utilizado para controlar cómo se realizará la transición de un dispositivo entre versiones.
Datos de instancia de dispositivo para todas las estructuras de datos definidas para dispositivos de esta clase y nivel de versión. (Tal como se define en la estructura de datos del modelo de datos instanciada en la estructura de datos de la versión del dispositivo).
Actividades del SDK de estructuras de datos del dispositivo
Las estructuras de datos del dispositivo pueden contener información sobre los dispositivos necesarios para realizar la transición del firmware entre diferentes versiones. Una herramienta de Control de versiones de la estructura de datos del dispositivo, para gestionar la definición de las diferentes estructuras de datos y las relaciones entre ellas para facilitar la transición automatizada entre versiones de software.
Captadores/Configuradores /Reflexión
Todas las estructuras de datos pueden soportar captadores/configuradores accesibles en la plataforma, y también disponibles a través de la interfaz en la dirección norte 160. Todos los elementos de datos instanciados del dispositivo descritos en el modelo de datos de la versión del dispositivo también pueden soportar captadores/ configuradores.
La única limitación de los captadores/ configuradores puede ser la descrita por el modelo de seguridad basado en roles. El modelo de rol para la seguridad para un dispositivo puede estar definido y encapsulado en el Modelo de datos de la versión del dispositivo. Todas las demás estructuras de datos en los objetos Clase del dispositivo, Versión del dispositivo e Instancia del dispositivo pueden soportar un modelo de seguridad adecuado.
La reflexión es la capacidad de consultar el tipo de datos y la metainformación asociada. La reflexión puede ser compatible para acceder al modelo de datos del dispositivo.
Serialización
Todas las estructuras de datos pueden ser serializables. Este es un mecanismo que se utiliza para soportar la replicación, la copia de seguridad y la configuración de principal/secundario.
Esto permite que varios servidores de DMAP interoperen entre sí. Todas las estructuras de datos se pueden serializar y, una vez serializadas, se pueden transferir entre servidores de DMAP. Este mecanismo se puede utilizar para diseñar servidores de DMAP en:
1) configuraciones de principal/secundario: donde los servidores de DMAP principales aceptan solicitudes de NBi y serializan las comunicaciones a los servidores de DMAP secundarios;
2) configuración agrupada: donde los servidores de DMAP operan al mismo nivel y comunican datos de instancia entre ellos; y
3) configuraciones del dispositivo de reenvío y del proxy.
La copia de seguridad, en espera (caliente/tibia/fría) puede utilizar el mismo mecanismo de serialización para comunicar los datos de la instancia para que se puedan guardar y restaurar cuando sea necesario.
Alertas, diagnósticos y registros: acciones de activación
Las alertas, los diagnósticos y los registros pueden utilizar el mismo mecanismo subyacente, que es definir las condiciones que darán lugar a que se produzca el evento de alerta/diagnóstico/registro. Esto se conoce como Acción de activación. Es posible que se generen datos como resultado del evento de Acción de activación. La acción de activación también puede definir dónde se envían esos datos.
El mecanismo de activación
Las acciones de activación se pueden asociar con instancias de versión del dispositivo o clase del dispositivo, lo que significa que una alerta podría ser específica para varios dispositivos físicos, todos del mismo tipo. También será posible definir una acción de activación dispositivo por dispositivo.
Las acciones de activación se pueden definir en:
1) nivel de clase del dispositivo: todos los dispositivos de esa clase;
2) nivel de versión del dispositivo: todos los dispositivos de una clase específica en un nivel de versión específico;
y/o
3) nivel de dispositivo: dispositivos objetivo individuales.
Estructura de datos de activación: condiciones
Los elementos de activación pueden ser estructuras de datos instanciadas y nombradas, donde cada elemento de activación nombrado tiene una serie de condiciones asociadas. Estas condiciones pueden ser simples, operador Ivalue, tripletes rvalue donde:
• el Ivalue representa una variable (es decir, un objeto Instancia de elemento de datos de dispositivo) u otro elemento de activación de condición
• un operador relacional, lógico o aritmético.
• un rvalue, que puede ser un Ivalue o una constante.
Un ejemplo de elemento de activación de condición puede ser Tensión del sensor (Voltage_Sensor) mayor de 12. De manera similar, las condiciones se pueden encadenar mediante lógica booleana que se refiera a otros activadores con nombre, es decir, Elemento de activación 1 Y Elemento de activación 2
Estructuras de datos de elementos de activación - componentes
Los elementos de activación pueden tener un nombre y pueden estar formados a partir de una lista de condiciones de activación.
Estructuras de datos de las acciones de activación
Se puede utilizar una estructura de datos de activación/acción para describir la acción o acciones a realizar en caso de que se aplique una condición de activación y el resultado del procesamiento de las condiciones sea verdadero. La estructura de datos de una acción de activación puede tener un nombre y puede comprender uno o más de:
• una estructura de datos de activación con nombre que comprende una lista de condiciones de activación • una devolución de llamada con nombre
• una estructura de modelo de datos con nombre que describe los datos de instancia asociados con la instancia de datos del dispositivo de activación.
Procesamiento de elementos de activación
El procesamiento de la Acción de activación se puede iniciar de varias formas. El mecanismo descrito en este ejemplo es accionado mediante datos.
• Se puede definir una acción de activación para un dispositivo o una colección de dispositivos
• Los datos de la instancia de datos del dispositivo se pueden actualizar o cambiar
• Todas las acciones de activación asociadas con el dispositivo pueden ser procesadas de una en una
• Si una lista de condiciones de activación asociadas con una acción de activación da como resultado VERDADERO, la estructura de datos asociada se puede completar con datos de la instancia de datos del dispositivo (es decir, todos los elementos de datos con el mismo nombre y tipo son copiados en la estructura de la instancia de datos de activación). El contenido de esta estructura de instancia de datos de activación se comunica a través de la interfaz de dirección norte 160 según lo definido por la devolución de llamada de la acción de activación
• Se pueden utilizar mecanismos para garantizar que esta acción de activación no se active repetidamente.
Se pueden utilizar otros mecanismos de iniciación para procesar los elementos de activación, como un proceso en segundo plano que puede estar realizando iteraciones a través de la lista completa de instancias del dispositivo, probando las condiciones de activación de cada dispositivo de una en una y de manera repetitiva.
Interfaz de dirección sur 170
Dispositivos gestionados: modelo lógico
El modelo de conectividad lógica de la plataforma de DM (véase la figura 12, Vista lógica de SBi) soporta tres categorías de comunicación.
1) Activaciones: este es el mecanismo utilizado para reactivar un dispositivo identificado y hacer que establezca comunicaciones con el servidor de DM. El modelo de seguridad de la plataforma M2M solo puede permitir que la activación del dispositivo se active desde el servidor de DM mediante un SMS-MT. Esto tiene la ventaja de que los dispositivos solo pueden ser activados para realizar operaciones a través del entorno de la plataforma M2M (con su mecanismo de restricción P2P forzado). Una alternativa a este ejemplo de activación activada por el servidor de DM es que los dispositivos se configuren con activadores de activación, de modo que los dispositivos activen automáticamente las activaciones después de tiempos de espera predefinidos, o como consecuencia de que los elementos de datos del dispositivo se encuentren dentro o fuera de los rangos predefinidos.
2) Dispositivo SMS-MO: los dispositivos pueden enviar mensajes SMS al servidor de DM. Este mecanismo puede ser utilizados como una alternativa a una conexión de conector, donde la información que se comunica al servidor de DM se puede representar utilizando un pequeño paquete de datos.
3) De dispositivo a servidor de DM. Este puede ser un protocolo de comunicaciones cliente/servidor TCP/UDP (se pueden utilizar otros protocolos) donde el dispositivo que funciona como cliente, puede establecer una conexión de conector con un servidor de DM. Una vez que se establece la conexión, el cliente puede comunicar los cambios de datos al servidor de DM, y el cliente también puede solicitar instrucciones de comando/control/comunicación del servidor de DM, sobre las cuales actuará.
Dispositivos gestionados: modelo físico
Los tipos de comunicación de datos a modo de ejemplo incluyen SMS y conexiones de Protocolo de Internet (con conexión o sin conexión). Las vías de conexión física serán a través de portadoras celulares o de mecanismos de conexión a Internet celular y por cable/inalámbrica.
La figura 9 ilustra esquemáticamente una disposición de conectividad física a modo de ejemplo. Este ejemplo incluye adaptadores específicos para interactuar con la SBi 170. Estos adaptadores junto con los comandos de activación 230 por SMS terminados en móvil (SMS-MT - SMS Mobile Terminated, en inglés) y la conectividad IP 240 a través de la red celular pueden utilizar una conexión de APN definida en el dispositivo M2M. Una vez que se crea un contexto de dispositivo de APN desde el dispositivo en el entorno del servidor de DM, los dispositivos pueden establecer conexiones de servidor / cliente en los servidores de DM.
Mecanismo de activación por SMS
La figura 10 ilustra esquemáticamente un proceso de activación por SMS 260 desde el servidor de DM al dispositivo. En este ejemplo, la única vía de conexión para iniciar las comunicaciones con los dispositivos (conectados a la red PLMN) es por medio de SMS-MT desde el entorno del servidor de DM de la plataforma M2M al dispositivo.
La figura 10 muestra la aplicación M2M (el servidor de DM) iniciando la generación de SMS-MT. Esto puede ser provocado por una serie de condiciones o criterios. Algunos pueden ser iniciados por acciones del cliente solicitadas a través de la Interfaz de dirección norte 160, por ejemplo. Otras condiciones que pueden desencadenar la activación del dispositivo podrían ser iniciadas automáticamente como resultado de las estructuras del Modelo de datos del dispositivo, que indican que se requiere alguna interacción del dispositivo (por ejemplo, los datos de instancia pueden requerir actualización debido a que están desactualizados). Se pueden aplicar reglas que incluyen que solo una aplicación de cliente de par a par por mensajes cortos, de la plataforma global de servicios de datos (GDSP SMPP -Global Data Service Platform Short Message Peer-to-Peer, en inglés) puede enviar SMS con terminación en móvil (SMS-MT) a una SIM de GDSP. Además, una aplicación de cliente SMPP de GDSP puede estar restringida para que no pueda enviar SMS-MT a ningún otro número, por ejemplo.
SMS desde un dispositivo al servidor de DM
Los dispositivos que utilizan SIM de la plataforma M2M pueden estar restringidos para que solo puedan enviar mensajes SMS originados en dispositivos móviles al servidor de DM (en la figura 11, esto se muestra como la aplicación M2M). Esto se puede utilizar como una ruta de comunicación alternativa desde el dispositivo al servidor de DM para situaciones que lo requieran.
La figura 11 muestra un proceso 270 a modo de ejemplo de un SMS que se envía desde un dispositivo 120 al servidor de DM. Este ejemplo puede incluir reglas de que una tarjeta SIM de GDSP puede enviar SMS originados en dispositivos móviles (s Ms -MO) solo a la aplicación cliente SMPP de GDSP definida por un centro de SMS (SMS-C -SMS Centre, en inglés).
La regla anterior puede significar que los SMS-MO son iniciados por el dispositivo de la plataforma M2M destinado a la aplicación M2M (el servidor de DM) en el servidor del cliente.
Conectividad IP de dispositivo a servidor de DM
Los dispositivos pueden soportar conectividad IP 240 de dispositivo a servidor de DM, utilizando protocolos de conexión y sin conexión. Cuando la comunicación tiene lugar a través de la red celular, el dispositivo puede establecer un contexto de dispositivo de APN, y la comunicación puede tener lugar a través de este contexto de dispositivo al objeto Instancia de dispositivo identificado representado en el servidor de DM.
Para conexiones de IP cableadas e inalámbricas, se puede utilizar la misma relación cliente / servidor entre el dispositivo y el servidor del dispositivo.
Dispositivo gestionado: tipos de dispositivos
En una implementación a modo de ejemplo, puede haber tres tipos de conectividad de dispositivo lógico:
1) La conexión de adaptador/agente de dispositivo, donde hay una conexión de adaptador de dispositivo lógico de uno a uno entre el servidor de DM a través de la SBi 170 y los dispositivos que utilizan un agente que soporta un protocolo que es común tanto para el adaptador como para el agente, por ejemplo, OMA-Lite, TR-069, SNMP u otro protocolo (por ejemplo, propietario).
2) La conexión Adaptador/Adaptador, donde hay una conexión a un segundo servidor de DM. En esta configuración, el segundo servidor de DM gestiona la conectividad del adaptador/agente del dispositivo, y los elementos de datos se comunican desde el segundo servidor de DM al primero. Esto se puede considerar como una configuración principal/secundario. Donde el servidor de DM superior es el principal, el servidor de DM subordinado es el secundario y las comunicaciones entre los dos se facilitan mediante mecanismos de serialización de objetos de datos.
3) La figura 12 ilustra una vista lógica de la SBi 170. El tercer tipo de relación lógica es donde el dispositivo está funcionando como una puerta de enlace a una serie de otras plataformas de DM 130, electrodomésticos y dispositivos 120, por ejemplo, un medidor inteligente que controla varios otros periféricos a través de I2C, RS484, RS232, ODB2 u otros buses. Este último ejemplo es una extensión del tipo de conexión lógica del primer dispositivo, pero donde la conectividad física a los periféricos es abstraída por los dispositivos 120 que son gestionados.
Abstracción de datos del dispositivo
Los mecanismos de abstracción de datos del dispositivo permiten que el servidor de DM virtualice imágenes de dispositivos físicos; este mecanismo de abstracción de datos se refiere a las vistas del servidor de DM de los dispositivos como datos de instancia, donde el contenido de estos datos de instancia se describe de manera declarativa utilizando un lenguaje de descripción del modelo de datos del dispositivo (por ejemplo, basado en XML). Esto permite que las aplicaciones interactúen con los dispositivos físicos indirectamente a través de los datos de instancia.
Este enfoque declarativo e indirecto de la gestión de dispositivos tiene una serie de beneficios, siendo no menos importante que permite al desarrollador/proveedor de dispositivos describir los dispositivos y su funcionalidad por medio de un modelo de datos de dispositivo.
Este enfoque de modelo de datos de dispositivo puede ser compatible y utilizado por varios protocolos de aplicación diferentes, incluidos OMA-LWM2M, TR-069 y SNMP, por ejemplo.
Este mecanismo de abstracción puede ser ampliado para soportar atributos adicionales que no son necesariamente soportados por todos los protocolos de comunicación subyacentes. Por ejemplo, OMA-DM soporta un modelo de seguridad basado en roles, pero SNMP y TR-069 no. Utilizar un modelo de datos que soporta atributos de rol de seguridad, proporciona compatibilidad con los protocolos de aplicación que lo soportan, pero también se puede utilizar para dispositivos que utilizan protocolos de aplicación que no lo soportan.
La figura 13 muestra parte de una estructura de base de datos de información de gestión (MIB - Management Information data Base, en inglés) a modo de ejemplo 320 utilizada para representar dispositivos gestionados de SNMP. Es posible que este protocolo de gestión de aplicaciones no soporte atributos basados en roles.
Soporte de atributos adicionales
Los dispositivos que utilizan el protocolo SNMP aún pueden utilizar un modelo de datos que soporte la especificación de roles de seguridad; solo significa que es posible que el dispositivo no soporte ese mecanismo basado en roles. Todavía tiene valor, ya que el desarrollador de dispositivos ahora puede describir el modelo de datos para el dispositivo en términos de la especificación de MIB y puede superponer metainformación adicional según corresponda.
El modelo de datos y los dispositivos de puerta de enlace
Tal como se describió anteriormente, el dispositivo puede funcionar como un dispositivo concentrador o de puerta de enlace a varios otros periféricos, donde estos periféricos están conectados a través de una multiplicidad de diferentes mecanismos de comunicación. En este caso, el modelo de datos puede alojar esta vista ampliada de la puerta de enlace/concentrador como si estos componentes periféricos formasen parte del mismo modelo de datos. Todas las comunicaciones entre el concentrador/puerta de enlace y los periféricos pueden, a continuación, ser abstraídas y ser transparentes para el servidor de DM y para cualquier aplicación que acceda al mismo. Cuando se requieran o se deseen mecanismos de control/estado, estos pueden ser incorporados de manera similar en el modelo de datos del dispositivo.
El diseñador/especificador del modelo de datos debe describir con precisión el modelo de datos del dispositivo/concentrador para que refleje la funcionalidad.
Capa de interfaz de dispositivo/en dirección sur (SBi - South Bound Interface, en inglés) 170
La capa de interfaz de dispositivo/en dirección sur proporciona el enlace entre la plataforma de DM y los dispositivos 120. En este ejemplo, la capa de interfaz de dispositivo realiza varias funciones:
Solicitudes de API de servicio de las capas de nivel superior y resultados de devolución
Garantiza que las solicitudes solo se realicen según los roles de seguridad de los solicitantes.
Garantiza que múltiples solicitudes de múltiples fuentes a dispositivos físicos estén sincronizadas correctamente
Garantiza que las conexiones de los dispositivos sean gestionadas de manera eficiente
soporta una (potencialmente) amplia cantidad de dispositivos suministrados por diferentes proveedores
Soporta interfaces a través de otras plataformas de DM
Un modelo para esta capa se muestra esquemáticamente como un modelo de interfaz de dispositivo 330 en la figura 14.
Los diferentes componentes que se muestran en esta figura incluyen:
• Una interfaz de dispositivo 340: esta es una instancia de un objeto de dispositivo que los solicitantes de nivel superior pueden utilizar para consultar y acceder a un dispositivo a través de la NBi 160 (la NBi 160 proporciona un mecanismo para que las aplicaciones obtengan/configuren datos de instancia de dispositivo). La interfaz de dispositivo 340 puede contener elementos separados
° Un objeto Solicitante de dispositivo 350: describe al agente solicitante en términos de su función de seguridad y enlace de comunicación de conector
° Un dispositivo sustituto 300: contiene una representación estándar de un dispositivo. Esta representación puede ser común a todos los dispositivos de los proveedores.
° Un adaptador de proveedor 310: cada proveedor puede tener un adaptador de subclase único que contiene toda la funcionalidad dependiente del dispositivo.
° Una conexión de dispositivo 360: contiene todos los objetos de datos que describen la conexión de SBi. Normalmente, este puede ser el objeto de conexión del conector más cualquier otra información, tal como el estado de un Activación por SMS pendiente, los detalles de una conexión de APN o la clase de conexión (cableada/inalámbrica/celular).
La figura 15 ilustra esquemáticamente un Modelo de agente/Adaptador de interfaz de dispositivo. Este enfoque “sustituto” para describir los dispositivos físicos desacopla las características específicas del proveedor del dispositivo de las API que pueden ser utilizados para realizar operaciones y consultar los dispositivos. La lógica específica del dispositivo se coloca de manera similar en los objetos utilizando un patrón de diseño de adaptador, en este ejemplo. Por lo tanto, esto puede resultar en una solución modelo-vista-controlador (MVC) que es fácil de utilizar y que se puede utilizar con diferentes tipos de dispositivos de proveedores. El objeto sustituto 300 contiene una representación de los datos almacenados en el dispositivo físico.
Este modelo de datos de dispositivo se describiría mejor utilizando una notación XML. Las instancias de objetos de dispositivo podrían utilizar la notación XML en tiempo de ejecución o, alternativamente, en tiempo de compilación. El modelo de datos puede definir un conjunto de variables que son asignadas en el modelo de datos OMA-DM/LWM2M. El modelo de datos puede incluir estructuras de lista de control de acceso (ACL - Access Control List, en inglés), por ejemplo.
Puede ser posible utilizar modelos de propiedades para hacer cumplir una ACL en estructuras de datos. Sin embargo, un enfoque más simple es crear un objeto de nivel superior que contenga un objeto sustituto del dispositivo y una representación del solicitante que realiza la consulta. Este objeto solicitante también puede incluir el rol de seguridad del solicitante.
La consulta de la versión de un dispositivo puede seguir la siguiente secuencia de operaciones a modo de ejemplo:
• Una aplicación necesita consultar la versión de un dispositivo específico.
• La aplicación invoca un captador de API para la clase del dispositivo: el parámetro de entrada del captador especifica un ID de dispositivo único y el nombre del campo (este ejemplo consultará un campo llamado Versión) y el objeto del solicitante.
• Compruebe que la función del objeto solicitante tenga permiso para acceder al campo del dispositivo. Si no es así, lance una excepción de seguridad.
• Si existe una instancia del objeto sustituto 300 del dispositivo y los datos de la versión son oportunos, devuelva la información de la versión del dispositivo contenida en los datos de la instancia sustituta y salga. (Nota: No es necesario consultar el dispositivo real).
• Si la instancia del dispositivo no existe, cree la instancia del dispositivo utilizando un patrón de creación de constructor. El constructor puede utilizar una subclase del dispositivo predefinida (instancia en tiempo de compilación) o utilizar XML para crear una instancia de dispositivo en tiempo de ejecución. El constructor puede necesitar instanciar tanto un objeto sustituto 30 como un objeto adaptador 310.
• La instancia del dispositivo existe, pero la información de la versión virtualizada no está actualizada. Por lo tanto, el objeto adaptador genera una solicitud a una plataforma M2M para iniciar una activación por SMS del dispositivo en el dispositivo M2M físico con un contexto de protocolo de datos en paquetes (PDP - Packet Data Protocol, en inglés) que termina en la plataforma de DM.
• Se crea el contexto del dispositivo entre el dispositivo y la plataforma de DM.
• El dispositivo identifica el dispositivo que representa utilizando su ID de dispositivo único. Esta información se utiliza para seleccionar la instancia de dispositivo en el servidor de DM que representa el dispositivo físico. A continuación, el objeto de conexión es asignado al objeto Solicitante de conexión de dispositivo. Toda la comunicación desde el dispositivo al servidor de DM ahora está vinculada directamente a las estructuras de datos que representan la instancia del dispositivo.
• El dispositivo físico y la instancia del dispositivo del servidor de DM ahora pueden comunicarse directamente y el dispositivo puede transferir valores para las estructuras de datos del dispositivo a la instancia del dispositivo. Esto se podría optimizar para cargar todos los datos o solo los datos que se requieren de inmediato.
• Devuelve los resultados de la función captador de versión a la aplicación de consulta.
La ventaja de este enfoque de “objeto sustituto” es que:
• Es más sencillo de implementar.
• Soporta el acceso multiproceso a los datos del dispositivo; siempre puede haber como máximo una instancia única del modelo de datos de un dispositivo, pero posiblemente varios agentes consultan esos datos a la vez. Las regiones de Mutex pueden operar dentro de los captadores /configuradores para garantizar una sincronización correcta.
• Se puede utilizar como mecanismo para gestionar un modelo de seguridad basado en roles.
• Los modelos de datos se pueden definir utilizando XML u otra notación, por lo que el mismo mecanismo se puede utilizar para interactuar con todas las estructuras de datos de los dispositivos M2M, incluidos los parámetros de configuración, el firmware y las aplicaciones. Esto simplifica y estandariza las funciones de gestión de dispositivos.
• Es adecuado para numerosas optimizaciones de rendimiento.
• Es compatible con productos de varios proveedores.
Interfaces de proveedores: abstracción de dispositivos
El modelo arquitectónico puede proporcionar interfaces a más de los dispositivos de un proveedor. Los productos de diferentes proveedores pueden tener diferentes capacidades y, en algunos casos, una funcionalidad muy diferente. Preferentemente, todos los dispositivos pueden soportar un protocolo de comunicaciones basado en estándares.
Cada tipo de dispositivo de proveedor puede requerir su propia Clase de adaptador de dispositivo específica y cada conexión de dispositivo físico/virtual puede requerir un objeto Instancia tanto de la clase sustituta 300 como del adaptador 310, para representar esa conexión.
Es posible que se requieran varios tipos de clases de adaptadores. La figura 15 ilustra un ejemplo de modelo de agente/adaptador de interfaz de dispositivo que puede ser:
• Cumple con los estándares, es decir, se puede utilizar una sola clase de adaptador para todos los dispositivos de los proveedores que soporten el estándar OMA-DM.
• No estándar: es decir, adaptadores que se conectan a dispositivos de proveedores de formas no estándar.
• DM a Puerta de enlace/Concentrador.
• DM a DM: no todos los adaptadores se pueden conectar a dispositivos de punto final. Puede ser necesario comunicarse con los dispositivos del proveedor a través de otras plataformas DM (por ejemplo, iDigi, Redbend).
La abstracción de la conectividad de la plataforma de DM al dispositivo mediante un modelo de adaptador sustituto significa que todas las aplicaciones de nivel superior pueden acceder a los dispositivos utilizando las mismas API.
Variaciones arquitectónicas
El servidor de DM se puede utilizar para representar muchos dispositivos físicos diferentes como instancias de dispositivos virtualizados. Los datos de esta instancia de dispositivo son volátiles y es posible que se hayan creado durante un período de tiempo prolongado. Las instancias de dispositivos que no se han actualizado porque los dispositivos físicos que representan no están disponibles (por ejemplo, porque se han apagado), pueden ser muy antiguas.
Si se reinicia el servidor de DM, existe la posibilidad de que se pierdan todos estos datos de instancia de dispositivo almacenados en una caché. El remedio en esta situación será volver a obtener los datos del Dispositivo virtualizado, desde los dispositivos físicos, OTRA VEZ. Los datos pueden ser almacenados permanentemente en la plataforma M2M, por ejemplo, en alguna base de datos. Como todos los datos de la instancia del dispositivo se pueden serializar, se pueden almacenar en cualquier lugar, incluso en otros servidores de DMAP.
Alternativamente, los datos de la instancia del dispositivo se pueden volver a obtener de otras maneras.
Mecanismos de recuperación de datos de instancias de dispositivos
Existen varios enfoques de ejemplo que se pueden utilizar para recuperar y distribuir datos de instancias de dispositivos con el fin de mejorar la disponibilidad del sistema:
• Crear copia de seguridad simple /restaurar: el servidor de DM soporta un mecanismo para realizar copias de seguridad de todas las estructuras de datos en un almacenamiento secundario. Todos los datos de la instancia del dispositivo se pueden serializar y estos datos serializados se pueden guardar en el disco. Una vez guardados, los objetos serializados se pueden volver a crear en la misma plataforma del servidor de DM después de un reinicio. Alternativamente, los datos serializados pueden ser utilizados para establecer un Punto de Recuperación y ser utilizados para recrear las Instancias de Dispositivo en una plataforma alternativa de servidor de DM de seguridad. Este proceso de restauración en el punto de recuperación archivado puede ser ejecutado en modo de espera frío, templado o caliente.
• Replicación: las estructuras de datos de instancia de dispositivo serializadas del servidor de DM pueden ser transferidas a una plataforma de servidor de DM replicante. Se puede acceder a este servidor de DM secundario replicante exactamente de la misma manera que a la plataforma del servidor de DM primario, a través de su interfaz en dirección norte 160, pero no tendrá una interfaz en dirección sur. (Sin embargo, soportará el mecanismo de activación por SMS).
• Principal/secundario: es similar a la configuración del servidor de replicación. La diferencia es que, en esta configuración, el servidor de DM secundario puede soportar la interfaz en dirección sur 170 y todos los datos de la instancia del dispositivo se pueden comunicar con la plataforma del servidor de DM principal mediante un enlace de comunicación DM-DM de adaptador/agente, donde los datos de instancia serializados se comunican desde el servidor secundario al principal.
• Híbrido: los servidores de DM pueden estar configurados para soportar las diferentes configuraciones arquitectónicas descritas anteriormente para diferentes dispositivos. Es posible que el software del servidor se esté ejecutando en la nube para hacer uso de la informática elástica. Si la carga aumenta, el rendimiento del software del servidor de DM aumenta al encender dicho software en servidores físicos adicionales. Del mismo modo, cuando no se necesiten, esos servidores adicionales no se utilizarán. Los datos de esos servidores no se perderán. Por lo tanto, es posible que se requiera un almacenamiento de datos permanente.
Actualización de software
El presente sistema puede conseguir el mantenimiento, la gestión y el soporte de múltiples versiones de Software para dispositivos. Además, el DMAP 60 ha sido diseñado para simplificar y reducir el coste de esta actividad.
Se describen los mecanismos que se pueden utilizar para soportar la gestión de firmware. Otros tipos de software pueden utilizar mecanismos similares. Dichas actualizaciones pueden incluir, entre otros, los siguientes:
• Sistema operativo, actualización completa o actualizaciones parciales
• Otros tipos de firmware, por ejemplo, Imágenes de FPGA/hardware basadas en flash, tal como se utilizan en ciertos enrutadores
• Software de la aplicación
Las actualizaciones de firmware son una categoría de activos de software que requiere gestión de versiones. Esto tiene una complejidad adicional, particularmente cuando están involucrados muchos dispositivos diferentes de muchas versiones diferentes. Puede surgir una mayor complejidad de gestión para el software de aplicación que ha sido instalado por los usuarios.
Los mecanismos que se describen a continuación están diseñados para gestionar el firmware; sin embargo, estos mecanismos y principios a modo de ejemplo se pueden ampliar para soportar otros tipos de activos de software según sea necesario.
Se soporta la gestión de la versión del software y del firmware de la aplicación del dispositivo.
Programador de actualizaciones de firmware /Programación
Las actualizaciones de firmware pueden ser gestionadas durante períodos de tiempo específicos. Específicamente, las ventanas de firmware pueden ser definidas y asociadas al espacio del dispositivo. Por ejemplo, esto puede ser país por país, o todos los dispositivos pueden ser actualizados en relación con una zona horaria específica.
El cambio de software o firmware a una nueva versión puede implicar un proceso de dos etapas:
1) T ransferir el nuevo software a la plataforma; y
2) Reiniciar el sistema para que ahora utilice el nuevo software.
El reinicio se puede activar de varias maneras a modo de ejemplo:
1) Automáticamente, pero esto podría afectar a los usuarios del sistema. Si el sistema se está utilizando para una tarea crítica, esto puede causar problemas.
2) Bajo el control del usuario o tras el reconocimiento del usuario. Esto requiere que un usuario humano tome la decisión.
3) Cuando sea más oportuno. La imagen del software puede tener efecto la siguiente vez que se reinicie el dispositivo.
Se pueden implementar reversiones de software a versiones anteriores al administrar actualizaciones de O/S. Este requisito se cumple para todas las actividades de gestión de software.
Para respaldar este requisito, se pueden incluir estructuras de referencia adicionales en el objeto Versión del dispositivo (véase 225 en la figura 8) para soportar la vinculación hacia atrás. Los objetos de dispositivo también pueden incluir una referencia a una versión objetivo de reversión.
Ejemplo de actualización de firmware
El proveedor del dispositivo, la aplicación o el usuario pueden crear una versión nueva y mejorada de firmware para un dispositivo. El proveedor probará este firmware hasta que esté seguro de que es lo suficientemente robusto para implementarlo en el entorno en vivo. Las etapas para implementar una versión de firmware pueden incluir (téngase en cuenta que la siguiente descripción es solo ilustrativa) una secuencia de etapas para representar una actualización y todas las actividades asociadas utilizando un enfoque declarativo. La actualización se puede definir junto con todas las dependencias y acciones en un objeto de datos de actualización. A continuación, el objeto de datos de actualización puede ser vinculado a una estructura de datos de red que describe la relación entre esta actualización y las actualizaciones anteriores. Una vez que la actualización está completamente definida, así como su relación con otras actualizaciones, la plataforma de DM puede procesar estas estructuras de datos para hacer la transición automática de dispositivos físicos a través de secuencias de operaciones de actualización.
Estas actividades se pueden subdividir en:
• Crear un objeto Versión de dispositivo para esta versión de firmware. Este es el objeto de actualización que describe una actualización de software específica junto con todas sus dependencias. El objeto Versión de dispositivo puede tener elementos miembros que describen:
° La imagen del firmware, que será la imagen binaria del código de firmware
° El modelo de datos de dispositivos en ese nivel de versión
° La clase del dispositivo para dispositivos de esta versión de dispositivo
• Crear un enlace desde un objeto Versión de dispositivo anterior a este objeto Versión de dispositivo. Este enlace describe la relación de esta actualización con otras actualizaciones anteriores, por ejemplo, para actualizar un dispositivo de la versión a a la versión c. La secuencia de actualización será la versión a, a la versión b y finalmente a la versión c. Alternativamente, puede haber una ruta de actualización de la versión a directamente a la versión c. En cualquier caso, este enlace describe las transiciones de actualización entre actualizaciones anteriores para actualizar un dispositivo a la última versión.
• Modificar una Instancia de dispositivo existente (en esta etapa de la prueba, esta Instancia de dispositivo puede ser un dispositivo de prueba) y configurar el elemento de datos de instancia de la versión objetivo del dispositivo, de modo que haga referencia a la nueva versión de dispositivo que representa esta nueva actualización de firmware.
• Modificar la configuración de Control de versión de instancia de dispositivo para indicar que debe realizar la transición de este dispositivo de su Versión de dispositivo actual a su nueva Versión de dispositivo. Esta y la etapa anterior, pueden informar al sistema de que necesita actualizar este dispositivo de prueba.
• Activar el Programador de firmware para que comience a ejecutarse.
El proceso del Programador de firmware puede realizar iteraciones a través de todas las instancias de dispositivo invocando transiciones de firmware según sea necesario. Los objetos de dispositivo 225 pueden contener objetos de datos que hacen referencia a la versión actual y a los objetos de la versión objetivo para la clase del dispositivo y las imágenes de firmware para estos. Una vez que se ha identificado una instancia de dispositivo como candidata para una transición de versión de dispositivo, es posible que se lleven a cabo una serie de actividades.
• Se captura el modelo de datos del dispositivo para el dispositivo en la versión actual. Todos los elementos de datos descritos en el modelo de datos se pueden leer desde el dispositivo para que sus valores sean los actuales. Los requisitos de moneda y otra metainformación que puedan ser aplicados pueden definirse de elemento de datos en elemento de datos.
• Se crea un nuevo modelo de datos de dispositivo utilizando el modelo de datos definido para la versión objetivo del software. Esto puede ser exactamente igual que la versión anterior, o puede haber múltiples diferencias entre la antigua y la nueva. En cualquier caso, el nuevo modelo de datos del dispositivo puede contener detalles suficientes para poder clonar el modelo de datos antiguo y aplicar todas o cualquiera de las modificaciones necesarias para llevarlo al nuevo modelo de datos objetivo de la versión del dispositivo.
• La nueva imagen del firmware objetivo es transferida al dispositivo
• El dispositivo carga la imagen del firmware y se reinicia
• Todos/cualquier cambio de estructura de datos requerido es transferido al dispositivo
• Las estructuras de datos del dispositivo se actualizan para indicar que el firmware ha sido transferido a la nueva versión.
La priorización y la programación de este proceso se pueden refinar según corresponda. Se puede implementar la ampliación de la funcionalidad para gestionar campañas de gestión de firmware de maneras más sofisticadas.
Actualización de firmware: actividades del SDK
Otras características y beneficios de este sistema pueden incluir:
1. La virtualización de los dispositivos físicos proporciona un enfoque mejorado.
2. T rabajar con modelos de datos de dispositivos también es una mejora.
3. Es posible que sea necesario implementar cualquier software de gestión de aplicaciones “estándar” en términos del bus de NBi y sus capacidades, y requeriría que los proveedores de dispositivos soportasen un modelo de datos estandarizado o genérico. Se pueden implementar herramientas de gestión de versiones.
4. La NBi, la autenticación y la comprobación de identidades de usuarios de terceros, etc. pueden reutilizar los mecanismos de gestión de identidad, o AAA, existentes. Cuando se utiliza un servidor proxy, un tercero (usuario o aplicación) puede obtener acceso al proxy a través de la NBi. Se puede utilizar un mecanismo similar en una plataforma M2M, donde los usuarios externos también obtienen acceso a una plataforma de operador. Por lo tanto, la reutilización de los componentes comunes del sistema evita las soluciones de tubos de estufa y la construcción desde cero de diversos componentes del sistema, tales como los que soportan el inicio de sesión y la autenticación.
5. Para los usuarios o clientes externos, puede haber una capacidad de inicio de sesión único (SSO - single sign on, en inglés), de modo que puedan iniciar sesión en el servicio del proxy de DM una vez que hayan iniciado sesión en la utilización de una plataforma M2M.
6. La arquitectura y el diseño del propio sistema de proxy de DM pueden ser modulares.
7. El “funcionamiento en la nube” del motor de procesamiento puede proporcionar beneficios adicionales. Por ejemplo, esto puede ser ventajoso si el número de dispositivos (por ejemplo, dispositivos TR-069) aumenta drásticamente. El TR-069 u otro adaptador puede requerir un mayor rendimiento y, por lo tanto, debería ser más fácil escalarlo, y esto es posible utilizando la informática elástica de una nube. Otra característica preferente puede ser que el proceso del adaptador TR-069 se pueda multiplicar en servidores adicionales en la nube, pudiendo estos adaptadores comunicarse con el resto del DMAP de la manera habitual.
Del mismo modo, si resulta que a muchos clientes les gusta configurar alertas para los activos M2M y el procesamiento del activador requiere un mayor rendimiento, esto se puede aceptar con solo presionar un pulsador (o de manera automatizada) utilizando la informática en la nube elástica. Una vez más, el componente de procesamiento del activador debe ser identificado como el que debe ser asignado a un rendimiento general más alto.
La informática elástica y los componentes internos del motor de procesamiento de DMAP pueden tener interfaces bien definidas que son adecuadas para la comunicación interna en la nube. Esto es compatible con el mecanismo de serialización.
8. Tal como se mencionó anteriormente, para “ver todo el DMAP en acción”, se pueden proporcionar diagramas de flujo de mensajes de alto nivel (utilizando algunas herramientas estándar). Esto puede mostrar la interacción entre el cliente -> NBi -> motor de procesamiento de DMAP -> SBi (sustituto -> adaptador -> TR-069/LWM2M) -> estructura de cliente de gestión de dispositivos en diferentes calles de natación, por ejemplo.
9. El diseño puede ser flexible, por ejemplo:
a. Diseño para la preparación para la implementación en la nube
b. Diseño para escalabilidad y rendimiento
c. Diseño para la extensibilidad con respecto al alcance de la función de DMAP (incluido el proxy que realiza alguna función en una arquitectura para análisis de datos o intermediación de objetos comerciales).
d. Diseño para la extensibilidad de los modelos de datos: para hacer frente a los activos y dispositivos M2M futuros, aún desconocidos, emergentes.
e. Diseño para la seguridad.
f. Diseño para fiabilidad y elasticidad (esto puede venir automáticamente a través de una implementación sobre un laaS a través de un SLA adecuado).
Las características adicionales a modo de ejemplo pueden incluir búsquedas cifradas, donde los términos de búsqueda (y/o los resultados) están cifrados. Esto se puede extender a diagnósticos/registros/alertas/aprendizaje automático cifrados. Los datos cifrados se pueden examinar en una plataforma de terceros neutral, y se puede adoptar una decisión de acción basada en los datos de entrada cifrados. Un ejemplo puede ser cuando una empresa de análisis realiza un análisis de datos de entrada cifrado e infiere resultados sin ningún conocimiento del texto sin formato de las entradas o salidas.
También se puede utilizar el cifrado homomórfico, ya que esto permite realizar cálculos arbitrarios en datos cifrados (por ejemplo, por partes que no son de confianza) sin romper el cifrado.
Se puede proporcionar un mecanismo que permita al operador definir pruebas que ejercitarán el equipo y verificarán su correcto funcionamiento. Por ejemplo, una prueba de suma de comprobación de memoria puede recopilar firmas de memoria generadas mediante comprobaciones de CRC polinomiales predefinidas en partes de la memoria. La función de suma de comprobación de memoria es beneficiosa, ya que se puede utilizar para confirmar la versión del software y se puede utilizar para confirmar el comportamiento correcto de las operaciones de lectura de memoria en el equipo.
El sistema proporciona un modo de asignar una colección de valores de datos en una estructura de lista única, de modo que toda la información específica de una tarea en particular es recopilada y se puede acceder a ella en una sola consulta.
En el contexto de los dos requisitos descritos anteriormente, se puede crear una estructura de datos de lista con todos los datos específicos de la versión que contenga todas las características y valores que puedan identificar de manera única un dispositivo, y que podrían incluir una suma de comprobación de memoria (para verificar que una versión específica de software fue instalada). Se puede crear una segunda estructura de datos de lista que contenga todas las características y valores relevantes para identificar el funcionamiento correcto y diagnosticar las posibles causas del funcionamiento incorrecto.
La descripción de estas estructuras de datos de listas basadas en roles incluye los beneficios de:
1) simplificar la tarea del desarrollador de aplicaciones;
2) simplificar la gestión y la aplicación de controles de seguridad; y
3) reducir los recursos de red necesarios para acceder a los datos de un dispositivo.
Los dispositivos tales como los dispositivos compatibles con M2M proporcionan funciones estandarizadas de diagnóstico, supervisión y gestión para que puedan ser gestionados de manera comercialmente eficaz.
Los atributos del sistema pueden incluir:
1) Un mecanismo de comprobación mejorado, para verificar que los dispositivos, y los dispositivos M2M en particular, son candidatos adecuados para las actualizaciones de software. El enfoque actual es programar en la información de la versión de software/hardware y permitir que esta información sea consultada. El enfoque actual carece de rigor, pero al hacer que el proceso de comprobación de la versión sea más riguroso, reducirá la probabilidad de que se produzcan errores potencialmente costosos.
2) Un proceso de diagnóstico mejorado, para proporcionar datos suficientes para permitir la detección y predicción de errores sofisticados de una manera independiente del dispositivo. El enfoque actual requiere que el operador tenga algún conocimiento del aparato, cómo funciona y los síntomas que debe buscar cuando diagnostica fallos. Este proceso, por lo general, manual, se basa en operadores expertos, con una experiencia que se mejora con el tiempo. Las mejoras propuestas permitirían al operador realizar diagnósticos de una manera independiente del dispositivo, lo que requiere un conocimiento o comprensión mínimos de cómo funciona el dispositivo, y donde gran parte de la actividad de diagnóstico se puede automatizar utilizando técnicas de inteligencia artificial, por ejemplo.
3) Un proceso de consulta de datos mejorado para facilitar la utilización de técnicas sofisticadas de aprendizaje automático en la plataforma de gestión por parte del operador de la plataforma, con el propósito de identificar las acciones a realizar de manera oportuna. El diagnóstico de fallos es una aplicación, pero existen potencialmente muchas otras aplicaciones para este beneficio.
4) Procesos de alerta mejorados, para proporcionar alertas sofisticadas del lado del dispositivo de una manera independiente del dispositivo.
5) Gestión de todas las mejoras anteriores, para simplificar la manera en que se utilizan estos procesos, de modo que el flujo de información siga un modelo de seguridad basado en roles con niveles garantizados de integridad y confidencialidad.
6) Todas las mejoras anteriores pueden ser proporcionadas de tal manera que el operador de la plataforma de DM no requiera visibilidad o comprensión de los dispositivos que se están gestionando.
Enfoque técnico
Definir un mecanismo estándar para recopilar valores de datos de dispositivos (por ejemplo, dispositivos M2M), de tal manera que se puede utilizar una sola consulta para obtener acceso a múltiples valores. Estas colecciones de valores se pueden denominar listas de características, tal como se ha descrito anteriormente.
Definir un mecanismo estándar para especificar valores de datos y valores de firma de datos que serán asignados a listas de características.
Definir un mecanismo estándar para consultar metainformación que describa los elementos de las listas de características, por ejemplo, tipo, derechos de acceso, rangos de valores, etc.
Definir un mecanismo estándar para describir los derechos de acceso a nivel de lista de características y los requisitos de autenticación necesarios para acceder a ellos, de tal manera que se proteja la integridad y la confidencialidad de la información representada por el contenido de las listas de características.
Definir un mecanismo estándar para describir vínculos entre características en diferentes listas de características, de tal manera que la información contenida en diferentes listas de características puede ser combinada con fines de análisis.
Definir un mecanismo estándar para especificar valores de datos de firma para electrodomésticos y dispositivos M2M, de tal manera que se puede confirmar la información sobre el estado de un dispositivo y los activos que representa. En conjunto, estas extensiones pueden permitir la utilización de análisis sofisticados.
Según un aspecto, se proporciona un mecanismo que permite a un desarrollador de dispositivos M2M asignar valores de datos de tal manera que sea adecuado para el modo en que se utilizarán esos datos. El mecanismo puede permitir que un operador de dispositivo o plataforma M2M proporcione un sistema automatizado para predecir fallos en los dispositivos que están siendo supervisados por el dispositivo o por el operador de la plataforma M2M, sin requerir que ese operador tenga ningún conocimiento o comprensión de los dispositivos que están siendo supervisados.
Esto puede permitir la provisión de un servicio de diagnóstico y predicción de fallos a terceros que implementen dispositivos equipados con M2M en las instalaciones del cliente final. Como una extensión de este sistema, podría ser integrado con Business Logic para permitir capacidades adicionales de alerta y predicción en un modo específico de la aplicación.
Un propósito del dispositivo o sistema es proporcionar un mecanismo genérico para asignar estructuras de datos no organizadas y organizadas jerárquicamente en estructuras de listas organizadas relacionalmente que sean adecuadas para la utilización de la aplicación.
Una aplicación de este dispositivo sería predecir el comportamiento futuro de un dispositivo y los eventos que está supervisando basándose en actividades pasadas. El propósito podría ser supervisar el funcionamiento correcto de los electrodomésticos de manera automatizada, o podría ser utilizado para predecir un evento específico de una aplicación inminente, tal como un aumento en los requisitos de energía para un hogar, por ejemplo.
El mecanismo permitirá que un operador capture y registre el comportamiento de un aparato durante un período de tiempo, de modo que los resultados futuros de un aparato puedan ser predichos de una manera que no confíe en que el operador tenga conocimiento del aparato o de su funcionamiento. Los resultados que se predicen se pueden referir al funcionamiento correcto del aparato que se está supervisando o podría ser alguna otra predicción que tenga algún valor (por ejemplo, predecir/identificar una emergencia médica).
Ejemplos:
i) Cláusula 1
Un dispositivo que asigna valores de datos en estructuras de listas lineales de tal manera que el contenido de las estructuras de listas se puede recopilar y analizar sin que el operador del proceso de recopilación o el proceso de análisis requiera conocimiento de lo que representan los datos.
NOTA: Estos valores de datos se denominan posteriormente características, en los siguientes ejemplos. Las colecciones de características se denominan listas de características.
ii) Cláusula 2
Una multiplicidad de tipos de características adecuadas para representar diferentes tipos de información.
iii) Cláusula 3
Las listas de características y las características tendrán metadatos asociados, suficientes para describir las características de una manera que facilitará el procesamiento de datos de características por parte de terceros, sin que los terceros requieran conocimientos del nivel de aplicación. Los metadatos ilustrativos incluirían el tipo de datos de características, rangos de valores posibles, información descriptiva, etc.
iv) Cláusula 4
Un mecanismo para describir datos de características, de tal manera que se minimice el requisito de almacenamiento de memoria para describir esos datos de características. En el caso de las sumas de comprobación, solo es necesario registrar si una suma de comprobación es correcta o incorrecta, y este elemento de datos de característica se puede describir como un solo bit. La ventaja que esto confiere es que reduce la cantidad de almacenamiento necesaria para registrar y comunicar los datos de características capturados.
v) Cláusula 5
Un mecanismo para describir conjuntos de elementos de datos de características en listas de características, que comprenden secuencias de valores comprimidas individuales. La ventaja que esto confiere es minimizar la cantidad de transacciones de comunicación necesarias para que un mecanismo de recopilación de datos de funciones M2M recopile un conjunto de funciones relacionadas de un dispositivo, en lugar de realizar múltiples solicitudes para consultar varios sensores, sumas de comprobación CRC, etc. El proceso realizará una única solicitud de comunicación Obtener datos de funciones, y todos los datos de funciones para el tipo de lista de funciones solicitado se recopilarán en una sola transacción.
vi) Cláusula 6
Un mecanismo para describir múltiples listas de características, de tal manera que un mecanismo de recopilación podría solicitar una lista de características específica para recopilar, que sería un subconjunto del conjunto completo de características, y solo contendría elementos de datos de características relevantes para el propósito que se recopila.
Esto permitiría a diferentes agencias de recopilación de listas de características recopilar listas de características adecuadas a sus requisitos. Por ejemplo, un aparato médico puede contener información confidencial del paciente, tal como la ubicación y la identidad personal, que sería valiosa para fines epidemiológicos y de diagnóstico médico, pero que no sería de interés para el proveedor del equipo. En dicho caso, se recopilaría una lista de características para su uso y análisis por parte del proveedor de hardware, a fin de confirmar el funcionamiento correcto del aparato, y los médicos recopilarían una segunda lista de características con el propósito de un análisis centrado en la medicina.
vii) Cláusula 7
Un mecanismo para asignar diferentes derechos de acceso en diferentes listas de características, de tal manera que diferentes actores tengan diferentes derechos de acceso a diferentes listas, con los niveles adecuados de confidencialidad e integridad aplicados.
viii) Cláusula 8
Un mecanismo para consultar, modificar y eliminar características. Utilizar listas de características para describir los valores de características de interés, de manera que diferentes actores tengan diferentes derechos de acceso a diferentes listas, con los niveles adecuados de confidencialidad e integridad aplicados.
ix) Cláusula 9
Un mecanismo para identificar circuitos defectuosos y asociar los fallos y los tipos de fallos con información de características que se había recopilado previamente según la Cláusula 3. Esto se denomina Datos de resultado en cláusulas posteriores.
x) Cláusula 10
Un mecanismo para identificar datos de resultados que no sean fallos del circuito, tal como se ha descrito en la Cláusula 9, tal como un indicador de que una emergencia médica es inminente, y de que un paciente que está siendo supervisado requiere atención urgente.
xi) Cláusula 11
Como para la cláusula 10, pero para otros resultados, tales como un indicador de que una vivienda no está haciendo un uso eficiente del suministro de energía eléctrica y que se recomendaría una auditoría energética.
xii) Cláusula 12
Un proceso que permite describir un dispositivo electrónico mediante múltiples firmas. Estas firmas se pueden generar de diversas maneras. Las firmas se generarán de una manera matemáticamente adecuada, diseñada para describir mejor un objeto de una manera única. Un mecanismo generaría firmas utilizando códigos de redundancia cíclica (CRC - Cyclic Redundancy Codes, en inglés) en combinación con un polinomio predefinido.
xiii) Cláusula 13
El dispositivo utilizaría una multiplicidad de tipos de características para describir múltiples características de un circuito electrónico. Estos tipos de funciones pueden incluir:
1) Una suma de comprobación generada para los valores retenidos en una región de la memoria del ordenador 2) Una suma de comprobación generada a partir de una secuencia de salidas digitales de un circuito tras la introducción de una secuencia predefinida de entradas.
3) Valores específicos guardados en la memoria
4) Valores específicos generados por circuitos eléctricos, por ejemplo, una lectura de temperatura
5) Valores específicos como para 4), que han sido procesados para proporcionar un valor adicional, por ejemplo, una función promedio o de máximo o mínimo
xiv) Cláusula 14
Una fase de análisis que correlacionaría las listas de características con los datos de los resultados, con el propósito de identificar cambios en el valor de las características que predecirían obtenciones de resultados específicos, tal como que un elemento del equipo fallará en 4 horas o que un paciente diabético tiene riesgo de coma hipoglucémico. Esta fase de análisis utilizaría procesos matemáticos (análisis de regresión lineal y análisis de regresión logística) junto con técnicas de aprendizaje automático (redes neuronales) para identificar qué características eran importantes en la predicción e identificación de resultados, tales como el posible fallo inminente de un dispositivo compatible con M2M o una emergencia médica.
NOTA: Es importante comprender que el sistema no confía en saber cuáles son las características durante la fase de análisis, y esta actividad de análisis puede ser automatizada total o parcialmente.
xv) Cláusula 15
Un mecanismo para describir las acciones que se deben realizar en caso de que un dispositivo muestre síntomas de fallo como se predijo durante la fase de análisis (según la Cláusula 14), tales como enviar un correo electrónico a una persona de apoyo o presentar una denuncia por problemas.
xvi) Cláusula 16
En el caso de una acción correctiva automatizada (es decir, actualizar la versión del software o deshabilitar/habilitar una característica específica del equipo), el sistema iniciaría esa acción correctiva.
xvii) Cláusula 17
Un mecanismo para describir vínculos entre varias listas de características, de tal manera que las características de una lista de características pueden ser correlacionadas con las características de otra lista de características. xviii) Cláusula 18
Un mecanismo para describir la información de ubicación para una lista de características, de tal manera que la codificación de la información de ubicación permite la correlación entre listas de características, pero no revela la ubicación física real.
xix) Cláusula 19
Un mecanismo para describir la información de ubicación que describe una ubicación en tres o cuatro dimensiones, en relación con puntos de referencia secretos predefinidos. Esto facilitaría el análisis de los datos por ubicación, de una manera que se anonimizara la ubicación geográfica real analizada.
xx) Cláusula 20
Un mecanismo que permite que un dispositivo externo se comunique con un dispositivo que implementa esta invención, para permitirle cambiar los valores del elemento de característica en una característica. Esta lista de funciones se puede denominar Lista de funciones para escribir.
xxi) Cláusula 21
Un mecanismo que hace que los valores de las características en una lista de características inicien selectivamente acciones a realizar. Esta lista de funciones se puede denominar Lista de funciones de acción. Un ejemplo de una Lista de funciones de acción puede contener tres elementos de valor de función, que consisten en:
1) Hora de inicio
2) Hora de finalización
3) Acción para apagar un sensor eléctrico
A continuación, se describen más detalles de la arquitectura general, que puede incluir:
• una primera interfaz (por ejemplo, interfaz en dirección norte - NBi) entre un usuario (por ejemplo, verticales) y una plataforma de gestión de dispositivos - DM (por ejemplo, DMAP), siendo dicha interfaz para permitir la gestión de uno o más dispositivos (por ejemplo, dispositivos M2M o un concentrador, que gestionan dispositivos M2M y otras plataformas de DM);
• una segunda interfaz (por ejemplo, interfaz en dirección sur - SBi) entre la plataforma de DM y (i) una segunda plataforma de DM o (ii) el uno o más dispositivos, en donde la segunda interfaz puede ser segura.
En otras palabras, la primera interfaz permite la comunicación entre un usuario y un dispositivo gestionado (por ejemplo, un activo M2M físico) a través de la plataforma de DM.
La arquitectura puede comprender, además, la plataforma de DM. La plataforma de DM puede comprender un servidor de DM.
El servidor de DM comprende, entre otras, las siguientes funcionalidades:
• gestión (directa o indirecta) de uno o más dispositivos, incluyendo, por ejemplo, recolección de dispositivos, registro/cancelación de registro de dispositivos;
• comunicación (directa o indirecta) con: (a) el usuario (a través de la primera interfaz) y/o (b.1) el uno o más dispositivos; o (b.2) la segunda plataforma de DM;
• descubrimiento de otros dispositivos;
• supervisión de dispositivos, activación de comunicaciones con el usuario para gestionar el dispositivo (por ejemplo, en respuesta a la observación de una o más condiciones configuradas para ser supervisadas), actualización de software/firmware en uno o más dispositivos.
El servidor de DM incluye, asimismo, mecanismos y estructuras para permitir que las diversas funcionalidades funcionen correctamente. El servidor de DM puede ser implementado como una plataforma de hardware, una plataforma de software y/o un servicio en la nube (por ejemplo, alojado en la nube, software como servicio, etc.). La segunda interfaz comprende, entre otras, las siguientes funcionalidades:
• gestionar la seguridad de la comunicación y verificar la autorización de las entidades comunicantes;
• manejar múltiples solicitudes;
• gestionar dispositivos de manera eficiente.
Modelo de datos y sustituto
Estructura del modelo abstraído
Se define y/o genera una estructura de modelo jerárquico abstraído para que pueda ser utilizada para abordar cualquier dispositivo y/o funcionalidades que se gestionen a través de una plataforma de gestión de dispositivos. La estructura del modelo jerárquico se puede utilizar para obtener un modelo específico que se utilizará en un nivel particular (por ejemplo, un nivel de aplicaciones verticales, un nivel de DMAP, un nivel de protocolo, un nivel de dispositivo). En otras palabras, la misma estructura podría ser utilizada para representar información asociada con la gestión de un dispositivo (por ejemplo, un dispositivo M2M) y, a continuación, ser “convertida” para que pueda ser utilizada adecuadamente para el nivel correcto, teniendo cada nivel requisitos específicos.
Modelo de comunicación utilizando un sustituto
El concepto general es que, utilizando un “sustituto” de la entidad de recepción de una comunicación de DM (por ejemplo, un dispositivo M2M, otra plataforma de DM, un concentrador que controla uno o más dispositivos), la comunicación en las dos interfaces puede ser dividida y simplificada de manera significativa.
En particular, un “sustituto” es una réplica de la entidad de recepción dentro del marco de la plataforma de DM, es decir, se ajusta a una estructura de datos unificada (por ejemplo, la estructura del modelo abstraído) y/o a un protocolo unificado definido para una primera interfaz (por ejemplo, la NBi). El “sustituto” está asociado con una instancia de la entidad de recepción.
De esta manera, la comunicación entre el usuario y la plataforma de DM a través de la primera interfaz (por ejemplo, NBi) se puede realizar utilizando un mensaje similar que se ajusta solo a la estructura de datos unificada, independientemente de la estructura de datos que utilice la entidad de recepción real. El usuario se comunica eficazmente con el “sustituto” en lugar de con la entidad de recepción real.
De manera similar, el “sustituto” en la plataforma de DM se comunicará con su entidad de recepción correspondiente a través de la segunda interfaz “adaptando” la estructura de datos unificada en la estructura de datos específica utilizada por la entidad de recepción correspondiente. Esto se hace mediante un adaptador.
Mecanismos adicionales
Supervisión de dispositivos sin conexión
Un mecanismo para permitir que la plataforma de DM supervise el dispositivo “en nombre” del usuario (por ejemplo, una aplicación vertical 20) en función de una indicación proporcionada por el usuario, y, a continuación, devolver información al usuario cuando la plataforma de DM identifica que ciertos criterios proporcionados en la indicación están satisfechos.
El mecanismo puede incluir que la plataforma de DM reciba una indicación del usuario o aplicación que especifique al menos un criterio a supervisar para uno o más dispositivos. La indicación puede incluir una manera específica de contactar con el usuario una vez que se ha satisfecho al menos un criterio. La indicación puede ser proporcionada por medio de una conexión asíncrona (por ejemplo, una conexión que está esencialmente configurada para proporcionar la indicación, pero no para recibir la respuesta desencadenada por el al menos un criterio). La plataforma de DM supervisa el uno o más dispositivos 120 en base al al menos un criterio. La plataforma de DM se pone en contacto con el usuario o la aplicación en respuesta al cumplimiento de al menos un criterio. La indicación puede ser un activador.
Actualización de firmware
La capacidad de actualizar el software en un dispositivo (para que esté actualizado) es una característica muy valiosa e importante de la gestión de dispositivos, pero es difícil de gestionar si tiene muchos miles de dispositivos, todos en diferentes versiones.
La plataforma de DM utiliza un enfoque declarativo para administrar la gestión de software/firmware para colecciones de dispositivos, que soporta diferentes tipos de dispositivos, diferentes secuencias de acciones para realizar durante las actualizaciones y, lo más importante, una máquina de estados, que describe la secuencia en donde deben ser realizadas las operaciones de actualización (es decir, donde se necesita realizar la transición del dispositivo a través de múltiples actualizaciones para llevar a los dispositivos al último nivel de versión).
Mensaje de activación: entrega de datos seguros
Este es un mecanismo para entregar parámetros seguros directamente a través del mensaje de activación (es decir, el mensaje utilizado para activar un dispositivo “latente”). El mensaje puede ser un mensaje SMS, por ejemplo. Este mensaje es enviado por la plataforma de DM para activar una conexión (por ejemplo, una conexión de UDP) entre el dispositivo y la plataforma de DM.
En particular, cuando se utiliza un mensaje SMS, si no hay una clave de SMS existente (es decir, el canal de SMS no está protegido), entonces el mensaje puede contener una arquitectura de arranque genérica (GBA - Generic Bootstrap Architecture, en inglés) de información de tipo directo (porque no es necesario asegurar los SMS). Por otro lado, si una clave existente para SMS está presente (es decir, el canal de SMS ha sido protegido), entonces el mensaje puede contener cualquier tipo de información de seguridad, por ejemplo, claves adicionales que se utilizarán para asegurado la conexión posterior.
El mecanismo puede incluir también un mecanismo para determinar si se ha asegurado el canal de SMS. Una de las ventajas de este mecanismo es que se puede reducir la señalización entre la plataforma de DM y el dispositivo. Es importante comprender que, en las plataformas actuales, la activación desde la plataforma de DM al dispositivo solo se puede utilizar para activar el dispositivo. Todas las comunicaciones de datos siempre se inician desde el dispositivo.
La figura 17 ilustra un diagrama esquemático de un sistema 800 utilizado para proporcionar comunicaciones entre un gestor de dispositivos 860 y uno o más dispositivos gestionados 120.
El gestor de dispositivos 860 contiene la lógica 810 que se utiliza para controlar el sistema (por ejemplo, realizar acciones en los dispositivos gestionados) y la interfaz con una pluralidad de interfaces de comunicaciones 820, 830 y 840. En esta implementación a modo de ejemplo, la interfaz de comunicaciones 820 es una interfaz de SMS que está dispuesto para enviar mensajes SMS a los dispositivos gestionados 120 a través de una red celular 850. Las interfaces de comunicación 830 y 840 son interfaces separadas y de diferentes tipos (por ejemplo, cualquiera de protocolo de control de transmisión (TCP), protocolo de datagrama de usuario (UDP), celular, inalámbrico, WiFi, WiMax, cableada, línea fija o línea telefónica) y se pueden comunicar de manera inalámbrica o mediante un enlace de línea fija o cableada para recibir datos y enviar datos a los dispositivos gestionados 120. Este ejemplo muestra dos interfaces de comunicación para enviar y recibir datos de los dispositivos gestionados 120. Sin embargo, cualquier número (por ejemplo, uno, dos, tres, cuatro, etc.) puede ser utilizado, solo o juntos en cualquier combinación.
La interfaz de comunicaciones 840 es una interfaz de comunicaciones opcional o alternativa en este ejemplo y puede ser utilizada en lugar de o para reemplazar la interfaz de comunicaciones 830. La interfaz de SMS 820 (u otro tipo) puede ser utilizada para enviar un mensaje desde el gestor de dispositivos 860 a cualquier uno o más de los dispositivos gestionados (por ejemplo, dispositivos M2M u otros gestores de dispositivos) para iniciar, arrancar, reactivar o reanudar las comunicaciones. Esta inicialización de comunicaciones puede estar utilizando una o ambas interfaces de comunicaciones 830 u 840. Cuando la interfaz de comunicaciones 840 no está presente o no está en uso, el mensaje hace que los dispositivos gestionados 120 inicien o reanuden las comunicaciones únicamente a través de la interfaz de comunicaciones 830.
Mensaje de activación: activar conexión de línea fija
Este mecanismo puede utilizar el mensaje de activación (o un mensaje alternativo) para solicitar el cambio de la conexión desde la conexión inalámbrica a través de la cual se envía el mensaje a un tipo alternativo de conexión inalámbrica (por ejemplo, una conexión con un ancho de banda mayor) o para una conexión por cable. La conmutación también puede ser de una conexión por cable a una conexión por cable diferente, o a una conexión inalámbrica, por ejemplo. La conmutación puede ser determinada, por ejemplo, basándose en la detección de un archivo grande a entregar (por ejemplo, que requeriría demasiado ancho de banda y/o tiempo). El mensaje puede indicarle al dispositivo que cambie automáticamente, o pedirle a un usuario asociado con ese dispositivo que cambie la conexión.
Este mecanismo podría, por ejemplo, ahorrar energía en los dispositivos M2M y tiempo para descargar el archivo (tiempo de conexión).
En el sistema 800 a modo de ejemplo que se muestra en la figura 17, en lugar de o además de provocar un inicio de comunicaciones desde los dispositivos gestionados 120, el mensaje SMS enviado utilizando la interfaz de SMS 820 a los dispositivos gestionados puede provocar o activar una conmutación de utilizar un sistema de comunicaciones o interfaz 830 (ya sea la interfaz o sistema utilizado para enviar el mensaje SMS o uno diferente) a otro sistema de comunicaciones o interfaz 840.
La figura 18 muestra un diagrama de flujo de un método 900 para iniciar comunicaciones o alterar las comunicaciones entre el gestor de dispositivos 860 (o DMAP 60) y uno o más de los dispositivos gestionados 120 mostrados en la figura 17. El método puede ser realizado por la lógica 810 ejecutada por un procesador (no mostrado en esta figura).
En la etapa 910, se envía un mensaje a través de un primer canal de comunicaciones utilizando la interfaz de comunicaciones 820 (por ejemplo, SMS). El uno o más dispositivos gestionados 120 reciben este mensaje en la etapa 920. Esto provoca la etapa 930, que es un inicio de comunicaciones entre los dispositivos gestionados y el gestor de dispositivos 860 sobre el segundo canal de comunicaciones utilizando la interfaz 830. La recepción del mensaje sobre la interfaz de comunicaciones 820 puede provocar, opcionalmente, una finalización de las comunicaciones sobre un tercer canal (utilizando la interfaz 840) en la etapa 925. Esto también se puede describir como una conmutación del canal de comunicaciones de utilizar la interfaz 830 a la interfaz 840 (es decir, de un canal a otro).
Mejoras adicionales:
• SBi: en particular, cómo manejar múltiples solicitudes de múltiples partes.
• Programación de actualizaciones de software/firmware.
La plataforma de DM utiliza un enfoque declarativo y utiliza estructuras de datos y sus relaciones para describir cómo funcionan las cosas.
Un “enfoque declarativo” es un término de programación utilizado para describir un modo basado en datos, de representar soluciones a problemas. El ejemplo más simple son los semáforos. Para una descripción de manera declarativa, se describirían los estados de los semáforos (declararlos) como: {Rojo, ámbar, verde, ámbar}
El procesador del semáforo diría entonces recorrer los cuatro estados para siempre.
Que es claro y sencillo.
El enfoque procedimental de la programación describiría el proceso como:
Si es rojo, entonces, el siguiente estado es ámbar
si no, si es verde, el siguiente estado es ámbar
si no, si es ámbar y el estado anterior es rojo, el siguiente estado es verde
Si no, el siguiente estado es rojo.
Lo que es más difícil de mantener.
El sistema mejorado formaliza un mecanismo para representar y capturar información y datos de dispositivos, especialmente en aplicaciones M2M, y simplifica el modo en que se utilizan y gestionan los datos capturados. De este modo, tiene aplicaciones en muchos sectores que involucran la obtención de datos desde dispositivos a distancia. El sistema también puede facilitar la mejora de las capacidades funcionales y de diagnóstico, especialmente cuando se trabaja con otros dispositivos y aplicaciones M2M. M2M implica capturar una gran cantidad de datos de una amplia gama de electrodomésticos y dispositivos. El problema y la oportunidad es cómo analiza y utiliza estos datos. La mejora proporciona un método para organizar los datos obtenidos en/desde dispositivos M2M, que facilitará la utilización y dará sentido a esos datos.
1) El protocolo SNMP soporta estructuras de datos que son jerarquías de objetos y que facilitan los procesos externos para consultar estas estructuras de datos. Los datos son consultados elemento por elemento, o las colecciones de datos dentro de un subárbol de la jerarquía de los objetos de datos pueden ser consultadas en una sola solicitud. Esta es una tecnología madura que cuenta con un amplio soporte.
2) OMA-DM y los protocolos incipientes LWM2M soportan la representación de estructuras de datos de una manera jerárquica y muy similar a SNMP, pero optimizada para entornos M2M.
Una deficiencia de estos modelos de datos jerárquicos es que son restrictivos y simplistas. No reflejan el modo en que se requiere la utilización de los datos. Como consecuencia, el desarrollador de aplicaciones debe comprender dónde y cómo se organizan los datos y, por lo general, debe realizar múltiples solicitudes de datos para capturar todos los elementos de datos de interés. Obtener los datos (utilizando múltiples consultas) es costoso, el diseño de aplicaciones que utilizan los datos requiere conocimiento del dominio, lo cual es costoso y limita el modo en que las aplicaciones pueden utilizar esos datos.
La mejora describe el modo de organizar y representar valores de datos en estructuras de lista, donde los elementos de datos están organizados en secuencias contiguas de valores. Los elementos de datos que son de (potencial) interés en un dispositivo M2M para los desarrolladores de aplicaciones se asignan a estructuras de listas. Ejemplos de listas ilustrativas:
1) Lista de diagnóstico de hardware, secuencia de valores de datos que representan comprobaciones de hardware en el dispositivo (comprobaciones de memoria de CRC, comportamiento del circuito eléctrico, sensor de temperatura, sensores de entrada de agua, etc.)
2) Lista de versiones del equipo, secuencia de valores de versión de todos los componentes y elementos de software identificables.
3) Lista de sensores, lista de valores de sensores, tales como valores procesados/sin procesar. Un ejemplo de un valor procesado sería cuando se promedió el valor de un sensor de temperatura durante un período de cinco minutos, o se promedió la intensidad de la señal de radio durante un período de tres meses.
4) Lista personal privada, información de ubicación, datos personales del cliente final, que está sujeta a la ley de protección de datos.
5) Listas de series de tiempo, en donde se pueden organizar varias listas en una secuencia, de modo que se puede acceder a las listas y gestionarlas de manera secuencial o de acceso aleatorio.
Utilizando la medición inteligente como ejemplo:
1) La lista de diagnóstico de hardware puede ser utilizada por la organización que mantiene el equipo de medición inteligente en el campo, y sería utilizada para diagnosticar y predecir defectos.
2) La lista de versiones del equipo puede ser utilizada por la organización que proporciona actualizaciones de firmware/software para verificar que se esté aplicando la versión correcta de la actualización.
3) La lista de sensores puede contener lecturas de sensores que se utilizarán con fines analíticos.
4) La lista personal privada se puede utilizar con los controles de seguridad adecuados para gestionar las funciones centradas en el cliente.
5) La lista de sensores (ver 3 arriba) se puede gestionar como una lista de series de tiempo, por lo que los valores de los sensores se obtienen a intervalos regulares (por ejemplo, cada 15 minutos) y se colocan en una lista de series de tiempo de varias filas. A continuación, las aplicaciones pueden consultar los valores según corresponda. Por ejemplo, una aplicación de lectura de medidores consultaría el dispositivo dos veces al día y leería todos los datos de series de tiempo obtenidos durante el período anterior.
En un aspecto, las estructuras de datos jerárquicas simples para dispositivos M2M se asignan a estructuras de listas utilizando conceptos que son comunes a las bases de datos relacionales. Muchas de las construcciones familiares para la programación de bases de datos relacionales SQL pueden ser incorporadas en este aspecto (por ejemplo, la utilización de valores nulos, mecanismos de reflexión, disparadores, claves principales y externas).
Hay muchas características de este enfoque (véanse las cláusulas anteriores) que facilitarán mucho la utilización de los datos almacenados en listas por parte de los desarrolladores de aplicaciones. La idea podría ser implementada por los diseñadores de hardware que definirían las listas de funciones en el producto, para que terceros puedan hacer un mejor uso de los productos. Esto podría ser implementado declarativamente por el desarrollador del equipo, quien utilizaría una notación XML para describir los elementos de cada lista y sus propiedades. Por ejemplo, un elemento de la lista sería una media móvil, con un tiempo de muestra de x, y con resultados que serían normalizados dentro de un rango comprendido entre a y b.
Las operaciones de gestión de listas pueden utilizar construcciones de teoría de conjuntos y, por lo tanto, permitir que dos listas sean consultadas como una combinación (Lista 1 Lista 2) o una intersección (Lista 1 y Lista 2) o como una diferencia (Lista 1 - Lista 2). Esto puede facilitar a los desarrolladores de aplicaciones la asignación de consultas de datos en estructuras de datos relevantes.
Las operaciones de gestión de listas pueden utilizar operaciones y construcciones relacionales (SQL) para consultar y modificar estructuras de datos. Los componentes de la lista pueden ser asignados en otras estructuras de datos en el nivel de la aplicación utilizando construcciones y operadores relacionales. Por ejemplo, las lecturas del sensor de temperatura pueden ser asignadas a un elemento de la lista como una media móvil de 30 días. Esto puede facilitar a los desarrolladores de productos la presentación de datos para el uso de la aplicación.
La plataforma de DM se puede describir como una máquina de flujo de datos que utiliza la teoría de conjuntos en conjuntos de datos de entrada para generar conjuntos de resultados que desencadenan actividades adicionales (análisis, diagnósticos y alertas).
La figura 15 muestra un diagrama esquemático de un sistema 600 para gestionar dispositivos 120, 130, 140. El gestor de dispositivos o DMAP 60 está en comunicación con un almacén de memoria 605 que contiene ubicaciones de memoria 610. El almacén de memoria 605 puede adoptar muchas formas alternativas, incluidas las relacionales. base de datos, sistema de archivos, disco duro, almacenamiento distribuido, memoria flash, memoria volátil o memoria no volátil, por ejemplo. Cada ubicación de memoria está asociada con un dispositivo 120, 130, 140 que está siendo gestionado por el sistema 600. Cada ubicación de memoria se utiliza para almacenar uno o más atributos 620.
El gestor de dispositivos 60 recibe instrucciones o comandos para realizar una acción sobre uno o más atributos almacenados. Por ejemplo, esto puede ser leer, escribir, borrar o actualizar un atributo o grupo de atributos. El gestor de dispositivos 60 también está configurado para recibir desde uno o más dispositivos 120, 130, 140 valores o datos que se corresponden con los atributos almacenados. Un dispositivo de sincronización 630 mantiene la sincronización entre los atributos almacenados y los atributos o valores asociados con cada uno de los dispositivos. El dispositivo de sincronización 630 puede formar parte del gestor de dispositivos 60, separado o a distancia.
En otras palabras, se pueden llevar a cabo acciones sobre los atributos almacenados en la memoria y/o se pueden recibir o recuperar valores desde los dispositivos físicos 120, 130, 140. El dispositivo de sincronización 630 garantiza que los atributos almacenados y los valores o atributos del dispositivo son mantenidos en sincronización o actualizados para reflejar cualquier cambio.
La figura 16 ilustra un método 700 para gestionar uno o más dispositivos 120, 130, 140. En la etapa 710 se almacenan los atributos. Esto puede estar en las ubicaciones de memoria 610 del almacén de memoria 605. El gestor de dispositivos 60 realiza una acción sobre estos atributos almacenados en la etapa 720. El gestor de dispositivos 60 recibe valores o atributos de dispositivos de los dispositivos gestionados 120, 130, 140 en la etapa 730. La sincronización entre los atributos almacenados 620 y los atributos de los dispositivos asociados 120, 130, 140 es mantenida en la etapa 740. Cabe señalar que las etapas 710, 720, 730 y 740 pueden tener lugar en cualquier orden, y dos o más de estas etapas pueden tener lugar simultáneamente. El método 700 también puede realizar iteraciones o funcionar de manera continua.
El sistema informático y la arquitectura pueden incluir un procesador, tal como una unidad central de procesamiento (CPU). El procesador puede ejecutar la lógica en forma de un programa de software. El sistema informático puede incluir una memoria que incluye un medio de almacenamiento volátil y no volátil. Un medio legible por ordenador puede estar incluido, para almacenar la lógica o las instrucciones del programa. Las diferentes partes del sistema pueden estar conectadas mediante una red (por ejemplo, redes inalámbricas y redes cableadas). El sistema informático puede incluir una o más interfaces. El sistema informático puede contener un sistema operativo adecuado tal como, por ejemplo, UNIX, Windows (RTM) o Linux.
Como apreciará el experto en la materia, los detalles de la realización anterior pueden ser variados sin apartarse del alcance de la presente invención, tal como está definida en las reivindicaciones adjuntas.
Por ejemplo, la plataforma de DM puede ser implementada en hardware utilizando varias FPGA.
Muchas combinaciones, modificaciones o alteraciones de las características de las realizaciones anteriores serán fácilmente evidentes para el experto, y se pretende que formen parte de la invención. Cualquiera de las características descritas específicamente en relación con una realización o ejemplo puede ser utilizada en cualquier otra realización, mediante la realización de los cambios adecuados.

Claims (10)

REIVINDICACIONES
1. Un método para comunicarse entre un dispositivo gestionado y un gestor de dispositivos, comprendiendo el método las etapas de:
enviar al dispositivo gestionado un mensaje a través de un primer canal de comunicaciones; e
iniciar la comunicación entre el dispositivo gestionado y el gestor de dispositivos a través de un segundo canal de comunicaciones en respuesta al mensaje, en donde el primer canal de comunicaciones y el segundo canal de comunicaciones son de diferentes tipos, en donde las comunicaciones entre el dispositivo gestionado y el gestor de dispositivos a través del segundo canal de comunicaciones están suspendidas hasta que se recibe el mensaje,
en donde la recepción del mensaje en el dispositivo gestionado provoca, además, que las comunicaciones entre el dispositivo gestionado y el gestor de dispositivos a través de un tercer canal de comunicaciones cesen y sean conmutadas al segundo canal de comunicaciones, en donde el tercer canal de comunicaciones es diferente al segundo canal de comunicaciones, y
en donde el primer canal de comunicaciones es un canal celular y el segundo canal de comunicaciones es un canal no celular.
2. El método según cualquiera de las reivindicaciones anteriores, en donde el primer canal de comunicaciones está dentro de un primer sistema de comunicaciones y el segundo canal de comunicaciones está dentro de un segundo sistema de comunicaciones diferente del primer sistema de comunicaciones.
3. El método según cualquiera de las reivindicaciones anteriores, en donde el mensaje es SMS o SMS, SMS-MT, WAP-directo u OMA-directo terminados en un dispositivo móvil.
4. El método según cualquiera de las reivindicaciones anteriores, en donde el dispositivo gestionado está en un estado de latencia hasta que se recibe el mensaje.
5. El método según la reivindicación 1, en donde el mensaje es enviado al dispositivo gestionado en respuesta a: un aumento en el volumen de datos; una solicitud para enviar al dispositivo gestionado un archivo por encima de un umbral predeterminado; una solicitud de actualización de firmware o software; un aumento de la energía eléctrica utilizada por el dispositivo gestionado por encima de un umbral predeterminado; y una disminución en la velocidad de transferencia de datos por debajo de un umbral predeterminado.
6. El método según cualquiera de las reivindicaciones anteriores, en donde el mensaje es un mensaje SMS seguro, en donde el SMS se asegura utilizando información establecida por la arquitectura de arranque genérica, GBA.
7. El método según cualquiera de las reivindicaciones 1 a 5, en donde el mensaje es un mensaje no seguro, en donde el mensaje es un mensaje SMS no seguro que contiene información directa de una arquitectura de arranque genérica, GBA, comprendiendo el método, además, la etapa de confirmar la autenticidad del mensaje utilizando la información de inserción de GBA y en donde la comunicación entre el dispositivo gestionado y el gestor de dispositivos a través de los segundos canales de comunicaciones se inicia tras una autenticación satisfactoria.
8. El método según cualquiera de las reivindicaciones anteriores, en donde el dispositivo gestionado es un dispositivo de máquina a máquina, M2M.
9. Un sistema para comunicarse con uno o más dispositivos gestionados que comprende:
un gestor de dispositivos;
una primera interfaz de comunicaciones;
una segunda interfaz de comunicaciones, diferente de la primera interfaz de comunicaciones;
una tercera interfaz de comunicaciones, diferente de la segunda interfaz de comunicaciones; y lógica configurada para:
enviar a un dispositivo gestionado un mensaje a través de un primer canal de comunicaciones utilizando la primera interfaz de comunicaciones; e
iniciar comunicaciones entre el dispositivo gestionado y el gestor de dispositivos a través de un segundo canal de comunicaciones utilizando la segunda interfaz de comunicaciones en respuesta al mensaje, en donde las comunicaciones entre el dispositivo gestionado y el gestor de dispositivos a través del segundo canal de comunicaciones están suspendidas hasta que se recibe el mensaje,
en donde la recepción del mensaje en el dispositivo gestionado provoca, además, que las comunicaciones entre el dispositivo gestionado y el gestor de dispositivos a través de un tercer canal de comunicaciones utilizando una tercera interfaz, cesen y sean conmutadas al segundo canal de comunicaciones, en donde el tercer canal de comunicaciones es diferente del segundo canal de comunicaciones, y
en donde la primera interfaz de comunicaciones es una interfaz celular y la segunda interfaz de comunicaciones es una interfaz no celular.
10. El sistema de la reivindicación 9, en donde la primera interfaz de comunicaciones está configurada para comunicarse con un primer sistema de comunicaciones y la segunda interfaz de comunicaciones está configurada para comunicarse con un segundo sistema de comunicaciones diferente del primer sistema de comunicaciones.
ES14776684T 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina Active ES2893353T3 (es)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
GB201316370A GB201316370D0 (en) 2013-09-13 2013-09-13 Secure device management
GB201318339A GB201318339D0 (en) 2013-10-16 2013-10-16 Machine to machine architecture
GB1409643.2A GB2518255A (en) 2013-09-13 2014-05-30 Communicating with a machine to machine device
GB1409641.6A GB2518254B (en) 2013-09-13 2014-05-30 Communicating with a machine to machine device
GB1409652.3A GB2518256A (en) 2013-09-13 2014-05-30 Communicating with a machine to machine device
GB1409663.0A GB2518257A (en) 2013-09-13 2014-05-30 Methods and systems for operating a secure mobile device
GB1414999.1A GB2518522B (en) 2013-09-13 2014-08-22 Communicating with a machine to machine device
GB1415003.1A GB2518296B (en) 2013-09-13 2014-08-22 Methods and systems for communicating with an M2M device
GB1414997.5A GB2518521A (en) 2013-09-13 2014-08-22 Communicating with an machine to machine device
GB1415925.5A GB2519429B (en) 2013-09-13 2014-09-09 Communicating with machine to machine devices
PCT/GB2014/052788 WO2015036793A1 (en) 2013-09-13 2014-09-12 Communicating with machine to machine devices

Publications (1)

Publication Number Publication Date
ES2893353T3 true ES2893353T3 (es) 2022-02-08

Family

ID=51214488

Family Applications (2)

Application Number Title Priority Date Filing Date
ES14776684T Active ES2893353T3 (es) 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina
ES20209753T Active ES2933426T3 (es) 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES20209753T Active ES2933426T3 (es) 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina

Country Status (6)

Country Link
US (14) US20160234183A1 (es)
EP (15) EP3044927A1 (es)
CN (1) CN105706469B (es)
ES (2) ES2893353T3 (es)
GB (15) GB2518254B (es)
WO (12) WO2015036791A1 (es)

Families Citing this family (181)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE48631E1 (en) * 2012-06-08 2021-07-06 Samsung Electronics Co., Ltd. Method and system for selective protection of data exchanged between user equipment and network
WO2014112969A1 (en) * 2013-01-15 2014-07-24 Hewlett-Packard Development Company, L.P. Dynamic firmware updating
EP3557894B1 (en) * 2013-05-06 2023-12-27 Convida Wireless, LLC Device triggering
US9100175B2 (en) 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
GB2518254B (en) 2013-09-13 2020-12-16 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
US10700856B2 (en) 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9871889B1 (en) * 2014-03-18 2018-01-16 EMC IP Holing Company LLC Techniques for automated capture of configuration data for simulation
CN104954399B (zh) * 2014-03-27 2018-06-19 正文科技股份有限公司 绑定移动载具与智能装置之方法及其绑定系统
JP6342014B2 (ja) * 2014-04-09 2018-06-13 コンヴィーダ ワイヤレス， エルエルシー サービスイネーブラ機能
WO2015179917A1 (en) * 2014-05-27 2015-12-03 Resmed Limited Remote diagnostics of respiratory therapy devices
KR101950122B1 (ko) * 2014-07-22 2019-05-22 콘비다 와이어리스, 엘엘씨 경량 기기 간 프로토콜을 디바이스 관리 프로토콜과 상호연동하기
GB2529838B (en) 2014-09-03 2021-06-30 Advanced Risc Mach Ltd Bootstrap Mechanism For Endpoint Devices
EP3198893A1 (en) * 2014-09-25 2017-08-02 Telefonaktiebolaget LM Ericsson (publ) Device mobility with coap
US9763063B2 (en) * 2014-10-06 2017-09-12 Derek D. Kumar Secure broadcast beacon communications
US9807079B2 (en) * 2014-10-23 2017-10-31 Palo Alto Network, Inc. Single sign on proxy for regulating access to a cloud service
CN107113333B (zh) * 2014-12-11 2021-06-08 英国电讯有限公司 在服务器计算机上安装软件的方法和通信接口装置
WO2016113593A1 (en) * 2015-01-13 2016-07-21 Telefonaktiebolaget Lm Ericsson (Publ) Application protocol query for securing gba usage
US9591027B2 (en) 2015-02-17 2017-03-07 Qualys, Inc. Advanced asset tracking and correlation
US10084865B2 (en) 2015-02-26 2018-09-25 Urban Airship, Inc. Mobile event notifications
US10200486B2 (en) 2015-02-26 2019-02-05 Urban Airship, Inc. Mobile event notifications for network enabled objects
JP2018507646A (ja) * 2015-02-27 2018-03-15 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 通信デバイスとネットワークデバイスとの間の通信におけるセキュリティ構成
GB2536698A (en) * 2015-03-26 2016-09-28 Eoghan Hynes Secure communications between a beacon and a handset
US11258874B2 (en) 2015-03-27 2022-02-22 Globallogic, Inc. Method and system for sensing information, imputing meaning to the information, and determining actions based on that meaning, in a distributed computing environment
US10601823B2 (en) 2015-04-07 2020-03-24 Tyco Fire & Security Gmbh Machine to-machine and machine to cloud end-to-end authentication and security
US10701111B2 (en) * 2015-04-10 2020-06-30 Nokia Of America Corporation Method and apparatus for device management
KR102423885B1 (ko) * 2015-05-08 2022-07-21 한국전자통신연구원 연산 에러 검출이 가능한 준동형 암호 방법 및 그 시스템
EP3374923B1 (en) 2015-05-22 2021-08-25 Huawei Device Co., Ltd. Cryptographic unit for public key infrastructure (pki) operations
GB2538773A (en) * 2015-05-28 2016-11-30 Vodafone Ip Licensing Ltd Device key security
CN105045114B (zh) * 2015-05-29 2019-11-19 四川长虹电器股份有限公司 一种信息处理方法、云服务平台及信息处理系统
US10135871B2 (en) * 2015-06-12 2018-11-20 Accenture Global Solutions Limited Service oriented software-defined security framework
WO2016202375A1 (en) 2015-06-17 2016-12-22 Telefonaktiebolaget Lm Ericsson (Publ) Method for enabling a secure provisioning of a credential, and related wireless devices and servers
EP3318032B1 (en) 2015-07-02 2022-05-04 Telefonaktiebolaget LM Ericsson (publ) Method for obtaining initial access to a network, and related wireless devices and network nodes
WO2017007385A1 (en) * 2015-07-06 2017-01-12 Telefonaktiebolaget Lm Ericsson (Publ) Facilitating secure communcation between a client device and an application server
GB2540354A (en) * 2015-07-13 2017-01-18 Vodafone Ip Licensing Ltd Generci bootstrapping architecture protocol
CN106487501B (zh) * 2015-08-27 2020-12-08 华为技术有限公司 密钥分发和接收方法、密钥管理中心、第一和第二网元
US10057382B2 (en) * 2015-09-24 2018-08-21 Amrita Vishwa Vidyapeetham Intelligent “IoT gateway”
KR101707602B1 (ko) * 2015-09-25 2017-02-17 상명대학교 천안산학협력단 해시 트리 기반 보안 메시지 인증 방법 및 이를 위한 장치
WO2017061815A1 (en) * 2015-10-07 2017-04-13 Samsung Electronics Co., Ltd. Method for resource mapping between restful server and onem2m system
CN108141369A (zh) * 2015-10-23 2018-06-08 瑞典爱立信有限公司 机器对机器装置的操作状态的建立
EP3381208B1 (en) * 2015-11-24 2020-02-26 Telefonaktiebolaget LM Ericsson (PUBL) Charging record authentication for anonymized network service utilization
US11044593B2 (en) * 2015-12-03 2021-06-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and devices for managing constrained devices
WO2017131564A1 (en) * 2016-01-27 2017-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Method for setting up a secure connection between lwm2m devices
US11290425B2 (en) * 2016-02-01 2022-03-29 Airwatch Llc Configuring network security based on device management characteristics
WO2017139046A1 (en) * 2016-02-09 2017-08-17 Presenso, Ltd. System and method for unsupervised root cause analysis of machine failures
US10268495B2 (en) * 2016-02-18 2019-04-23 Verizon Patent And Licensing Inc. Virtual device model system
US10172000B2 (en) * 2016-03-17 2019-01-01 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
US10158991B2 (en) * 2016-03-17 2018-12-18 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
US10135946B2 (en) * 2016-04-11 2018-11-20 Verizon Patent And Licensing Inc. Sending messages to mobile devices
US10788202B2 (en) 2016-05-23 2020-09-29 Hsl Energy Holding Aps Apparatus for production of steam from an aqueous liquid
US10484363B2 (en) * 2016-05-23 2019-11-19 Lg Electronics Inc. Method and apparatus for authenticating a device using Bluetooth technology
WO2017202466A1 (en) * 2016-05-26 2017-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Network application function registration
US9847875B1 (en) * 2016-06-20 2017-12-19 Verizon Patent And Licensing Inc. Methods and systems for bootstrapping an end-to-end application layer session security keyset based on a subscriber identity master security credential
US11075806B1 (en) 2016-06-30 2021-07-27 Juniper Networks, Inc. Hierarchical naming scheme for state propagation within network devices
EP3270620A1 (en) * 2016-07-13 2018-01-17 Gemalto Sa Method and devices for managing a secure element
EP3270321B1 (en) * 2016-07-14 2020-02-19 Kontron Modular Computers SAS Technique for securely performing an operation in an iot environment
US10298996B2 (en) 2016-08-18 2019-05-21 At&T Intellectual Property I, L.P. Satellite TV user community smart device monitoring and management
US10650621B1 (en) 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network
US10791108B2 (en) * 2016-10-04 2020-09-29 Joseph Jay Austin Apparatuses, systems and methods for tracking network connected devices
EP3523724B1 (en) * 2016-10-07 2023-12-06 Convida Wireless, LLC Service layer resource management for generic interworking and extensibility
CN107995673A (zh) * 2016-10-27 2018-05-04 中兴通讯股份有限公司 一种语音数据处理装置、方法及终端
US20180139090A1 (en) * 2016-11-15 2018-05-17 John Geiger Method for secure enrollment of devices in the industrial internet of things
US10455057B2 (en) * 2016-11-29 2019-10-22 Verizon Patent And Licensing Inc. System and method for Lightweight-Machine-to-Machine device registration and assignment
GB2558205B (en) * 2016-12-15 2019-07-03 Arm Ip Ltd Enabling communications between devices
JP2018101724A (ja) * 2016-12-21 2018-06-28 株式会社村田製作所 積層セラミックコンデンサ
US10887173B2 (en) 2016-12-21 2021-01-05 Juniper Networks, Inc. Communicating state information in distributed operating systems
US11316744B2 (en) 2016-12-21 2022-04-26 Juniper Networks, Inc. Organizing execution of distributed operating systems for network devices
US11316775B2 (en) 2016-12-21 2022-04-26 Juniper Networks, Inc. Maintaining coherency in distributed operating systems for network devices
US20180184290A1 (en) * 2016-12-22 2018-06-28 Cypress Semiconductor Corporation Embedded Certificate Method for Strong Authentication and Ease of Use for Wireless IoT Systems
US10430566B2 (en) * 2016-12-27 2019-10-01 Paypal, Inc. Vehicle based electronic authentication and device management
CN108306911B (zh) * 2017-01-12 2020-12-29 中移物联网有限公司 一种物联网事件监测方法及设备
US10439895B2 (en) * 2017-01-31 2019-10-08 Salesforce.Com, Inc. Dynamic selection of channels for incoming communication
US10389593B2 (en) * 2017-02-06 2019-08-20 International Business Machines Corporation Refining of applicability rules of management activities according to missing fulfilments thereof
ES2742128T3 (es) * 2017-03-03 2020-02-13 Boeing Co Sistema y método implementado por ordenador para la autentificación entre máquinas de un aparato
US10929573B2 (en) * 2017-03-21 2021-02-23 The Boeing Company Systems and methods for designing and modeling products in a cloud environment
US10992711B2 (en) * 2017-04-13 2021-04-27 At&T Intellectual Property I, L.P. Network aware data driven internet of things service engine
US10972453B1 (en) * 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
CN113518022A (zh) * 2017-05-31 2021-10-19 普天智能照明研究院有限公司 用于用户设备与家居设备连接配置的方法
US10548185B2 (en) * 2017-06-23 2020-01-28 At&T Mobility Ii Llc Facilitating integrated management of connected assets that utilize different technologies and that are located across disparate wireless communications networks
US10528293B2 (en) 2017-06-26 2020-01-07 International Business Machines Corporation Grouping devices as a virtual device for providing better quality of device data
WO2019007476A1 (en) * 2017-07-03 2019-01-10 Telefonaktiebolaget Lm Ericsson (Publ) SECURE COMMUNICATIONS USING NETWORK ACCESS IDENTITY
JP6934762B2 (ja) * 2017-07-04 2021-09-15 株式会社ソラコム 機器をリモートで管理するための装置、方法及びそのためのプログラム
CN107493571B (zh) * 2017-07-20 2020-04-14 深圳市盛路物联通讯技术有限公司 物联网中继器基于类型的上行数据加密控制方法及装置
US20190036896A1 (en) * 2017-07-27 2019-01-31 Cisco Technology, Inc. Generic Bootstrapping Architecture (GBA) Based Security Over Constrained Application Protocol (CoAP) for IoT Devices
US10628151B2 (en) * 2017-08-10 2020-04-21 Dell Products L.P. Systems and methods for usage driven determination of update criticality
US10944753B2 (en) * 2017-08-17 2021-03-09 Verizon Patent And Licensing Inc. IoT devices wireless network connectivity policy management
TWI685227B (zh) * 2017-08-28 2020-02-11 大同股份有限公司 閘道器、物聯網裝置控制系統與其方法
EP3677063B1 (en) * 2017-08-30 2023-10-04 Telefonaktiebolaget LM Ericsson (Publ) Reconfiguration of communications devices
US10901812B2 (en) * 2017-09-18 2021-01-26 Rapyuta Robotics Co., Ltd. Managing communication between cloud and heterogeneous devices across networks
US10560326B2 (en) 2017-09-22 2020-02-11 Webroot Inc. State-based entity behavior analysis
CN107749878B (zh) * 2017-10-16 2021-05-14 新华三信息安全技术有限公司 一种同步文件的方法及装置
WO2019075608A1 (zh) * 2017-10-16 2019-04-25 Oppo广东移动通信有限公司 一种加密数据流的识别方法、设备、存储介质及系统
US10833923B2 (en) 2017-10-26 2020-11-10 Skylo Technologies Inc. Dynamic multiple access for distributed device communication networks with scheduled and unscheduled transmissions
KR102005361B1 (ko) * 2017-10-31 2019-07-30 주식회사 디케이아이테크놀로지 저전력/광대역 네트워크를 지원하는 아이오티 단말의 오티에이 기술을 이용한 클라우드기반 단말 통합관리시스템
US10469600B2 (en) * 2017-11-14 2019-11-05 Dell Products, L.P. Local Proxy for service discovery
US10833926B2 (en) * 2017-11-17 2020-11-10 T-Mobile Usa, Inc. Touchless secure bootstrapping of IoT devices
EP3718015A4 (en) 2017-11-27 2021-08-04 RealNetworks, Inc. PROCESSING MESSAGING PLATFORM COMMUNICATIONS USING DETECTION AND CATEGORIZATION OF MESSAGE GROUPS
EP3718279A1 (en) * 2017-11-30 2020-10-07 Telefonaktiebolaget LM Ericsson (publ) Serving-network based perfect forward security for authentication
US10306442B1 (en) 2018-01-16 2019-05-28 Skylo Technologies Inc. Devices and methods for specialized machine-to-machine communication transmission network modes via edge node capabilities
CN108337308B (zh) * 2018-01-31 2021-08-10 高新兴物联科技有限公司 Lwm2m客户端与上位机数据通信方法、装置及其系统
MX2020008131A (es) * 2018-02-02 2020-11-18 Atc Tech Llc Coordinación del intercambio de datos de un dispositivo de red.
US11729612B2 (en) * 2018-03-08 2023-08-15 Cypress Semiconductor Corporation Secure BLE just works pairing method against man-in-the-middle attack
US10747290B1 (en) * 2018-03-30 2020-08-18 Shopkick, Inc. Varying application strategy based on device state
KR20190118862A (ko) * 2018-04-11 2019-10-21 에스케이하이닉스 주식회사 메모리 시스템 및 메모리 컨트롤러의 동작 방법
WO2019203221A1 (ja) * 2018-04-17 2019-10-24 日本電信電話株式会社 機器制御装置、機器制御方法、及び機器制御システム
US20190332814A1 (en) * 2018-04-27 2019-10-31 Nxp B.V. High-throughput privacy-friendly hardware assisted machine learning on edge nodes
US10990593B2 (en) * 2018-05-04 2021-04-27 Saleforce.com, inc. Providing matching security between data stores in a database system
US10594549B2 (en) * 2018-05-18 2020-03-17 Nant Holdings Ip, Llc Fine grained network management to edge device features
US11218371B2 (en) * 2018-06-01 2022-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for performing communication in internet of things
WO2020001728A1 (en) * 2018-06-25 2020-01-02 Telefonaktiebolaget Lm Ericsson (Publ) Bootstrapping devices on a network
GB2575433B (en) * 2018-06-26 2020-07-08 Advanced Risc Mach Ltd Automatic client device registration
US11438447B2 (en) * 2018-07-03 2022-09-06 Telefonaktiebolaget Lm Ericsson (Publ) First node, communication device, and methods performed thereby for handling positioning information
US10778444B2 (en) * 2018-07-11 2020-09-15 Verizon Patent And Licensing Inc. Devices and methods for application attestation
FR3084181A1 (fr) * 2018-07-20 2020-01-24 Orange Procede de coordination d'une pluralite de serveurs de gestion d'equipements
US10868876B2 (en) * 2018-08-10 2020-12-15 Cisco Technology, Inc. Authenticated service discovery using a secure ledger
US11100228B2 (en) * 2018-10-25 2021-08-24 Dell Products, L.P. System and method to recover FPGA firmware over a sideband interface
CN111147421B (zh) * 2018-11-02 2023-06-16 中兴通讯股份有限公司 一种基于通用引导架构gba的认证方法及相关设备
EP3881571A1 (en) * 2018-11-16 2021-09-22 Convida Wireless, Llc Control plane and user plane selection for small data
GB2579571B (en) * 2018-12-03 2021-05-12 Advanced Risc Mach Ltd Device bootstrapping
US11144045B2 (en) * 2018-12-18 2021-10-12 General Electric Company Apparatus and method for repair of edge devices
US11516263B2 (en) * 2019-03-14 2022-11-29 T-Mobile Usa, Inc. Secure and transparent transport of application level protocols to non-IP data delivery communication channels
US11095742B2 (en) 2019-03-27 2021-08-17 Juniper Networks, Inc. Query proxy for delivery of dynamic system state
WO2020199827A1 (en) * 2019-04-04 2020-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for communication between lwm2m client and server
US11552781B2 (en) 2019-04-05 2023-01-10 Honeywell International Inc. Using error detection bits for cryptographic integrity and authentication
GB2582947B (en) * 2019-04-10 2021-10-13 Advanced Risc Mach Ltd Provisioning data on a device
US11175899B2 (en) * 2019-04-17 2021-11-16 Vmware, Inc. Service upgrade integration for virtualized computing environments
GB2584527B (en) * 2019-05-10 2021-12-08 Advanced Risc Mach Ltd Machine to machine communications
US20220164239A1 (en) * 2019-05-13 2022-05-26 Hyundai Motor Company Method and device for deleting resource in m2m system
CN110213744A (zh) * 2019-05-31 2019-09-06 恒宝股份有限公司 一种智能卡实现m2m业务的方法、装置及智能卡
JP6856090B2 (ja) * 2019-06-07 2021-04-07 ダイキン工業株式会社 機器管理システム
JP7315825B2 (ja) * 2019-06-14 2023-07-27 ダイキン工業株式会社 機器管理システムおよび認証方法
EP3767909A1 (de) * 2019-07-17 2021-01-20 Siemens Mobility GmbH Verfahren und kommunikationseinheit zur kryptographisch geschützten unidirektionalen datenübertragung von nutzdaten zwischen zwei netzwerken
US11050699B2 (en) 2019-08-06 2021-06-29 Airship Group, Inc. Cross-channel orchestration of messages
CN110533128B (zh) * 2019-08-21 2023-08-04 上海唯链信息科技有限公司 一种基于加密的防伪溯源数据处理方法、装置、系统及介质
US11089062B2 (en) * 2019-08-29 2021-08-10 International Business Machines Corporation Automated security architecture formulation and deployment
CN110505307B (zh) * 2019-08-30 2022-04-26 公安部交通管理科学研究所 一种网间交通流数据的交换方法及系统
EP4022479A4 (en) * 2019-09-18 2023-09-13 GPSIP, Inc. WIRELESS LOCATION-ASSISTED ZONE CONTROL SYSTEM WITH SECURE LOCATION TRANSMISSION
KR20220037507A (ko) * 2019-09-19 2022-03-24 구글 엘엘씨 개인 분석가능 어드레스들을 이용한 네트워크 필터링
CN112654013B (zh) * 2019-09-25 2022-06-14 华为技术有限公司 证书发放方法和装置
US11023220B2 (en) 2019-09-26 2021-06-01 Dell Products L.P. Firmware update with integrated smart sequence and action engine
US11429457B2 (en) 2019-09-26 2022-08-30 Dell Products L.P. System and method to securely exchange system diagnostics information between firmware, operating system and payload
EP3809259B1 (en) * 2019-10-16 2023-08-16 NXP USA, Inc. Network node firmware update
CN112714421B (zh) * 2019-10-24 2023-03-17 华为云计算技术有限公司 通信方法、网络设备以及终端设备
US11109343B2 (en) 2019-10-30 2021-08-31 Qualcomm Incorporated Transport protocol usage of confirmable versus non-confirmable notifications based on criticality of the observation
JP7092843B2 (ja) * 2019-10-31 2022-06-28 アシュラント，インコーポレーテッド 独立したコンピューティングリソースを管理し、および同期させるためのシステム、方法、装置、およびコンピュータプログラム製品
US11206135B2 (en) * 2019-11-11 2021-12-21 International Business Machines Corporation Forward secrecy in Transport Layer Security (TLS) using ephemeral keys
FR3103586B1 (fr) * 2019-11-22 2023-04-14 St Microelectronics Alps Sas Procédé de gestion du fonctionnement d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
US11658963B2 (en) 2019-12-04 2023-05-23 International Business Machines Corporation Cooperative communication validation
CN111181970B (zh) * 2019-12-31 2022-03-11 广州邦讯信息系统有限公司 一种使用国密算法应用于国产化fsu的方法和系统
US10827329B1 (en) 2020-02-26 2020-11-03 At&T Mobility Ii Llc Facilitation of dynamic edge computations for 6G or other next generation network
US11418933B2 (en) 2020-03-19 2022-08-16 At&T Mobility Ii Llc Facilitation of container management for internet of things devices for 5G or other next generation network
US11627464B2 (en) 2020-05-14 2023-04-11 Cisco Technology, Inc. Grouping users by pre-shared key (PSK) in hospitality
US11275576B2 (en) 2020-06-19 2022-03-15 Apple Inc. Techniques for firmware updates with accessories
CN111769940B (zh) * 2020-07-09 2023-02-03 天翼物联科技有限公司 一种密钥在线分发方法、系统及介质
CN111556487B (zh) * 2020-07-13 2020-11-06 深圳杰睿联科技有限公司 一种基于混合协议的sim卡空中传输系统及其工作方法
US11337096B2 (en) * 2020-07-17 2022-05-17 T-Mobile Usa, Inc. Predicting whether a user of a wireless telecommunication network will report a problem
CN111935697B (zh) * 2020-08-06 2022-08-19 中国联合网络通信集团有限公司 eSIM发现服务方法、发现服务器及eSIM终端
CN114143016A (zh) * 2020-08-14 2022-03-04 中兴通讯股份有限公司 基于通用引导架构gba的鉴权方法、及对应装置
US11811932B2 (en) * 2020-10-26 2023-11-07 Proofpoint, Inc. Using signed tokens to verify short message service (SMS) message bodies
CN114765550B (zh) * 2020-12-31 2023-11-21 网联清算有限公司 一种业务安全处理方法及系统
CN112911728B (zh) * 2021-01-29 2023-05-02 极米科技股份有限公司 隧道直接链路建立中搜索对等终端的方法、终端及介质
CN112862994A (zh) * 2021-02-07 2021-05-28 中国第一汽车股份有限公司 一种etc防拆认证方法、etc、车载设备终端及系统
US11689896B2 (en) * 2021-02-26 2023-06-27 EMC IP Holding Company LLC Secure remote access to private networks without internet connectivity
JP2022130947A (ja) * 2021-02-26 2022-09-07 株式会社日立製作所 暗号通信システム及び通信端末
US11895133B2 (en) 2021-04-05 2024-02-06 Bank Of America Corporation Systems and methods for automated device activity analysis
US11558850B2 (en) * 2021-04-13 2023-01-17 Qualcomm Incorporated Methods for handling anomaly notification messages
CN113065830B (zh) * 2021-04-19 2022-01-18 深圳市库宝软件有限公司 仓储系统属性预修改方法、装置、电子设备及存储介质
US11784981B2 (en) 2021-06-04 2023-10-10 Bank Of America Corporation Data processing transactions using machine to machine (M2M) data transfer
US11792165B2 (en) 2021-06-04 2023-10-17 Bank Of America Corporation Supporting data processing transactions using machine to machine (M2M) data transfer
GB2608634A (en) 2021-07-08 2023-01-11 Vodafone Group Services Ltd Device data validity
GB2609242A (en) * 2021-07-26 2023-02-01 Vodafone Group Services Ltd Waking up a device
US11956199B2 (en) 2021-07-26 2024-04-09 Airship Group, Inc. Software development kit enabled cross-channel two-way software application messaging
US11265370B1 (en) * 2021-07-27 2022-03-01 Bank Of America Corporation Machine to machine (M2M) data transfer between data servers
US11785018B2 (en) 2021-07-29 2023-10-10 Bank Of America Corporation Mobile device management system for securely managing device communication
US20230107962A1 (en) * 2021-10-01 2023-04-06 TrustFour Technologies, Inc. Mutual Key Management Service System and Method
US11941266B2 (en) 2021-10-20 2024-03-26 Samsung Electronics Co., Ltd. Resource isolation in computational storage devices
EP4187845A1 (en) * 2021-11-25 2023-05-31 Sandvik Mining and Construction Oy User authentication in an industrial system
US20230367575A1 (en) * 2022-05-13 2023-11-16 Micron Technology, Inc. Techniques for managing offline identity upgrades
US11968093B1 (en) * 2022-09-20 2024-04-23 Gen Digital Inc. Efficient scaling of a domain name system service architecture
CN115694891B (zh) * 2022-09-23 2024-05-14 智己汽车科技有限公司 一种基于中央计算平台的路侧设备通信系统及方法
US11709660B1 (en) 2022-10-12 2023-07-25 Stodge Inc. Integrated third-party application builder trigger for message flow

Family Cites Families (147)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US102690A (en) * 1870-05-03 Improvement in pipe-tongs
US6185678B1 (en) * 1997-10-02 2001-02-06 Trustees Of The University Of Pennsylvania Secure and reliable bootstrap architecture
US6578066B1 (en) * 1999-09-17 2003-06-10 Alteon Websystems Distributed load-balancing internet servers
WO2000068856A2 (en) * 1999-05-11 2000-11-16 Webvan Group, Inc. Electronic commerce enabled delivery system and method
US7069452B1 (en) 2000-07-12 2006-06-27 International Business Machines Corporation Methods, systems and computer program products for secure firmware updates
US7774231B2 (en) * 2000-09-29 2010-08-10 Nokia Corporation Electronic payment methods for a mobile device
US7184984B2 (en) * 2000-11-17 2007-02-27 Valaquenta Intellectual Properties Limited Global electronic trading system
US20020136410A1 (en) * 2001-03-26 2002-09-26 Sun Microsystems, Inc. Method and apparatus for extinguishing ephemeral keys
US20020157002A1 (en) * 2001-04-18 2002-10-24 Messerges Thomas S. System and method for secure and convenient management of digital electronic content
EP1271875A1 (en) * 2001-06-21 2003-01-02 Koninklijke Philips Electronics N.V. Device arranged for exchanging data, and method of manufacturing
US7058926B2 (en) 2001-08-13 2006-06-06 International Business Machines Corporation Tool for implementing Floating-Point related applications using customized language
US8140845B2 (en) * 2001-09-13 2012-03-20 Alcatel Lucent Scheme for authentication and dynamic key exchange
US7076657B2 (en) * 2001-12-28 2006-07-11 Siemens Communications, Inc. Use of short message service (SMS) for secure transactions
US6804777B2 (en) 2002-05-15 2004-10-12 Threatguard, Inc. System and method for application-level virtual private network
US20030229686A1 (en) 2002-06-07 2003-12-11 Kris Kortright System and method for synchronizing the configuration of distributed network management applications
US7296156B2 (en) * 2002-06-20 2007-11-13 International Business Machines Corporation System and method for SMS authentication
FI20030943A (fi) * 2003-06-25 2004-12-26 Nokia Corp Menetelmä machine-to-machine-yksikön parametrien konfiguroimiseksi ja machine-to-machine-yksikkö
JP4617763B2 (ja) * 2003-09-03 2011-01-26 ソニー株式会社 機器認証システム、機器認証サーバ、端末機器、機器認証方法、および機器認証プログラム
KR20050049222A (ko) * 2003-11-21 2005-05-25 에스케이텔레텍주식회사 단문메시지의 기밀 전송 방법
US20050120106A1 (en) 2003-12-02 2005-06-02 Nokia, Inc. System and method for distributing software updates to a network appliance
US7360129B2 (en) 2003-12-30 2008-04-15 Broadcom Corporation Simultaneous switch test mode
FR2867652B1 (fr) * 2004-03-15 2006-05-26 Wavecom Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants
WO2006085207A1 (en) 2005-02-11 2006-08-17 Nokia Corporation Method and apparatus for providing bootstrapping procedures in a communication network
US7628322B2 (en) * 2005-03-07 2009-12-08 Nokia Corporation Methods, system and mobile device capable of enabling credit card personalization using a wireless network
FI20050384A0 (fi) 2005-04-14 2005-04-14 Nokia Corp Geneerisen todentamisarkkitehtuurin käyttö Internet-käytäntöavainten jakeluun matkaviestimissä
US9167471B2 (en) * 2009-05-07 2015-10-20 Jasper Technologies, Inc. System and method for responding to aggressive behavior associated with wireless devices
US9226151B2 (en) 2006-04-04 2015-12-29 Jasper Wireless, Inc. System and method for enabling a wireless device with customer-specific services
US8122240B2 (en) 2005-10-13 2012-02-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for establishing a security association
US8005879B2 (en) * 2005-11-21 2011-08-23 Sap Ag Service-to-device re-mapping for smart items
WO2007063420A2 (en) * 2005-12-01 2007-06-07 Nokia Corporation Authentication in communications networks
US8522025B2 (en) * 2006-03-28 2013-08-27 Nokia Corporation Authenticating an application
US8037522B2 (en) 2006-03-30 2011-10-11 Nokia Corporation Security level establishment under generic bootstrapping architecture
US20070248232A1 (en) 2006-04-10 2007-10-25 Honeywell International Inc. Cryptographic key sharing method
US20070254711A1 (en) * 2006-04-26 2007-11-01 Young David C Accessing a SIM card to obtain configuration information by a remote embedded communication module
DE102006054091B4 (de) * 2006-11-16 2008-09-11 Siemens Ag Bootstrapping-Verfahren
US20080120705A1 (en) * 2006-11-17 2008-05-22 Bellsouth Intellectual Property Corporation Systems, Methods and Computer Program Products Supporting Provision of Web Services Using IMS
US7774008B2 (en) 2006-12-22 2010-08-10 Cellco Partnership MDN-less SMS messaging (network solution) for wireless M2M application
US7992198B2 (en) * 2007-04-13 2011-08-02 Microsoft Corporation Unified authentication for web method platforms
US9332575B2 (en) 2007-06-27 2016-05-03 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for enabling connectivity in a communication network
WO2009004590A2 (en) * 2007-07-03 2009-01-08 Nokia Siemens Networks Oy Method, apparatus, system and computer program for key parameter provisioning
US8201219B2 (en) * 2007-09-24 2012-06-12 Bridgewater Systems Corp. Systems and methods for server load balancing using authentication, authorization, and accounting protocols
KR20100083840A (ko) * 2007-10-05 2010-07-22 인터디지탈 테크날러지 코포레이션 Ｕｉｃｃ와 단말기간 보안 채널화를 위한 기술
US7984486B2 (en) 2007-11-28 2011-07-19 Nokia Corporation Using GAA to derive and distribute proxy mobile node home agent keys
WO2009080095A1 (en) * 2007-12-19 2009-07-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for use in a communications network
CN102047629A (zh) * 2008-01-18 2011-05-04 交互数字专利控股公司 用于启用机器对机器通信的方法和设备
US8090963B2 (en) * 2008-02-19 2012-01-03 Research In Motion Limited Automated power management of a peripheral device
US8867989B2 (en) * 2008-04-15 2014-10-21 Ams International Ag Method for reducing a noise in a signal received in a contactless-card interrogator and a circuit to perform said method
PL2528268T6 (pl) * 2008-06-06 2022-04-25 Telefonaktiebolaget Lm Ericsson (Publ) Generowanie klucza kryptograficznego
US8750506B2 (en) 2008-07-31 2014-06-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods, nodes, system, computer programs and computer program products for secure user subscription or registration
US8386767B2 (en) * 2008-08-15 2013-02-26 Telefonaktiebolaget L M Ericsson (Publ) Methods and systems for bootstrapping security key information using session initiation protocol
US8472388B2 (en) * 2008-10-10 2013-06-25 Telefonaktiebolaget Lm Ericsson (Publ) Gateway apparatus, authentication server, control method thereof and computer program
US8578153B2 (en) * 2008-10-28 2013-11-05 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for provisioning and managing a device
EP2187592A1 (en) * 2008-11-13 2010-05-19 Vodafone Holding GmbH Machine-to machine device and smartcard for use in the device
US20100199095A1 (en) * 2009-01-30 2010-08-05 Texas Instruments Inc. Password-Authenticated Association Based on Public Key Scrambling
JP2012520027A (ja) 2009-03-06 2012-08-30 インターデイジタル パテント ホールディングス インコーポレイテッド 無線装置のプラットフォームの検証と管理
US8213971B2 (en) * 2009-04-27 2012-07-03 Qualcomm Incorporated Apparatus and method for activating computer applications with SMS messaging
EP2264642B1 (en) 2009-06-02 2014-02-26 Vodafone Holding GmbH Data exchange with a man-machine-device using short range radio communication
ES2391603T3 (es) 2009-06-02 2012-11-28 Vodafone Holding Gmbh Registro de un dispositivo móvil en una red de comunicaciones móviles
US8682903B2 (en) * 2009-06-30 2014-03-25 International Business Machines Corporation System and method for synchronized content directories on cluster devices
US9590961B2 (en) * 2009-07-14 2017-03-07 Alcatel Lucent Automated security provisioning protocol for wide area network communication devices in open device environment
CN102656845B (zh) * 2009-10-16 2015-04-01 泰克莱克股份有限公司 用于向直径信令路由器提供集成的监控和/或防火墙功能的方法、系统和计算机可读介质
WO2011063826A1 (en) * 2009-11-24 2011-06-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for use in a generic bootstrapping architecture
EP2336986A1 (en) * 2009-12-17 2011-06-22 Gemalto SA Method of personalizing an application embedded in a secured electronic token
EP2514134A1 (en) * 2009-12-18 2012-10-24 Nokia Corp. Credential transfer
EP2343916B1 (en) 2010-01-12 2018-05-09 Koninklijke KPN N.V. Secure coupling of hardware components
WO2011085810A1 (en) 2010-01-14 2011-07-21 Nokia Siemens Networks Oy Method and device for data processing in a wireless network
DE102010001076A1 (de) 2010-01-21 2011-07-28 PMDTechnologies GmbH, 57076 Induktiver Näherungssensor und Verfahren zur Näherungsmessung
EP3002965B1 (en) 2010-01-28 2019-08-21 Koninklijke KPN N.V. Efficient terminal authentication in telecommunication networks
KR101684753B1 (ko) 2010-02-09 2016-12-08 인터디지탈 패튼 홀딩스, 인크 신뢰적인 연합 아이덴티티를 위한 방법 및 장치
US8447970B2 (en) * 2010-02-09 2013-05-21 Microsoft Corporation Securing out-of-band messages
DE102010010760B4 (de) 2010-03-09 2012-02-02 Siemens Aktiengesellschaft Verfahren zur Vergabe eines Schlüssels an ein einem drahtlosen Sensor-Aktor-Netz neu hinzuzufügendes Teilnehmergerät
CN102196436B (zh) * 2010-03-11 2014-12-17 华为技术有限公司 安全认证方法、装置及系统
WO2011115407A2 (en) * 2010-03-15 2011-09-22 Samsung Electronics Co., Ltd. Method and system for secured remote provisioning of a universal integrated circuit card of a user equipment
US8432871B1 (en) 2010-03-26 2013-04-30 Juniper Networks, Inc. Offloading mobile traffic from a mobile core network
US9729516B2 (en) * 2010-04-09 2017-08-08 Gemalto Sa Method of machine-to-machine communication
WO2011131220A1 (en) * 2010-04-19 2011-10-27 Nokia Siemens Networks Oy Gba and ims authentication procedures
US8661257B2 (en) 2010-05-18 2014-02-25 Nokia Corporation Generic bootstrapping architecture usage with Web applications and Web pages
US9602277B2 (en) * 2010-06-07 2017-03-21 Protected Mobilty, Llc User interface systems and methods for secure message oriented communications
US9143324B2 (en) * 2010-06-07 2015-09-22 Protected Mobility, Llc Secure messaging
CN102299797A (zh) * 2010-06-23 2011-12-28 财团法人工业技术研究院 认证方法、密钥分配方法及认证与密钥分配方法
US9736873B2 (en) * 2010-06-25 2017-08-15 Interdigital Patent Holdings, Inc. Interface of an M2M server with the 3GPP core network
US8464061B2 (en) * 2010-08-30 2013-06-11 Apple Inc. Secure wireless link between two devices using probes
GB201015324D0 (en) 2010-09-14 2010-10-27 Vodafone Ip Licensing Ltd Secure association
US9185054B2 (en) * 2010-09-15 2015-11-10 Oracle International Corporation System and method for providing zero buffer copying in a middleware machine environment
CN102136934B (zh) * 2010-10-21 2015-01-21 华为技术有限公司 实现Zigbee设备远程升级的方法、装置及网络系统
CN102469455B (zh) * 2010-11-08 2016-04-13 中兴通讯股份有限公司 基于通用引导架构的机器类通信设备分组管理方法及系统
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
KR20120067459A (ko) * 2010-12-16 2012-06-26 삼성전자주식회사 서비스 제공업체와 이동망 사업자간의 기기간 단말별 서비스 인증 방법 및 장치
CN102595389B (zh) * 2011-01-14 2017-11-03 中兴通讯股份有限公司 一种mtc服务器共享密钥的方法及系统
WO2012113136A1 (en) * 2011-02-22 2012-08-30 Renesas Mobile Corporation Method and apparatus for establishing a device-to-device connection
EP2679073A4 (en) * 2011-02-25 2016-10-19 Ericsson Telefon Ab L M IP COMMUNICATION AUTHORIZATION WITH A MACHINE MACHINE DEVICE
TR201103175A2 (tr) 2011-04-01 2012-10-22 Turkcell �Let���M H�Zmetler� Anon�M ��Rket� Güvenli mesaj iletimi sağlayan bir sistem ve yöntem
DE102011007534A1 (de) * 2011-04-15 2012-10-18 Vodafone Holding Gmbh Datenübermittlung zu einem Identifizierungsmodul in einem Mobilfunkendgerät
CN102204217A (zh) * 2011-05-30 2011-09-28 华为技术有限公司 通知网络能力的方法、装置和系统
JP2013005430A (ja) 2011-06-15 2013-01-07 Lg Electronics Inc 無線通信システムにおけるデータ送信方法及び装置
GB2492750A (en) 2011-07-04 2013-01-16 Sony Corp Communications system with reconfigurable user identification module
CN102869015B (zh) * 2011-07-04 2017-12-15 中兴通讯股份有限公司 一种mtc设备触发的方法和系统
US8989091B2 (en) * 2011-07-15 2015-03-24 Telefonaktiebolaget L M Ericsson (Publ) Dynamic enablement of M2M services over 3GPP access networks
KR101295580B1 (ko) * 2011-07-15 2013-08-09 엘지전자 주식회사 무선접속시스템에서 harq 채널식별자를 이용한 harq 동작 지원방법 및 장치
US9185080B2 (en) * 2011-08-12 2015-11-10 Intel Deutschland Gmbh Data transmitting devices, data receiving devices, methods for controlling a data transmitting device, and methods for controlling a data receiving device
US9432822B2 (en) * 2011-10-03 2016-08-30 Lg Electronics Inc. Mobility management entity handling SMS-related signal
CN105577364B (zh) 2011-10-27 2019-11-05 华为技术有限公司 一种加密方法、解密方法和相关装置
BR112014010428B1 (pt) * 2011-10-31 2022-04-05 Telefonaktiebolaget Lm Ericsson (Publ) Método para segurança na comunicação de dados, aparelho para uso em um método para segurança na comunicação de dados, nó de comunicação, e, meio de armazenamento
CN103108311B (zh) 2011-11-11 2017-11-28 中兴通讯股份有限公司 一种mtc设备与uicc绑定的方法、装置及系统
CN102497630B (zh) * 2011-11-25 2015-07-01 北京握奇数据系统有限公司 一种m2m设备及其实现业务的方法、智能卡和通信模组
CN104145465B (zh) * 2012-02-02 2017-08-29 诺基亚通信公司 机器类型通信中基于群组的自举的方法和装置
WO2013121362A2 (en) * 2012-02-13 2013-08-22 Telefonaktiebolaget Lm Ericsson (Publ) M2m service enablement over access networks
CN104205898A (zh) 2012-02-16 2014-12-10 诺基亚通信公司 用于m2m环境中基于群组的服务引导的方法和系统
US8577337B2 (en) * 2012-03-05 2013-11-05 Rogers Communications Inc. Radio management method and system using embedded universal integrated circuit card
US9380038B2 (en) * 2012-03-09 2016-06-28 T-Mobile Usa, Inc. Bootstrap authentication framework
GB2501724A (en) * 2012-05-02 2013-11-06 Vodafone Ip Licensing Ltd Routing messages in a telecommunications network to machine-to-machine devices
KR20130127826A (ko) * 2012-05-15 2013-11-25 엠디에스테크놀로지 주식회사 오티에이를 이용한 엠투엠 단말기의 응용프로그램 관리 시스템
CN103428666A (zh) 2012-05-24 2013-12-04 华为技术有限公司 一种计费的方法及装置
WO2013191515A1 (ko) * 2012-06-22 2013-12-27 엘지전자 주식회사 무선 통신 시스템에서 서버를 활성화 또는 비활성화하기 위한 방법 및 장치
US9894511B2 (en) * 2012-09-03 2018-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for automatic provisioning of external identifiers used for machine type devices in a 3GPP network
WO2014039387A1 (en) * 2012-09-04 2014-03-13 Interdigital Patent Holdings, Inc. Method and apparatus for using multiple universal resource identifiers in m2m communications
US9167042B1 (en) * 2012-09-10 2015-10-20 Amazon Technologies, Inc. Maintaining communication channel for device notifications
IN2015DN01110A (es) * 2012-09-13 2015-06-26 Nec Corp
US9872169B2 (en) * 2012-09-14 2018-01-16 Telefonaktiebolaget Lm Ericsson (Publ) Operating a data back end node in a data layered architecture network
CN104685825B (zh) 2012-09-26 2018-07-06 英派尔科技开发有限公司 一种安全通信的方法、计算设备及非暂态计算机可读存储介质
US9654971B2 (en) * 2012-10-30 2017-05-16 Lg Electronics Inc. Method and apparatus for authenticating access authority for specific resource in wireless communication system
KR101538424B1 (ko) * 2012-10-30 2015-07-22 주식회사 케이티 결제 및 원격 모니터링을 위한 사용자 단말
KR20150088787A (ko) * 2012-11-05 2015-08-03 엘지전자 주식회사 무선 통신 시스템에서 특정 리소스에 대한 정보 갱신을 위한 방법 및 장치
US20140126548A1 (en) * 2012-11-05 2014-05-08 Qualcomm Incorporated Dynamic paging channel selection in a machine-to-machine wireless wide area network
CN103812644B (zh) * 2012-11-09 2017-04-26 华为终端有限公司 一种信息配置方法、设备及系统
EP2741465B1 (en) * 2012-12-04 2021-03-17 Orange Method and device for managing secure communications in dynamic network environments
KR20150092108A (ko) * 2012-12-05 2015-08-12 엘지전자 주식회사 무선 통신 시스템에서 정보 변경 통지를 위한 방법 및 장치
WO2014093613A1 (en) * 2012-12-12 2014-06-19 Interdigital Patent Holdings, Inc. Independent identity management systems
US9277378B2 (en) 2012-12-21 2016-03-01 Verizon Patent And Licensing Inc. Short message service validation engine
US9262242B2 (en) * 2012-12-31 2016-02-16 Verizon Patent And Licensing Inc. Machine-to-machine (“M2M”) device client systems, methods, and interfaces
US9232524B2 (en) * 2013-01-05 2016-01-05 Qualcomm Incorporated Multiple access scheme for multi-channels of a network with a limited link budget
US8787554B1 (en) * 2013-01-11 2014-07-22 American Express Travel Related Services Company, Inc. System and method for a digital network for switching web service messages
CN104937895B (zh) * 2013-01-18 2018-04-24 Lg电子株式会社 在无线通信系统中控制访问的方法和设备
US9002997B2 (en) 2013-01-22 2015-04-07 Amazon Technologies, Inc. Instance host configuration
US8782774B1 (en) * 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
EP2965553B1 (en) 2013-03-08 2020-02-26 Nokia Technologies Oy Method and apparatus for multisim devices with embedded sim functionality
CN105103578A (zh) 2013-04-05 2015-11-25 交互数字专利控股公司 安全端对端和组通信
US9124403B2 (en) * 2013-04-30 2015-09-01 Qualcomm Incorporated Puncturing scheme based decoder optimizations
EP3557894B1 (en) 2013-05-06 2023-12-27 Convida Wireless, LLC Device triggering
US20150019637A1 (en) * 2013-07-12 2015-01-15 Seven Networks, Inc. Distributed caching systems with configurable extended caching optimization
CN109769227B (zh) * 2013-07-25 2022-02-22 康维达无线有限责任公司 端到端m2m服务层会话
US9189930B2 (en) * 2013-08-20 2015-11-17 Verizon Patent And Licensing Inc. Customizing alerts on an alerting device
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US9100175B2 (en) 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
GB2518254B (en) 2013-09-13 2020-12-16 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
US9426729B2 (en) * 2013-10-22 2016-08-23 Cisco Technology, Inc. Network selection for mobile client devices in integrated cellular and Wi-Fi networks
WO2015072899A1 (en) * 2013-11-15 2015-05-21 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for bootstrapping of resource constrained devices

Also Published As

Publication number Publication date
EP3044984A1 (en) 2016-07-20
US10313308B2 (en) 2019-06-04
US10313307B2 (en) 2019-06-04
EP3044928B1 (en) 2020-11-04
GB2583432A (en) 2020-10-28
EP3767984C0 (en) 2024-02-21
WO2015036791A1 (en) 2015-03-19
GB2518254B (en) 2020-12-16
WO2015036789A3 (en) 2015-06-11
GB2584371A (en) 2020-12-02
GB202016853D0 (en) 2020-12-09
GB201409652D0 (en) 2014-07-16
US10630646B2 (en) 2020-04-21
EP3767984A1 (en) 2021-01-20
EP3044985A1 (en) 2016-07-20
GB2518296B (en) 2021-02-24
US20170295143A1 (en) 2017-10-12
EP3800862A1 (en) 2021-04-07
GB2586549B (en) 2021-05-26
US10439991B2 (en) 2019-10-08
GB2520591A (en) 2015-05-27
EP3044973A1 (en) 2016-07-20
EP3044934A2 (en) 2016-07-20
US11044234B2 (en) 2021-06-22
US20160234170A1 (en) 2016-08-11
US20160234182A1 (en) 2016-08-11
EP3044975B8 (en) 2021-06-30
US20160234177A1 (en) 2016-08-11
GB202012632D0 (en) 2020-09-30
EP3800862B1 (en) 2022-11-09
GB201409641D0 (en) 2014-07-16
GB202012324D0 (en) 2020-09-23
WO2015036772A1 (en) 2015-03-19
EP3832982B1 (en) 2024-02-21
GB2518301A (en) 2015-03-18
GB201409663D0 (en) 2014-07-16
GB201414999D0 (en) 2014-10-08
GB2518301B (en) 2020-07-15
WO2015036778A1 (en) 2015-03-19
GB2518522B (en) 2020-07-22
US20160234683A1 (en) 2016-08-11
US10764252B2 (en) 2020-09-01
US10305862B2 (en) 2019-05-28
ES2933426T3 (es) 2023-02-08
EP3044975A1 (en) 2016-07-20
EP3044983B1 (en) 2021-05-19
EP3044976A1 (en) 2016-07-20
EP3044973B1 (en) 2021-03-17
WO2015036773A3 (en) 2015-06-11
GB2518975A (en) 2015-04-08
WO2015036771A1 (en) 2015-03-19
GB2518976A (en) 2015-04-08
GB201415925D0 (en) 2014-10-22
WO2015036782A1 (en) 2015-03-19
US20160232116A1 (en) 2016-08-11
US9635057B2 (en) 2017-04-25
EP3044928A1 (en) 2016-07-20
US11063912B2 (en) 2021-07-13
GB2518296A (en) 2015-03-18
EP3855701A1 (en) 2021-07-28
EP3832982A1 (en) 2021-06-09
GB201415927D0 (en) 2014-10-22
GB2518976B (en) 2020-11-04
US20160234181A1 (en) 2016-08-11
WO2015036785A1 (en) 2015-03-19
WO2015036773A2 (en) 2015-03-19
US20160226847A1 (en) 2016-08-04
GB2586549A (en) 2021-02-24
GB2518521A (en) 2015-03-25
GB201415931D0 (en) 2014-10-22
GB2519429B (en) 2020-12-23
EP3044975B1 (en) 2021-05-26
GB2583432B (en) 2021-02-24
US10412052B2 (en) 2019-09-10
EP3044974A1 (en) 2016-07-20
GB2518257A (en) 2015-03-18
EP3044982A1 (en) 2016-07-20
WO2015036776A1 (en) 2015-03-19
EP3767984B1 (en) 2024-02-21
EP3044927A1 (en) 2016-07-20
WO2015036793A1 (en) 2015-03-19
GB2519429A (en) 2015-04-22
GB2518255A (en) 2015-03-18
GB201415918D0 (en) 2014-10-22
EP3044983A1 (en) 2016-07-20
US20160234183A1 (en) 2016-08-11
EP3832982C0 (en) 2024-02-21
GB201414997D0 (en) 2014-10-08
EP3044976B1 (en) 2021-11-03
GB201409643D0 (en) 2014-07-16
GB2584371B (en) 2021-03-17
US20160226828A1 (en) 2016-08-04
US20160234255A1 (en) 2016-08-11
GB2520591B (en) 2020-09-23
EP3044982B1 (en) 2021-07-21
CN105706469A (zh) 2016-06-22
GB2518254A (en) 2015-03-18
US10673820B2 (en) 2020-06-02
US20200322315A1 (en) 2020-10-08
WO2015036783A1 (en) 2015-03-19
WO2015036789A2 (en) 2015-03-19
GB2518256A (en) 2015-03-18
CN105706469B (zh) 2020-03-10
GB201415921D0 (en) 2014-10-22
WO2015036777A1 (en) 2015-03-19
GB2518975B (en) 2020-12-30
US20190306123A1 (en) 2019-10-03
US20160234686A1 (en) 2016-08-11
GB201415003D0 (en) 2014-10-08
EP3044984B1 (en) 2021-07-21
GB2518522A (en) 2015-03-25

Similar Documents

Publication Publication Date Title
ES2893353T3 (es) Comunicación con dispositivos de máquina a máquina
US20220114251A1 (en) Reputation management and intent-based security mechanisms
Bansal et al. IoT ecosystem: A survey on devices, gateways, operating systems, middleware and communication
US20210279049A1 (en) Firmware upgrade method and apparatus
CN110024330B (zh) 对IoT装置的服务提供
Sinha et al. Building an E Ective IoT Ecosystem for Your Business
US11134085B2 (en) Cloud least identity privilege and data access framework
US10728307B2 (en) Cloud intelligence data model and framework
Calderoni et al. Benchmarking cloud providers on serverless iot back-end infrastructures
Dautov et al. Context-Aware Digital Twins to Support Software Management at the Edge
Majdi et al. Evaluation of Mobile Device Management tools and analyzing integration models for mobility enterprise
Soler Mascarell Home automation platform based on Node Red
Ozeer Autonomic resilience of distributed IoT applications in the Fog
Medina Merino Internet of Things demonstrator based on the OpenMote platform
Terrell et al. Constellation: An edge-based semantic runtime system for internet of things applications
Mariniello Cloud IoT platform for Access Control
Moyano et al. Engineering trust-awareness and self-adaptability in services and systems
Cheng A multi-agent security system for android platform
Lima Analysis and detection of anomalies in mobile devices
Annor A lightweight implementation of the internet of things
Cruz et al. Analysis and detection of anomalies in mobile devices
Rouvoy Contributions to the Autonomy of Ubiquitous Software Systems
Ottallah Implementation of Secure Key Management Techniques in Wireless Sensor Networks