KR102098156B1 - Remote ble mesh network system and method for configuring the same - Google Patents

Abstract

The present disclosure provides a remote BLE mesh network system comprising: a BLE mesh network configured of a plurality of nodes; a cloud server performing registration of the nodes for the BLE mesh network, correlation setting between the plurality of nodes, and monitoring management for the BLE mesh network; and a BLE mesh gateway configuring hardware connection of the BLE mesh network and performing protocol conversion between data transmission and reception through an Internet network between the BLE mesh network and the cloud server, and a method for configuring the same. According to the present disclosure, spatiotemporal constraints in the configuration and utilization of the BLE mesh network can be overcome.

Description

REMOTE BLE MESH NETWORK SYSTEM AND METHOD FOR CONFIGURING THE SAME

The present disclosure relates to a low power Bluetooth (BLE) mesh network system and a method of configuring a BLE mesh network system.

Bluetooth (Bluetooth) is a short-range wireless technology that can send and receive data by wirelessly connecting various devices at a short distance. When performing wireless communication between two devices using Bluetooth communication, a user performs a procedure of discovering and discovering Bluetooth devices to be communicated. In the present disclosure, a device may mean an apparatus and an apparatus.

Among Bluetooth communication methods, low-power Bluetooth (Bluetooth Low Energy, BLE) has been applied since Bluetooth 4.0, and it can stably provide hundreds of kilobytes (KB) of information by consuming less power. Low-power Bluetooth technology uses Attribute Protocol to exchange information between devices. The BLE method can reduce energy consumption by reducing header overhead and simplifying operation.

In general, Bluetooth technology has been a one-to-one connection between devices and devices, but with the advent of Bluetooth mesh networks, it has developed into a technology that can connect multiple devices. The IoT devices may be connected using the BLE mesh network, and the IoT devices connected to the BLE mesh network may be controlled using at least one control device.

The BLE mesh system can realize a wireless sensor network for a long time with only a small capacity battery in a short-range wireless communication, and at the same time, can solve a limitation of a relative distance. However, as multiple BLE nodes are used, complexity can be increased in registering multiple nodes, configuring correlations, and managing them. The app / web-based terminal device of also needs to configure one node, and it requires cumbersome work to add software operation and upgrade for each case.

Against this background, the purpose of the present disclosure is to integrate a cloud-based remote network and a local BLE mesh network, and to perform software software such as registration, correlation setting, and monitoring management for devices. The operation is performed by a remote cloud server, and the local hardware wireless communication network is to provide a remote BLE mesh network system and a configuration method thereof that can be implemented with a BLE mesh gateway and a number of BLE mesh nodes linked thereto.

In order to achieve the above object, in one aspect, the present disclosure is a low-power Bluetooth Low Energy (BLE) mesh network composed of a plurality of nodes, registration of a node for a BLE mesh network, and establishment of correlation between the plurality of nodes. And a BLE mesh gateway that configures the hardware connection of the cloud server and the BLE mesh network that performs monitoring management for the BLE mesh network, and performs protocol conversion between data transmission and reception through the Internet network between the BLE mesh network and the cloud server. It provides a remote BLE mesh network system comprising a.

In another aspect, the present disclosure transmits node information for an unconfigured device to be added to a BLE mesh network composed of a plurality of nodes to a cloud server through a BLE mesh gateway, and registers information for the unconfigured device from the cloud server. It provides a method of configuring a remote BLE mesh network system comprising the step of receiving and engaging the unconfigured device in the BLE mesh network based on the received registration information.

As described above, according to the present disclosure, software operations such as registration of devices, correlation setting, and monitoring management are performed in a remote cloud server, and a local hardware wireless communication network is a BLE mesh gateway and the same. By implementing a number of interlocked BLE mesh nodes, space-time restrictions can be resolved by adding remote management for the configuration and utilization of the BLE mesh network.

In addition, according to the present disclosure, stability of a BLE mesh network may be improved using a software development kit (SDK) and an application programming interface (API) applied to the BLE mesh gateway and the proxy node.

In addition, according to the present disclosure, by managing the entire software for registering, correlating, monitoring, and managing a plurality of nodes for configuring a BLE mesh network in a cloud server, the degree of freedom in configuring and utilizing the BLE mesh network is improved. I can do it.

In addition, according to the present disclosure, it is possible to improve the stability of the BLE mesh network by simplifying the nodes constituting the BLE mesh network to include only hardware and communication protocol exchange software for configuring the wireless network.

In addition, according to the present disclosure, the BLE mesh gateway is provided with only BLE mesh network protocol communication and Internet network SDK protocol conversion software, so that frequent upgrades required for user application, node registration, correlation setting, and the like can be omitted.

In addition, according to the present disclosure, by performing all application management such as node registration, correlation setting, and monitoring management in the cloud server, user and administrator functions may be improved, and software and BLE mesh network configuration or management may be easy.

1 is a diagram showing an example of a topology of a BLE mesh network.
2 is a view for explaining a remote BLE mesh network system according to the present disclosure.
3 is a view for explaining the operation of the registration engine of the cloud server according to the present disclosure.
4 is a view for explaining the operation of the setting engine of the cloud server according to the present disclosure.
5 is a flowchart of a method of configuring a remote BLE mesh network system according to the present disclosure.
6 to 8 are flowcharts of a method of operating a remote BLE mesh network system according to the present disclosure.

Hereinafter, some embodiments of the present disclosure will be described in detail through exemplary drawings. In adding reference numerals to the components of each drawing, the same components may have the same reference numerals as possible even though they are displayed on different drawings. In addition, in describing the present disclosure, when it is determined that a detailed description of a related known configuration or function may obscure the subject matter of the present disclosure, the detailed description may be omitted.

In addition, in describing the components of the present disclosure, terms such as first, second, A, B, (a), and (b) may be used. These terms are only for distinguishing the component from other components, and the nature, order, or order of the component is not limited by the term. When a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected to or connected to the other component, but another component between each component It should be understood that elements may be "connected", "coupled" or "connected".

Unless otherwise defined, all terms (including technical and scientific terms) used in the present disclosure may be used as meanings commonly understood by those skilled in the art to which the embodiments of the present disclosure pertain. . In addition, terms defined in the commonly used dictionary are not ideally or excessively interpreted unless specifically defined. In addition, terms to be described later are terms defined in consideration of functions in the embodiments of the present disclosure, which may vary according to a user's or operator's intention or practice. Therefore, the definition should be made based on the contents throughout the present disclosure.

Hereinafter, a remote BLE mesh network system and a configuration method thereof according to embodiments of the present disclosure will be described with reference to the accompanying drawings.

1 is a diagram showing an example of a topology of a BLE mesh network.

Low-power Bluetooth (Bluetooth Low Energy; BLE, hereinafter referred to as BLE)) In the mesh network 1, each node performs Bluetooth communication using BLE technology. Compared to Bluetooth BR / EDR (Basic Rate / Enhanced Data Rate) technology, BLE technology has a relatively small duty cycle and is capable of low-cost production, and can significantly reduce power consumption through low-speed data rates. BLE technology simplifies the connection process between devices, and the packet size is also designed smaller than that of Bluetooth BR / EDR technology.

Each node constituting a BLE mesh network is provided with data to each other and, when receiving a data request, can provide data through a response. In order to exchange data, each node transmits and receives a notification message, an indication message, and a confirmation message corresponding to the indication message. In this disclosure, 'node' is used to refer to devices constituting a mesh network, and nodes and devices may be used interchangeably.

As illustrated in FIG. 1, the BLE mesh network is a network in which a plurality of devices are connected like a network through Bluetooth to transmit and receive data. Provisioning, which is a process for joining a new device to a BLE mesh network, is generally performed through an application installed on a device such as a smartphone or tablet corresponding to the proxy node 2. A device used to perform provisioning corresponds to a provisioner.

A new device targeted for participation in a BLE mesh network is called a non-configuration device. The provisioning process starts with a beaconing step indicating that provisioning is possible using an advertising packet in an unconfigured device. Thereafter, an invitation step in which the provisioner sends a provisioning invitation to the non-configuration device, a public key exchange step in which the provisioner and the non-configuration device exchange public keys with each other, and an authentication step in which the provisioner and the non-configuration device authenticate each other. And distributing provisioning information.

Nodes constituting the BLE mesh network can transmit and receive messages through the mesh network. In addition, each node may perform only a function of transmitting and receiving a message, or may further support at least one of four functions: an additional function of proxy, relay, friend, or low power.

In the case of the proxy node 2, a Generic Attribute Profile (GATT) interface is provided so that a BLE device without a Bluetooth mesh stack can communicate with the mesh network. In the case of the relay node 3, the received message is retransmitted so that the message can traverse the entire mesh network. In the case of the low-power node 4, the main purpose is to transmit a message to a device having limited power, but it is a node that occasionally needs to receive a message. In this case, the friend node 5 is a node having a friendship relationship with the low power node 4, and stores the message transmitted to the low power node 4, and transmits the stored message according to the request of the low power node 4 .

In a BLE mesh network, a source device that transmits data and a destination device that receives data may be referred to as an edge node. Relay nodes relay messages between edge nodes.

Each node contains a message cache of recently received messages. If the received message already exists in the message cache, the message is not relayed. If the received message does not exist in the message cache, the message is relayed and stored in the message cache.

The edge node is generally powered by a battery, and normally sleeps and then wakes up either interactively or periodically. An edge node is a message whose message does not exist in the message cache, the message is authenticated by a known network key, and the destination of the message is the unicast address of the edge node, or the broadcast address or group address is the address where the edge node belongs to. If the condition is satisfied, the received message can be processed.

The relay node is a device that is generally supplied with main power, and is always awake, and can transmit received data for other nodes. In the relay node, the message does not exist in the message cache, the message is authenticated by a known network key, and a field indicating whether the message is relayed (for example, the number of relays) is a value that allows relay, and the destination address is relay. If the condition that is not the unicast address assigned to the node is satisfied, the received message can be retransmitted to another node.

The data transmission method in the BLE mesh network can be divided into a floating method and a routing method according to data transmission methods of relay nodes. In the routing method, the source device transmits a message to a specific relay node, and the specific relay node receiving it transmits the message with information of another relay node or destination device to retransmit the message.

The routing method uses a broadcasting channel or a point-to-point connection method for receiving and retransmitting a message. In the routing method, the routing device receiving the message determines the best routing route for transmitting the message to the intermediate device or the destination device, and determines to which route the message is transmitted based on the determined routing table.

Since the messages in the routing method must be transmitted while maintaining the routing tables, complexity increases as the message increases, requires a lot of memory, is less dynamic than the floating method, and is more difficult to implement, but is more scalable.

The floating method refers to a method in which relay nodes that receive a message shoot back in the air by using a characteristic in which radio waves spread in all directions in the air. That is, the source device transmits a message to the relay nodes through broadcast channels, and the relay nodes that receive the message transmit the message back to neighboring relay nodes and transmit the message to the destination device.

In the floating method, a broadcasting channel is used for receiving and retransmitting the message, and the transmission range of the message can be extended. The mesh network of the floating scheme is a dynamic network, and in a floating mesh network, a device may be able to receive and transmit a message as long as the density of the device is satisfied at any time. The floating method is easy to implement, but the scalability problem may occur as the network expands because messages are transmitted without direction.

That is, in the floating mesh network, when a device transmits a message, a plurality of devices receive a message, and the received message is transmitted to another plurality of devices again. Unlike the routing method, the floating method can easily deliver a message without the cost of constructing a routing table, but increases the network traffic due to the characteristic that all relay devices that have received the message retransmit the received message. To prevent this, the number of devices constituting the mesh network may be appropriately adjusted, and the number of correct devices may be determined by various factors. For example, it may be determined by network capacity, traffic load of data sources, network latency, and reliability requirements.

As described above, in the existing BLE mesh network, network configuration or management is performed by each of the nodes included in the BLE mesh network, so that there may be spatial limitations due to local network management. In addition, due to limitations in flexibility of user software applications according to addition of nodes and network configuration, user self-correlation or upgrade may occur frequently. In addition, it is difficult to configure a manager for a BLE mesh network, so there may be limitations in providing user convenience. In addition, node registration, configuration, and monitoring management for BLE mesh network configuration are limited to the proxy application, and the complexity can be increased by separately installing the software in the local network when configuring or changing the system.

In order to solve these problems, hereinafter, a remote BLE mesh network system according to the present disclosure will be described with reference to related drawings.

2 is a view for explaining a remote BLE mesh network system according to the present disclosure. 3 is a view for explaining the operation of the registration engine of the cloud server according to the present disclosure. 4 is a view for explaining the operation of the setting engine of the cloud server according to the present disclosure.

Referring to FIG. 2, the remote BLE mesh network system 10 according to the present disclosure includes a low-power Bluetooth Low Energy (BLE) mesh network 100 composed of a plurality of nodes, and registration of nodes to a BLE mesh network. Configure the hardware connection of the cloud server 300 and the BLE mesh network to perform correlation management and monitoring management for the BLE mesh network between nodes of the network, and between the BLE mesh network and the cloud server, data of It includes a BLE mesh gateway 200 that performs protocol conversion during transmission and reception.

The BLE mesh network 100 may include relay nodes that relay messages, low power nodes, friend nodes, and proxy nodes. The functions of the BLE mesh network and each node may be applied in substantially the same manner as described above in FIG. 1 in a range not contrary to the contents of the present disclosure.

In FIG. 2, one BLE mesh network is illustrated, but this is not limited thereto. According to another example, a plurality of independent BLE mesh networks based on the BLE mesh gateway 200 may be configured and managed in the cloud server 300, respectively.

According to an example, a plurality of nodes in the BLE mesh network 100 may be implemented to include only a module for configuring a hardware communication network of the BLE mesh network 100. That is, the plurality of nodes includes only a module for performing protocol communication for transmitting or receiving data in the BLE mesh network 100, and user application software according to a correlation between the plurality of nodes may not be mounted. have. In this case, user application software for setting or managing correlation between a plurality of nodes may be provided in the remote cloud server 300.

The BLE mesh gateway 200 may include a module for configuring a hardware mesh network of the BLE mesh network 100. The BLE mesh gateway 200 may communicate data protocol packets for data transmission / reception with nodes in the BLE mesh network 100 and network configuration of the BLE mesh network 100 in both directions or in one direction. The BLE mesh gateway 200 may include a wireless communication device for communicating with nodes on the BLE mesh network 100.

In addition, the BLE mesh gateway 200 may include a wired / wireless communication device such as Ethernet or Wi-Fi to perform communication through the remote cloud server 300 and an Internet network. The BLE mesh gateway 200 may receive data from the remote cloud server 300 and transmit it to a plurality of nodes in the BLE mesh network 100. The BLE mesh gateway 200 may perform protocol conversion when transmitting and receiving data between the BLE mesh network 100 and the cloud server 300 according to a preset software development kit (SDK).

When the BLE mesh gateway 200 receives a data packet from the BLE mesh network 100, it may perform protocol conversion on the Internet network to transmit data to the cloud server 300. In addition, when receiving a data packet from the cloud server 300, the BLE mesh gateway 200 may perform protocol conversion on the BLE mesh network and transmit data to a node in the BLE mesh network 100. That is, the BLE mesh gateway 200 may not include a software application function such as registration or setting of a separate node in addition to a communication interface with the cloud server 300 through protocol conversion of data packets.

The cloud server 300 may register a node for the BLE mesh network 100, set correlation between a plurality of nodes, and monitor and manage the BLE mesh network 100. To this end, the cloud server 300 may include an SDK interface that receives node information from the BLE mesh network 100 and node registration from the BLE mesh gateway 200. In addition, the cloud server 300 may include an SDK interface for exchanging data with the BLE mesh gateway 200 for configuring and setting correlation between nodes. In addition, the cloud server 300 may include a software application programming interface (API) for monitoring management (dashboard) of the proxy node 150, which is a cloud server 300 or an external device operated by a user.

That is, the cloud server 300 may be provided with application software such as node registration and correlation setting for configuring the BLE mesh network 100 in software. Accordingly, each node of the BLE mesh network may not have software for node registration or correlation setting, thereby reducing complexity, and additionally securing reliability by management through the cloud server 300. In addition, a professional administrator can manage the BLE mesh network through the cloud server 300, and convenience can be improved in adding nodes to the BLE mesh network or configuring a network. In addition, by management through the cloud server 300, it is possible to reduce the frequency of occurrence of independent upgrades of user applications.

The plurality of nodes constituting the BLE mesh network 100 may include at least one proxy node 150. According to an example, the proxy node 150 may be a user-operable smartphone or tablet. The proxy node 150 may transmit and receive data according to the BLE mesh protocol with other nodes within the BLE mesh network 100. In addition, the proxy node 150 may transmit and receive data through the client server 300 and the API. That is, the proxy node 150 may include a software application that enables at least one of remote access through an API of the cloud server 300 and local access through a local BLE mesh network.

The user can participate in the remote network and the local BLE MESH network with the cloud server 300 through the proxy node 150, so that monitoring and management of the BLE MESH network network can be performed without time and space restrictions. In addition, even in the event of an abnormality in the remote network, since it can be managed in the local network through the proxy node 150, stability of the network system can be additionally secured.

According to an example, in order to add an unconfigured device that is not included in the BLE mesh network 100 as a new node, the BLE mesh gateway 200 may receive node information from the unconfigured device. The node information may include identification information of an unconfigured device, such as a universally unique identifier (UUID). The BLE mesh gateway 200 may convert the node information for the unconfigured device into a protocol server according to a preset SDK and transmit it to the cloud server 300.

The cloud server 300 may register the unconfigured device in association with the BLE mesh network based on the received node information, and transmit the registration information to the BLE mesh gateway 200. That is, provisioning, which is an additional function of a new node, which was previously performed by a provisioner such as a proxy node, may be performed by the cloud server 300. According to an example, the provisioning process between the above-described proxy node and the unconfigured device may be performed substantially the same between the cloud server 300 and the unconfigured device through the relay of the BLE mesh gateway 200.

When the unconfigured device is registered by the cloud server 300, and registration information is received, the BLE mesh gateway 200 may participate in the registered unconfigured device in the BLE mesh network 100. The hardware network configuration of the new node with the BLE mesh network follows a known Bluetooth technology, and a detailed description thereof will be omitted. Through this, the unconfigured device may be configured as one node of the BLE mesh network in hardware.

According to an example, the cloud server 300 is configured to set a correlation between a plurality of nodes and a registration engine that registers and cancels a node for the BLE mesh network 100 through a preset SDK. The engine may include a setting engine and an application programming interface (API) for monitoring and managing a plurality of nodes. Also, according to an example, the cloud server 300 may additionally include an engine for collecting, storing, and analyzing separate data.

The registration engine of the cloud server 300 performs provisioning for a plurality of nodes included in the BLE mesh network, and information related to description, monitoring, and control for each node. You can register or cancel. The registration engine can be operated by the SDK of the registration / revocation protocol packet of the preset device. In addition, the SDK may include additional engines for device identification and security.

Referring to FIG. 3, a registration information table for a plurality of nodes included in a BLE mesh network managed by a registration engine is shown. For example, in the case of node 1, the description is set to a switch, and it is set to control on / off operation of the switch by monitoring on / off of the switch. In the case of node N-1, the descreen is set to temperature, and is set to monitor the sensing value of the temperature sensor. As such, information on each of a plurality of nodes included in the BLE mesh network may be registered in the registration engine.

In addition, when an administrator input for releasing a specific node from the BLE mesh network is received, the registration engine may delete information corresponding to the corresponding node from the stored information table. When the registration engine transmits termination information related to this to the BLE mesh gateway 200, the BLE mesh gateway can remove the corresponding node from the BLE mesh network in hardware. As described above, the remote BLE mesh network system according to the present disclosure may be designed in a structure in which addition of a new node to a BLE mesh network or removal of an existing node can be easily performed.

The setting engine of the cloud server 300 may be configured to define a correlation between all nodes registered in the local BLE mesh network 100 in connection with the registration engine. The correlation may be preset to communicate with the BLE mesh gateway 200 through the SDK, or communicate with the proxy node 150 through the API, and to feedback the result corresponding to the event corresponding to the condition. According to an example, the corresponding SDK and API may be interlocked with an additional engine for device identification and security.

The configuration engine can receive all node information of a specific BLE mesh network registered in the registration engine, and based on the information, users and administrators can define correlations. The correlation can be preset as a condition and a result. The condition may be singular or multiple nodes, and may define a state in which each node can occur. The result may also be a singular or a plurality of nodes, and may be set as an action that each node should take when a condition condition occurs.

According to an example, the correlation configuration generated by the setting engine may be implemented in a table format as shown in FIG. 4, but is not limited thereto. According to another example, the correlation configuration generated by the setting engine may be implemented in a graphic format. The preset correlation may be the basis of the event-based operation application of the BLE mesh network, and actual network operation may be performed through the SDK and API.

4, a configuration information table for a plurality of nodes included in a BLE mesh network managed by a configuration engine is illustrated. For example, in the case of situation A, the condition is set to the ON state of node 1, and the result is set to the ON operation of node 2. For example, situation A may be a situation in which when the state of the light switch that is the first node is turned on, the computer that is the second node of the room where the light switch is located is turned on.

Similarly, in the case of situation Z, the condition is set to a state in which the detection value at node 8 is greater than 50, and the result is set to the on operation of node 6 and the off operation of node 13. That is, when the condition that the state of the node 1 is on is satisfied, the node 2 is also set to operate in the on state. As described above, a predetermined correlation may be stored in each of the plurality of nodes included in the BLE mesh network in the setting engine.

The setting engine receives the operation status when a specific event of the nodes occurs (SDK or API), and an API for displaying it as a dashboard, and an API that delivers results based on the event conditions, and a state change according to the result And an API for receiving (SDK or API) and displaying it on a dashboard.

Event conditions of the conditions and results of the setting engine may be output through an API for monitoring and managing a plurality of nodes. Further, the event status of the conditions and results may be transmitted to a web / app or other user manipulation / display device through an API. Through this, an administrator of the cloud server 300 or a user of the proxy node 150 can monitor and manage the operation of a plurality of nodes in the BLE mesh network.

According to this, software operations such as registration, correlation setting, and monitoring management of devices are performed on a remote cloud server, and a local hardware wireless communication network is configured with a BLE mesh gateway and a number of BLE mesh nodes linked thereto. By implementing, it is possible to solve the spatio-temporal limitations by adding remote management for the configuration and utilization of the BLE mesh network.

In addition, it is possible to improve the stability of the BLE mesh network by using a software development kit (SDK) and an application programming interface (API) applied to the BLE mesh gateway and the proxy node. In addition, by managing the software for registering, correlating, and monitoring multiple nodes for configuring a BLE mesh network in a cloud server, freedom in configuring and utilizing the BLE mesh network can be improved. In addition, it is possible to improve the stability of the BLE mesh network by simplifying the nodes constituting the BLE mesh network to have only hardware and communication protocol exchange software for configuring the wireless network.

In addition, by providing only BLE mesh network protocol communication and Internet network SDK protocol conversion software in the BLE mesh gateway, frequent upgrades required for user application, node registration, correlation setting, etc. can be omitted. In addition, by performing all application management such as node registration, correlation setting, and monitoring management in the cloud server, user and administrator functions can be improved, and software and BLE mesh network configuration or management can be facilitated.

5 is a flowchart of a method of configuring a remote BLE mesh network system according to the present disclosure.

The configuration method of the remote BLE mesh network system according to the present disclosure may be implemented in the remote BLE mesh network system 10 described with reference to FIG. 2. Hereinafter, a configuration method of a remote BLE mesh network system according to the present disclosure and an operation of the remote BLE mesh network system 10 for implementing the same will be described in detail with reference to necessary drawings.

Referring to FIG. 5, node information for an unconfigured device to be added to a BLE mesh network composed of a plurality of nodes may be transmitted to a cloud server through a BLE mesh gateway [S100].

In order to add an unconfigured device not included in the BLE mesh network as a new node, the BLE mesh gateway may receive node information from the unconfigured device. The node information may include identification information of an unconfigured device such as a UUID. The BLE mesh gateway can convert the node information for the unconfigured device according to a preset SDK and transmit it to the cloud server.

Referring again to FIG. 5, it is possible to receive registration information for an unconfigured device from a cloud server [S110].

The cloud server may register the unconfigured device in association with the BLE mesh network based on the received node information, and transmit the registration information to the BLE mesh gateway. That is, provisioning, which is an additional function of a new node, which was conventionally performed by a provisioner such as a proxy node, can be performed in a cloud server. The BLE mesh gateway can receive registration information for the registered node from the cloud server.

Referring again to FIG. 5, it is possible to engage a non-configuration device in the BLE mesh network based on the received registration information [S120].

When the unconfigured device is registered by the cloud server, and the registration information is received, the BLE mesh gateway can participate in the registered unconfigured device in the BLE mesh network. Through this, the unconfigured device may be configured as one node of the BLE mesh network in hardware. Through this process, the addition and expansion of nodes to the BLE mesh network can be performed.

Hereinafter, a method of operating a BLE mesh network composed of a plurality of nodes will be described in detail with reference to related drawings.

6 to 8 are flowcharts of a method of operating a remote BLE mesh network system according to the present disclosure.

6 is a flowchart for adding a new node to a BLE mesh network and excluding a termination node. The non-configuration device not included in the BLE mesh network may transmit node information including identification information to the BLE mesh gateway (S200). The BLE mesh gateway may convert the node information for the unconfigured device into a protocol server according to a preset SDK and transmit it to the cloud server (S210).

The cloud server may register the unconfigured device in association with the BLE mesh network based on the received node information (S220), and transmit the registration information to the BLE mesh gateway (S230). When the registration information is received, the BLE mesh gateway may convert the registration information into a non-configuration device and transmit the protocol (S240). Based on the registration information, the non-configuration device may participate in the BLE mesh network (S250). Through this, the unconfigured device may be configured as one node of the BLE mesh network in hardware.

In addition, when an administrator input for releasing a specific node from the BLE mesh network is received (S300), the cloud server may delete information corresponding to the corresponding node from the stored information table. The cloud server may transmit termination information related to this to the BLE mesh gateway (S310). The BLE mesh gateway can remove the corresponding node from the BLE mesh network in hardware (S320). As described above, the remote BLE mesh network system according to the present disclosure may be designed in a structure in which addition of a new node to a BLE mesh network or removal of an existing node can be easily performed.

According to this, it is possible to improve the degree of freedom in configuring and utilizing the BLE mesh network by managing the software for registration, correlation setting, and monitoring management of multiple nodes for the configuration of the BLE mesh network in the cloud server. In addition, it is possible to improve the stability of the BLE mesh network by simplifying the nodes constituting the BLE mesh network to have only hardware and communication protocol exchange software for configuring the wireless network.

In addition, by providing only BLE mesh network protocol communication and Internet network SDK protocol conversion software in the BLE mesh gateway, frequent upgrades required for user application, node registration, correlation setting, etc. can be omitted.

7 is a flowchart for setting and managing correlation of a plurality of nodes in a BLE mesh network. The cloud server may store all the node information of the BLE mesh network, and based on this, the correlation between the plurality of nodes may be set according to the input from the administrator (S400). The correlation may be set to communicate through the BLE mesh gateway and the SDK, or through the proxy node and the API, and feedback the result corresponding to the event corresponding to the condition.

In the setting engine, correlation can be set by conditions and results. The condition may be singular or multiple nodes, and may define a state in which each node can occur. The result may also be a singular or a plurality of nodes, and may be set as an action that each node should take when a condition condition occurs.

The cloud server may transmit the set correlation information to the BLE mesh gateway (S410). The BLE mesh gateway may convert the received correlation information into a protocol according to a preset SDK and transmit it to the BLE mesh network (S420). The established correlation may be the basis of the event-based operation application of the BLE mesh network, and actual network operation may be performed through the SDK and API.

When a node that satisfies the condition of correlation occurs among nodes included in the BLE mesh network, the node may perform an operation set in the correlation where the condition is satisfied (S430). For example, when the condition that the state of the light switch, which is the first node, is turned on is satisfied, the computer, which is the second node that is set as a correlation, may be turned on.

The node performing the set operation may transmit operation information on the operation performed by the BLE mesh gateway (S440). The BLE mesh gateway may convert the received operation information into a protocol server according to a preset SDK and transmit it to the cloud server (S450). The cloud server may output the received operation information, which is an event state of conditions and results, through an API for monitoring and managing a plurality of nodes (S460). The administrator of the cloud server can monitor and manage the BLE mesh network through the output information (S470).

According to this, software operations such as registration, correlation setting, and monitoring management of devices are performed on a remote cloud server, and a local hardware wireless communication network is configured with a BLE mesh gateway and a number of BLE mesh nodes linked thereto. By implementing, it is possible to solve the spatio-temporal limitations by adding remote management for the configuration and utilization of the BLE mesh network. In addition, by performing all application management, such as node registration, correlation setting, and monitoring management, in the cloud server, it is possible to improve administrator functions, and to configure or manage software and BLE mesh networks.

8 is a flowchart illustrating an operation of a proxy node that is a user manipulation device. The proxy node may be a user-operable smartphone or tablet. The proxy node may transmit and receive data with other nodes in the BLE mesh network based on the BLE protocol (S500). Also, the proxy node may transmit and receive data through the client server and the API (S510). That is, the proxy node may include a software application that enables at least one of remote access through the cloud server's API and local access through a local BLE mesh network.

When a node that satisfies the above-described correlation condition occurs among the nodes included in the BLE mesh network, the corresponding node may perform an operation set in the correlation where the condition is satisfied (S520). The node performing the set operation may transmit operation information on the operation performed to the proxy node (S530). The proxy node may output the received operation information, which is an event state of conditions and results (S540). The user of the proxy node can monitor and manage the BLE mesh network through the output information (S550).

According to this, the user can participate in a remote network with a cloud server and a local BLE MESH network through a proxy node, so that monitoring and management of the BLE MESH network network can be performed without time and space restrictions. In addition, even when an abnormality occurs in the remote network, since it can be managed in the local network through a proxy node, stability of the network system can be additionally secured.

The present disclosure described above can be embodied as computer readable codes on a medium in which a program is recorded. The computer-readable medium includes any kind of recording device in which data readable by a computer system is stored. Examples of computer-readable media include a hard disk drive (HDD), solid state disk (SSD), silicon disk drive (SDD), ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage device. This includes, and is also implemented in the form of a carrier wave (eg, transmission over the Internet).

The above description and the accompanying drawings are merely illustrative of the technical spirit of the present disclosure, and those of ordinary skill in the art to which the present disclosure pertains combine combinations of configurations without departing from the essential characteristics of the present disclosure. , Various modifications and variations such as separation, substitution and change will be possible. Therefore, the embodiments disclosed in the present disclosure are not intended to limit the technical spirit of the present disclosure, but to explain the scope, and the scope of the technical spirit of the present disclosure is not limited by the embodiments. That is, within the scope of the present disclosure, all of the constituent elements may be selectively combined and operated. The scope of protection of the present disclosure should be interpreted by the claims below, and all technical spirits within the scope equivalent thereto should be interpreted as being included in the scope of the present disclosure.

10: Remote BLE mesh network system
100: BLE mesh network 150: proxy node
200: BLE mesh gateway 300: cloud server

Claims (13)

A low-power Bluetooth Low Energy (BLE) mesh network composed of a plurality of nodes;
A cloud server that registers a node for the BLE mesh network, sets correlation between the plurality of nodes, and monitors and manages the BLE mesh network; And
Includes; a BLE mesh gateway that configures a hardware connection of the BLE mesh network, and performs protocol conversion when transmitting and receiving data through the Internet network between the BLE mesh network and the cloud server.
The plurality of nodes includes at least one proxy node,
The proxy node transmits and receives data to and from other nodes in the BLE mesh network, and transmits and receives data through the cloud server and API through a remote BLE mesh network system. According to claim 1,
The BLE mesh gateway is a remote BLE mesh network system that performs protocol conversion when transmitting and receiving data between the BLE mesh network and the cloud server according to a preset software development kit (SDK). According to claim 2,
The BLE mesh gateway transmits information on unconfigured devices that are not included in the BLE mesh network to the cloud server, and receives registration information on the unconfigured devices from the cloud server. Remote BLE mesh network system to engage devices. delete A low-power Bluetooth Low Energy (BLE) mesh network composed of a plurality of nodes;
A cloud server that registers a node for the BLE mesh network, sets correlation between the plurality of nodes, and monitors and manages the BLE mesh network; And
Includes; a BLE mesh gateway that configures a hardware connection of the BLE mesh network, and performs protocol conversion when transmitting and receiving data through the Internet network between the BLE mesh network and the cloud server.
The cloud server monitors and manages a plurality of nodes, including a registration engine that registers and terminates nodes for the BLE mesh network, a setting engine that sets correlations between the plurality of nodes, and a plurality of nodes. It includes an application programming interface (API), and transmits and receives data to and from the BLE mesh gateway according to a preset SDK,
The registration engine is a remote BLE mesh network system that performs provisioning for a plurality of nodes included in the BLE mesh network and manages information related to description, monitoring, and control. The method of claim 5,
The setting engine is a remote BLE mesh network system that establishes a correlation between a plurality of nodes included in the BLE mesh network in association with the registration engine. The method of claim 6,
The correlation is a remote BLE mesh network system that is set as a condition for at least one node among the plurality of nodes and an operation of each node when the condition is satisfied. delete In the method of configuring a BLE mesh network system,
Transmitting node information for an unconfigured device to be added to a BLE mesh network composed of a plurality of nodes to a cloud server through a BLE mesh gateway;
Receiving registration information for the unconfigured device from the cloud server;
Joining the unconfigured device to the BLE mesh network based on the received registration information;
Establishing a correlation between the plurality of nodes;
Upon satisfying the condition according to the correlation, receiving operations of the satisfied nodes; And
And outputting an operation result of the received nodes. The method of claim 9,
The transmitting step is a method of configuring a remote BLE mesh network system that performs protocol conversion according to a preset SDK for the node information and transmits it to the cloud server. The method of claim 9,
The step of receiving the registration information is a method of configuring a remote BLE mesh network system that performs protocol conversion according to a preset SDK for the registration information received from the cloud server. delete The method of claim 9,
Monitoring and managing a plurality of nodes constituting the BLE mesh network in the cloud server or proxy node; Method of configuring a remote BLE mesh network system further comprising a.

Images