CN114520967B

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

Info

Publication number: CN114520967B
Application number: CN202011296659.8A
Authority: CN
Inventors: 刘邦哲; 王楠; 杨斌
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2020-11-18
Filing date: 2020-11-18
Publication date: 2025-08-08
Anticipated expiration: 2040-11-18
Also published as: CN114520967A

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

Method and system for accessing equipment to network and corresponding Internet of things equipment

Technical Field

The present invention relates to internet of things (IoT) technology, and in particular, to a method and system for accessing a device to a network, and a corresponding internet of things device.

Background

Bluetooth technology is one of the most common wireless communication technologies used worldwide. Among these, bluetooth low energy (Bluetooth Low Energy) is now widely used and is deployed on billions of smartphones, tablets, and other smart devices (e.g., wearable devices) worldwide.

The Bluetooth Mesh network is a new Bluetooth standard based on BLE approved in 2017, and is a networking technology capable of realizing communication of many-to-many (m: m) devices. Bluetooth Mesh networks are optimized for creating large-scale device networks, and are well suited for building automation, sensor networks, asset tracking, and other internet of things solutions requiring tens, hundreds, or thousands of devices to communicate with each other.

The bluetooth Mesh network introduces a new protocol stack. Since this protocol stack builds on bluetooth low energy technology, existing BLE devices (e.g., smartphones and tablet computers) can access the bluetooth Mesh network via proxy nodes. In the prior art, communication between a bluetooth device and a smart phone may be achieved by configuring a GATT bearer layer in a bluetooth device having a bluetooth Mesh protocol station, and installing a specific APP in a BLE device such as a smart phone. However, the GATT-based connection increases the cost of the bluetooth device, and limits large-scale industrial popularization.

For this reason, a method capable of realizing device access with a simpler configuration is required.

Disclosure of Invention

In order to solve at least one of the problems, the invention provides a brand new device access scheme. According to the scheme, the requirement on the GATT module can be eliminated, the broadcasting is directly used for accessing the Bluetooth Mesh network by the Internet of things equipment, and particularly, the broadcasting is used for realizing starting configuration and subsequent control.

According to a first aspect of the invention, a method for accessing a network by a device is provided, wherein the method comprises the steps that the device broadcasts an access request in an ADV format, a node of a Bluetooth Mesh network receives the access request, the node is a low-power Bluetooth device without a Bluetooth Mesh protocol stack, and the node performs a starting configuration operation for accessing the device to the Bluetooth Mesh network based on the access request.

According to a second aspect of the present invention, a system for accessing a network by a device is provided, including a device to be accessed to a bluetooth Mesh network and a node in the bluetooth Mesh network, where the node is a low-power bluetooth device without a bluetooth Mesh protocol stack, and the device is configured to broadcast an access request in ADV format, generate check data based on secret data stored locally and send ADV format broadcast with the check data, the node is configured to receive the access request, and perform a start configuration operation of the device to connect to the bluetooth Mesh network based on the access request.

According to a third aspect of the present invention, there is provided a cloud access system, including the system according to the second aspect, and a server, wherein a node in the access system communicates with the server via wireless transmission, the access request includes identity data of the device, the node is configured to send the identity data of the device to the server, receive check data from the device and forward the check data to the server, and complete connection authentication with the device when the server checks to pass, the server is configured to receive the identity data of the device sent by the node, search secret data corresponding to the device based on the identity data, and receive the check data sent by the node and check based on the found secret data.

According to a fourth aspect of the present invention, there is provided an internet of things device, comprising a processing module configured to generate an access request in an ADV format, and an ADV format broadcast required to initiate a configuration operation and data contained therein, and a communication module configured to send and receive the ADV format broadcast required to initiate the configuration operation, wherein the access request and the ADV format broadcast have agreed broadcast types.

According to a fifth aspect of the invention, a terminal device is provided, which comprises a Bluetooth communication module, a processing module and the Bluetooth communication module, wherein the Bluetooth communication module is used for receiving an access request in an ADV format broadcast by the Internet of things device, the processing module is used for performing starting configuration operation with the Internet of things device through the ADV format broadcast based on the access request, and the Bluetooth communication module is used for sending a control instruction to the Internet of things device through the ADV format broadcast after the Internet of things device is accessed to a Bluetooth Mesh network.

According to a sixth aspect of the invention, a method for connecting with an internet of things device is provided, which comprises the steps of receiving an access request in an ADV format broadcast by the internet of things device through a Bluetooth communication module, and performing a start configuration operation with the internet of things device through the ADV format broadcast based on the access request, wherein the ADV format broadcast has a contracted broadcast type and a contracted packet header composition.

Therefore, the invention provides a scheme for interacting with the Bluetooth Mesh device by utilizing broadcasting on the BLE device instead of GATT so as to realize the network distribution and control operation of the Bluetooth Mesh device. Therefore, the two devices can communicate according to the agreed broadcast type and format, so that the requirement of the Bluetooth Mesh device, especially the low-cost device, on the GATT module is eliminated, and conditions are provided for large-scale popularization of the Bluetooth Mesh network.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be apparent from the following more particular descriptions of exemplary embodiments of the disclosure as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts throughout exemplary embodiments of the disclosure.

Fig. 1A-B illustrate examples of device access authentication.

Fig. 2 shows the hierarchy of the bluetooth Mesh protocol stack.

Fig. 3 shows a schematic flow chart of a method of a device accessing a network according to an embodiment of the invention.

Fig. 4 shows a composition example of an access system implemented by the present invention.

Fig. 5 shows an example after device access.

Fig. 6 depicts an example of a device distribution network flow based on BLE broadcast in accordance with the present invention.

Fig. 7 shows an example of a device control flow based on BLE broadcasting according to the present invention.

Fig. 8 shows a schematic diagram of the composition of an internet of things device according to an embodiment of the invention.

Fig. 9 shows a schematic composition of a terminal device according to an embodiment of the invention.

Fig. 10 shows a schematic flow chart of a method of connecting with an internet of things device according to one embodiment of the invention.

Detailed Description

Preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While the preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

The Bluetooth Mesh is a Bluetooth equipment local networking specification specified by Bluetooth official organizations, can support equipment many-to-many transmission, particularly improves the communication capability of building a large-range network coverage, and is suitable for the solution of the Internet of things, such as building automation, wireless sensor networks and the like, which needs to enable tens of thousands of equipment to be transmitted in a reliable and safe environment.

Devices in Mesh networks are referred to as nodes, and devices in non-Mesh networks are referred to as "devices" that are not configured to be booted. The process of converting a device into a node is referred to as "provisioning". For example, the user may consider purchasing a new bluetooth light that supports Mesh, bring it home and make a start-up setting. In order to make it a part of Mesh network to control through existing bluetooth lighting switch and dimmer, it is necessary to start up the configuration of this type of lighting lamp. The boot configuration is a secure process, and the device that is not originally boot configured will have a series of encryption keys after boot configuration, and will be identified by the boot configured device (typically, a tablet computer or a smart phone). One of the keys is referred to as a network key or NetKey for short. All nodes in the Mesh network have at least one NetKey and the device must have the key to become joining the corresponding network and become a node. Secure acquisition NetKey by initiating a configuration process is the basic first step before a node is put into use.

In a boot configuration using a BLE device such as a tablet or smart phone as a "node", it is necessary to connect with a "device" that is not boot configured based on the GATT. Because bluetooth devices with simple structures, such as bluetooth lamps, also need to be equipped with GATT modules, the cost limitations of the devices described above can increase, impeding large-scale networking of bluetooth Mesh. For this reason, a method capable of implementing access to a bluetooth Mesh network by a device with a simpler configuration is required.

For the convenience of understanding the principles of the present invention, a background description will be given below of a bluetooth Mesh network, especially a start configuration procedure of a node joining the network.

The bluetooth Mesh network is a VIP club. If you are members of the club, you can access at will, enjoying facilities and services corresponding to the category of the conference. If you are not members, you go beyond the gate guard. To make a device a member of a bluetooth Mesh network, the device must be added to the network through a security procedure called "provisioning" to ensure the security of the network.

Security is the core of bluetooth Mesh networks, and the process of adding devices to, or removing devices from, the network will all strictly follow the security requirements. According to the specification, the bluetooth Mesh network uses a set of systems including various security keys to protect the network as a whole, and simultaneously to protect and separate applications within the network from each other. With the correct security key, the device can become a member of the network and have access to the particular application. All nodes in the network have a key called "network key" or "NetKey". Only if the device has possession of this key, it becomes a member of the network, i.e. one of the nodes therein.

The start-up configuration is the process by which a device joins the Mesh network and becomes a node. It involves several stages, generates various security keys, and is itself a secure process. The presets may be made using an application on a device such as a tablet. In this case, the device for driving the preset process is referred to as a start-up configuration device (Provisioner). The device to be preset to become a node may be referred to as a "device to be accessed" in the present invention.

The preset process is performed by five steps including:

step 1 Beacon broadcast (Beaconing)

To support a variety of different bluetooth Mesh functions (including but not limited to presets), a completely new GAP broadcast type (reference: bluetooth core specification annex) has been introduced, including < < Mesh Beacon > > broadcast type. The non-preset device will indicate its availability by using the < < Mesh Beacon > > broadcast type in the advertisement packet. The user may need to initiate a new device broadcast in this way, for example, by pressing a button combination, or by holding a button for a period of time.

Step 2 invitation (Invitation)

In this step the initiating configuration device will send an invitation in the form of an initiating configuration invitation PDU (Provisioning Invite PDU, PDU: protocolDataUnit, i.e. protocol data unit) to the initiating configuration device to be subjected to. The Beacon device will respond, i.e. reply with information about itself in Provisioning Capabilities PDU (start configuration capability PDU).

Step3 exchange public keys (Exchanging public keys)

The initiating configuration device and the device to be preset may exchange their public keys, either directly or through out-of-band (OOB), which keys may be static or temporary.

At this stage, the bootable configuration device (Provisioner) selects the appropriate authentication method based on the functionality of the bootable configuration device and notifies the bootable configuration device of the manner to be taken. The booted configuration device and the non-booted configuration device then create an elliptic curve public-private key pair and exchange public keys. Each device then uses its own private key and the public key of the peer device to calculate a symmetric key, ECDHSECRET. The key is used to verify the identity of the peer device.

Step 4 Authentication (Authentication)

During the authentication step, the device to be configured for activation will output a random single or multiple digits to the user in some form by an action appropriate to its function. For example, it may flash an LED lamp several times. The user inputs the number output by the new device into the starting configuration device, and the two devices perform encryption exchange of the random number so as to complete authentication of the two devices.

Step 5. Initiate distribution of configuration data (Distribution of provisioning data)

After authentication is completed successfully, a session key is generated through the private keys of the two devices and the exchanged peer-to-peer public key. The session key is then used to secure the subsequent distribution of data required to complete the provisioning process, including a security key called the network key (NetKey). After the preset is completed, the preset device will have a network NetKey, which is a Mesh security parameter, also called IV index and unicast address, and is allocated by the start-up configuration device. The device to be accessed then completes the start-up configuration to access the network and may now be referred to as a node.

Fig. 1A-B illustrate examples of device access authentication. As shown in fig. 1A, the internet of things device 100 as a device needs to be connected with the terminal device 200 as a node. The internet of things device 100 may typically connect and communicate via short range data transmission (e.g., several 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 a bluetooth low energy protocol (BLE). The connection between the device and the node may be simply the connection between the internet of things device 100 and the terminal device 200, for example, the connection between the bluetooth weight scale and the smart phone in the above example. In other embodiments, the internet of things device 100 may connect to an existing bluetooth Mesh network via a startup configuration with the terminal device 200 as one node of the bluetooth Mesh network. Here, since the terminal device 200 is a conventional BLE device without a bluetooth Mesh protocol stack, the device 100 and the node 200 access the bluetooth Mesh network via PBGATT (via the start-up configuration of the GATT bearer).

Similarly, as shown in fig. 1B, the internet of things device 100 as a device needs to be connected to the intelligent device 250 as a node, as shown by the intelligent speaker 250. Since the smart speaker 250 may be a device with a bluetooth Mesh protocol stack, when the smart speaker 250 is used as a device for performing a startup configuration, the device 100 may access the bluetooth Mesh network via PBADV (a startup configuration via a broadcast bearer).

As mentioned above, bluetooth Mesh networks introduce a completely new protocol stack. And this protocol stack builds on bluetooth low energy technology. Fig. 2 shows the hierarchy of the bluetooth Mesh protocol stack.

Above the existing bluetooth low energy (Bluetooth Low Energy, hereinafter simply BLE) protocol layer, the bluetooth Mesh protocol layer further includes a bearer layer, a network layer, a lower transport layer, an upper transport layer, an access layer, a base model layer, and a model layer. In this case:

Bearer layer (bearer layer) the bearer layer defines how PDUs are transmitted using the underlying low power stack. Two bearer layers, broadcast bearer layer, are currently defined. (ADVERTISING BEARER) and GATT bearer layer.

Network layer (network layer) the network layer defines various message address types and network message formats. Relay and proxy behavior is implemented through the network layer.

An underlying transport layer (lower transport layer) that is capable of handling segmentation and reassembly of PDUs when needed.

The upper transport layer (upper transport layer) is responsible for encrypting, decrypting and authenticating application data coming in and going out by the access layer. It is also responsible for a special message called "transmission control message" (transport control messages), including heartbeats and messages associated with "friendship".

The access layer (ACCESS LAYER) is responsible for formatting the application data, defining and controlling the encryption and decryption processes performed in the upper transport layer, and verifying whether the received data is suitable for the correct network and application before forwarding the data to the protocol stack.

Base model (foundation models) the base model layer is responsible for implementing models related to Mesh network configuration and management.

Model models the model layer is related to the implementation of the model etc., such as behavior, messages, states etc.

During the boot configuration, the boot configuration device will communicate with the device to be boot configured using the bluetooth Mesh protocol known as the "boot configuration protocol". The boot configuration device may use the boot configuration protocol through either the PB-ADV or PB-GATT bearer layer to ensure that the boot configuration device's application may also be implemented on earlier versions of smartphones as long as they support Bluetooth low energy (Bluetooth Low Energy) and GATT.

In other words, if the device to be configured for startup ("node" 250) and the device to be configured for startup ("device" 100) are both provided with the bluetooth Mesh protocol stack as shown in fig. 1B, both parties can directly complete the information exchange and authentication process via GAP broadcasting based on steps 1-5 as above.

However, if, as shown in fig. 1A, the device to be configured for startup ("node" 200) and the device to be configured for startup ("device" 100) are not both provided with a bluetooth Mesh protocol stack, i.e., the node 200 is a BLE device without a bluetooth protocol stack, such as a smart phone, then the node 200 is required to introduce GATT functionality in order for the bluetooth device 100, which also includes a GATT bearer layer, to complete startup configuration authentication. When using the GATT bearer layer, bluetooth Mesh Protocol Data Units (PDUs) need to be encapsulated in Proxy protocols (Proxy protocols), whereby the conversion from the broadcast bearer layer to the GATT bearer layer and vice versa is achieved by the Proxy node.

In the prior art, in order to directly use a device without a bluetooth Mesh protocol stack to complete startup authentication of a newly added bluetooth device (for example, using a smart phone to operate a newly purchased bluetooth lamp to access an existing home internet of things, such as a bluetooth Mesh network), a GATT-based connection between the mobile phone and the device is required. Although the handset may be referred to as a part of the bluetooth Mesh network via the proxy node by installing an APP having a GATT bearer function, in order to perform the startup configuration via the handset, the corresponding bluetooth device needs to be equipped with a GATT bearer. However, the GATT-based connection increases the cost of the bluetooth device, and limits large-scale industrial popularization.

Therefore, the invention provides a brand new device access scheme. The scheme enables the conventional BLE equipment without the Bluetooth Mesh protocol stack, such as a smart phone, to directly use GAP broadcasting to access the Bluetooth Mesh network by the Internet of things equipment, and particularly to completely start configuration and subsequent control by using the broadcasting, thereby eliminating the need for the GATT module in the Internet of things equipment and further reducing the equipment cost.

In step S310, the device broadcasts an access request in ADV format. Herein, the "ADV" format refers to a broadcast (BLE ADVERTISING PACKETS) compliant with the low power bluetooth protocol. For example, the device may be a bluetooth Mesh device 400 as shown in fig. 4 and 5 below, and unlike the conventional bluetooth Mesh device 100, the device 400 may not include a GATT bearer layer.

In step S320, a node of the bluetooth Mesh network receives the access request, where the node is a low-power bluetooth device that does not have a bluetooth Mesh protocol stack. For example, the node may be a BLE device 200, e.g. a smartphone 200, as shown in fig. 4 and 5 below. Although the handset has GATT communication functionality, it communicates with the device 400 that does not include the GATT bearer layer by means of a contracted form of broadcast.

In step S330, the node performs a start configuration operation for accessing the device to the bluetooth Mesh network based on the access request. Specifically, the node and device complete the startup configuration through subsequent interactions broadcast via the ADV format.

Based on the invention, the Bluetooth Mesh device can directly communicate with the conventional BLE device through the BLE broadcast data packet so as to finish the starting configuration operation of accessing the Bluetooth Mesh network. Therefore, the Bluetooth Mesh device can eliminate the need for the GATT module, thereby reducing the cost of the device and facilitating large-scale popularization.

In the context of a bluetooth Mesh network, a "node" is a device that has been accessed to the network, and a "device" is a device that has not been accessed to the network. The "device" needs to go through the "start configuration" procedure as described above to be able to access the network and change from "device" to "node".

Here, the device to be subjected to the startup configuration, i.e., the device to be accessed (e.g., the bluetooth lamp 400 waiting for access), is a device provided with a bluetooth Mesh protocol stack, i.e., includes all the protocol layers shown in fig. 2. But unlike the conventional bluetooth Mesh device, the device to be accessed includes only a broadcast bearer layer (ADVERTISING BEARER) in the bearer layer, and the omitted GATT bearer layer, and can communicate with a BLE node without a bluetooth Mesh protocol stack through broadcasting in an ADV format.

Accordingly, the node for the startup configuration device is a low power bluetooth device without a bluetooth Mesh protocol stack, for example, a smart phone or a tablet computer (the mobile phone 200 shown in fig. 4 and 5) as a control center is often used in existing smart home. Although used to perform control operations for bluetooth Mesh networks, existing smartphones or tablet computers do not actually have a bluetooth Mesh protocol stack, but are only a low power Bluetooth (BLE) device, i.e., only the BLE layer comprising the protocol layers shown in fig. 2. Generally, for bluetooth Mesh communication, an APP including a GATT bearer layer needs to be installed in a smart phone or a tablet computer, so that interaction with other bluetooth devices via the GATT is achieved through a proxy node and a proxy protocol is encapsulated outside an ADV format data packet. In the present invention, although a node (e.g., a smart phone) may also be provided with a GATT bearer layer (e.g., to communicate with other bluetooth Mesh devices), it selects to communicate with a device to be accessed (e.g., a bluetooth lamp waiting for access) through broadcast conforming to BLE protocol, and can perform operations of steps required to initiate configuration.

In other words, unlike the access to the bluetooth Mesh network through PBGATT (via the start-up configuration of the GATT bearer layer) shown in fig. 1A, the present invention makes use of the broadcast protocol that can be followed by BLE devices, so that bluetooth Mesh devices can still access the bluetooth Mesh network through PBADV (via the start-up configuration of the broadcast bearer layer) in the face of BLE nodes.

In one embodiment, the start-up configuration operation performed in step 330 may be a network configuration operation performed by the node and the device at a Mesh networking provisioning level, and then the device may further perform classical network configuration operations (as described in steps 1 to 5 above).

Due to the interaction between bluetooth Mesh devices and conventional BLE devices as nodes, broadcast via ADV format, in the low power bluetooth protocol issued, the broadcast packet of BLE does not include a type specific to bluetooth Mesh network start-up configuration. For this reason, devices and nodes need to agree on the broadcast type so that the interacting parties can acquire the broadcast packet of that particular type and can resolve it correctly.

When a BLE device is broadcasting, it will periodically send a data packet containing the preamble, access address, CRC, bluetooth address of the sender, etc. the part of interest is typically a broadcast payload (ADVERTISING PAYLOAD) of length 0-31 bytes from the point of view of the developer. The bluetooth stack will automatically populate other fields in the broadcast packet, but the broadcast payload may be under the control of the developer.

Here, "broadcast data" may refer to a 0-31 byte long payload (in the Bluetooth Core specification, this field is referred to as AdvData) that is available to the developer. The broadcast data contains one or more broadcast data (AD) elements. The format of each element is as follows:

first byte length of element (excluding length byte itself)

Second to three bytes broadcast type-specifying which data is contained in the element

Broadcast data, which may contain one or more bytes, has a meaning defined by the broadcast type.

In the present invention, in order to realize the start-up configuration operation, it is necessary to select a broadcast type that is not prone to causing misunderstanding. The broadcast data of the above broadcast type can be modified by a developer, and it is preferable that the broadcast data be of a broadcast type as long as possible.

In one embodiment, manufactureData types may be used as agreed broadcast types, for example. In the bluetooth core specification, the type number of the Manufacturer SPECIFIC DATA is 0xFF, and a vendor message may be included in the broadcast data. Since the Manufacturer SPECIFIC DATA can be used by a developer to add any custom data to the broadcast packet and has 30 bytes of broadcast data, it can be selected as a contracted broadcast type. To this end, when a device is to make a Mesh network access, a node may turn on a scan, and the scan may scan for a particular type of broadcast. For example, when a smartphone (node) starts scanning, instead of scanning PDUs encapsulated based on a conventional proxy protocol (e.g., via the GATT bearer layer), the node may scan the received conventional BLE broadcast and read its second and third bytes of data, which if 0xFF, indicates that this is an access request issued by the device based on the agreed type, and the node may proceed with subsequent data transmissions accordingly.

In one embodiment, the node (e.g., handset 200 shown in fig. 4 and 5) and the device (e.g., bluetooth lamp 400 shown in fig. 4 and 5) may use a different type of broadcast of the contract in each step of interaction of the startup configuration. For example, different broadcast types are used during the exchange key or authentication phase. In another embodiment, the node and the device may each use a different broadcast type in each step of interaction of the startup configuration, e.g., the node always uses one broadcast type and the device always uses another broadcast type.

However, it is preferred that the subsequent broadcast packets that the node and device interact with in the start-up configuration may also have the same broadcast type as the access request, e.g. the second to three bytes of data are all 0xFF. At this point, the specific operation type of each step involved in the start-up configuration may be agreed upon in the broadcast data (i.e., payload) portion of the broadcast data packet.

In particular, a particular type of broadcast may include a fixed header that indicates identity, a particular type of operation, and packet information. The above "fixed header" is not a header of the specific type of broadcast in the bluetooth core protocol, but a fixed header located in broadcast data (i.e., payload) of the specific type of broadcast, which is agreed with the device and the node. Before the above "fixed header", a "real" header of the symbol bluetooth core protocol of the element length and broadcast type (e.g., 0 xFF) is also included.

In the agreed fixed header, a certain field of fixed order (e.g., the nth byte, or several bytes, in the fixed header) may be assigned to a specific operation type. The specific operation type may indicate different operations in the start-up configuration by different numbers. For example, the number a refers to an access request, the number B refers to transmitting configuration information of a distribution network, the number C refers to receiving a configuration reply acknowledgement (Ack), and the number D refers to issuing a random number. It should be understood that A, B, C, D herein refers to different numbers, rather than to actual values of the numbers. Thus, by reading a specific byte of a payload of a specific type of broadcast, the meaning of data contained in the data packet can be confirmed and the corresponding operation can be performed.

In addition to the specific operation type, the identity of the single party or both parties involved in the operation, as well as the information of the package itself, should be declared in the agreed fixed header. For example, the declared identity may be an identity of the device to be accessed, such as a manufacturer, version number, device identifier, etc. The information of the packet itself may include the number of packets included in the current operation type, the number of the current packet, the message ID, the packet length, etc.

After the agreed fixed header, a payload portion for transmitting data required for a specific start configuration operation may be further included. The payload portion is a portion of data immediately after the header is fixed, among the specific type of broadcast-by-itself data (payload). Such as issued random numbers, check data, etc.

Since each BLE broadcast packet has a limited length, for example, a Manufacturer SPECIFIC DATA has 30 bytes of broadcast data and a fixed header for explaining the situation is also included in the available broadcast data, a payload portion for transmitting data required for a specific start configuration operation has a limited length. To this end, the method may further comprise determining whether to perform the unpacking 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 packet number and the current packet number, for example, a partial field included in the information for referring to the packet itself in the fixed packet header as above.

After the device to be accessed completes the start-up configuration operation, the device to be accessed (e.g., bluetooth lamp 400 shown in fig. 4) accesses the bluetooth Mesh network, becomes a node in the network (e.g., bluetooth lamp 400 shown in fig. 5) and can interact with other nodes within the bluetooth Mesh network using ADV format broadcast. For example, the accessed device 400 (which may also be referred to as a "node" at this time) interacts with the aforementioned node, which may still use the AD format broadcast. For example, broadcast data packets of the agreed broadcast type and the agreed header format are also used for communication. For example, after the bluetooth lamp is connected to the bluetooth Mesh network, it may still receive operations from the smart phone, such as turning on, turning off, and adjusting brightness, etc., through BLE broadcasting.

In addition, although the device to be accessed realizes access authentication with the BLE device through the broadcast data of the appointed type and format, after the Mesh network is accessed to be called a node, the accessed device can use the broadcast of the ADV format to perform conventional broadcast interaction with the Bluetooth Mesh node in the Bluetooth Mesh network. For example, in the example of fig. 5, bluetooth lamp 400 interacts with smart speaker 100, such as receiving control instructions from smart speaker 100, using conventional broadcasts in a Mesh network. Specifically, the accessed device can directly use the broadcast bearing layer in the bluetooth Mesh protocol stack to perform conventional communication with other bluetooth Mesh nodes. For example, the smart speakers may send broadcast messages via their broadcast bearer layer to control the bluetooth devices after access.

In other words, the device 400 communicates with the bluetooth Mesh device and the BLE device based on different rules for different nodes (e.g., the bluetooth Mesh device 100 and the BLE device 200) after the device to be accessed accesses the bluetooth Mesh network, although broadcast communication with other nodes within the network is possible.

Because the device to be accessed is the Bluetooth Mesh device which does not have the GATT bearing layer and only comprises the broadcast bearing layer, the device to be accessed can perform conventional communication conforming to the Bluetooth Mesh rule with other Bluetooth Mesh devices in the Bluetooth Mesh network. However, for the BLE device accessing the bluetooth Mesh network, GATT communication cannot be performed with the BLE device, so that only specific types of broadcast data agreed by both parties can be used for communication.

Since the device may have its own "identity", i.e. network ID, after completing the access of the distribution network to the bluetooth Mesh network, the network ID of the device may be used as the identity of the device instead of the device identifier (e.g. MAC address or a part thereof) used before in the broadcast of the interaction after the access of the device. In other words, part of the fields of the agreed header in the subsequent broadcast may be replaced.

After a description of the broadcast type and composition, the start-up configuration flow will be described in more detail below.

The access request sent by the device to the node may contain identity data of the device, such as a unique identity identifier (ProductKey) of the device and identity information such as a device name (DEVICENAME). The identity information can help the node to determine the identity of the equipment to be accessed, and the cloud terminal can conveniently inquire the corresponding information when the authentication of the cloud terminal operation is involved. In other embodiments, the above-mentioned identity information may also be included in subsequent requests of the access request. For example, the device may indicate an access intention and a device type in an access request, and send identity information via broadcast after having responded to by the node.

After receiving these identity data, the node may complete the startup configuration of the device to access the bluetooth Mesh network based on the identity data.

Authentication of the device to connect the node can be realized only through an authentication flow between the device and the node, and participation of a cloud authentication platform can also be involved. In the authentication process related to cloud, the authentication of the node to connect the device 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 the authentication of the device to connect the node.

The authentication method comprises the steps that the node sends identity data of the equipment to a server, the equipment generates check data based on secret data stored locally and sends the check data to the node, the node forwards the check data to the server, the server searches secret data corresponding to the equipment based on the identity data and checks the check data based on the secret data, and the node completes authentication of the equipment connected with the node based on the check success.

In particular, the node may send the identity data of the device to the server. As mentioned before, the above-mentioned identity data may be sent in connection with an access request of the device, or via a subsequent information transmission. Based on a predetermined rule or an instruction of the node, the device may generate check data based on the locally stored secret data and send the check data to the node. The node may then forward the verification data to the server. The server may find secret data corresponding to the device based on the identity data of the device obtained previously, and verify the verification data based on the secret data. If the verification is successful, the server issues a notification. Subsequently, the node may complete authentication of the device connection node based on the verification success.

From this, through the introduction of secret data that only is known by thing networking device and high in the clouds platform, can realize high security authentication of high in the clouds platform to thing networking device identity to avoid the node to the knowledge of secret data. To ensure security, secret data may be avoided from propagating in the air in the clear, or in a form that can be deduced. Thus, in one embodiment, the verification data generated based on the secret data may be generated in a manner that does not back-extrapolate the complete secret data. Even if the node knows the check data or the check data is intercepted by the other party, the complete secret data cannot be recovered from the check data. Similarly, the communication key generated based on the secret data as follows may also be generated in such a way that the complete secret data cannot be back-deduced.

In order to achieve an accurate indication of the identity of itself and a correct lookup of secret data by the server, the data packet broadcast by the device may include the unique identity identifier of the device, and the identity data of the device sent by the node to the server may include the above-mentioned unique identity identifier obtained from the access request or subsequent transmission information. For example, in different implementations, the device may fill in a product identifier (product id, PID) or MAC address, or both PID and MAC, in the access request or subsequent transmission information. Preferably, identity and secret data of the internet of things device can be maintained by the cloud, and data burning is performed before the device leaves the factory. In one embodiment, the cloud may assign each of the internet of things devices a triplet including a PID, a MAC address, and secret data. The triples are pre-burned in the device and avoid the secret data from propagating over the air in a deducible form. In order to further improve the safety, the cloud can allocate different secret data for each device, so that one machine is secret. Thus, cracking one device does not affect other devices of the same model.

In one embodiment of the invention, the authentication of the connection of the device to the node may be done based on only a one-way check of the check data from the device by the server as referred to in the above steps. Thus, the server can determine the identity of the device based on the secret data verified in the verification data. For example, a device reporting a particular PID and/or MAC uses the same locally stored secret data as the corresponding secret data recorded by the cloud to generate verification data, thereby enabling the cloud to confirm that the device reporting the particular PID and/or MAC is the device itself having the particular PID and/or MAC (i.e., not other devices lie in identity to connect).

In other embodiments, the completion of the connection authentication may also include verification of the server identity by the device. For example, the server may generate second verification data based on the retrieved secret data for verification by the device based on the local secret data.

In a preferred embodiment, the authentication of the server identity by the device may be achieved by a change in the use of an encryption key between the device and the node. Accordingly, the connection method of the present invention may further include the server and the device each generating a communication key based on the secret data held by each according to a predetermined rule, the server transmitting the communication key to the node, and performing data encrypted communication between the device and the node using the communication key. Thus, in case the communication key provided by the server at the node is different from the communication key with which the device encrypts the data, the instant node establishes a connection with the device and obtains the data from the device, and the received data cannot be encrypted due to the inconsistency of the communication keys.

Still further, since the communication key is generated by the server and the device, respectively, the transmission of the communication key involves only the transmission of the server to the node and not the transmission between the device and the node. The connection between the server and the node is a private connection between the server and the intelligent terminal with a higher security than the transmission between the first and the node. Thus, transmission of the communication key between the first and the node is avoided, and replay attacks can be effectively avoided.

In order to improve the security, the participation of random numbers can be also involved in the connection authentication of the invention. Thus, the device generating the verification data based on the locally stored secret data may comprise generating the verification data based on the random number and the secret data. The random number may be generated by the device itself and sent via the node to the server for verification, may be generated by the server and sent via the node to the device, or may be generated by the node, and in various embodiments the device may generate the verification data based on one or more random numbers and the secret data. The device generating verification data based on the one or more random numbers and the secret data includes the node generating the one or more random numbers and sending to the device and the server, the device generating verification data based on the secret data and the random numbers, and the server verifying the verification data based on the secret data includes the server verifying the verification data based on the random numbers and the secret data.

For example, the device may encrypt the received random number as a check ciphertext using the secret data as a key, e.g., using the AES128CBC algorithm. After receiving the check ciphertext, the server may decrypt the check ciphertext using the searched secret data and check whether the decrypted random number is the same, thereby determining whether the check is successful. It should be appreciated that other encryption algorithms may be used based on such factors as computational effort, for example, using a relatively simple RC5 block encryption algorithm to encrypt the random number, so long as the interceptor of the verification data cannot derive the secret data itself in the reverse direction from the random number.

The random number may also be used for subsequent generation of the communication key. To this end, the server and the device may each generate a communication key based on the secret data and the random number according to a predetermined rule, and the communication key is transmitted to the node by the server. The communication key may then be used for data encrypted communication between the device and the node. The data encryption communication performed after authentication is completed may be wireless encryption communication via bluetooth or WiFi, and a key of the communication may be transmitted via a power line.

In one embodiment, the communication key may be generated based on the secret data, the random number, and a unique identity identifier of the device. The unique identifier may be included in a broadcast packet and served by the node. As such, it is desirable to determine that the interceptor cannot reverse-infer the complete secret data from the generated communication key. For example, in one embodiment, the communication key may be defined as BLEkey = SHA256 (Random, PID, MAC, secret). That is, the character string data of four values of Random number (Random), PID, MAC and Secret are connected by English comma, then SHA256 abstract calculation is carried out, and the first 16 bytes are taken. After the communication key is generated, data encryption may be performed using a corresponding algorithm, such as an AES128CBC algorithm and an RC5 block encryption algorithm.

To ensure security, the mutual authentication is preferably performed using a different random number each time the device attempts to connect to the node. Since a different random number is used each time, each connection of the device will request the server to generate a new BLE Key, and after each disconnection, the first and nodes need to clear the currently used BLE Key.

Further, the cloud may record a Random value within a period of time, and consider the device to be cracked if repeated Random is encountered. For this purpose, the device access method of the present invention may further include the server recording a random number used each time the device tries to connect to the node within a predetermined period of time, and the server determining that the node has been hacked when the recorded random number includes a repeated random number. The server may then instruct the node to take a corresponding action, such as disconnecting the device, etc.

In addition, the server may assign network parameters to the devices at the appropriate time. After the connection authentication of the device is completed, the node transmits network configuration data based on the network parameters to the device.

The above device access scheme of the present invention may also be implemented as a system for device access to a network. Fig. 4 shows a composition example of an access system implemented by the present invention. As shown in fig. 4, the system comprises a device 400 to be connected to a bluetooth Mesh network and a node 200 in the bluetooth Mesh network, which is a low power bluetooth device without a bluetooth Mesh protocol stack, such as a smart phone. For accessing 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 check data based on locally stored secret data and transmit an ADV format broadcast with the check data. Correspondingly, the node 200 is configured to receive the access request, and perform a startup configuration operation of the device to connect to the bluetooth Mesh network based on the access request.

The device and the node interact as required for boot configuration with a agreed specific type of broadcast, and the specific type of broadcast includes a boot configuration type field for indicating a specific operation type. The specific type broadcast includes a fixed header for indicating identity, specific operation type and packet information, and a payload portion for transmitting data required for specific start-up configuration operations. For example, it may be agreed to use ManufactureData type (type number 0 xFF) for message propagation. And the composition of the header is agreed in the broadcast data broadcasted by ManufactureData.

Preferably, the system is a system comprising nodes in the bluetooth Mesh network. As shown in fig. 4, other bluetooth Mesh devices 100, such as a television, an electric cooker, and a smart speaker, have been connected to the bluetooth Mesh network. Fig. 5 shows an example after device access. As shown in fig. 4 and 5, for conventional bluetooth Mesh devices 100 equipped with a GATT bearer layer, such as televisions, rice cookers, and smart speakers, the BLE device 200 may interact with these devices 100 based on the GATT.

In contrast, as shown in fig. 5, the accessed device 400 may perform conventional broadcast interaction with other nodes in the system that have a bluetooth Mesh protocol stack. The bluetooth lamp 400 may interact with the smart speaker 100 in a conventional broadcast, e.g., the smart speaker 100 may send an on command to the bluetooth lamp 400 via a conventional broadcast after receiving a user's "on" voice command. The accessed device 400 can also perform appointed specific type broadcasting interaction with nodes without a Bluetooth Mesh protocol stack in the system. For example, bluetooth lamp 400 may continue to interact with smartphone 200 in a broadcast consistent manner, e.g., continue message dissemination via ManufactureData type (type number 0 xFF).

The authentication may also involve cloud participation, and for this purpose, the present invention may also be implemented as a cloud access system, including a system for accessing a network by a device as described above, and a server, such as server 300 shown in fig. 4. The node 200 in the access system communicates with the server 300 via wireless transmission, wherein the access request contains identity data of the device. The node is used for sending the identity data of the equipment to the server, receiving the verification data from the equipment and forwarding the verification data to the server, and completing the connection authentication with the equipment when the verification of the server is passed. The server is used for receiving the identity data of the equipment sent by the node, searching secret data corresponding to the equipment based on the identity data, receiving the verification data sent by the node and verifying based on the searched secret data.

The method of device access to a network and the corresponding device access system according to the invention have been described above in connection with fig. 3-5. An example of a device distribution network procedure based on BLE broadcasting according to the present invention will be described below with reference to fig. 6.

As shown in fig. 6, the internet of things device 400 accesses the node 200 (e.g., operates through an APP installed on the mobile phone 200), and then the process of accessing the internet of things (starting a configuration flow) requires participation of the cloud platform 300, and specifically involves the following steps:

app 200 obtains startup configuration information, such as related information of the existing bluetooth Mesh network, user data, and the like.

2. The user gives instructions to scan the XXX device. For example, the user may click on an icon in APP 200 to add a new device, or may further select the type of device to add. In some embodiments, the above types may indicate that the device 400 does not include a GATT bearer layer, and thus the nature of data transmission using a scheduled broadcast is required.

3. The device 400 may send an access request, for example, by powering up, for example, a broadcast packet in the agreed form as described above.

App 200 receives a user instruction and turns on scanning.

5. After scanning the device, APP 200 enters a distribution flow. For example, a random number required for the distribution network may be first generated. The random numbers are used by the cloud 300 and the device 400 to generate verification data. Two random numbers RandomA and RandomB, random numbers a and B, may be generated. The two random numbers can be uploaded to the cloud in an encrypted form so as to improve security.

6. APP 200 may then send the configuration information for the distribution network.

7. Accordingly, device 400 sends a receipt of a configuration reply acknowledgement (Ack).

8. After receiving the Ack, APP 200 may send RandomA and RandomB to the device, for example, in an alternating transmission of two packets. The random numbers may be used for generation of verification data for each of the cloud 300 and the device 400.

9. For this purpose, APP 200 sends a random number in encrypted form, e.g., randomB a, to the cloud for verification of the generation of data. Meanwhile, APP 200 may also send confirmation key ConfirmationKey to cloud 300.

10. Cloud 300 records the random number uploaded by APP 200, e.g., randomB a, and uses the secret data of cloud-stored device 400 to generate verification data (i.e., confirmationCloud) for use in authenticating the identity.

11. Cloud 300 issues verification data (i.e., confirmationCloud) to APP 200.

12. Meanwhile, the device 400 may agree with rule generation to generate RandomB i a from RandomA and RandomB and generate check data (i.e., confirmationDevice) using self-burnt secret data (e.g., triplet data including secret data).

13. The device then sends the generated check data (i.e., confirmationDevice) to the APP 200.

App 200 reports the acquired device check data (i.e., confirmationDevice) to cloud 300 and may send RandomB i a again.

15. The cloud 300 compares whether the verification data (ConfirmationDevice) generated by the device is consistent with the result (ConfirmationCloud) of the cloud computing. If so, record RandomB A.

16. Subsequently, the cloud 300 issues a send authentication pass message to the APP 200.

Apps 200 may use the prior acquisition (ConfirmationCloud) as a key and encrypt the transmit distribution network data to device 400 via ConfirmationCloud. Two packets may also be sent alternately, due to the payload constraints in the agreed broadcast.

18. Subsequently, the device 400 replies to the success of the network allocation.

After the apps 200 receive the message, they start the standard Mesh distribution network flow.

Apps 200 and device 400 complete the distribution network through interactions. At this point, device 400 may generate DEVICEKEY from the stored secret data and provide to APP200.

Apps 200 notify the user of the success of the distribution network.

The app200 band DEVICEKEY reports successful network allocation, and subsequent communication can be encrypted by DEVICEKEY.

23. Finally, cloud 300 notifies APP 200 to begin subsequent communications with device 400, such as classical distribution with device 400. That is, after the provisioning of the provisioning layer is successful, classical Mesh networking is performed.

After accessing the bluetooth Mesh network, the device 400 may receive control from the BLE device 200 in a agreed broadcast manner, except that it may receive conventional control of the bluetooth Mesh device (e.g., a smart speaker) as shown in fig. 5. The interactions broadcast via conventions described above may be regarded as interactions that are not in the Mesh network.

1. The user gives instructions to control the XXX device. For example, the user may click on a device icon in APP200 to further select an operation to be performed, such as selecting to turn on bluetooth light 400.

App 200 may query the cloud to obtain corresponding instruction information.

3. Cloud 300 can reply to APP 200 with an instruction.

4. Subsequently, as shown in the Alt box, since the device 400 is a device that does not include the GATT bearer layer, the APP200 communicates with the device 400 in a contracted broadcast, and the above-described interaction can be regarded as an interaction outside the Mesh network.

The APP 200 then intercepts at the Network layer, breaks the outgoing packets into small parts for emission in the BLE broadcast in the agreed format.

5. As indicated by the Alt box, if the Network ID (Network ID) contained in the BLE broadcast matches the assigned Network ID of the device 400, the device will record the corresponding data.

Specifically, the device 400 may (1) record unicastaddress (unicast address) of the devices included in the BLE broadcast to make sure that the BLE broadcast needs to be used when replying again. The device 400 may also (2) store the corresponding msgld (message number) packets, thereby concatenating the complete data for parsing.

6. Since the APP 200 will repeatedly send the broadcast of the same content, the device 400 may discard broadcast packets consistent in content for this purpose.

7. After the parsing is completed, the device 400 may perform a corresponding operation, such as turning on the bluetooth lamp 400 and replying to the response by broadcasting.

Apps 200 may listen for ACCS messages and notify the user of the results.

Apps 200 may inform whether the control was successful or failed. For example, it is shown that the bluetooth lamp 400 has been turned on.

10. Outside of the agreed broadcast communications of the present invention, APP200 may interact with other devices within the Mesh network in the original logic (e.g., GATT).

As previously indicated, the internet of things device capable of executing the scheme has the capability of generating a broadcast in a contracted format and parsing the broadcast in a corresponding format. Fig. 8 shows a schematic diagram of the composition of an internet of things device according to an embodiment of the invention.

As shown, the internet of things device 400 may include a processing module 410 and a communication module 420. In some embodiments, the communication module 420 may be implemented by a bluetooth Mesh chip. Unlike conventional chips that include GATT bearer layers, the bearer layer of the bluetooth Mesh chip of the present invention may include only a broadcast bearer layer and communicate with BLE devices via agreed broadcast types and formats to complete start-up configuration and subsequent control operations. Thereby, the price of the internet of things device 400 can be reduced. This is crucial for cost control of devices that are relatively simple in function and relatively inexpensive, e.g. bluetooth lamps.

Specifically, the processing module 410 is configured to generate an ADV format access request and subsequent ADV format broadcast and data contained therein required to initiate a configuration operation. The communication module 420 is used for receiving and transmitting the ADV format broadcast required for starting the configuration operation. Here, the access request and the subsequent ADV format broadcast have a contracted broadcast type.

In one embodiment, the access request or subsequent broadcast sent via the communication module includes the identity data of the internet of things device. For example, the identity data of the device 400 may be included in the broadcast data packet of step 3 shown in fig. 6.

Further, the communication module 420 may be configured to transmit verification data generated based on the locally stored secret data. The processing module 410 may be configured to generate verification data based on the secret data stored locally, and complete a start configuration operation with the bluetooth Mesh network after receiving a message that the verification is successful. The device 400 may further comprise a storage module for storing said secret data and said identity data. The storage module can comprise a burning storage element for burning and storing a unique identity identifier indicating the identity of the internet of things device and the secret data. For example, corresponding triplet data (PID, MAC, and Secret) of each internet of things device may be pre-burned (e.g., burned before shipping). Meanwhile, a list containing triples of each Internet of things device can be stored in the cloud database.

After accessing the bluetooth Mesh network, the communication module 420 may be configured to interact with low-power bluetooth devices in the network that do not have a bluetooth Mesh protocol stack using ADV format broadcast of a contracted broadcast type, as described above, and perform conventional broadcast interactions with other nodes in the network that have a bluetooth Mesh protocol stack.

As previously described, the internet of things device 400 and BLE device 200 (nodes in the bluetooth Mesh network) may exchange data required for the startup configuration via a broadcast of a contracted type. For example, message propagation is via a ManufactureData type (type number 0 xFF) broadcast. The above-described type convention requires that the internet of things device 400 and BLE device 200 follow together. However, for some BLE devices 200, such as a mobile phone with an iOS system installed, the type ManufactureData may not be modified due to the closed-type iOS system, and other modifiable types may be selected for transmission, such as ServiceUUID (type number 0x 16). In other words, the mobile phone of the iOS system may receive a ManufactureData type broadcast but cannot transmit the type, for which purpose a ServiceUUID type broadcast may be selected.

To this end, the processing module 410 may be configured to generate an access request having an ADV format of a first contract type, and receive a returned ADV format broadcast, determine whether the broadcast type of the received broadcast is the first contract type or the second contract type, parse the received broadcast based on the determined type, and generate and transmit a subsequent ADV format broadcast having the first contract type. For example, the internet of things device 400 may broadcast ManufactureData type access requests in step 3 as shown in fig. 6, and based on the broadcast type (e.g., 0xFF or 0x 16) of the feedback broadcast of APP200 received in step 6, confirm the type of BLE device, and then choose to parse the broadcast of the specific type. Since the iOS system can still receive and parse ManufactureData types of broadcasts, the device 400 can always select ManufactureData types of broadcasts for messaging.

Correspondingly, the invention can also be realized as a terminal device. The terminal device may be a conventional device with a BLE protocol stack, such as a smart phone or tablet. Fig. 9 shows a schematic composition of a terminal device according to an embodiment of the invention.

As shown in fig. 9, the terminal device 200 includes a processing module 210 and a bluetooth communication module 220. The bluetooth communication module 220 is configured to receive an ADV format access request broadcasted by the internet of things device. The processing module 210 is configured to perform a start configuration operation with the internet of things device via an ADV format broadcast based on the access request. Further, the bluetooth communication module 220 is configured to send a control instruction to the internet of things device via ADV format broadcast after the internet of things device accesses the bluetooth Mesh network. Specifically, the bluetooth communication module 220 may be a bluetooth module of the terminal device 200, which includes a low-power bluetooth protocol, and further, a corresponding APP may be installed on the device 200, which can interact with the previous internet of things device 400 in a agreed broadcast type and format. In other words, the ADV format broadcast transmitted and received by the bluetooth communication module 220 has an agreed broadcast type and an agreed header composition.

Further, the APP installed on the device 200 may also include the GATT bearer function, thereby facilitating conventional communications with other bluetooth Mesh devices via the GATT, such as PB-GATT (start-up configuration via the GATT.

The invention can also be realized as a method for connecting with the Internet of things equipment. Fig. 10 shows a schematic flow chart of a method of connecting with an internet of things device according to one embodiment of the invention. The method may be performed by the terminal device 200 as described above.

In step S1010, an ADV format access request broadcast by the internet of things device is received via the bluetooth communication module. In step S1020, a start-up configuration operation with the internet of things device is performed via an ADV format broadcast based on the access request, wherein the ADV format broadcast has a contracted broadcast type and a contracted header composition.

Here, the bluetooth communication module is a special communication module that can communicate with the internet of things device in a contracted broadcast type and format (e.g., a contracted packet header).

The above-described start-up configuration procedure may start with a scan of the terminal device, for which purpose the method may further comprise starting the scan, wherein the scan comprises a scan for a contract type broadcast.

Furthermore, the method according to the invention may also be implemented as a computer program or computer program product comprising computer program code instructions for performing the steps defined in the above-mentioned method of the invention.

Or the invention may also be embodied as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) having stored thereon executable code (or a computer program, or computer instruction code) that, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform the steps of the above-described method according to the invention.

Those of skill would 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.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The foregoing description of embodiments of the invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the improvement of technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method of a device accessing a network, comprising:

The equipment broadcasts an access request in an ADV format;

A node of the Bluetooth Mesh network receives the access request, wherein the node is a low-power Bluetooth device without a Bluetooth Mesh protocol stack, and a broadcast packet of the low-power Bluetooth does not comprise a type special for starting configuration of the Bluetooth Mesh network;

The node performs a start-up configuration operation of accessing the device to the bluetooth Mesh network based on the access request,

The equipment and the node agree on the broadcast type, so that the interaction parties can acquire the broadcast packet in the ADV format and can correctly analyze the broadcast packet.

2. The method of claim 1, wherein the node performing a startup configuration operation to access the device to the bluetooth Mesh network based on the access request comprises:

the node and the device complete the startup configuration through subsequent interactions broadcast via the ADV format.

3. The method of claim 2, wherein the device and the node broadcast interactions required to initiate configuration with a contracted specific type.

4. The method of claim 3, wherein the specific type broadcast includes a launch configuration type field for indicating a specific operation type.

5. The method of claim 3, wherein the specific type broadcast includes a fixed header indicating identity, specific operation type, and packet information.

6. The method of claim 5, wherein the particular type of broadcast includes a payload portion for transmitting data required for a particular start-up configuration operation.

7. The method of claim 6, further comprising:

determining whether to perform unpacking transmission based on a maximum length of the payload portion and a length of data to be transmitted, wherein the specific type broadcast includes a packet number field for indicating a total packet number and a current packet number.

8. A method as in claim 3, further comprising:

The node turns on a scan, wherein the scan includes a scan for the particular type of broadcast.

9. The method of claim 1, further comprising:

the node interacts with the accessed device using ADV format broadcast.

10. The method of claim 9, wherein the network ID of the device is used as an identity of the device instead of the MAC address of the device in the broadcast of the interaction after the device is accessed.

11. The method of claim 9, further comprising:

and the accessed equipment uses the ADV format broadcast to interact with other nodes in the Bluetooth Mesh network.

12. The method of claim 1, wherein the access request contains identity data of the device, and the node completes a startup configuration of the device to access the bluetooth Mesh network based on the identity data.

13. The method of claim 12, wherein the authenticating of the device to connect the node based on the access request comprises:

The node sends the identity data of the equipment to a server;

the device generates check data based on secret data stored by the device and sends the check data to the node;

the node forwards the check data to the server;

the server searches the secret data corresponding to the equipment based on the identity data and verifies the verification data based on the secret data, and

And the node completes the authentication of the equipment connected with the node based on the successful verification.

14. The method of claim 13, wherein the device generating verification data based on the locally stored secret data comprises:

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 generating verification data based on the locally stored secret data comprises:

The device generates verification 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 comprises:

The node generating the one or more random numbers and sending to the device and the server;

the device generates check 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 a device to access a network, comprising a device to be accessed to a bluetooth Mesh network and a node in the bluetooth Mesh network, the node being a low power bluetooth device without a bluetooth Mesh protocol stack, and a broadcast packet of the low power bluetooth not including a type specific to bluetooth Mesh network initiation configuration, wherein:

The device is used for:

broadcasting an access request in an ADV format;

Generating verification data based on the locally stored secret data and transmitting an ADV format broadcast with said verification data,

The node is configured to:

Receiving the access request, and

The node performs the start configuration operation of the device to connect with the Bluetooth Mesh network based on the access request,

18. The system of claim 17, wherein the device and the node interact as required for boot configuration with a contracted specific type broadcast, and the specific type broadcast includes a boot configuration type field for indicating a specific operation type.

19. The system of claim 18, wherein the particular type of broadcast comprises:

fixed header for indicating identity, specific operation type and packet information, and

A payload section for transmitting data required for a specific start-up configuration operation.

20. The system of claim 17, wherein the system is a system comprising nodes within the bluetooth Mesh network, wherein,

The accessed device performs conventional broadcast interaction with other nodes with Bluetooth Mesh protocol stack in the system, and

And the accessed equipment performs appointed specific type broadcasting interaction with a node which does not have a Bluetooth Mesh protocol stack in the system.

21. A cloud access system comprising the system of any of claims 17-20, and a server with which nodes in the access system communicate via wireless transmissions, wherein the access request contains identity data of the device,

The node is configured to:

transmitting identity data of the device to the server;

receiving verification data from the device and forwarding to the server, and

When the server checks to pass, the connection authentication with the device is completed,

The server is used for:

receiving the identity data of the equipment sent by the node;

searching secret data corresponding to the equipment based on the identity data;

And receiving the verification data sent by the node and verifying based on the searched secret data.

22. An internet of things device, comprising:

A processing module for:

generating an access request in an ADV format and starting an ADV format broadcast required for a configuration operation and data contained therein,

A communication module for:

the ADV format broadcast required to initiate configuration operations is transceived,

Wherein the access request and the ADV format broadcast have agreed broadcast types,

Wherein the access request is received by a node of the bluetooth Mesh network, the node is a low-power bluetooth device without a bluetooth Mesh protocol stack, and the broadcast packet of the low-power bluetooth does not comprise a type which is specially used for the starting configuration of the bluetooth Mesh network,

The Internet of things equipment and the nodes agree on the broadcast type, so that the interaction parties can acquire the broadcast packet in the ADV format and can accurately analyze the broadcast packet.

23. The apparatus of claim 22, wherein,

The access request or subsequent broadcast sent by the communication module comprises the identity data of the internet of things device.

24. The apparatus of claim 23, wherein,

The communication module is used for:

transmitting verification data generated based on the locally stored secret data,

The processing module is used for:

Verification data generated based on the locally stored secret data;

Completing the start configuration operation with the Bluetooth Mesh network after receiving the successful verification message, and

The Internet of things device further comprises a storage module, wherein the storage module is used for:

The secret data and the identity data are stored.

25. The device of claim 24, wherein the storage module comprises:

And a burning storage element for burning and storing the unique identity identifier indicating the identity of the equipment of the Internet of things and the secret data.

26. The apparatus of claim 22, wherein after accessing the bluetooth Mesh network, the communication module is configured to:

Interacting with the node using an ADV format broadcast of the agreed broadcast type, and

And carrying out conventional broadcast interaction with other nodes with Bluetooth Mesh protocol stacks in the network.

27. The apparatus of claim 22, wherein the processing module is to:

Generating an access request in an ADV format having a first contract type;

receiving returned broadcast in the ADV format, and judging whether the broadcast type of the received broadcast is a first contract type or a second contract type;

parsing received broadcast based on type of determination, and

A subsequent ADV format broadcast having the first contract type is generated and transmitted.

28. A terminal device, comprising:

Bluetooth communication module:

The method comprises the steps of receiving an access request in an ADV format, which is broadcasted by an Internet of things device;

A processing module for:

performing a start-up configuration operation with the internet of things device via an ADV format broadcast based on the access request, and

The Bluetooth communication module is used for:

After the internet of things equipment is accessed to the Bluetooth Mesh network, a control instruction is sent to the internet of things equipment through an ADV format broadcast,

Wherein the terminal device is used as a node of the Bluetooth Mesh network to receive the access request, the terminal device is a low-power Bluetooth device without a Bluetooth Mesh protocol stack, the broadcast packet of the low-power Bluetooth does not comprise a type special for the starting configuration of the Bluetooth Mesh network,

The nodes and the Internet of things equipment agree on broadcast types, so that the interaction parties can acquire broadcast packets in an ADV format and can accurately analyze the broadcast packets.

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