KR20240123461A - Method for communication of IoT devices and detection of security threats of IoT devices by IoT gateway - Google Patents

Abstract

The present invention relates to a method for communicating with an IoT device by an Internet of Things (IoT) gateway, and according to one embodiment, a method for communicating between an IoT gateway and an IoT device is disclosed, including: a step of extracting a payload from a message received from a first IoT device; a step of comparing the extracted payload with IoT device information pre-stored in a database to confirm the type and the protocol used by the first IoT device; a step of generating a virtual resource model object based on the OCF framework for the first IoT device and generating a device identification number (ID) for the first IoT device; a step of converting the payload into information according to the OCF-based protocol and mapping the converted information to the virtual resource model object; and a step of detecting a risk factor of the first IoT device.

Description

Method for communication with IoT devices and detection of security threats of IoT devices by IoT gateway

The present invention relates to an IoT gateway that provides compatibility with IoT devices having various protocols and a control method thereof, and more specifically, to an IoT gateway that converts development resources generated for interworking with IoT devices using various types of protocols by various manufacturers into the OCF method, which is a standard platform, thereby providing compatibility with various IoT devices, reducing development resources, and providing various conveniences, and to a control method thereof that detects and blocks risks of hacking between IoT devices to provide a secure environment.

The Internet of Things (IoT) can refer to a technology that performs desired services by organically connecting surrounding objects to each other through wired and wireless networks to collect, process, and share information.

Initially, there was a tendency to view IoT from the perspective of environmental information sensing and communication and networking of sensed information, but recently, it has expanded to the concept of WoT (Web of Things), which extends the concept of web services to devices, and the concept of IoE (Internet of Everything), which expands the target of things to all objects.

Meanwhile, Smart City is one of the IoT application services that has realized the original purpose of IoT, hyper-connectivity. Smart City aims to secure urban data through IT technology and network access, and to use and redistribute urban resources efficiently based on this data, ultimately enriching and making the lives of citizens in the city more convenient.

To achieve this, a network environment can be created throughout the city, and IoT devices equipped with sensors can be installed in various infrastructures such as cultural facilities, houses, roads, and businesses to collect sensed data, and the city's information can be comprehensively managed and operated based on this data.

In addition, another IoT application service is the smart home. The smart home recognizes the current situation based on data collected by IoT devices, analyzes this, and processes the data to suit the user's lifestyle pattern, thereby providing customized services to the user.

In order to provide IoT application services such as smart cities or smart homes, IoT devices equipped with sensors to collect necessary data and capable of communicating through a network, gateways and servers that communicate with multiple IoT devices, collect and process data, and provide services to users are required. In addition, since multiple IoT devices are integrated and concentrated in one place, security elements for the connected network and IoT devices must also be included.

In order to provide various 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 advanced. For example, under the leadership of the Linux Foundation, members including LG Electronics, Haier, Panasonic, Qualcomm, and Sharp came together to launch the AllSeen Alliance to establish IoT-related standards, and selected Qualcomm's P2P solution, AllJoyn open project, as the foundation framework for the IoE. In addition, seven global standard development organizations including TTA in Korea, ESTI in Europe, and ATIS and TIA in North America came together to form a project for the purpose of developing a joint platform for the Internet of Things and announced the oneM2M standard. In addition, many companies including Intel, Samsung Electronics, and Amtel launched the Open Interconnect Consortium (OIC) and established the Open Connectivity Foundation (OCF) to develop standard specifications.

In particular, among the IoT standardization organizations, the Open Connectivity Foundation (OCF) has established the open source-based OCF standard for the IoT, and the OCF standard is a representative IoT standard that has been rapidly adopted among various standards related to the IoT recently. OCF is a standard platform technology that connects IoT devices and enables mutual control of resources existing in IoT devices. OCF adopts the Restful method in which each server defines various IoT services that it can provide in the form of resources and clients can use the desired services, with a server-client model. Meanwhile, the OCF uses the Constrained Application Protocol (CoAP) to enable the IoT to be implemented even in small devices with low computing power.

In this way, in the case of IoT devices that use OCF technology, they can normally communicate with other devices that use OCF technology through the protocol adopted by OCF, but there is a problem that makes it difficult to communicate with other devices that use other standard technologies other than OCF. This problem is bound to be an obstacle to both the OCF camp and other standard technology camps expanding their respective ecosystems.

As there are various IoT frameworks and communication protocols for IoT devices, it has become difficult to comprehensively control and manage IoT devices that use different frameworks or protocols. This problem has become worse as the number of IoT devices connected to a single gateway has increased.

The present invention is intended to solve the above problems, and aims to provide an IoT gateway that can be integrated in the form of an OCF standard protocol to connect with and control a plurality of IoT devices using different protocols.

In addition, the present invention aims to provide a novel IoT gateway capable of determining the type of IoT device and the protocol used by providing a rule set learned through a machine learning algorithm even for a new IoT device for which there is no existing data.

In addition, the present invention aims to provide a novel IoT gateway having a function capable of detecting and blocking risk factors that may occur during communication with a linked IoT device.

According to one embodiment of the present invention, a method for communicating with an IoT device by an Internet of Things (IoT) gateway, comprising: extracting a payload from a message received from a first IoT device; comparing the extracted payload with IoT device information stored in a database to confirm a type and a protocol used by the first IoT device; generating a virtual resource model object based on an OCF framework for the first IoT device and generating a device identification number (ID) for the first IoT device; converting the payload into information according to an OCF-based protocol and mapping the converted information to the virtual resource model object; And a step of detecting a risk factor of the first IoT device; In the step of confirming the type of the first IoT device and the protocol used, if the type of the first IoT device and the protocol used cannot be confirmed by comparison with the pre-stored IoT device information, predetermined information is acquired from the received message, and the type of the first IoT device and the protocol used are determined based on the acquired information and a first rule set that has been learned and stored in advance, and in the step of detecting the risk factor of the first IoT device, if the converted information includes a value out of the range allowed for each resource of the virtual resource object model based on a second rule set that has been learned and stored in advance, it is determined that there is a risk factor in the first IoT device.

According to one embodiment of the present invention, the first ruleset may be configured to determine the device type and protocol of the given device as the type and protocol of the first IoT device if the similarity between the model name of the first IoT device and the model name of a given device among the IoT device information pre-stored in the database exceeds a preset value.

In addition, according to one embodiment of the present invention, if it is determined in the step of detecting a risk factor of the first IoT device that there is a risk factor in the first IoT device, the step of blocking communication with the first IoT device and transmitting a message notifying the integrated control server of risk information about the first IoT device and the fact that communication has been blocked may be further included.

According to the present invention, it is possible to link and control multiple IoT devices using different protocols by using an IoT gateway that can be integrated in the form of an OCF standard protocol.

In addition, according to the present invention, by providing a ruleset learned through a machine learning algorithm, the accuracy of determining the type and protocol used of an IoT device can be increased even for a new IoT device for which there is no existing data.

In addition, according to the present invention, it is possible to detect and block risk factors that may occur during communication with a linked IoT device, thereby enhancing security and enabling safe linkage and control of IoT devices.

FIG. 1 is a schematic diagram illustrating an entire system including an IoT gateway according to one embodiment of the present invention;
FIG. 2 is a block diagram of an IoT gateway according to one embodiment of the present invention;
FIG. 3 is a block diagram showing each module constituting a protocol conversion unit according to an embodiment of the present invention.
FIG. 4 is a block diagram showing each module constituting a device management unit according to an embodiment of the present invention;
FIG. 5 is a block diagram showing each module constituting a 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 one embodiment of the present invention.
FIG. 7 is a diagram illustrating an example of a resource model object based on the OCF framework according to one embodiment of the present invention.

The above objects, other objects, features and advantages of the present invention will be readily understood through the following preferred embodiments related to the attached drawings. However, the present invention is not limited to the embodiments described herein and may be embodied in other forms. Rather, the embodiments introduced herein are provided so that the disclosed contents can be thorough and complete and so that the spirit of the present invention can be sufficiently conveyed to those skilled in the art.

When terms such as first, second, etc. are used in this specification to describe components, these components should not be limited by these terms. These terms are only used to distinguish one component from another. The embodiments described and illustrated herein also include complementary embodiments thereof.

In this specification, the singular includes the plural unless specifically stated otherwise in the phrase. The expressions “including,” “consisting of,” and “consisting of” used in the specification do not exclude the presence or addition of one or more other components in addition to the components mentioned.

In this specification, the term 'software' means a technology that moves hardware in a computer, the term 'hardware' means a type of device or apparatus that constitutes a computer (CPU, memory, input device, output device, peripheral device, etc.), the term 'step' means a series of processes or operations connected in time series to achieve a given goal, the term 'computer program', 'program', or 'algorithm' means a set of commands suitable for processing by a computer, and the term 'program recording medium' means a computer-readable recording medium that records a program used to install, execute, or distribute a program.

The terms “node,” “part,” “module,” “unit,” “block,” “board,” etc., used herein to refer to components of the invention may mean a physical, functional, or logical unit that processes at least one function or operation, and which may be implemented by one or more hardware, software, or firmware, or by a combination of one or more hardware, software, and/or firmware.

In this specification, a 'mobile device', a 'computer', a 'computing device', a 'server device', or a 'server' may be implemented as a device having an operating system such as Windows, Mac, or Linux, a computer processor, memory, application programs, a storage device (e.g., HDD, SDD), and a monitor. The computer may be, for example, a desktop computer, a laptop, a mobile terminal, etc., but these are exemplary and not limited thereto. The mobile terminal may be one of a smart phone, a tablet PC, or a mobile wireless communication device such as a PDA.

In this specification, the term “component ‘A’ transmitting information, details, and/or data to component ‘B’” is used to mean that component ‘A’ transmits information, details, and/or data directly to component ‘B’ or that component ‘A’ transmits information, details, and/or data to component ‘B’ via at least one other component.

Hereinafter, the present invention will be described in detail with reference to the drawings. In describing specific embodiments below, various specific contents have been written to more specifically describe the invention and help understanding. However, readers who have knowledge in this field enough to understand the present invention can recognize that it can be used without these various specific contents. In addition, in describing the invention, it is mentioned in advance that parts that are known or commonly known techniques but are not significantly related to the invention are not described in order to prevent confusion in describing the present invention.

FIG. 1 schematically illustrates an entire system including an IoT gateway according to one embodiment of the present invention.

The IoT gateway (100) illustrated in FIG. 1, in order to interwork with an IoT device (200) that uses various types of protocols, compares a message received from an IoT device (200) with stored IoT device information, verifies the type of the IoT device (200) and the information on the protocol used, creates a virtual resource model object based on the OCF framework, and converts the received message into an OCF-based protocol. Meanwhile, if the type of the IoT device (200) and the information on the protocol used are not verified even when compared with the IoT device information, it determines that it is an IoT device that is being registered for the first time, and obtains various information such as MAC (media Access Control) information or UUID (universally unique identifier) of the IoT device, manufacturer information, information on the service port used, and model name from the received message, and determines the type of the IoT device (200) and the protocol used based on a rule set that has been learned in advance and stored, and adds this information to the IoT device information.

Since the ruleset cannot include information on all IoT devices currently in existence, and IoT devices with new types and protocols may continue to appear on the market, the IoT gateway (100) may perform machine learning on the ruleset using at least one of the known machine learning algorithms, thereby increasing the accuracy of resource model determination, such as by generating a virtual resource model object and determining the protocol to be used based on device type analysis when linking IoT devices in a manner not reflected in the ruleset in the future. At this time, at least some of the various pieces of information acquired may be used for learning using a known machine learning method.

Meanwhile, the IoT gateway (100) maps a message converted into an OCF-based protocol to a resource of a virtual resource model object created based on the OCF framework. Since the virtual resource model object based on the OCF framework for the linked IoT device (200) is created and the data required for the resource is mapped, the IoT gateway (100) communicates with the integrated control server (300) supporting the OCF protocol using CoAP (Constrained Application Protocol) and receives a RESTful control message for controlling the linked IoT device (200) from the integrated control server (300), and reconverts the control message to a protocol used by the IoT device (200) and transmits it based on the control message, thereby controlling the IoT device (200).

In addition, the IoT gateway (100) performs a function of detecting and blocking risk factors that may occur during communication with the linked IoT device (200). That is, it constantly detects information received from the IoT device (200) and blocks the linked IoT device (200) when abnormal information is detected, or it maintains a list of IoT devices (200) that can be linked with the IoT gateway (100) in a whitelist manner and blocks IoT devices that are not registered in the whitelist when they attempt to transmit information in general control situations except for the initial linkage.

An IoT gateway may correspond to, but is not limited to, any one of a mobile device, a computer, a computing device, a server device, or a server according to the definition of the present invention, and any device that has a local or remote storage device such as a cloud and performs the functions described in the present invention while interconnecting and communicating with one or more IoT devices and an integrated control server via wired and/or wireless means may correspond to an IoT gateway according to the present invention.

Next, 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 uses CoAP used in the OCF standard to connect with the IoT gateway (100), but may also use a protocol that does not support the OCF standard, such as the MQTT (Message Queuing Telemetry Transport) protocol, HTTP, or RS-485, which is one of the serial communications, or may be a non-OCF device that does not comply with the OCF standard for control. Regardless of the device type and the protocol used, the IoT device (200) may connect with the IoT gateway (100) to provide information and be controlled.

The IoT device (200) can be any device that basically has a sensing function for detecting a specific state and a networking function for linking and communicating with an IoT gateway, and it can be understood that in addition to this, it can also have additional functions, such as an actuating function for performing a specific operation, depending on its type.

The integrated control server (300) may be an integrated control center in the case of a smart city, a server installed by a user in the case of a smart home, or an application in a mobile phone, and is characterized by having a function capable of collecting necessary information from various IoT devices (200) linked through an IoT gateway (100) and performing necessary control based thereon. Here, the integrated control server (300) performs communication based on the OCF standard with the IoT gateway (100) regardless of the type of IoT device (200) and the protocol used, thereby enabling control of the IoT device (200), thereby reducing development resources while providing compatibility with various IoT devices.

The integrated control server (300) may correspond to any one of a mobile device, a computer, a computing device, a server device, or a server according to the definition of the present invention, but is not limited thereto. Any device that performs the functions described in the present invention, such as transmitting a control message for controlling an IoT device linked to an IoT gateway while communicating with an IoT gateway, may correspond to the integrated control server according to the present invention.

In the example of Fig. 1, assuming that there are two IoT devices (200) that do not comply with the OCF standard, a temperature sensor and an air conditioner, when the temperature sensor and the air conditioner are first connected to the IoT gateway (100), the IoT gateway (100) analyzes the communication protocol from the received message, determines the device type and the protocol used, and creates an OCF-based virtual resource model object based on the same. The created virtual resource model objects correspond to objects for the temperature sensor and the air conditioner, respectively, and, as necessary properties, will include the current temperature and the unit of the temperature (e.g., Celsius or Fahrenheit) in the case of the temperature sensor, and will also include whether the air conditioner is currently operating (ON/OFF).

In this way, information on the OCF-based objects for the generated temperature sensor and air conditioner device can be retrieved and/or notified to the integrated control server (300) based on the CRUDN method, which includes operations that satisfy the RESTful method based on the resource model, that is, Create, Retrieve, Update, Delete, and Notify, respectively, and if the integrated control server (300) sets a control to operate when a specific temperature (e.g., 27 degrees Celsius) is reached and the air conditioner does not operate, and to stop operating when the temperature drops to a specific temperature (e.g., 23 degrees Celsius) and the air conditioner operates, the integrated control server (300) transmits an update to change the property on whether the air conditioner device is operating from OFF to ON based on the information that the temperature value of the temperature sensor is 27 degrees Celsius and whether the air conditioner device is operating is OFF, and based on this, the IoT gateway (100) transmits an update to change the property on whether the air conditioner device is operating from OFF to ON. The transmitted content is converted and transmitted in accordance with the protocol, and the air conditioner device can operate the air conditioner by changing the status from OFF to ON accordingly.

Similarly, based on the information that the temperature value of the temperature sensor is 23 degrees Celsius and the operation status of the air conditioner is ON, the integrated control server (300) transmits an update to change the property of the operation status of the air conditioner from ON to OFF, and based on this, the IoT gateway (100) converts and transmits the control message transmitted in accordance with the protocol used by the air conditioner, and the air conditioner can change the status from ON to OFF accordingly, thereby stopping the air conditioner in operation.

FIG. 2 illustrates a block diagram of an IoT gateway according to one embodiment of the present invention.

Referring to FIG. 2, 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).

The protocol conversion unit (110) verifies and interprets the communication protocol bound from the message received during communication with the IoT device (200), extracts the payload therefrom, compares the payload with the IoT device information stored in the database (160), verifies the IoT device type and protocol information used, and if there is no object created for the corresponding IoT device, creates a virtual resource model object based on the OCF framework, converts the received payload into an OCF-based protocol, and transfers it to the device management unit (120) through the device information transfer module (114). If there is no IoT device information matching the database, it determines that it is an IoT device that is being registered for the first time, transfers the payload to the device management unit (120) through the device information transfer module (114), and creates a virtual resource model object based on the OCF framework based on the IoT device type determined by the device management unit (120). In addition, when a control message to a specific IoT device is received from the integrated control server (300), the received message is converted and bound to a protocol and communication protocol used by the specific IoT device and then transmitted after checking the protocol information used stored in the database (160).

Referring to FIG. 3, which illustrates a block diagram including each module constituting a protocol conversion unit (110) according to an embodiment of the present invention, the protocol conversion unit (110) will be described in more detail. 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) verifies and interprets the communication protocol bound to the message received from the IoT device (200) and extracts the payload from the received information. Various protocols such as MQTT, HTTP, RS-485, CoAP, and WebSocket via wireless or wired serial may be used as the communication protocol, and the communication protocol processing module (111) can verify which communication protocol is bound by comparing the information about the standard of each protocol and the header from the received message, and extract the payload therefrom. In addition, the communication protocol processing module (111) can further perform the function of binding the communication protocol used by a specific IoT device to the payload converted into the protocol used by the IoT device for message transmission to the specific IoT device and transmitting it to the IoT device. At this time, the communication protocol used by the specific IoT device can be verified by storing the result confirmed upon message reception in the database (160) and referring to it.

The protocol conversion module (112) checks the IoT device type and protocol information used by comparing the extracted payload with the IoT device information stored by the database (160), and converts it into an OCF-based protocol based on the information. 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 of the bridging specification of OCF and devices in a non-OCF ecosystem, where the bridging specification defines general requirements for resource discovery, message conversion, security, and multi-bridge processing, and the bridging specification may provide specific requirements for connection between OCF and non-OCF protocols, including mapping of core resources, errors, and algorithmic conversion of user resource types, and may further include the previously known OCF-AllJoyn Mapping Spec or OCF-oneM2M Mapping Spec.

If it does not match the IoT device information stored in the database (160), it is determined that it is a device to be newly registered in the IoT gateway (100) and the payload is transmitted to the device management unit (120).

In addition, the protocol conversion module (112) can further perform the function of converting a message based on the OCF standard into a protocol used by the virtual IoT device of the object for message transmission to a specific IoT device and transmitting the converted message to the communication protocol processing module (111).

Next, the virtual model object creation module (113) creates a virtual resource model object based on the OCF framework if a virtual model object for the IoT device has not yet been created. Referring to FIG. 7, which illustrates an example of a resource model object based on the OCF framework according to an embodiment of the present invention, the virtual model object creation module (113) can identify a smart light from the type of the IoT device and create a virtual model object including oic.r.switch.binary and oic.r.brightness, which are resource types corresponding to /light and /dimming, which are resource URIs supported by the OCF standard. Thereafter, the virtual model object can be controlled (e.g., turning the power on/off or controlling the dimming function by adjusting the brightness) in the OCF standard manner through the integrated control server (300).

Finally, the device information transmission module (114) transmits the generated virtual resource model object and the received payload to the device management unit (120), while transmitting the received payload for machine learning to the device analysis machine learning unit (130).

Next, the device management unit (120) generates a device ID so that it can match information about the IoT device (200) linked to the IoT gateway (100) when the virtual resource model object generated by the protocol conversion unit (110) is transmitted, and adds it to the IoT device information stored in the database (160). In order for the IoT device information to be clearer, the device management unit (120) can further collect and store the device manufacturer, model name, identification information such as MAC information or UUID of the IoT device, and the used service port through the transmitted payload. Meanwhile, the device management unit (120) maps the generated virtual resource model object and the information converted into an OCF-based protocol. Continuing from the example of Fig. 7, by referring to the information converted into an OCF-based protocol, it is confirmed that the smart light corresponding to the IoT device is turned on and the brightness is 100, and this is mapped to the virtual resource model object generated for the corresponding IoT device, so that the value corresponding to the resource /light is reflected as TRUE and the value corresponding to the resource /diming as 100.

Meanwhile, when a situation arises where an IoT device that has not been previously registered is first registered, the device management unit (120) determines the type of the IoT device and the protocol used based on the ruleset learned by the device analysis machine learning unit (130) and stored in the database (160). The determined type and protocol are used by the protocol conversion unit (110) to convert the OCF-based protocol and generate a virtual resource model object, and then the device management unit (120) can perform the aforementioned procedures such as device ID generation.

Referring to FIG. 4, which illustrates a block diagram including each module constituting the device management unit (120) according to an embodiment of the present invention, the device management unit (120) will be described in more detail. The device management unit (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 so that information can be matched to a virtual resource model object created based on the type of the linked IoT device (200) generated in the protocol conversion unit (110).

The device packet information collection module (122) can further collect device manufacturer, model name, IoT device MAC information or UUID, and other identification information, as well as the service port used, through the transmitted payload. The information stored in this way can be used in a machine learning algorithm in the device analysis machine learning unit (130) described below to determine the device type and the protocol used, and to increase the accuracy of the virtual resource model object to be generated in response thereto.

The device management module (123) maps the information generated/collected by the device generation module (121) and the device packet information collection module (122) and stores it in a database, and maps the information converted into an OCF-based protocol to a virtual resource model object corresponding to the generated device ID. If an IoT device that has not been previously registered attempts to be registered for the first time, the device management module (123) determines the type of the IoT device and the protocol used based on the ruleset stored in the database (160), and the determined type and protocol are used by the protocol conversion unit (110) to convert the OCF-based protocol and generate a virtual resource model object, and thereafter, the device management unit (120) can perform the aforementioned procedures such as device ID generation.

The device management module (123) also transmits information to the control management unit (140) based on the virtual resource model object matched with the linked IoT device and the message information of the IoT device. In the example of FIG. 7 described above, if it is confirmed that the smart light corresponding to the IoT device is turned on and the brightness is 100 according to the message information of the IoT device, this information is transmitted to the control management unit (140). Meanwhile, the device management module (123) can 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).

Meanwhile, the device analysis machine learning unit (130) uses at least one of the known machine learning methods to determine the type of the linked IoT device and the protocol used based on the information received from the protocol conversion unit (110) or the device management unit (120), and creates and updates a learned ruleset and stores it in the database (160). At this time, the ruleset is learned by the device analysis machine learning unit (130) based on information about various existing IoT devices (IoT device type, protocol used, device manufacturer, model name, identification information such as MAC information or UUID of the IoT device, and used service port).

The ruleset learned and updated in this way can determine the type and protocol of an IoT device based on information about the various IoT devices described above (IoT device type, protocol used, device manufacturer, model name, identification information such as MAC information or UUID of the IoT device, and service port used).

For example, if the type and protocol used by an IoT device cannot be confirmed by comparing with IoT device information pre-stored in a database (160), if the similarity between the model name of the IoT device and the model name of a predetermined device among the IoT device information pre-stored in the database exceeds a preset value, the device type and protocol of the predetermined device can be determined as the type and protocol of the IoT device by a ruleset.

For example, the device analysis machine learning unit (130) can distinguish model names and IoT device types by manufacturer, and if information received from a new IoT device does not match an existing model name and device type although it is a device manufactured by the manufacturer, if at least 70% or more of the model names match an existing model name, the type of the new IoT device is determined to be a newly released model of the device type corresponding to the existing model that matches, or if there is no model name that matches 70% or more of the model names and types corresponding to a specific type (e.g., thermostat) account for 70% or more of the IoT devices corresponding to the manufacturer, the rule set can be configured to determine that it is a newly released model for the specific type (thermostat).

As another example, a ruleset can be configured to calculate the identity of the device type and the protocol used by the service port used, and if no other information matches except the service port, determine that it corresponds to the most numerous device type and protocol among the IoT devices using the same service port. In addition, a ruleset can be configured to determine the priority of the comparison of each piece of information to first determine whether the model name matches, and then determine whether it matches or is similar in the order of the manufacturer, the similarity of the identification number of the IoT device, the service port used, etc. Alternatively, if necessary, the user can be enabled to learn about new device information by setting the device type and the protocol used according to the device type.

Since the above-described examples of the ruleset configuration are only some examples, the learning method of the ruleset configured by the device analysis machine learning unit (130) of the present invention is not limited to the above-described examples, and various types of learning can be performed based on the information that can be obtained to increase the accuracy.

When a new IoT device is connected, the device analysis machine learning unit (130) can receive information related thereto from the protocol conversion unit (110) or the device management unit (120) and update the learning and rule set. The learned and updated rule set can be usefully utilized when a new IoT device is first registered in the device management unit (120).

Next, the control management unit (140) communicates with the integrated control server (300) using an OCF-based protocol, receives a control message of a specific IoT device (200) linked to an IoT gateway (100) from the control server (300), and controls the specific IoT device (200) through the protocol conversion unit (110).

Referring to FIG. 5, which illustrates a block diagram including each module constituting a control management unit (140) according to an embodiment of the present invention, the control management unit (140) will be described in more detail. The control management unit (140) includes a control conversion module (141), a control receiving module (142), and a control transmission module (143).

The control conversion module (141) receives a message from an IoT device matching a specific ID from the device management unit (120), verifies the IoT device that transmitted the message using the ID, and transmits the message to the integrated control server (300) via the control transmission module (143). At this time, since an OCF-based virtual resource model object has already been created and the integrated control server (300) supports the OCF standard, no separate protocol conversion is required. In addition, when the integrated control server (300) receives a control message for a specific IoT device via the control reception module (142), the device management unit (120) specifies the IoT device to which the control message is to be transmitted using the ID created and stored, and then completes the conversion to the protocol used by the specific IoT device provided by the protocol conversion unit (110) and the binding of the communication protocol via the control transmission module (143), and then transmits the message to the specific IoT device.

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 transmits it to the control conversion module (141).

The control transmission module (143) binds the message transmitted from the control conversion module (141) to the CoAP communication protocol supported by OCF and transmits it to the integrated control server (300), and also converts the control message received from the integrated control server (300) into a protocol used by the IoT device to be transmitted through the protocol conversion unit (110) and completes binding of the communication protocol before transmitting it.

In the example of FIG. 7 described above, if the resource of the IoT device further includes a resource corresponding to the current time (/time), and if the integrated control server (300) sets a control command to turn on the light and set the brightness to 20 when it is 6 a.m. and the smart light corresponding to the IoT is turned off, and to increase the brightness by 20 every 5 minutes until it reaches 100, the control management unit (140) transmits a message received from the IoT device to the integrated control server (300) through an OCF-based protocol, and if the control command is triggered based on the resources therein, the control management unit (140) receives a control message from the integrated control server (300) (for example, a control message using an OCF-based protocol to turn on the light and set the brightness to 20 when it is 6 a.m. and the light is turned off) and transmits it to the IoT device. In addition, the control management unit (140) receives a control message from the integrated control server (300) to increase the brightness by 20 every 5 minutes until the brightness reaches 100, and transmits the control message to the corresponding IoT device.

The risk detection unit (150) detects and blocks risk factors during the process in which 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 connection, stored in a database (160), and constantly detects network packets between IoT devices communicating with the IoT gateway (100). Except for the case in which a new IoT device is newly registered with the IoT gateway (100) and corresponds to the initial registration, the unit can block packets sent by IoT devices that are not registered in the whitelist, and if the initial registration is normally performed, the IoT device can be additionally registered in the whitelist. The whitelist may be IoT device information or may be managed separately.

In addition, 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 if data received from an IoT device is not included within a normal range by utilizing the stored rule set information, it determines that a security risk has occurred, and in this case, it blocks communication with the IoT device and transmits a message to the integrated control server (300) informing of the risk information of the IoT device that has occurred and the fact that it has been blocked as a result.

Here, the ruleset information that can be used for risk detection can include various methods used for risk detection on a network, and as an example, cases where data having the same device identification number but with changed information such as the type of the device is received, or cases where a value that is out of the range of a specific resource of a generated virtual resource model object is transmitted (for example, in the example of FIG. 7, when the value corresponding to the resource /dimming exceeds 100 or is a negative number, etc.) can be included in the ruleset information that can be used for risk detection, but is not necessarily limited thereto, and can include various methods used for risk detection on a network that are known.

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 temporarily or permanently creates. Examples thereof may include, but are not limited to, IoT device information, a rule set used to determine the type of IoT device and the use of a protocol, and a whitelist and rule set used by a risk detection unit.

FIG. 6 is a flowchart illustrating interconnection between IoT devices by an IoT gateway according to one embodiment of the present invention.

Referring to FIG. 6, when an IoT device (200) transmits a message, an IoT gateway (100) receives it (S100), verifies and interprets a bound communication protocol, and extracts a payload therefrom (S200). Here, the communication protocol may be any one of various protocols such as MQTT, HTTP, RS-485, CoAP, and WebSocket via a wireless or wired serial method, and in step (S200), the IoT gateway (100) can verify which communication protocol is bound by comparing the header from the received information with information about the specifications of each protocol, and extract a payload therefrom.

In step (S300), the IoT gateway (100) checks the IoT device type and the protocol used by comparing the extracted payload with the IoT device information stored in the database (160). If the matching data is in the IoT device information but there is no virtual object created yet (S400), the IoT gateway (100) creates a virtual resource model object based on the OCF framework and converts the received payload into an OCF-based protocol (S500). If there is a created virtual object, only the protocol conversion of the received payload is performed without creating a separate virtual object (S500).

Meanwhile, if there is no matching data in the IoT device information at step (S300), it is determined as an IoT device being registered for the first time, and various information such as a unique identifier of the IoT device, such as MAC (media Access Control) information or UUID (Universally Unique Identifier), manufacturer information, service port information used, model name, etc. are obtained from the extracted payload, and the type of the IoT device and the protocol used are determined (S600) based on the ruleset that the IoT gateway (100) has learned and stored. At least some of the information obtained and determined at step (S600) can be reflected in the ruleset and used for learning based on the machine learning method, and based on the type of the IoT device and the protocol used determined at step (S600), it is possible to move to step (S400) to perform a virtual object creation (S600) and an OCF-based protocol conversion of the payload (S500).

Next, the IoT gateway (100) generates a device ID so that it can match information about a linked IoT device (200) when a new virtual object is created, and adds it to the IoT device information stored in the database (160) (S700). Meanwhile, the IoT gateway (100) maps information converted into an OCF-based protocol to the created virtual object to which an ID has been assigned (S800). In the virtual resource model object based on the OCF framework created through this, all necessary information, such as status information, is mapped and stored regardless of the protocol used according to the type of the linked IoT device (200), and messages can be transmitted to the integrated control server (300) not shown in FIG. 6 through a protocol that supports the OCF standard.

Meanwhile, when a control message for a specific IoT device (200) is transmitted from an integrated control server (300) not shown in FIG. 6 to an IoT gateway (100), the IoT gateway (100) extracts a payload from the control message (S900). Here, since both the integrated control server (300) and the IoT gateway (100) support the OCF standard, the control message is transmitted using CoAIP, which is a communication protocol supported by the OCF standard. Next, the IoT gateway (100) compares the information obtainable from the payload with the IoT device information stored in the database (160), identifies the specific IoT device (200) to which the control message is to be transmitted, and converts the control message to match the protocol used by the specific IoT device (200) (S1000). Thereafter, the converted control message is bound to a communication protocol used by a specific IoT device (200) and then transmitted to the specific IoT device (200) (S1100), and the specific IoT device (200) performs the requested control content based on the received control message.

As described above, those skilled in the art will understand that various modifications and variations can be made based on the description of this specification. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the claims described below but also by equivalents of the claims.

100: IoT Gateway 110: Protocol Conversion Unit
111: Communication protocol processing module 112: Protocol conversion module
113: Virtual model object creation module 114: Device information transfer module
120: Device Management Unit 121: Device Creation Module
122: Device packet information collection module 123: Device management module
130: Device Analysis Machine Learning Department 140: Control Management Department
141: Control Transformation Module 142: Control Receiving Module
143: Control transmission module 150: Hazard detection unit
160: Database 200: IoT Device
300: Integrated Control Server

Claims (5)

A method of communicating with an IoT device by an Internet of Things (IoT) gateway,
A step of extracting a payload from a message received from a first IoT device;
A step of comparing the extracted payload with IoT device information stored in a database to confirm the type and protocol used by the first IoT device;
A step of creating a virtual resource model object based on the OCF framework for the first IoT device and generating a device identification number (ID) for the first IoT device;
A step of converting the above payload into information according to an OCF-based protocol and mapping the converted information to the virtual resource model object; and
A step of detecting a risk factor of a first IoT device; comprising:
In the step of confirming the type of the first IoT device and the protocol used, if the type of the first IoT device and the protocol used cannot be confirmed by comparison with the pre-stored IoT device information, predetermined information is acquired from the received message, and the type of the first IoT device and the protocol used are determined based on the acquired information and the first ruleset that has been learned and stored in advance.
A method for communicating between an IoT gateway and an IoT device, characterized in that in the step of detecting a risk factor of the first IoT device, if the converted information includes a value outside the range allowed for each resource of the virtual resource object model based on a second rule set that has been learned and stored in advance, it is determined that there is a risk factor in the first IoT device. In paragraph 1,
A method for communication between an IoT gateway and an IoT device, characterized in that the acquired predetermined information includes at least one of identification information of the first IoT device, MAC (Media Access Control) information or UUID (Universally Unique Identifier), manufacturer information, information on the service port used, and a model name. In the second paragraph,
A method for communication between an IoT gateway and an IoT device, characterized in that the first ruleset is configured to determine the device type and protocol of the given device as the type and protocol of the first IoT device if the similarity between the model name of the first IoT device and the model name of a given device among the IoT device information pre-stored in the database exceeds a preset value. In paragraph 1,
A method for communicating between an IoT gateway and an IoT device, characterized in that the method further includes a step of: blocking communication with the first IoT device and transmitting a message notifying the integrated control server of risk information about the first IoT device and the fact that communication has been blocked, if it is determined that there is a risk factor in the first IoT device in the step of detecting a risk factor in the first IoT device. In paragraph 1,
A method for communication between an IoT gateway and an IoT device, characterized in that the IoT gateway includes a device analysis machine learning unit (130) that learns the first ruleset.

Images