WO2024049011A1 - Passerelle iot assurant une compatibilité avec des dispositifs iot ayant divers protocoles, et son procédé de commande - Google Patents

Passerelle iot assurant une compatibilité avec des dispositifs iot ayant divers protocoles, et son procédé de commande Download PDF

Info

Publication number
WO2024049011A1
WO2024049011A1 PCT/KR2023/010738 KR2023010738W WO2024049011A1 WO 2024049011 A1 WO2024049011 A1 WO 2024049011A1 KR 2023010738 W KR2023010738 W KR 2023010738W WO 2024049011 A1 WO2024049011 A1 WO 2024049011A1
Authority
WO
WIPO (PCT)
Prior art keywords
iot
protocol
information
ocf
iot device
Prior art date
Application number
PCT/KR2023/010738
Other languages
English (en)
Korean (ko)
Inventor
강세범
정성기
이재진
Original Assignee
주식회사 융창
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 융창 filed Critical 주식회사 융창
Publication of WO2024049011A1 publication Critical patent/WO2024049011A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y20/00—Information sensed or collected by the things
    • G16Y20/20—Information sensed or collected by the things relating to the thing itself
    • 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
    • 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/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Definitions

  • the present invention relates to an IoT gateway that provides compatibility with IoT devices with various protocols and a control method thereof. More specifically, the present invention relates to development that occurs to interoperate with IoT devices using various types of protocols by various manufacturers. This relates to an IoT gateway and its control method that converts resources into the OCF method, a standard platform, to provide compatibility with various IoT devices.
  • the Internet of Things can refer to a technology that performs desired services by organically connecting surrounding objects through wired and wireless networks to collect, process, and share information.
  • Smart City is one of the IoT application services that realizes hyper-connectivity, the original purpose of IoT.
  • the purpose of a smart city is to ultimately make the lives of citizens in the city more enriched and convenient by securing city data through IT technology and network access, and using this data to efficiently use and redistribute city resources.
  • IoT devices equipped with sensors in various infrastructure such as cultural facilities, houses, roads, and businesses, collect data sensed by IoT devices, and integrate city information based on this. It can be managed and operated.
  • IoT application services is Smart Home, which recognizes the current situation based on data collected by IoT devices, analyzes this, and processes the data to suit the user's lifestyle patterns. By doing so, customized services can be provided to users.
  • IoT devices In order to provide such diverse IoT application services, various types of IoT devices are being produced by numerous manufacturers, and various protocols for controlling them have also been developed and developed.
  • IoT-related standards under the leadership of the Linux Foundation, members such as LG Electronics, Haier, Panasonic, Qualcomm, and Sharp gathered to launch the AllSeen Alliance, and Qualcomm's P2P solution, AllJoyn, was launched.
  • the open project was selected as the base framework for IoE.
  • seven standard development organizations around the world including Korea's TTA, Europe's ESTI, and North America's ATIS and TIA, gathered together to form a project for the purpose of developing a common IoT platform and announced the oneM2M standard.
  • many companies, including Intel, Samsung Electronics, and Amtel launched the Open Interconnect Consortium (OIC) and established the Open Connectivity Foundation (OCF) to develop standards.
  • OIC Open Interconnect Consortium
  • OCF Open Connectivity Foundation
  • OCF Open Connectivity Foundation
  • the OCF standard is a representative Internet of Things standard that is being rapidly adopted among various standards related to the Internet of Things.
  • OCF is a standard platform technology that connects IoT devices and allows mutual control of resources existing in IoT devices.
  • OCF uses a server-client model, and each server defines the various IoT services they can provide in the form of resources and adopts a Restful method that allows clients to use the desired service.
  • CoAP Constrained Application Protocol
  • the present invention is intended to solve the above problems, and its purpose is to provide an IoT gateway that can be integrated in the form of the OCF standard protocol to interface with and control multiple IoT devices using different protocols.
  • the purpose of the present invention is to provide a new IoT gateway that can determine the type of IoT device and the protocol used by providing a rule set learned through a machine learning model even if it is a new IoT device without existing data. do.
  • the purpose of the present invention is to provide a novel IoT gateway with the function of detecting and blocking risk factors that may occur in the process of communicating with linked IoT devices.
  • an IoT gateway that provides compatibility with IoT devices having various protocols
  • the type and use of the first IoT device are based on a message received from the first IoT device.
  • a protocol conversion unit that verifies the protocol, creates a virtual resource model object based on the OCF framework, and converts the received message into an OCF-based protocol, assigns a device ID to the created resource model object, and assigns a device ID to the OCF framework.
  • an IoT gateway that includes a device manager that maps the received message converted to a base protocol and a control manager that transmits the generated resource model object to an integrated control server using an OCF-based protocol.
  • the device manager determines a predetermined value from the received message. Information is acquired, and the type of the first IoT device and the protocol used are further determined based on the obtained information and a pre-learned and stored rule set.
  • the IoT gateway further includes a device analysis machine learning unit that learns and stores the rule set.
  • the predetermined information to be obtained is at least one of media access control (MAC) information or universally unique identifier (UUID) information of the first IoT device, manufacturer information, service port information in use, and model name.
  • MAC media access control
  • UUID universally unique identifier
  • the IoT gateway further includes a risk detection unit that detects risk factors from a message received from the first IoT device and blocks the first IoT device.
  • an IoT gateway that can be integrated in the form of the OCF standard protocol.
  • FIG. 1 is a diagram schematically showing the entire system including an IoT gateway according to an embodiment of the present invention
  • FIG. 2 is a block diagram of an IoT gateway according to an embodiment of the present invention.
  • FIG. 3 is a block diagram showing each module constituting the protocol conversion unit according to an embodiment of the present invention.
  • FIG. 4 is a block diagram including each module constituting the device management unit according to an embodiment of the present invention.
  • FIG. 5 is a block diagram showing each module constituting the control management unit according to an embodiment of the present invention.
  • FIG. 6 is a flowchart illustrating an IoT gateway performing initial registration of a new IoT device according to an embodiment of the present invention
  • Figure 7 is a diagram illustrating an example of an OCF framework-based resource model object according to an embodiment of the present invention.
  • the term 'software' refers to technology that moves hardware in a computer
  • the term 'hardware' refers to the tangible devices or devices that make up a computer (CPU, memory, input device, output device, peripheral device, etc.)
  • the term 'step' refers to a series of processes or operations connected in time series to achieve a predetermined goal
  • the term 'computer program', 'program', or 'algorithm' refers to a set of instructions combined for processing by a computer.
  • the term 'program recording medium' refers to a computer-readable recording medium that records a program used to install, execute, or distribute a program.
  • 'mobile device', 'computer', 'computing device', 'server device', or 'server' refers to an operating system such as Windows, Mac, or Linux, a computer processor, memory, applications, and storage devices (e.g. For example, it can be implemented as a device equipped with an HDD, SDD), and a monitor.
  • the computer may be a device such as a desktop computer, a laptop, or a mobile terminal, but these are examples and are not limited thereto.
  • the mobile terminal may be one of mobile wireless communication devices such as a smartphone, tablet PC, or PDA.
  • component 'A' transmitting information, details, and/or data to component 'B' means that component 'A' transmits directly or indirectly to component 'B'. It is used in the meaning that includes.
  • FIG 1 schematically shows the entire system including an IoT gateway according to an embodiment of the present invention.
  • the IoT gateway 100 shown in FIG. 1 compares the message received from the IoT device 200 with previously stored IoT device information to communicate with the IoT device 200. ) and the protocol information used. Afterwards, the IoT gateway 100 creates a virtual resource model object based on the OCF framework and converts the message received from the IoT device 200 into an OCF-based protocol.
  • the IoT gateway 100 determines the IoT device 200 as a new IoT device and IoT device ( 200), various information such as the unique identifier of the IoT device such as MAC (media access control) information or UUID (Universally Unique Identifier), manufacturer information, service port information used, and model name are obtained.
  • the IoT gateway 100 applies the acquired information to a rule set learned in advance using a machine learning model, determines the type of IoT device 200 and the protocol used, and adds this to the IoT device information. Add content.
  • the IoT gateway 100 maps the message converted to the OCF-based protocol to the resource of a virtual resource model object created based on the OCF framework. Since a virtual resource model object based on the OCF framework for the linked IoT device 200 has been created and the data required for the resource has been mapped, the IoT gateway 100 is connected to the integrated control server 300 supporting the OCF protocol through CoAP ( Communicates using Constrained Application Protocol.
  • CoAP Communicates using Constrained Application Protocol.
  • the IoT gateway 100 receives a RESTful control message for controlling the IoT device 200 from the integrated control server 300, it converts the control message according to the protocol used by the IoT device 200 to control the IoT device (200).
  • the IoT device 200 can be controlled by transmitting to 200).
  • the IoT gateway 100 performs a function of detecting and blocking risk factors that may occur during communication with the linked IoT device 200. For example, when abnormal information is detected among the information received from the IoT device 200, the linked IoT device 200 may be blocked. As another example, a white list of IoT devices 200 that can interoperate with the IoT gateway 100 may be maintained, and IoT devices not registered in the white list may be blocked when they attempt to transmit information.
  • the IoT gateway 100 may correspond to any one of a mobile device, computer, computing device, server device, or server, but is not limited thereto. Any device that has a remote storage device, such as a local or cloud, and performs the functions described in the present invention while communicating wired and/or wirelessly with one or more IoT devices 200 and the integrated control server 300 is subject to the present invention. It may correspond to the IoT gateway 100 according to the following.
  • the IoT device 200 is a general term for IoT devices manufactured by various manufacturers and using various protocols.
  • the IoT device 200 may be a device that supports the OCF standard and interoperates with the IoT gateway 100 using CoAP used in the OCF standard, but may also be a device that uses RS using the MQTT (Message Queuing Telemetry Transport) protocol, HTTP, or serial communication. It may be using a protocol that does not support the OCF standard, such as -485, or it may be a non-OCF device that does not comply with the OCF standard.
  • the IoT device 200 can provide information and be controlled in conjunction with the IoT gateway 100 according to the present invention, regardless of the device type and protocol used.
  • the IoT device 200 may be any device that has a sensing function to detect a specific state and a networking function to communicate with the IoT gateway 100.
  • the integrated control server 300 is an arbitrary device equipped with the function to collect necessary information from various IoT devices 200 linked through the IoT gateway 100 and control the IoT devices 200 based on this.
  • the integrated control server 300 may correspond to any one of a mobile device, computer, computing device, server device, or server, but is not limited thereto.
  • the integrated control center can be the integrated control server 300, and in the case of a smart home, a server installed by the user or an application in a mobile phone can also serve as the integrated control server 300. .
  • the integrated control server 300 can control the IoT device 200 by performing communication based on the OCF standard with the IoT gateway 100 regardless of the type of the IoT device 200 and the protocol used, thereby reducing development resources. However, it can provide compatibility with various IoT devices.
  • the IoT gateway analyzes the communication protocol of each device from the message received from each IoT device 200, determines the device type and protocol used, and creates each OCF-based virtual resource model object based on this.
  • the created virtual resource model objects correspond to objects for the temperature sensor and air conditioner device, respectively.
  • the virtual resource model object of the temperature sensor will include the current temperature and the temperature unit (e.g., Celsius or Fahrenheit) as necessary properties
  • the virtual resource model object of the air conditioner will include current operation status (ON/OFF), etc. Temperature information, etc. will be included as necessary properties.
  • information about each virtual resource model object of the temperature sensor and air conditioner device can be used to perform operations that satisfy the RESTful method based on the resource model, such as Create, Retrieve, Update, and Delete. , it can be read (Retrieve) and/or Notified (Notify) by the integrated control server 300 according to the CRUDN method including Notify.
  • the integrated control server 300 sets a control to operate the air conditioner when a certain temperature (e.g., 27 degrees Celsius) is reached and to stop the operation of the air conditioner when the temperature drops to a certain temperature (e.g., 23 degrees Celsius), the temperature Based on the information that the temperature value of the sensor is 27 degrees Celsius and whether the air conditioner is operating is OFF, the integrated control server 300 updates the property for whether the air conditioner is operating from OFF to ON.
  • the request is transmitted to the IoT gateway 100, and the IoT gateway 100 converts the update request according to the protocol used by the air conditioner device and transmits it to the air conditioner device.
  • the air conditioner device can operate the air conditioner by changing its state from OFF to ON according to this request.
  • the integrated control server 300 changes the property for whether the air conditioner is operating from ON to OFF.
  • An update request is sent to the IoT gateway 100.
  • the IoT gateway 100 converts the update request according to the protocol used by the air conditioner device and transmits it to the air conditioner device, and the air conditioner device changes the state from ON to OFF accordingly, thereby stopping the air conditioner.
  • FIG. 2 shows a block diagram of IoT gateway 100 according to an embodiment of the present invention.
  • the IoT gateway 100 includes a protocol conversion unit 110, a device management unit 120, a device analysis machine learning unit 130, a control management unit 140, a risk detection unit 150, and a database 160. ) includes.
  • the protocol conversion unit 110 verifies and interprets the bound communication protocol from the message received from the IoT device 200, extracts the payload from it, and stores the payload in the database 160. Compare with the stored IoT device information to check the IoT device type and protocol information used. If there is no object created for the corresponding IoT device, a virtual resource model object based on the OCF framework is created, the received payload is converted into an OCF-based protocol, and the device management unit 120 is sent through the device information transfer module 114. ) is transmitted.
  • the device management unit 120 determines the type and protocol of the IoT device.
  • the protocol conversion unit 110 creates a virtual resource model object based on the OCF framework based on the IoT device type determined by the device management unit 120.
  • the received message is converted and bound into a message according to the protocol of the IoT device and transmitted to the IoT device 200. .
  • FIG. 3 is a block diagram of some modules constituting the protocol conversion unit 110 according to an embodiment of the present invention.
  • the protocol conversion unit 110 includes a communication protocol processing module 111, a protocol conversion module 112, a virtual model object creation module 113, and a device information transmission module 114.
  • the communication protocol processing module 111 checks and interprets the communication protocol bound to the message received from the IoT device 200 and extracts a payload from the received information.
  • Various protocols such as MQTT, HTTP, RS-485, CoAP, and WebSocket can be used as communication protocols through wireless or wired serial methods, and the communication protocol processing module 111 has information on the specifications of each protocol.
  • the communication protocol processing module 111 determines which communication protocol is bound to the received message by comparing the received message with the header of each protocol based on the specifications for the header of each communication protocol, and performs payment processing from the message. load can be extracted.
  • the communication protocol processing module 111 binds the communication protocol used by the IoT device 200 to the payload converted into the protocol used by the IoT device 200 and delivers a message to the corresponding IoT device 200. You can.
  • the protocol conversion module 112 compares the extracted payload with IoT device information stored in the database 160 to confirm the IoT device type and protocol information used, and converts the payload data into an OCF-based protocol based on this. do.
  • the protocol information used here may be one of the protocols supporting various frameworks established to control IoT devices, such as AllJoyn, oneM2M, and HomeKit.
  • the protocol conversion module 112 may include a framework for connection between OCF devices in the OCF bridging specification and devices in a non-OCF ecosystem.
  • the bridging specification defines general requirements for resource discovery, message transformation, security, and multiple bridge handling. Additionally, the bridging specification may provide specific requirements for the connection between OCF and non-OCF protocols, including mapping of core resources, errors, and algorithmic conversion of the user's resource type, and may provide specific requirements for connectivity between OCF and non-OCF protocols, such as the previously known OCF-AllJoyn Mapping Spec or OCF-oneM2M Mapping Spec may be further included.
  • the protocol conversion module 112 determines the IoT device 200 as a new device and delivers the payload to the device manager 120. do.
  • the protocol conversion module 112 converts the OCF standard-based message into a protocol used by the IoT device in order to deliver a message to an IoT device using a protocol other than the OCF standard, and uses the communication protocol processing module 111. It may further include functions that are transmitted to .
  • the virtual model object creation module 113 creates a virtual resource model object based on the OCF framework when a virtual model object for the IoT device has not yet been created.
  • Figure 7 shows an example of a virtual resource model object based on the OCF framework according to an embodiment of the present invention.
  • the virtual model object creation module 113 confirms that the IoT device is a smart lighting based on the type of the IoT device, and uses the resource URIs "/light" and "/dimming" supported by the corresponding OCF standard. You can create a virtual model object containing the corresponding resource types "oic.r.switch.binary" and "oic.r.brightness". Afterwards, the virtual model object can be controlled (for example, turning the power on/off or adjusting the brightness, etc.) using the OCF standard method through the integrated control server 300.
  • the device information transmission module 114 delivers the created virtual resource model object and the received payload to the device management unit 120, and also transmits the received payload to the device analysis machine learning unit 130. ) is transmitted.
  • the device management unit 120 receives the virtual resource model object generated by the protocol conversion unit 110, the device management unit 120 is configured to match information about the IoT device 200 linked to the IoT gateway 100. A device ID is created, and the device ID is added to the IoT device information stored in the database 160.
  • the device management unit 120 further collects identification information such as device manufacturer, model name, IoT device MAC information or UUID, and service port used from the delivered payload and stores them in the database 160. You can save it.
  • identification information such as device manufacturer, model name, IoT device MAC information or UUID, and service port used from the delivered payload and stores them in the database 160. You can save it.
  • the device management unit 120 maps the created virtual resource model object and information converted to an OCF-based protocol. Referring again to FIG. 7, the device manager 120 verifies that the smart light is turned on and the brightness is 100 by referring to the information converted to the OCF-based protocol, and stores this as a virtual resource created for the corresponding IoT device. By mapping to a model object, the value corresponding to resource "/light” is reflected as TRUE, and the value corresponding to resource "/diming" is reflected as 100.
  • the device management unit 120 configures the IoT device based on the ruleset learned by the device analysis machine learning unit 130 and stored in the database 160. Determine the type of device and protocol used. The determined type and protocol are used by the protocol conversion unit 110 to convert OCF-based protocols and create a virtual resource model object, and then the device management unit 120 can perform the above-described procedures such as device ID creation. .
  • Figure 4 shows a schematic block diagram of the device manager 120 according to an embodiment of the present invention.
  • the device manager 120 includes a device creation module 121, a device packet information collection module 122, and a device management module 123.
  • the device creation module 121 assigns a device ID to the virtual resource model object created by the protocol conversion unit 110 so that information can be matched.
  • the device packet information collection module 122 may further collect device manufacturer, model name, identification information such as MAC information or UUID of the IoT device, service port used, etc. through the payload.
  • the information collected in this way can be used as learning data for the machine learning model in the device analysis machine learning unit 130 to determine the device type and protocol used, and can be used to increase the accuracy of the virtual resource model object to be created in response. .
  • the device management module 123 maps the information created and collected in the device creation module 121 and the device packet information collection module 122 and stores it in a database, and stores the OCF-based protocol in the virtual resource model object corresponding to the device ID. Map the converted information.
  • the device management module 123 determines the type of IoT device and the protocol used based on the rule set stored in the database 160. The determined type and protocol are used by the protocol conversion unit 110 to convert OCF-based protocols and create a virtual resource model object, and then the device management unit 120 can perform the above-described procedures such as device ID creation. .
  • the device management module 123 also transmits the virtual resource model object matched to the linked IoT device and the message information of the IoT device to the control management unit 140.
  • the device management module 123 confirms that the smart lighting corresponding to the IoT device is turned on and the brightness is 100 according to the message information of the IoT device, it sends this information to the control management unit 140. Deliver.
  • the device management module 123 may receive risk detection rule set information for each IoT device type from the integrated control server 300 and transmit it to the risk detection unit 150.
  • the device analysis machine learning unit 130 performs machine learning to determine the type of IoT device and the protocol used based on the information received from the protocol conversion unit 110 or the device management unit 120.
  • a rule set is created and updated using the model and stored in the database 160.
  • the ruleset is based on information about various existing IoT devices (IoT device type, protocol used, device manufacturer, model name, IoT device identification information such as MAC information or UUID, service port used) and a device analysis machine learning unit ( 130).
  • the device analysis machine learning unit 130 classifies the model name and IoT device type by manufacturer, analyzes information received from a new IoT device, and analyzes the information received from the new IoT device, even though the IoT device is a device manufactured by a specific manufacturer. If it does not exactly match the model name and more than 70% of the existing model name matches the existing model name, a rule set can be configured to determine that the new IoT device is a newly released model of the device type corresponding to the existing model.
  • the device main machine learning unit 130 may determine that, although the new device is a device from a specific manufacturer, there is no existing model name that matches more than 70% of the model name, and there is no existing model name that matches more than 70% of the model name, and the device has a specific device type (e.g., thermostat) among the IoT devices of that manufacturer. If it accounts for more than 70% of the manufacturer's products, a rule set can be configured to determine that it is a newly released model for a specific type (temperature controller).
  • a specific device type e.g., thermostat
  • the identity of the device type and protocol used is calculated for each service port in use, and if no information other than the service port matches, the device type and protocol are used for the most types of IoT devices using the same service port.
  • a ruleset can be configured to determine what is applicable.
  • the priority of comparing each information is determined first to determine whether the model name matches, and then the manufacturer, the similarity of the IoT device identification number, the service port used, etc. are compared in that order to see if they match or are similar. You can also configure a ruleset to determine whether or not. Alternatively, if necessary, the user can learn new device information by manually setting the device type and the protocol used according to the device type.
  • the learning method of the rule set configured by the device analysis machine learning unit 130 of the present invention is not limited to the above-described examples, and can be used in various ways based on information that can be obtained. The accuracy can be increased by performing method learning.
  • the device analysis machine learning unit 130 can receive information related to this from the protocol conversion unit 110 or the device management unit 120 to learn and update the rule set, and the learned and updated The ruleset can be usefully used when initially registering a new IoT device in the device management unit 120.
  • control management unit 140 communicates with the integrated control server 300 using an OCF-based protocol, receives the control message of the IoT device 200 linked to the IoT gateway 100 from the control server 300, and converts the protocol.
  • the IoT device 200 is controlled through the unit 110.
  • FIG. 5 shows a schematic block diagram of the control management unit 140 according to an embodiment of the present invention.
  • the control management unit 140 includes a control conversion module 141, a control reception module 142, and a control transmission module 143.
  • control conversion module 141 When the control conversion module 141 receives a message from any IoT device 200, it identifies the IoT device 200 that delivered the message using the device ID and integrates the message through the control transmission module 143. Transmitted to the control server 300. At this time, an OCF-based virtual resource model object has already been created and the integrated control server 300 supports the OCF standard, so separate protocol conversion is not required.
  • control conversion module 141 when the control conversion module 141 receives a control message for a specific IoT device from the integrated control server 300 through the control reception module 142, the control conversion module 141 uses the ID generated and stored in the device manager 120. This specifies the IoT device that will deliver the control message.
  • the control reception module 142 receives a control message for a specific IoT device bound to the CoAP communication protocol supported by OCF from the integrated control server 300, extracts the payload, and delivers it to the control conversion module 141.
  • the control transmission module 143 binds the message delivered from the control conversion module 141 to the CoAP communication protocol supported by OCF and transmits it to the integrated control server 300. Additionally, when the control transmission module 143 receives a control message for any IoT device from the integrated control server 300, it converts the control message into a protocol used by the IoT device and transmits it to the IoT device.
  • the resources of the IoT device further include resources corresponding to the current time (/time), and if the integrated control server 300 says, “At 6 a.m., turn on the smart lights and adjust the brightness.”
  • the control management unit 140 receives the message received from the smart lighting through the OCF-based protocol. It is transmitted to the integrated control server 300, and when the control command is triggered based on the resources therein, the control management unit 140 receives the control command from the integrated control server 300 and transmits it to the smart lighting.
  • the risk detection unit 150 detects and blocks risk factors while the IoT gateway 100 communicates with the linked IoT device 200.
  • the risk detection unit 150 has a whitelist, which is a list of IoT devices that allow access, stored in the database 160, and constantly detects network packets between IoT devices communicating with the IoT gateway 100 to detect new IoT devices. Except in the case of initial registration to the IoT gateway 100, if a packet is sent from an IoT device that is not registered in the whitelist, it can be blocked. If initial registration is normally made, the IoT device in question can be placed in the whitelist. You can additionally register.
  • the whitelist may be IoT device information or may be managed separately.
  • the risk detection unit 150 receives and stores rule set information that can be used for risk detection from the device management unit 120, and uses the stored rule set information to detect security if the data received from the IoT device is not within the normal range. It can be determined that a risk has occurred. If it is determined that a security risk has occurred, the risk detection unit 150 may block communication with the IoT device and deliver a message to the integrated control server 300 indicating the risk information of the IoT device and that it has been blocked. .
  • Ruleset information that can be used for risk detection may include various methods used to detect risks on a network. As an example, data with the same device identification number but with changed other information such as the device type is received, or the generated virtual It can be used for risk detection when a value outside the range of a specific resource of the resource model object is passed (e.g., in the example of Figure 7, the value corresponding to the resource "/dimming" exceeds 100 or is a negative number, etc.). It may be included in existing ruleset information, but is not necessarily limited to this, and may include various methods used to detect risks on known networks.
  • the database 160 is connected locally or remotely to the IoT gateway 100 and stores various data that each component of the IoT gateway 100 uses, learns, updates, and creates temporarily or permanently. It is stored, and examples may include, but are not limited to, IoT device information, rulesets used to determine the use of IoT device types and protocols used, whitelists and rulesets used by the risk detection unit, etc. no.
  • FIG. 6 is a flowchart illustrating the interworking between IoT gateways and IoT devices according to an embodiment of the present invention.
  • the IoT gateway 100 receives it (S100), checks and interprets the bound communication protocol, and extracts a payload from it (S200).
  • the communication protocol can be any one of various protocols such as MQTT, HTTP, RS-485, CoAP, and WebSocket through wireless or wired serial methods.
  • the IoT gateway 100 can check which communication protocol is bound by comparing the header from the information about the specifications of each protocol and the received information, and extract the payload therefrom.
  • step S300 the IoT gateway 100 compares the extracted payload with the IoT device information stored in the database 160 to confirm the IoT device type and protocol used. If matching data is in the IoT device information but no virtual object has been created yet, the IoT gateway 100 creates a virtual resource model object based on the OCF framework (S400) and transfers the received payload to the OCF-based protocol. Convert to (S500). If there is a created virtual object, only protocol conversion of the received payload is performed without creating a separate virtual object (S500).
  • step S300 if matching data is not in the IoT device information, it is determined to be a newly registered IoT device, and the IoT device information, such as MAC (media access control) information or UUID (Universally Unique Identifier) from the extracted payload, is determined to be a newly registered IoT device.
  • the IoT device information such as MAC (media access control) information or UUID (Universally Unique Identifier) from the extracted payload.
  • MAC media access control
  • UUID Universalally Unique Identifier
  • At least some of the information acquired and determined in step S600 can be reflected in the ruleset and used for learning based on machine learning methods, based on the type of IoT device and the protocol used determined in step S600.
  • a virtual object can be created (S400) and OCF-based protocol conversion of the payload (S500) can be performed.
  • the IoT gateway 100 creates a device ID to match information about the linked IoT device 200 and adds it to the IoT device information stored in the database 160 (S700 )do.
  • the IoT gateway 100 maps the information converted to the OCF-based protocol to the created virtual object to which an ID is assigned (S800).
  • S800 an ID is assigned
  • all necessary information such as status information, is mapped and stored according to the type of IoT device 200, regardless of the protocol used, and can be stored through a protocol that supports the OCF standard.
  • a message can be delivered to the integrated control server 300.
  • the IoT gateway 100 extracts a payload from the control message (S900).
  • the control message is transmitted using CoAP, a communication protocol supported by the OCF standard.
  • the IoT gateway 100 compares the information obtainable from the payload with the IoT device information stored in the database 160 to identify the IoT device 200 to which the control message is to be transmitted, and the IoT device 200 Convert the control message (S1000) according to the protocol in use.
  • the converted control message is bound to the communication protocol used by the IoT device 200 and then transmitted to the IoT device 200 (S1100), and the IoT device 200 performs the requested control based on the received control message. Carry out the content.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Informatics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention divulgue, selon un mode de réalisation, une passerelle IoT qui assure la compatibilité avec des dispositifs IoT ayant divers protocoles, la passerelle IoT comprenant : une unité de conversion de protocole qui, sur la base d'un message reçu d'un premier dispositif IoT, vérifie le type du premier dispositif IoT et un protocole utilisé par celui-ci, et qui génère un objet de modèle de ressource virtuelle basé sur une structure de format OCF et qui convertit le message reçu en un protocole basé sur un format OCF ; une unité de gestion de dispositif qui attribue un ID de dispositif à l'objet de modèle de ressource généré et qui mappe l'objet de modèle de ressource généré avec le message reçu qui a été converti en protocole basé sur un format OCF ; et une unité de gestion de commande qui transmet l'objet de modèle de ressource généré à un serveur de commande intégré en utilisant le protocole basé sur un format OCF.
PCT/KR2023/010738 2022-08-31 2023-07-25 Passerelle iot assurant une compatibilité avec des dispositifs iot ayant divers protocoles, et son procédé de commande WO2024049011A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220110027A KR102519701B1 (ko) 2022-08-31 2022-08-31 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법
KR10-2022-0110027 2022-08-31

Publications (1)

Publication Number Publication Date
WO2024049011A1 true WO2024049011A1 (fr) 2024-03-07

Family

ID=85979124

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/010738 WO2024049011A1 (fr) 2022-08-31 2023-07-25 Passerelle iot assurant une compatibilité avec des dispositifs iot ayant divers protocoles, et son procédé de commande

Country Status (2)

Country Link
KR (1) KR102519701B1 (fr)
WO (1) WO2024049011A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118282806A (zh) * 2024-05-30 2024-07-02 深圳市控汇智能股份有限公司 一种多路协议转换的数据网关

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102519701B1 (ko) * 2022-08-31 2023-04-13 주식회사 융창 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법
CN117319526A (zh) * 2023-11-27 2023-12-29 杭州义益钛迪信息技术有限公司 协议确定方法、装置、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101679578B1 (ko) * 2015-05-27 2016-11-25 주식회사 윈스 IoT 보안을 위한 제어 서비스 제공 장치 및 방법
KR20180058415A (ko) * 2016-11-24 2018-06-01 금오기전 주식회사 멀티 프로토콜 IoT 게이트웨이 장치 및 방법
KR20190103520A (ko) * 2018-02-13 2019-09-05 (주)브로드웨이브 논아이피 사물인터넷 디바이스의 오씨에프 적용을 위한 방법
KR20200085754A (ko) * 2017-12-06 2020-07-15 인텔 코포레이션 사물 인터넷(iot) 네트워크 최적화를 위한 플러그인 관리
KR102159077B1 (ko) * 2019-04-19 2020-09-23 (주)노르마 인공 지능을 이용한 IoT 디바이스의 타입을 결정하는 시스템
KR102519701B1 (ko) * 2022-08-31 2023-04-13 주식회사 융창 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101679578B1 (ko) * 2015-05-27 2016-11-25 주식회사 윈스 IoT 보안을 위한 제어 서비스 제공 장치 및 방법
KR20180058415A (ko) * 2016-11-24 2018-06-01 금오기전 주식회사 멀티 프로토콜 IoT 게이트웨이 장치 및 방법
KR20200085754A (ko) * 2017-12-06 2020-07-15 인텔 코포레이션 사물 인터넷(iot) 네트워크 최적화를 위한 플러그인 관리
KR20190103520A (ko) * 2018-02-13 2019-09-05 (주)브로드웨이브 논아이피 사물인터넷 디바이스의 오씨에프 적용을 위한 방법
KR102159077B1 (ko) * 2019-04-19 2020-09-23 (주)노르마 인공 지능을 이용한 IoT 디바이스의 타입을 결정하는 시스템
KR102519701B1 (ko) * 2022-08-31 2023-04-13 주식회사 융창 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118282806A (zh) * 2024-05-30 2024-07-02 深圳市控汇智能股份有限公司 一种多路协议转换的数据网关

Also Published As

Publication number Publication date
KR102519701B1 (ko) 2023-04-13

Similar Documents

Publication Publication Date Title
WO2024049011A1 (fr) Passerelle iot assurant une compatibilité avec des dispositifs iot ayant divers protocoles, et son procédé de commande
US7870232B2 (en) Messaging in a home automation data transfer system
US7694005B2 (en) Remote device management in a home automation data transfer system
WO2014092375A1 (fr) Procédé et appareil de commande d'accès entre un dispositif local et un serveur externe dans un système de réseau local
WO2015064912A1 (fr) Procédé de commande de système domotique intelligent, et dispositif électronique correspondant
WO2012067382A2 (fr) Procédé permettant d'établir une connexion réseau, procédé permettant une connexion à un réseau et groupe de communication sans fil qui applique ces procédés
WO2013133549A1 (fr) Système de gestion de santé utilisant un réseau domestique et son procédé de fonctionnement
EP2671153A2 (fr) Appareil et procédé permettant de donner à un dispositif numérique une fonction d'installation automatique d'une application
WO2015093893A1 (fr) Procédé et dispositif de notification d'événement dans un système de réseau domestique
WO2020197275A1 (fr) Procédé d'installation de profil d'abonné et dispositif électronique associé
EP2673920A1 (fr) Procédé et appareil pour contrôler la connexion entre des dispositifs
WO2020040396A1 (fr) Système de virtualisation de réseau iot en nuage et procédé de réseautage
WO2020171307A1 (fr) Système de gestion de tableaux de commutation à l'aide d'un réseau en anneau
WO2013039297A2 (fr) Procédé et système pour rechercher un objet dans un réseau
WO2011030967A1 (fr) Passerelle filaire/sans fil intégrée et procédé de fonctionnement de cette passerelle
WO2013069886A1 (fr) Système de commande d'installation et son procédé de fonctionnement
US10972464B2 (en) Network system
WO2016190465A1 (fr) Procédé de fourniture d'informations actives basée sur la localisation, et système associé
WO2022114655A1 (fr) Système et procédé de configuration d'intelligence artificielle de dispositif à base de nuage
KR102675964B1 (ko) 다양한 프로토콜을 갖는 사물인터넷(IoT) 디바이스와 IoT 게이트웨이의 통신 방법
WO2011027978A2 (fr) Passerelle de l'ubiquité pour ville de l'ubiquité, et système et procédé de traitement de message la comprenant
WO2013100484A1 (fr) Terminal utilisateur et procédé de partage de données entre applications associées
WO2012047026A2 (fr) Procédé et appareil de fourniture d'un service de réseau externe sur la base d'une visualisation de publicités
WO2021080110A1 (fr) Système et procédé permettant de gérer et d'identifier l'affiliation d'un terminal dans un environnement en nuage
WO2015093770A1 (fr) Système de réseau m2m, passerelle m2m, et procédé d'installation de module logiciel dans une passerelle m2m, pour exécuter une transmission de données avec un dispositif

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23860693

Country of ref document: EP

Kind code of ref document: A1