Method and system for device access to network and corresponding Internet of Things device

Abstract

Disclosed are a device access method, system, and corresponding Internet of Things (IoT) device. The method comprises: a device broadcasting an access request in ADV format; a node in a Bluetooth Mesh network receiving the access request, wherein the node is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack; and the node performing a startup configuration operation to connect the device to the Bluetooth Mesh network based on the access request. The present invention eliminates the need for a GATT module and directly uses broadcasting to connect IoT devices to a Bluetooth Mesh network, particularly utilizing broadcasting to implement startup configuration and subsequent control.

Description

Technical Field

[0001] The present invention relates to Internet of Things (IoT) technology, and in particular to a method and system for connecting a device to a network and corresponding IoT device. Background Art

[0002] Bluetooth technology is one of the most widely used wireless communication technologies in the world. Among them, Bluetooth Low Energy (BLE) has been widely adopted and deployed in billions of smartphones, tablets, and other smart devices (such as wearable devices) worldwide.

[0003] Bluetooth Mesh, a new Bluetooth standard based on BLE and approved in 2017, is a networking technology that enables many-to-many (m:m) device communication. Optimized for creating large-scale device networks, Bluetooth Mesh is well-suited for building automation, sensor networks, asset tracking, and other IoT solutions that require dozens, hundreds, or thousands of devices to communicate with each other.

[0004] Bluetooth Mesh networking introduces a completely new protocol stack. Because this protocol stack is built on Bluetooth Low Energy technology, existing BLE devices (such as smartphones and tablets) can access Bluetooth Mesh networks via proxy nodes. Conventional technology enables communication between Bluetooth devices and smartphones by configuring the GATT bearer layer in Bluetooth devices equipped with a Bluetooth Mesh protocol station and installing a specific app in BLE devices such as smartphones. However, this GATT-based connection increases the cost of Bluetooth devices, limiting their widespread industrial adoption.

[0005] Therefore, a method is needed to implement device access with a simpler configuration. Summary of the Invention

[0006] To address at least one of the above issues, the present invention proposes a novel device access solution that eliminates the need for a GATT module and directly uses broadcasts to connect IoT devices to a Bluetooth Mesh network, particularly enabling startup configuration and subsequent control.

[0007] According to a first aspect of the present invention, a method for device access to a network is proposed, comprising: a device broadcasting an access request in ADV format; a node in a Bluetooth Mesh network receiving the access request, wherein the node is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack; and the node performing a startup configuration operation to connect the device to the Bluetooth Mesh network based on the access request.

[0008] According to a second aspect of the present invention, a system for device access to a network is proposed, comprising a device to be accessed to a Bluetooth Mesh network and a node in the Bluetooth Mesh network, wherein the node is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack, wherein: the device is used to: broadcast an access request in ADV format; generate verification data based on locally stored secret data and send an ADV format broadcast with the verification data, the node is used to: receive the access request; and the node performs a startup configuration operation for the device to connect to the Bluetooth Mesh network based on the access request.

[0009] According to a third aspect of the present invention, a cloud access system is proposed, comprising the system as described in the second aspect, and a server, wherein the nodes in the access system communicate with the server via wireless transmission, wherein the access request includes the identity data of the device, and the node is used to: send the identity data of the device to the server; receive verification data from the device and forward it to the server, and complete the connection authentication with the device when the server passes the verification, and the server is used to: receive the identity data of the device sent by the node; search for secret data corresponding to the device based on the identity data; receive the verification data sent by the node and perform verification based on the found secret data.

[0010] According to a fourth aspect of the present invention, an Internet of Things device is proposed, comprising: a processing module for generating an access request in ADV format and an ADV format broadcast required for starting a configuration operation and the data contained therein; a communication module for sending and receiving the ADV format broadcast required for starting the configuration operation, wherein the access request and the ADV format broadcast have an agreed broadcast type.

[0011] According to a fifth aspect of the present invention, a terminal device is proposed, comprising: a Bluetooth communication module for receiving an access request in ADV format broadcast by the Internet of Things device; a processing module for performing a startup configuration operation with the Internet of Things device via ADV format broadcast based on the access request; and the Bluetooth communication module for sending control instructions to the Internet of Things device via ADV format broadcast after the Internet of Things device accesses the Bluetooth Mesh network.

[0012] According to a sixth aspect of the present invention, a method for connecting to an Internet of Things device is proposed, comprising: receiving an access request in ADV format broadcast by the Internet of Things device via a Bluetooth communication module; based on the access request, performing a startup configuration operation with the Internet of Things device via ADV format broadcast, wherein the ADV format broadcast has an agreed broadcast type and an agreed packet header composition.

[0013] Therefore, this paper proposes a solution that uses broadcasts, rather than GATT, on BLE devices to interact with Bluetooth Mesh devices, enabling network configuration and control of Bluetooth Mesh devices. This allows both devices to communicate using agreed-upon broadcast types and formats, eliminating the need for GATT modules for Bluetooth Mesh devices, especially low-cost ones, and paving the way for the large-scale deployment of Bluetooth Mesh networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of exemplary embodiments of the present disclosure with reference to the accompanying drawings, wherein like reference numerals generally represent like components in the exemplary embodiments of the present disclosure.

[0015] Figure 1A -B shows an example of device access authentication.

[0016] Figure 2 Shows the layers of the Bluetooth Mesh protocol stack.

[0017] Figure 3 A schematic flowchart of a method for a device to access a network according to an embodiment of the present invention is shown.

[0018] Figure 4 A composition example of the access system implemented by the present invention is shown.

[0019] Figure 5 An example after a device is connected is shown.

[0020] Figure 6 An example of a device network configuration process based on BLE broadcasting according to the present invention is described.

[0021] Figure 7 An example of a device control process based on BLE broadcasting according to the present invention is shown.

[0022] Figure 8 A schematic diagram showing the composition of an Internet of Things device according to an embodiment of the present invention is shown.

[0023] Figure 9 A schematic diagram showing the composition of a terminal device according to an embodiment of the present invention is shown.

[0024] Figure 10 A schematic flowchart of a method for connecting to an Internet of Things device according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0025] The preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although preferred embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. Rather, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0026] Bluetooth Mesh is a local networking specification for Bluetooth devices designated by the official Bluetooth organization. It can support multi-to-multi device transmission and specifically improves the communication capabilities of building large-scale network coverage. It is suitable for IoT solutions such as building automation and wireless sensor networks that require tens of thousands of devices to transmit in a reliable and secure environment.

[0027] Devices in a mesh network are called nodes, while devices in a non-mesh network are called unprovisioned devices. The process of converting a device into a node is called provisioning. For example, consider purchasing a new mesh-enabled Bluetooth light, bringing it home, and setting it up. To make it part of the mesh network and control it with existing Bluetooth light switches and dimmers, the light needs to be provisioned. Provisioning is a secure process in which an unprovisioned device acquires a series of cryptographic keys and is recognized by the provisioning device (usually a tablet or smartphone). One of these keys is called a network key, or NetKey for short. All nodes in a mesh network have at least one NetKey, which a device must possess in order to join the network and become a node. Securely obtaining a NetKey through the provisioning process is a fundamental first step before a node can be put into use.

[0028] When configuring a Bluetooth Low Energy (BLE) device such as a tablet or smartphone as a "node," it requires GATT to connect to unconfigured "devices." Since even simple Bluetooth devices like Bluetooth light bulbs require a GATT module, this increases the cost of these devices and hinders the large-scale deployment of Bluetooth Mesh networks. Therefore, a method is needed to connect devices to a Bluetooth Mesh network with simpler configuration.

[0029] To facilitate understanding of the principles of the present invention, the following will first provide a background description of the Bluetooth Mesh network, especially the startup configuration process for a node to join the network.

[0030] A Bluetooth Mesh network is like a VIP club. If you're a member, you have free access and enjoy the amenities and services commensurate with your membership. If you're not a member, you can't get past the gatekeeper. To become a member of a Bluetooth Mesh network, a device must go through a secure process called provisioning to join the network and ensure network security.

[0031] Security is at the core of Bluetooth Mesh networking, and the process of adding or removing devices from the network adheres to strict security requirements. According to the specification, Bluetooth Mesh networks use a system of security keys to protect the network as a whole, while also protecting and isolating individual applications within the network. Only with the correct security keys can a device become a member of the network and be authorized to participate in specific applications. All nodes in the network possess a key called the "Network Key," or "NetKey." Only devices in possession of this key can become members of the network, effectively becoming a node.

[0032] Provisioning is the process by which a device joins a mesh network and becomes a node. It involves several stages, generates various security keys, and is inherently a secure process. Provisioning can be performed using an app on a device such as a tablet. In this case, the device driving the provisioning process is called the provisioner. The device being provisioned to become a node is referred to as a "to-be-connected device" in this disclosure.

[0033] The provisioning process proceeds in five steps, including:

[0034] Step 1. Beaconing

[0035] To support various Bluetooth Mesh features (including but not limited to provisioning), new GAP broadcast types have been introduced (reference: Bluetooth Core Specification Appendix), including <<Mesh Beacon> >Broadcast type. Unconfigured devices will use the <<Mesh Beacon> >Broadcast type to indicate its availability. The user might initiate a new device broadcast in this way, for example by pressing a button combination or holding a button for a period of time.

[0036] Step 2. Invitation

[0037] In this step, the provisioning device sends an invitation to the device being provisioned in the form of a Provisioning Invite PDU (PDU: Protocol Data Unit). The Beacon device responds by replying with information about itself in a Provisioning Capabilities PDU (PDU).

[0038] Step 3. Exchanging public keys

[0039] The provisioning device and the device to be provisioned can exchange their public keys, which can be static or ephemeral, directly or out-of-band (OOB).

[0040] During this phase, the provisioner selects an appropriate authentication method based on the unprovisioned device's capabilities and notifies the unprovisioned device of the method to be used. The provisioner and unprovisioned device then create an elliptic curve public-private key pair and exchange public keys. Each device then uses its own private key and the peer's public key to calculate a symmetric key, the ECDHSecret. This key is used to verify the peer's identity.

[0041] Step 4. Authentication

[0042] During the authentication step, the device being provisioned outputs a random single-digit or multi-digit number to the user in a manner appropriate to its function. For example, it might flash an LED several times. The user enters the number output by the new device into the provisioning device, and the two devices exchange this random number cryptographically, authenticating each other.

[0043] Step 5. Distribution of provisioning data

[0044] After successful authentication, a session key is generated using the private keys of both devices and the exchanged peer public keys. This session key is then used to protect the subsequent distribution of data required to complete the provisioning process, including a security key known as the network key (NetKey). After provisioning is complete, the provisioned device possesses the network's NetKey, a mesh security parameter also known as the IV index and unicast address, assigned by the provisioning device. The device is now provisioned and connected to the network, and can now be referred to as a node.

[0045] Figure 1A -B shows an example of device access authentication. Figure 1A As shown, the IoT device 100 as a device needs to be connected to the terminal device 200 as a node. The IoT device 100 can usually be connected and communicated through short-range data transmission (for example, a few centimeters to hundreds of meters) with the terminal device 200 based on Bluetooth technology. For example, the Bluetooth weight scale 100 is connected to the smartphone 200 via the Bluetooth Low Energy protocol (BLE). The connection between the device and the node may be simply the connection between the IoT device 100 and the terminal device 200, such as the connection between the Bluetooth weight scale and the smartphone in the above example. In other embodiments, the IoT device 100 can be connected to the existing Bluetooth Mesh network via the startup configuration with the terminal device 200 as a node of the Bluetooth Mesh network. Here, since the terminal device 200 is a conventional BLE device that does not have a Bluetooth Mesh protocol stack, the device 100 and the node 200 access the Bluetooth Mesh network via PBGATT (startup configuration via the GATT bearer layer).

[0046] Similarly, if Figure 1B As shown, the IoT device 100 as a device needs to be connected to the smart device 250 as a node, which is shown as a smart speaker 250. Since the smart speaker 250 can be a device with a Bluetooth Mesh protocol stack, when the smart speaker 250 is used as a startup configuration device, it can access the Bluetooth Mesh network with the device 100 via PBADV (Startup Configuration via Broadcast Bearer Layer).

[0047] As mentioned earlier, Bluetooth Mesh networking introduces a new protocol stack, which is built on Bluetooth low energy technology. Figure 2 Shows the layers of the Bluetooth Mesh protocol stack.

[0048] On top of the existing Bluetooth Low Energy (BLE) protocol layer, the Bluetooth Mesh protocol layer also includes the bearer layer, network layer, bottom transport layer, upper transport layer, access layer, basic model layer, and model layer. Among them:

[0049] Bearer layer: The bearer layer defines how to transmit PDUs using the underlying low-power stack. Currently, two bearer layers are defined: Advertising Bearer and GATT Bearer.

[0050] Network layer: The network layer defines various message address types and network message formats. Relay and proxy behaviors are implemented through the network layer.

[0051] Lower transport layer: The lower transport layer can handle the segmentation and reassembly of PDUs when necessary.

[0052] The upper transport layer is responsible for encrypting, decrypting, and authenticating application data entering and leaving the access layer. It is also responsible for special messages called transport control messages, including heartbeats and messages related to "friendship."

[0053] Access layer: Responsible for the format of application data, defines and controls the encryption and decryption processes performed in the upper transport layer, and verifies that received data is appropriate for the correct network and application before forwarding it to the protocol stack.

[0054] Foundation models: The foundation model layer is responsible for implementing models related to Mesh network configuration and management.

[0055] Models: The model layer is concerned with the implementation of models, as well as the implementation of behaviors, messages, states, etc.

[0056] During provisioning, the provisioner communicates with the device being provisioned using a Bluetooth Mesh protocol called the Provisioning Protocol. The provisioner can use the Provisioning Protocol over either the PB-ADV or PB-GATT bearer layers, ensuring that provisioner applications can be implemented on older smartphones as long as they support Bluetooth Low Energy and GATT.

[0057] In other words, if Figure 1B As shown, both the configuration initiator ("node" 250) and the device to be configured ("device" 100) have Bluetooth Mesh protocol stacks. The two parties can then directly complete the information exchange and authentication process via GAP broadcast based on steps 1-5 above.

[0058] But if Figure 1AAs shown, the configuration device ("node" 200) and the device to be configured ("device" 100) do not both have a Bluetooth Mesh protocol stack. That is, node 200 is a BLE device without a Bluetooth protocol stack, such as a smartphone. In this case, node 200 needs to introduce GATT functionality to facilitate the configuration authentication of Bluetooth device 100, which also includes a GATT bearer layer. When using the GATT bearer layer, the Bluetooth Mesh Protocol Data Unit (PDU) needs to be encapsulated in a proxy protocol. This allows the proxy node to achieve conversion from the broadcast bearer layer to the GATT bearer layer, and vice versa.

[0059] In the prior art, in order to directly complete the startup authentication of a newly added Bluetooth device using a device that does not have the Bluetooth Mesh protocol stack (for example, using a smartphone to connect a newly purchased Bluetooth light bulb to an existing home IoT network, such as a Bluetooth Mesh network), a GATT-based connection between the phone and the device is required. Although a phone can become part of a Bluetooth Mesh network via a proxy node by installing an app with GATT bearer layer functionality, the corresponding Bluetooth device also needs to be equipped with a GATT bearer layer in order to be started and configured via the phone. However, this GATT-based connection increases the cost of Bluetooth devices, limiting their widespread industrial adoption.

[0060] To this end, this paper proposes a novel device access solution. This solution enables conventional BLE devices, such as smartphones, that lack a Bluetooth Mesh protocol stack to directly access the Bluetooth Mesh network using GAP broadcasts. Specifically, this solution fully initiates configuration and subsequent control using broadcasts, eliminating the need for GATT modules in IoT devices and further reducing device costs.

[0061] Figure 3 A schematic flowchart of a method for a device to access a network according to an embodiment of the present invention is shown.

[0062] In step S310, the device broadcasts an access request in the ADV format. Here, the "ADV" format refers to broadcasts that comply with the low-power Bluetooth protocol (BLE advertising packets). For example, the device can be as follows Figure 4 and Figure 5 The Bluetooth Mesh device 400 shown in FIG. 1 is different from the conventional Bluetooth Mesh device 100 in that the device 400 may not include a GATT bearer layer.

[0063] In step S320, a node of the Bluetooth Mesh network receives the access request, and the node is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack. For example, the node can be as follows Figure 4 and Figure 5 The BLE device 200 shown in FIG. 2 is, for example, a smartphone 200. Although the smartphone has a GATT communication function, it communicates with a device 400 that does not include a GATT bearer layer through a broadcast in a predetermined form.

[0064] In step S330, the node performs a startup configuration operation to connect the device to the Bluetooth Mesh network based on the access request. Specifically, the node and the device complete the startup configuration through subsequent interactions via ADV format broadcasts.

[0065] Based on this invention, Bluetooth Mesh devices can directly communicate with conventional BLE devices through BLE broadcast data packets to complete the startup configuration operation of accessing the Bluetooth Mesh network. As a result, Bluetooth Mesh devices can eliminate the need for GATT modules, thereby reducing device costs and facilitating large-scale promotion.

[0066] In the context of a Bluetooth Mesh network, a "node" is a device that has already joined the network, while a "device" is a device that has not yet joined the network. A "device" needs to go through the "provisioning" process described above before it can join the network and transform from a "device" to a "node."

[0067] Here, the device to be started and configured, that is, the device to be connected (for example, the Bluetooth lamp 400 waiting to be connected), is a device with a Bluetooth Mesh protocol stack, that is, including Figure 2 However, unlike conventional Bluetooth Mesh devices, the access device only includes the Advertising Bearer layer in the bearer layer, omitting the GATT bearer layer. Furthermore, it can communicate with BLE nodes that do not have the Bluetooth Mesh protocol stack through ADV format broadcasts.

[0068] Accordingly, the node used as the startup configuration device is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack. For example, in existing smart homes, a smartphone or tablet computer is often used as a control center ( Figure 4 and 5 Although it is used to control the Bluetooth Mesh network, the existing smart phone or tablet computer does not actually have a Bluetooth Mesh protocol stack, but is only a low-power Bluetooth (BLE) device, that is, it only includes Figure 2The BLE layer of the protocol layer shown. Usually, in order to carry out Bluetooth Mesh communication, it is necessary to install an APP including the GATT bearer layer in a smartphone or tablet, thereby realizing interaction with other Bluetooth devices via GATT through a proxy node and encapsulating the proxy protocol outside the ADV format data packet. In the present invention, although the node (for example, a smartphone) can also have a GATT bearer layer (for example, for communicating with other Bluetooth Mesh devices), it chooses to communicate with the device to be connected (for example, a Bluetooth light waiting to be connected) through a broadcast that complies with the BLE protocol, and is able to implement the operations of each step required to start the configuration.

[0069] In other words, unlike Figure 1A As shown, the Bluetooth Mesh network is accessed through PBGATT (startup configuration via the GATT bearer layer). The present invention uses the broadcast protocol that all BLE devices can follow, so that the Bluetooth Mesh device can still access the Bluetooth Mesh network through PBADV (startup configuration via the broadcast bearer layer) when facing a BLE node.

[0070] In one embodiment, the startup configuration operation performed in step 330 may be a network configuration operation between the node and the device at an agreed level on the Mesh network, and then the device may also perform a classic network configuration operation (as described in steps 1 to 5 above).

[0071] Because interactions between Bluetooth Mesh devices and regular BLE devices (acting as nodes) occur via ADV format broadcasts, and the published Bluetooth Low Energy protocol doesn't include a type specifically used for Bluetooth Mesh network startup configuration in BLE advertising packets, devices and nodes must agree on a specific advertising type so that both parties can receive and correctly parse that specific type of advertising packet.

[0072] When a BLE device advertises, it periodically sends packets containing the following information: preamble, access address, CRC, sender's Bluetooth address, etc. From a developer's perspective, the interesting part is usually the advertising payload, which is 0-31 bytes long. The Bluetooth stack automatically fills in the other fields in the advertising packet, but the advertising payload can be controlled by the developer.

[0073] Here, "advertisement data" can refer to a payload of 0-31 bytes that can be used by developers (in the Bluetooth Core specification, this field is called AdvData). Advertisement data contains one or more Advertisement Data (AD) elements. The format of each element is as follows:

[0074] First byte: the length of the element (excluding the length byte itself)

[0075] Bytes 2 to 3: Broadcast type – specifies what data is contained in the element

[0076] Broadcast data: can contain one or more bytes, the meaning of which is defined by the broadcast type.

[0077] In the present invention, in order to implement the startup configuration operation, it is necessary to select a broadcast type that is not prone to misunderstanding. The broadcast data of the above broadcast type can be modified by the developer, and a broadcast type with as long broadcast data as possible is preferred.

[0078] In one embodiment, for example, the ManufacturerData type can be used as the agreed broadcast type. In the Bluetooth core specification, the type number of Manufacturer Specific Data is 0xFF, and the manufacturer message can be included in the broadcast data. Since Manufacturer Specific Data can be used by developers to add arbitrary customized data to the broadcast packet and has 30 bytes of broadcast data, it can be selected as the agreed broadcast type. To this end, when a device wants to access the Mesh network, the node can start scanning, and the scan can scan for a specific type of broadcast. For example, when a smartphone (node) starts scanning, unlike scanning a PDU encapsulated based on a conventional proxy protocol (for example, via the GATT bearer layer), the node can scan the received conventional BLE broadcast and read its second and third bytes of data. If it is 0xFF, it means that this is an access request issued by the device based on the agreed type, and the node can send subsequent data accordingly.

[0079] In one embodiment, a node (e.g., Figure 4 and Figure 5 200) and devices (e.g., Figure 4 and Figure 5 In the example of the Bluetooth light bulb 400 shown in FIG, different broadcast types can be used during each step of the startup configuration interaction. For example, different broadcast types can be used during key exchange or authentication. In another embodiment, a node and a device can each use different broadcast types during each step of the startup configuration interaction. For example, a node can always use one broadcast type, while a device can always use another broadcast type.

[0080] However, it is preferred that subsequent broadcast packets exchanged between nodes and devices during the startup configuration process also have the same broadcast type as the access request, for example, the second to third bytes of data are all 0xFF. In this case, the specific operation type of each step involved in the startup configuration can be agreed upon in the broadcast data (i.e., payload) portion of the broadcast packet.

[0081] Specifically, a specific type of broadcast may include a fixed header for indicating identity, specific operation type, and packet information. The above-mentioned "fixed header" is not the header of this specific type of broadcast in the Bluetooth core protocol, but a fixed header agreed upon by the device and the node, which is located in the broadcast data (i.e., payload) of this specific type of broadcast. Before the above-mentioned "fixed header", there is also a "real" header of the Bluetooth core protocol that includes the element length and the broadcast type (e.g., 0xFF).

[0082] In the agreed fixed packet header, a certain field in a fixed order (for example, the Nth byte in the fixed packet header, or several bytes) can be assigned to a specific operation type. The specific operation type can indicate different operations in the startup configuration through different numbers. For example, number A refers to an access request, number B refers to sending network configuration information, number C refers to receiving a configuration reply confirmation (Ack), number D refers to sending a random number, etc. It should be understood that here, A, B, C, and D refer to different numbers, not the actual values of the numbers. Therefore, by reading the specific bytes of the payload of a specific type of broadcast, it is possible to confirm the meaning of the data contained in the data packet and perform corresponding operations.

[0083] In addition to the specific operation type, the agreed-upon fixed packet header should also declare the identities of the parties involved in the operation, as well as information about the packet itself. For example, the declared identity could be the identity of the device being connected, such as the manufacturer number, version number, or device identifier. Information about the packet itself could include the number of packets included in the current operation type, the current packet number, message ID, and packet length.

[0084] Following the fixed header, a payload section may also be included, used to transmit data required for specific startup configuration operations. This payload section is the portion of the broadcast data (payload) immediately following the fixed header within a specific type of broadcast. Examples include random numbers and checksums.

[0085] Because the length of each BLE advertising data packet is limited, for example, Manufacturer Specific Data has 30 bytes of advertising data, and the available advertising data also includes a fixed header for describing the situation, the length of the payload portion used to transmit the data required for specific startup configuration operations is limited. To this end, the method may also include: determining whether to perform unpacking and transmission based on the maximum length of the payload portion and the length of the data to be transmitted. To this end, the specific type of broadcast may include a packet number field for indicating the total number of packets and the current number of packets, such as the partial field included in the fixed header for referring to the information of the packet itself.

[0086] After the device to be connected completes the startup configuration operation, the device to be connected (for example, Figure 4 The Bluetooth lamp 400 shown in FIG. 4 is connected to the Bluetooth Mesh network and becomes a node in the network (for example, Figure 5 The Bluetooth light bulb 400 shown in the figure can also use ADV format broadcasts to interact with other nodes in the Bluetooth Mesh network. For example, after connecting, the connected device 400 (also referred to as a "node") can still interact with the aforementioned nodes using AD format broadcasts. For example, communication still uses broadcast packets with a specified broadcast type and specified header format. For example, after connecting to the Bluetooth Mesh network, the Bluetooth light bulb can still receive operations from the smartphone via BLE broadcasts, such as turning it on, off, and adjusting the brightness.

[0087] In addition, although the access device realizes access authentication with the BLE device through the broadcast data of the agreed type and format, after accessing the Mesh network and becoming a node, the accessed device can use the ADV format broadcast to perform regular broadcast interaction with the Bluetooth Mesh nodes in the Bluetooth Mesh network. For example, Figure 5 In this example, Bluetooth light bulb 400 interacts with smart speaker 100 using regular broadcasts in the mesh network, for example, receiving control commands from smart speaker 100. Specifically, connected devices can directly use the broadcast bearer layer in the Bluetooth Mesh protocol stack to conduct regular communications with other Bluetooth Mesh nodes. For example, the smart speaker can control connected Bluetooth devices by sending broadcast messages via its broadcast bearer layer.

[0088] In other words, after the device to be connected accesses the Bluetooth Mesh network, although it can broadcast communication with other nodes in the network, for different nodes (for example, Bluetooth Mesh device 100 and BLE device 200), the device 400 communicates with the Bluetooth Mesh device and BLE device based on different rules.

[0089] Since the device being connected is a Bluetooth Mesh device that only has an advertising bearer layer and does not have a GATT bearer layer, it can communicate with other Bluetooth Mesh devices in the Bluetooth Mesh network in a conventional manner that complies with Bluetooth Mesh rules. However, BLE devices connected to the Bluetooth Mesh network cannot communicate with it through GATT and can only communicate using the specific type of advertising data agreed upon by both parties as described above.

[0090] After a device completes network configuration and joins a Bluetooth Mesh network, it will have its own "identity," namely, a network ID. Therefore, in subsequent broadcasts, the device's network ID can be used instead of the previously used device identifier (e.g., MAC address or part thereof) as the device's identity. In other words, some fields in the agreed packet header can be replaced in subsequent broadcasts.

[0091] After describing the types and components of broadcasts, the following describes the startup configuration process in more detail.

[0092] The access request sent by the device to the node may include the device's identity data, such as the device's unique identifier (ProductKey) and device name (DeviceName). The above identity information can help the node to clearly identify the device to be accessed, and facilitate the cloud to query the corresponding information when authentication of cloud operations is involved. In other embodiments, the above identity information can also be included in subsequent requests of the access request. For example, the device can indicate the access intention and device type in the access request, and then send the identity information via broadcast after a node responds.

[0093] After receiving the identity data, the node can complete the startup configuration of the device to access the Bluetooth Mesh network based on the identity data.

[0094] Authentication of the device's connection to the node may be achieved solely through an authentication process between the device and the node, or may involve the participation of a cloud-based authentication platform. In the cloud-based authentication process, the node's authentication of the device's connection to the node based on the access request may include: the node interacting with a server via wireless transmission based on the identity data, thereby completing authentication of the device's connection to the node.

[0095] Specifically, the node authenticates the connection of the device to the node based on the access request, including: the node sends the identity data of the device to the server; the device generates verification data based on the secret data stored locally, and sends the verification data to the node; the node forwards the verification data to the server; the server searches for the secret data corresponding to the device based on the identity data, and verifies the verification data based on the secret data; and the node completes the authentication of the connection of the device to the node based on the success of the verification.

[0096] Specifically, the node can send the device's identity data to the server. As mentioned above, the above identity data can be sent together with the device's access request or via subsequent information transmission. Based on predetermined rules or instructions from the node, the device can generate verification data based on the secret data stored locally and send the verification data to the node. The node can then forward the verification data to the server. The server can search for the secret data corresponding to the device based on the previously obtained device's identity data and verify the verification data based on the secret data. If the verification is successful, the server will issue a notification. Subsequently, based on the successful verification, the node can complete the authentication of the device connection node.

[0097] Thus, by introducing secret data known only to the IoT device and the cloud platform, it is possible to achieve high-security authentication of the IoT device identity by the cloud platform, and avoid the nodes from knowing the secret data. In order to ensure security, it is possible to avoid the secret data from being transmitted in plain text or in a derivable form over the air. Therefore, in one embodiment, the verification data generated based on the secret data can be generated in a way that the complete secret data cannot be deduced. Even if the node knows the verification data, or the verification data is intercepted by another party, the complete secret data cannot be recovered from it. Similarly, the following communication key generated based on the secret data can also be generated in a way that the complete secret data cannot be deduced.

[0098] To accurately indicate its own identity and ensure that the server can correctly retrieve secret data, the data packets broadcast by the device can include the device's unique identifier, and the device identity data sent by the node to the server can include the unique identifier obtained from the access request or subsequent transmission information. For example, in different implementations, the device can enter the product identifier (ProductID, PID) or the MAC address, or both the PID and MAC, in the access request or subsequent transmission information. Preferably, the cloud maintains the identity and secret data of the IoT device and burns the data into the device before it leaves the factory. In one embodiment, the cloud can assign a triplet to each IoT device, which includes the PID, MAC address, and secret data. This triplet is pre-burned into the device and prevents the secret data from being transmitted over the air in a derivable form. To further enhance security, the cloud can assign different secret data to each device, ensuring a unique secret for each device. This way, hacking one device will not affect other devices of the same model.

[0099] In one embodiment of the present invention, the connection authentication between the device and the node can be completed based solely on the one-way verification of the verification data from the device by the server as involved in the above steps. As a result, the server can determine the identity of the device based on the secret data verified in the verification data. For example, the device reporting a specific PID and / or MAC uses the same locally stored secret data as the corresponding secret data recorded in the cloud to generate the verification data, thereby enabling the cloud to confirm that the device reporting the specific PID and / or MAC is the device with the specific PID and / or MAC (i.e., not another device falsely reporting its identity to connect).

[0100] In other embodiments, the completion of the connection authentication may further include verification of the server identity by the device. For example, the server may generate second verification data based on the found secret data for verification by the device based on the local secret data.

[0101] In a preferred embodiment, the device's verification of the server's identity can be indirectly achieved through the use of an encryption key between the device and the node. Therefore, the connection method of the present invention may further include: the server and the device each generating a communication key based on their respective secret data according to predetermined rules; the server transmitting the communication key to the node; and using the communication key to encrypt data between the device and the node. Therefore, if the communication key provided by the server at the node differs from the communication key used by the device for data encryption, even if the node establishes a connection with the device and obtains data from the device, it will be unable to encrypt the received data due to the inconsistent communication keys.

[0102] Furthermore, since the communication key is generated by the server and the device, the transmission of the communication key only involves transmission from the server to the node, not between the device and the node. The connection between the server and the node is a private connection between the server and the smart terminal, which is more secure than transmission between the first and the node. Therefore, avoiding the transmission of the communication key between the first and the node can effectively prevent replay attacks.

[0103] In order to improve security, the connection authentication of the present invention may also involve the participation of random numbers. Therefore, the device generates verification data based on the secret data stored locally, which may include generating verification data based on random numbers and the secret data. The above-mentioned random number can be generated by the device itself and sent to the server via the node for verification, or it can be generated by the server and sent to the device via the node, or it can be generated by the node, and in different embodiments, the device can generate verification data based on one or more random numbers and the secret data. The device generates verification data based on one or more random numbers and the secret data, which includes: the node generates the one or more random numbers and sends them to the device and the server; the device generates verification data based on the secret data and the random number, and the server verifies the verification data based on the secret data, which includes: the server verifies the verification data based on the random number and the secret data.

[0104] For example, the device can use secret data as a key to encrypt a received random number as verification ciphertext, for example, using the AES128CBC algorithm. After receiving the verification ciphertext, the server can decrypt it using the found secret data and verify whether the decrypted random number is the same, thereby determining whether the verification is successful. It should be understood that other encryption algorithms can also be used based on factors such as computing power. For example, the relatively simple RC5 block cipher algorithm can be used to encrypt the random number, as long as the interceptor of the verification data cannot use the random number to reversely deduce the secret data itself.

[0105] The random number can also be used to generate subsequent communication keys. To this end, the server and device can each generate a communication key based on the secret data and the random number according to predetermined rules, and the server can send the communication key to the node. This communication key can then be used for encrypted data communication between the device and the node. After authentication is complete, the encrypted data communication can be wirelessly encrypted via Bluetooth or WiFi, and the key for this communication can be transmitted via power lines.

[0106] In one embodiment, the communication key can be generated based on the secret data, the random number and the unique identifier of the device. The above-mentioned unique identifier can be included in the broadcast data packet and installed by the node server. Similarly, it is necessary to determine that the interceptor cannot infer the complete secret data from the generated communication key. For example, in one embodiment, the communication key can be defined as: BLEkey = SHA256 (Random, PID, MAC, Secret). That is: the string data of the four values of random number (Random), PID, MAC, and Secret are connected with English commas, and then the SHA256 digest calculation is performed, and the first 16 bytes are taken. After the communication key is generated, the corresponding algorithm can be used for data encryption, such as the AES128CBC algorithm and the RC5 block encryption algorithm.

[0107] To ensure security, each time a device attempts to connect to a node, a different random number is preferably used for mutual authentication. Since a different random number is used each time, the device will request a new BLEKey from the server each time it connects. After each disconnection, the first node needs to clear the currently used BLEKey.

[0108] Furthermore, the cloud can record random values over a period of time, and if a repeated random value is encountered, the device is considered to be compromised. To this end, the device access method of the present invention can also include the server recording the random number used by the device each time it attempts to connect to the node within a predetermined period of time; and if the recorded random numbers include a repeated random number, the server determines that the node has been compromised. The server can then instruct the node to take appropriate action, such as disconnecting from the device.

[0109] In addition, the server can assign network parameters to the device at the appropriate time. After the device's connection authentication is completed, the node sends network configuration data based on these network parameters to the device.

[0110] The above-mentioned device access solution of the present invention can also be implemented as a system for device access to a network. Figure 4 FIG. 1 shows an example of the composition of the access system implemented by the present invention. Figure 4As shown, the system includes a device 400 to be connected to a Bluetooth Mesh network and a node 200 in the Bluetooth Mesh network. The node is a low-power Bluetooth device without a Bluetooth Mesh protocol stack, such as a smartphone. To access the mesh network via a node without a Bluetooth Mesh protocol stack, the device 400 is configured to: broadcast an access request in ADV format; generate verification data based on locally stored secret data and send an ADV-formatted broadcast containing the verification data. Accordingly, the node 200 is configured to: receive the access request; and, based on the access request, perform startup configuration operations for the device to connect to the Bluetooth Mesh network.

[0111] The device and the node use an agreed-upon specific type of broadcast to perform the interactions required for startup configuration, and the specific type of broadcast includes a startup configuration type field for indicating a specific operation type. The specific type of broadcast includes: a fixed header for indicating identity, specific operation type, and packet information; and a payload portion for transmitting data required for a specific startup configuration operation. For example, it can be agreed that the ManufactureData type (type number 0xFF) is used for message propagation. In addition, the composition of the header is agreed upon in the broadcast data of the ManufactureData broadcast.

[0112] Preferably, the system is a system comprising each node in the Bluetooth Mesh network. Figure 4 As shown, other Bluetooth Mesh devices 100, such as a TV, a rice cooker, and a smart speaker, have been connected to the Bluetooth Mesh network. Figure 5 An example of a device connected is shown. Figure 4 and Figure 5 As shown, for conventional Bluetooth Mesh devices 100 equipped with a GATT bearer layer, such as televisions, rice cookers, and smart speakers, the BLE device 200 can interact with these devices 100 based on GATT.

[0113] In contrast, Figure 5 As shown, the connected device 400 can perform regular broadcast interactions with other nodes in the system that have a Bluetooth Mesh protocol stack. The Bluetooth lamp 400 can perform regular broadcast interactions with the smart speaker 100. For example, after receiving the user's voice command to "turn on the light", the smart speaker 100 sends a turn-on command to the Bluetooth lamp 400 via a regular broadcast. The connected device 400 can also perform broadcast interactions of a specific type agreed upon with nodes in the system that do not have a Bluetooth Mesh protocol stack. For example, the Bluetooth lamp 400 can continue to perform broadcast interactions with the smartphone 200 in a manner that conforms to the agreed format, for example, continuing to propagate messages via the ManufactureData type (type number 0xFF).

[0114] The above authentication may also involve the participation of the cloud. For this purpose, the present invention may also be implemented as a cloud access system, including the system for device access to the network as described above, and a server, such as Figure 4 The server 300 shown. The node 200 in the access system communicates with the server 300 via wireless transmission, wherein the access request includes the device's identity data. The node is configured to: send the device's identity data to the server; receive verification data from the device and forward it to the server; and complete connection authentication with the device when the server passes the verification. The server is configured to: receive the device's identity data sent by the node; search for secret data corresponding to the device based on the identity data; receive the verification data sent by the node and perform verification based on the found secret data.

[0115] As above combined Figure 3-5 The method for accessing a device to a network and the corresponding device access system according to the present invention are described. Figure 6 , describes an example of a device network configuration process based on BLE broadcast according to the present invention.

[0116] like Figure 6 As shown, the process of IoT device 400 accessing node 200 (for example, by operating an APP installed on mobile phone 200) and then accessing the IoT (starting the configuration process) requires the participation of cloud platform 300, and the specific steps involved are as follows:

[0117] 1. APP 200 obtains startup configuration information, such as information about the existing Bluetooth Mesh network and user data.

[0118] 2. The user issues a command to scan for XXX devices. For example, the user may click the Add New Device icon in App 200, or may further select the type of device to add. In some embodiments, the type may indicate that device 400 does not include a GATT bearer layer and therefore requires the use of a broadcast protocol for data transmission.

[0119] 3. The device 400 may send an access request, for example, by powering on, for example, using a broadcast data packet in the agreed format as described above.

[0120] 4. APP 200 receives the user's instruction and starts scanning.

[0121] 5. After scanning the device, app 200 begins the network configuration process. For example, it can first generate the random number required for network configuration. This random number is used to generate verification data for both cloud 300 and device 400. Two random numbers, RandomA and RandomB, can be generated. These two random numbers can be uploaded to the cloud in encrypted form for enhanced security.

[0122] 6. Subsequently, APP 200 may send network configuration information.

[0123] 7. Accordingly, the device 400 sends an acknowledgment (Ack) of receiving the configuration reply.

[0124] 8. After receiving the Ack, APP 200 can send RandomA and RandomB to the device, for example, by sending two packets alternately. The above random numbers can be used to generate verification data for the cloud 300 and the device 400 respectively.

[0125] 9. To this end, APP 200 sends an encrypted random number, such as RandomB||A, to the cloud for verification data generation. At the same time, APP 200 can also send a confirmation key ConfirmationKey to the cloud 300.

[0126] 10. The cloud 300 records the random number uploaded by the APP 200, such as RandomB||A, and uses the secret data of the device 400 stored in the cloud to generate verification data (ie, ConfirmationCloud) for identity authentication.

[0127] 11. The cloud 300 sends verification data (ie, ConfirmationCloud) to the APP 200.

[0128] 12. At the same time, the device 400 can generate RandomB||A from RandomA and RandomB according to a predetermined rule, and use the secret data burned into itself (for example, triple data including the secret data) to generate verification data (ie, ConfirmationDevice).

[0129] 13. Subsequently, the device sends the generated verification data (ie, ConfirmationDevice) to the APP 200.

[0130] 14. APP 200 reports the obtained device verification data (ie, ConfirmationDevice) to the cloud 300 and can send RandomB||A again.

[0131] 15. Cloud 300 compares the verification data generated by the device (ConfirmationDevice) with the result calculated by the cloud (ConfirmationCloud). If they are consistent, RandomB||A is recorded.

[0132] 16. Subsequently, the cloud 300 sends an authentication success message to the APP 200.

[0133] 17. APP 200 can use the previously obtained (ConfirmationCloud) as a key and encrypt and send the network configuration data to device 400 via ConfirmationCloud. Due to the payload limit in the agreed broadcast, two packets can also be sent alternately.

[0134] 18. Subsequently, device 400 responds that network configuration is successful.

[0135] 19. After receiving the message, APP200 starts the standard Mesh network configuration process.

[0136] 20. APP200 and device 400 complete network configuration through interaction. At this point, device 400 can generate a deviceKey based on the stored secret data and provide it to APP200.

[0137] 21. APP200 notifies the user that the network configuration is successful.

[0138] 22. APP200 reports the network configuration success with the deviceKey, and subsequent communications can be encrypted using the deviceKey.

[0139] 23. Finally, the cloud 300 notifies the app 200 to start subsequent communication with the device 400. For example, the classic network configuration can be performed with the device 400. That is, after the agreed layer network configuration is successful, the classic Mesh network is then performed.

[0140] After the device 400 is connected to the Bluetooth Mesh network, it can Figure 5 As shown, after receiving the conventional control of the Bluetooth Mesh device (e.g., smart speaker), it is still possible to receive control from the BLE device 200 in the form of a scheduled broadcast. The above interaction via scheduled broadcast can be regarded as an interaction outside the Mesh network.

[0141] Figure 7 An example of a device control process based on BLE broadcasting according to the present invention is shown.

[0142] 1. The user gives an instruction to control the XXX device. For example, the user can click on the device icon in the APP 200 to further select the operation to be performed, such as turning on the Bluetooth light 400.

[0143] 2. APP 200 can query the cloud to obtain corresponding instruction information.

[0144] 3. The cloud 300 can reply instructions to the APP 200.

[0145] 4. Subsequently, as shown in the Alt box, since the device 400 does not include a GATT bearer layer, the APP 200 communicates with the device 400 using the agreed broadcast. The above interaction can be regarded as an interaction outside the Mesh network.

[0146] Therefore, the APP 200 intercepts the packet at the Network layer, breaks the sent packet into small parts, and sends them in a BLE broadcast of the agreed format.

[0147] 5. As shown in the Alt box, if the Network ID included in the BLE broadcast matches the network ID assigned to the device 400, the device will record the corresponding data.

[0148] Specifically, the device 400 can (1) record the unicast address of the device contained in the BLE broadcast to make it clear that the BLE broadcast needs to be used when replying. The device 400 can also (2) store the corresponding msgld (message number) packet and splice the complete data for parsing.

[0149] 6. Since APP 200 will repeatedly send broadcasts with the same content, the device 400 can discard broadcast packets with the same content.

[0150] 7. After completing the analysis, the device 400 can perform corresponding operations, such as turning on the Bluetooth light 400, and reply with a response through broadcasting.

[0151] 8. APP200 can monitor ACCS messages and notify the user of the results.

[0152] 9. The APP 200 can notify whether the control is successful or failed. For example, it can display that the Bluetooth lamp 400 has been turned on.

[0153] 10. In addition to the broadcast communication protocol of the present invention, APP 200 can interact with other devices in the Mesh network using the original logic (eg, GATT).

[0154] As mentioned above, IoT devices that can execute the scheme have the ability to generate broadcasts in a specified format and parse broadcasts in the corresponding format. Figure 8 A schematic diagram showing the composition of an Internet of Things device according to an embodiment of the present invention is shown.

[0155] As shown, IoT device 400 may include a processing module 410 and a communication module 420. In certain embodiments, communication module 420 may be implemented by a Bluetooth Mesh chip. Unlike conventional chips that include a GATT bearer layer, the bearer layer of the Bluetooth Mesh chip of the present invention may only include a broadcast bearer layer, communicating with BLE devices via a specified broadcast type and format to complete startup configuration and subsequent control operations. This can reduce the price of IoT device 400. This is crucial for cost control in relatively simple and inexpensive devices, such as Bluetooth light bulbs.

[0156] Specifically, processing module 410 is used to generate an access request in ADV format and the subsequent ADV format broadcast and data contained therein required for initiating configuration operations. Communication module 420 is used to send and receive the ADV format broadcast required for initiating configuration operations. Here, the access request and the subsequent ADV format broadcast have a predetermined broadcast type.

[0157] In one embodiment, the access request or subsequent broadcast sent via the communication module includes the identity data of the IoT device. Figure 6 The broadcast data packet in step 3 may include the identity data of the device 400 .

[0158] Furthermore, the communication module 420 can be used to: send verification data generated based on the secret data stored locally. The processing module 410 can be used to: generate verification data based on the secret data stored locally; and complete the startup configuration operation with the Bluetooth Mesh network after receiving the message of successful verification. The device 400 may also include a storage module for storing the secret data and the identity data. Specifically, the storage module may include: a burning storage element for burning and storing a unique identity identifier indicating the identity of the IoT device and the secret data. For example, the corresponding triplet data (PID, MAC and Secret (secret data)) of each IoT device will be pre-burned (for example, burned before leaving the factory). At the same time, a list of triples containing each IoT device can be stored in a cloud database.

[0159] After accessing the Bluetooth Mesh network, the communication module 420 can be used as described above to use the ADV format broadcast of the agreed broadcast type to interact with low-power Bluetooth devices in the network that do not have the Bluetooth Mesh protocol stack; and to perform regular broadcast interactions with other nodes in the network that have the Bluetooth Mesh protocol stack.

[0160] As mentioned above, the IoT device 400 and the BLE device 200 (nodes in the Bluetooth Mesh network) can exchange the data required for startup configuration via broadcasts of agreed types. For example, messages are propagated via broadcasts of the ManufactureData type (type number 0xFF). The above type conventions need to be followed by both the IoT device 400 and the BLE device 200. However, for some BLE devices 200, such as mobile phones with iOS installed, the ManufactureData type may not be modifiable due to the closed nature of the iOS system. In this case, other modifiable types can be selected for transmission, such as ServiceUUID (type number 0x16). In other words, mobile phones with iOS systems can receive broadcasts of the ManufactureData type, but cannot send this type. For this reason, you can choose to send broadcasts of the ServiceUUID type.

[0161] To this end, the processing module 410 can be used to: generate an access request in the ADV format of the first agreed type; receive a returned ADV format broadcast, determine whether the broadcast type of the received broadcast is the first agreed type or the second agreed type; parse the received broadcast based on the determined type; and generate and send a subsequent ADV format broadcast of the first agreed type. For example, the IoT device 400 can be used in the following example: Figure 6 In step 3, a ManufactureData type access request is broadcast, and based on the broadcast type (e.g., 0xFF or 0x16) of the feedback broadcast received from APP 200 in step 6, the type of BLE device is confirmed, and then a specific type of broadcast is selected for parsing. Since the iOS system can still receive and parse ManufactureData type broadcasts, device 400 can always select ManufactureData type broadcasts for message sending.

[0162] Accordingly, the present invention can also be implemented as a terminal device. The terminal device can be a conventional device with a BLE protocol stack, such as a smart phone or a tablet computer. Figure 9 A schematic diagram showing the composition of a terminal device according to an embodiment of the present invention is shown.

[0163] like Figure 9As shown, the terminal device 200 includes a processing module 210 and a Bluetooth communication module 220. The Bluetooth communication module 220 is used to receive an access request in the ADV format broadcast by the IoT device. The processing module 210 is used to perform startup configuration operations with the IoT device via ADV format broadcast based on the access request. Furthermore, the Bluetooth communication module 220 is used to send control instructions to the IoT device via ADV format broadcast after the IoT device accesses the Bluetooth Mesh network. Specifically, the Bluetooth communication module 220 can be a Bluetooth module that comes with the terminal device 200, which includes a low-power Bluetooth protocol. Furthermore, a corresponding APP can be installed on the device 200, which can interact with the previous IoT device 400 in an agreed broadcast type and format. In other words, the ADV format broadcast sent and received by the Bluetooth communication module 220 has an agreed broadcast type and an agreed packet header composition.

[0164] Furthermore, the APP installed on the device 200 may also include GATT bearer layer functionality, thereby facilitating conventional communication with other Bluetooth Mesh devices via GATT, such as PB-GATT (startup configuration via GATT).

[0165] The present invention can also be implemented as a method for connecting with an Internet of Things device. Figure 10 A schematic flow chart of a method for connecting to an IoT device according to an embodiment of the present invention is shown. The method can be executed by the terminal device 200 as described above.

[0166] In step S1010, an access request in the ADV format broadcasted by an IoT device is received via the Bluetooth communication module. In step S1020, based on the access request, a startup configuration operation is performed with the IoT device via an ADV format broadcast, wherein the ADV format broadcast has a predetermined broadcast type and a predetermined packet header composition.

[0167] Here, the Bluetooth communication module is a special communication module that can communicate with IoT devices in a prescribed broadcast type and format (eg, a prescribed packet header).

[0168] The above startup configuration process may start with scanning of the terminal device. For this purpose, the method may further include: starting the scan, wherein the scan includes scanning for broadcasts of an agreed type.

[0169] Therefore, this paper proposes a solution that uses broadcasts, rather than GATT, on BLE devices to interact with Bluetooth Mesh devices, enabling network configuration and control of Bluetooth Mesh devices. This allows both devices to communicate using agreed-upon broadcast types and formats, eliminating the need for GATT modules for Bluetooth Mesh devices, especially low-cost ones, and paving the way for the large-scale deployment of Bluetooth Mesh networks.

[0170] In addition, the method according to the present invention may also be implemented as a computer program or a computer program product, which includes computer program code instructions for executing the above steps defined in the above method of the present invention.

[0171] Alternatively, the present invention can also be implemented as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) on which executable code (or computer program, or computer instruction code) is stored. When the executable code (or computer program, or computer instruction code) is executed by a processor of an electronic device (or computing device, server, etc.), the processor executes the various steps of the above-mentioned method according to the present invention.

[0172] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both.

[0173] The flowcharts and block diagrams in the accompanying drawings show the possible implementation architecture, functions and operations of the systems and methods according to multiple embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of code, and the part of the module, program segment or code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0174] While various embodiments of the present invention have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for a device to access a network, comprising: The device broadcasts an access request in ADV format; A node of the Bluetooth Mesh network receives the access request, wherein the node is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack, and the low-power Bluetooth advertising packet does not include a type specifically used for Bluetooth Mesh network startup configuration; The node performs a startup configuration operation to connect the device to the Bluetooth Mesh network based on the access request, The device and the node agree on a broadcast type, so that both interacting parties can obtain a broadcast packet in an ADV format and correctly parse it.

2. The method according to claim 1, wherein The node performing a startup configuration operation of connecting the device to the Bluetooth Mesh network based on the access request includes: The node and the device complete the startup configuration through subsequent interactions via ADV format broadcast.

3. The method according to claim 2, wherein: The device and the node perform the interaction required for starting configuration by broadcasting an agreed specific type.

4. The method according to claim 3, wherein: The specific type broadcast includes a startup configuration type field for indicating a specific operation type.

5. The method according to claim 3, wherein: The specific type of broadcast includes a fixed packet header for indicating an identity, a specific operation type, and packet information.

6. The method according to claim 5, wherein: The specific type of broadcast includes a payload portion for transmitting data required for a specific startup configuration operation.

7. The method of claim 6, further comprising: Whether to perform depacketization and transmission is determined based on the maximum length of the payload part and the length of the data to be transmitted, wherein the specific type of broadcast includes a packet number field for indicating the total number of packets and the current number of packets.

8. The method of claim 3, further comprising: The node starts scanning, wherein the scanning includes scanning for the specific type of broadcast.

9. The method of claim 1 , further comprising: The node interacts with the connected device using ADV format broadcasting.

10. The method of claim 9, wherein: In the interactive broadcast after the device is connected, the network ID of the device is used instead of the MAC address of the device as the identity of the device.

11. The method of claim 9, further comprising: After access, the device uses ADV format broadcast to interact with other nodes in the Bluetooth Mesh network.

12. The method of claim 1, wherein: The access request includes the identity data of the device, and the node completes the startup configuration of the device accessing the Bluetooth Mesh network based on the identity data.

13. The method of claim 12, wherein: The node performing authentication of the device connecting to the node based on the access request includes: The node sends the identity data of the device to the server; The device generates verification data based on the secret data stored locally, and sends the verification data to the node; The node forwards the verification data to the server; The server searches for the secret data corresponding to the device based on the identity data, and verifies the verification data based on the secret data; and The node completes authentication of the device connecting to the node based on the successful verification.

14. The method of claim 13, wherein: The device generates verification data based on secret data stored locally, including: The device generates the verification data in such a way that the complete secret data cannot be deduced.

15. The method of claim 13, wherein: The device generates verification data based on secret data stored locally, including: The device generates check data based on one or more random numbers and the secret data.

16. The method of claim 15, wherein: The device generating verification data based on one or more random numbers and the secret data includes: The node generates the one or more random numbers and sends them to the device and the server; The device generates verification data based on the secret data and the random number, and The server verifying the verification data based on the secret data includes: The server verifies the verification data based on the random number and the secret data.

17. A system for device access to a network, comprising a device to be connected to a Bluetooth Mesh network and a node in the Bluetooth Mesh network, wherein the node is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack, and the low-power Bluetooth advertising packet does not include a type specifically used for Bluetooth Mesh network startup configuration, wherein: The device is used to: Broadcast access request in ADV format; Generate verification data based on the secret data stored in the local computer and send an ADV format broadcast with the verification data. The node is used to: receiving the access request; and The node performs a startup configuration operation for the device to connect to the Bluetooth Mesh network based on the access request, The device and the node agree on a broadcast type, so that both interacting parties can obtain a broadcast packet in an ADV format and correctly parse it.

18. The system of claim 17, wherein: The device and the node perform the interaction required for startup configuration using an agreed specific type of broadcast, and the specific type of broadcast includes a startup configuration type field for indicating a specific operation type.

19. The system of claim 18, wherein: The specific types of broadcasts include: A fixed header that indicates identity, specific operation type, and packet information; and The payload portion is used to transmit the data required for specific startup configuration operations.

20. The system of claim 17, wherein: The system is a system including each node in the Bluetooth Mesh network, wherein: The connected device performs regular broadcast interaction with other nodes in the system that have a Bluetooth Mesh protocol stack; and After access, the device performs a broadcast interaction of a specific type agreed upon with a node in the system that does not have a Bluetooth Mesh protocol stack.

21. A cloud access system comprising the system according to any one of claims 17 to 20, and a server, wherein nodes in the access system communicate with the server via wireless transmission, wherein: The access request includes the identity data of the device, The node is used to: sending identity data of the device to the server; receiving verification data from the device and forwarding it to the server, and When the server passes the verification, the connection authentication with the device is completed. The server is used to: receiving identity data of the device sent by the node; searching for secret data corresponding to the device based on the identity data; The verification data sent by the node is received and verification is performed based on the found secret data.

22. An Internet of Things device, comprising: Processing module for: Generates an access request in ADV format and the ADV format broadcast and the data contained therein required to start the configuration operation, Communication modules for: Send and receive ADV format broadcasts required to start configuration operations. The access request and the ADV format broadcast have an agreed broadcast type. The access request is received by a node of the Bluetooth Mesh network, the node is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack, and the low-power Bluetooth broadcast packet does not include a type specifically used for Bluetooth Mesh network startup configuration, The IoT device and the node agree on the broadcast type, so that both parties can obtain the ADV format broadcast packet and parse it correctly.

23. The apparatus of claim 22, wherein: The access request or subsequent broadcast sent via the communication module includes the identity data of the Internet of Things device.

24. The apparatus of claim 23, wherein: The communication module is used to: Send verification data generated based on the secret data stored locally, The processing module is used to: Verification data generated based on secret data stored locally; After receiving the verification success message, the startup configuration operation with the Bluetooth Mesh network is completed, and The Internet of Things device further includes a storage module for: The secret data and the identity data are stored.

25. The apparatus of claim 24, wherein: The storage module includes: A unique identification identifier indicating the identity of the IoT device and the secret data are burned into and stored in a burning storage element.

26. The apparatus of claim 22, wherein: After accessing the Bluetooth Mesh network, the communication module is used to: Interacting with the node using the agreed ADV format broadcast of the broadcast type; and Perform regular broadcast interactions with other nodes in the network that have the Bluetooth Mesh protocol stack.

27. The apparatus of claim 22, wherein: The processing module is used to: generating an access request in an ADV format having a first agreed type; Receive the returned ADV format broadcast, and determine whether the broadcast type of the received broadcast is the first agreed type or the second agreed type; Parsing the received broadcast based on the determined type; and A subsequent ADV format broadcast having the first subscription type is generated and sent.

28. A terminal device comprising: Bluetooth communication module: Used to receive access requests in ADV format broadcast by IoT devices; Processing module for: Based on the access request, performing a startup configuration operation with the IoT device via ADV format broadcast, and The Bluetooth communication module is used to: After the IoT device is connected to the Bluetooth Mesh network, a control instruction is sent to the IoT device via ADV format broadcast. The terminal device receives the access request as a node of the Bluetooth Mesh network, the terminal device is a low-power Bluetooth device that does not have a Bluetooth Mesh protocol stack, and the low-power Bluetooth broadcast packet does not include a type specifically used for Bluetooth Mesh network startup configuration, The node and the IoT device agree on a broadcast type, so that both parties can obtain a broadcast packet in the ADV format and parse it correctly.

29. The apparatus of claim 28, wherein The ADV format broadcast sent and received by the Bluetooth communication module has the agreed broadcast type and agreed packet header composition.

Images