WO2022011563A1

WO2022011563A1 - Internet of things configuration method and apparatus, computer device, and storage medium

Info

Publication number: WO2022011563A1
Application number: PCT/CN2020/101950
Authority: WO
Inventors: 茹昭
Original assignee: Oppo广东移动通信有限公司
Priority date: 2020-07-14
Filing date: 2020-07-14
Publication date: 2022-01-20
Also published as: CN115486038A

Abstract

The present application relates to the technical field of Internet of Things, and discloses an Internet of Things configuration method and apparatus, a computer device, and a storage medium. The method comprises: receiving, by an OCF bridge device, a network configuration request sent by an OCF client, the network configuration request comprising an attribute value of a configuration attribute; determining a non-OCF virtual client corresponding to the network configuration request; sending a network configuration instruction to the non-OCF virtual client, the network configuration instruction being used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value, and the configuration operation being an operation of configuring a non-OCF protocol network corresponding to the non-OCF virtual client. The solution implements configuration of a non-OCF protocol network by an OCF client, thereby improving the network management effect on the Internet of Things.

Description

Internet of things configuration method, device, computer equipment and storage medium

technical field

The present application relates to the field of wireless communication technologies, and in particular, to an Internet of Things configuration method, device, computer equipment, and storage medium.

Background technique

In the Internet of Things (IOT), the user can remotely control the functional operation of the server device through the client.

In related technologies, the protocol widely used in the Internet of Things is the Open Connectivity Foundation (OCF) protocol. At the same time, there are many servers (which can be called non-OCF servers) that support non-OCF protocols on the market. In order to make the client (OCF client) supporting the OCF protocol compatible with non-OCF server devices, in a feasible solution, the conversion between the OCF protocol and the non-OCF protocol is realized through a bridge platform, which has made the OCF client The endpoint can access the non-OCF protocol network.

SUMMARY OF THE INVENTION

The embodiments of the present application provide an Internet of Things configuration method, apparatus, computer equipment, and storage medium. The technical solution is as follows:

On the one hand, an embodiment of the present application provides a method for configuring the Internet of Things, the method is executed by the OCF bridge platform of the Open Connectivity Foundation, and the method includes:

Receive a network configuration request sent by the OCF client through the OCF bridge device, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is an attribute in a configuration resource supported by the OCF bridge device;

determining a non-OCF virtual client corresponding to the network configuration request;

Send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; the configuration operation is for the Configure the non-OCF protocol network corresponding to the non-OCF virtual client.

On the other hand, an embodiment of the present application provides an IoT configuration device, the device is used in an OCF bridging platform, and the device includes:

A request receiving module, configured to receive a network configuration request sent by an OCF client through an OCF bridge device, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is an attribute in a configuration resource supported by the OCF bridge device ;

a virtual client determination module, configured to determine a non-OCF virtual client corresponding to the network configuration request;

a configuration module, configured to send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; the configuration The operation is an operation of configuring the non-OCF protocol network corresponding to the non-OCF virtual client.

In another aspect, an embodiment of the present application provides a computer device, the computer device includes a processor, a memory, and a transceiver, the memory stores a computer program, and the computer program is configured to be executed by the processor to Implement the above IoT configuration method.

In another aspect, an embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored in the storage medium, and the computer program is loaded and executed by a processor to implement the above-mentioned method for configuring the Internet of Things.

In another aspect, a computer program product or computer program is provided, the computer program product or computer program comprising computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned method for configuring the Internet of Things.

The technical solutions provided in the embodiments of the present application can bring the following beneficial effects:

The OCF bridge device is provided with a configuration resource for configuring the non-OCF protocol network. When a network configuration request sent by the OCF client is received through the OCF bridge device, and the network configuration request includes the attribute value of the configuration attribute in the configuration resource When , the non-OCF virtual client is instructed to perform the configuration operation on the non-OCF protocol network, thereby realizing the configuration of the non-OCF protocol network through the OCF client, thereby improving the network management effect of the Internet of Things.

Description of drawings

In order to illustrate the technical solutions in the embodiments of the present application more clearly, the following briefly introduces the drawings that are used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained from these drawings without creative effort.

1 is a schematic diagram of a network architecture of the Internet of Things provided by an embodiment of the present application;

2 is a schematic diagram of a bridge model from the Zigbee protocol to the OCF protocol involved in the embodiment shown in FIG. 1;

3 is a flowchart of an Internet of Things configuration method provided by an embodiment of the present application;

4 is an architectural diagram of a network configuration involved in the embodiment shown in FIG. 3;

5 is a flowchart of a method for configuring the Internet of Things provided by an embodiment of the present application;

Fig. 6 is a kind of starting non-OCF protocol network involved in the embodiment shown in Fig. 5;

7 is a schematic diagram of an operation flow of stopping a non-OCF protocol network involved in the embodiment shown in FIG. 5;

Fig. 8 is the operation flow chart of modifying the non-OCF protocol network key involved in the embodiment shown in Fig. 5;

FIG. 9 is a schematic diagram of another startup non-OCF protocol network involved in the embodiment shown in FIG. 5;

10 is a schematic diagram of another startup non-OCF protocol network involved in the embodiment shown in FIG. 5;

11 is a block diagram of an IoT configuration apparatus provided by an embodiment of the present application;

FIG. 12 is a schematic structural diagram of a computer device provided by an embodiment of the present application.

detailed description

In order to make the objectives, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

The network architecture and service scenarios described in the embodiments of the present application are for the purpose of illustrating the technical solutions of the embodiments of the present application more clearly, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. The evolution of new business scenarios and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

Please refer to FIG. 1 , which shows a schematic diagram of a network architecture of the Internet of Things provided by an embodiment of the present application. The network architecture of the Internet of Things may include: a non-OCF server 110, an OCF bridge platform 120, and an OCF client 130;

The non-OCF server 110 may be a device for providing IoT functional services. Also, the non-OCF server 110 is a server that supports other communication protocols other than the OCF protocol.

For example, the non-OCF server 110 is a server that supports the Zigbee protocol (such as Zigbee 3.0, a wireless network protocol for low-speed and short-distance transmission), or the non-OCF server 110 supports the Bluetooth protocol, such as Bluetooth low energy The server of the (Bluetooth Low Energy, BLE) protocol.

For example, the server 110 may be a smart home device, such as a smart TV, a smart air conditioner, a smart refrigerator, a smart microwave oven, a smart rice cooker, a cleaning robot, and the like.

Alternatively, the server 110 may be industrial production equipment, such as lathes, industrial robots, solar panels, wind turbines, and the like.

Alternatively, the server 110 may be a commercial service device, for example, a vending machine or the like.

Alternatively, the server 110 may be an intelligent monitoring device, such as a monitoring camera, an infrared sensor, a sound sensor, a temperature sensor, and the like.

The OCF client 130 is a terminal device on the user side. For example, the client can be a smart phone, a tablet, a smart watch, etc.; or, the client can also be a personal computer, such as a desktop computer, a laptop computer, a personal workstation, and so on.

The OCF client 130 is a device that supports the OCF protocol.

The OCF bridging platform 120 is a device for bridging the non-OCF server 110 supporting the non-OCF protocol and the OCF client 130 supporting the OCF protocol, so that the non-OCF server 110 supporting different protocols and the OCF client 130 can communicate with each other. .

The OCF bridging platform 120 may be a network device that implements network interconnection above the network layer, also known as a network connector, a protocol converter, and the like. The OCF bridge platform 120 may provide network connection services for the server 110 .

The OCF bridging platform 120 may be a professional gateway, such as a home gateway, or the OCF bridging platform 120 may also be an access device with a gateway function, such as a router with a gateway function.

In this embodiment of the present application, the above-mentioned OCF bridge platform 120 and the OCF client 130 are connected through a wired or wireless network.

Optionally, the above wired or wireless network uses standard communication technologies and/or protocols. For example, the above wired or wireless network may be a communication network based on the IoT protocol of the Internet of Things.

In a mapping relationship scheme from non-OCF protocols such as BLE protocol and Zigbee protocol to OCF protocol, the translation work from other non-OCF protocols to OCF protocol is completed by the OCF bridging platform. Taking the mapping relationship from Zigbee protocol to OCF protocol as an example, Please refer to FIG. 2 , which shows a schematic diagram of a bridge model from a Zigbee protocol to an OCF protocol involved in an embodiment of the present application.

As shown in Figure 2, the IoT network includes an OCF client, an OCF bridge platform and a non-OCF server. The OCF Bridge Platform includes the following components:

Virtual (Virtual) Zigbee client (Client) 21 (or other non-OCF protocol virtual clients such as Virtual BLE Client): Virtual Zigbee Client is a virtual Zigbee 3.0 client, the virtual device can be a coordinator device (Coordinator), Router or common device (End Device);

Zigbee 3.0 bridging functional component 22: The functional component 22 mainly maps the Zigbee 3.0 server (Server) device into a standard OCF protocol device according to the Zigbee to OCF bridging specification;

Virtual OCF server (Virtual OCF Server) 23: The virtual OCF server 23 is a virtual server device of the OCF protocol, and is an OCF protocol device obtained by the Zigbee 3.0 Server after being mapped by the bridge platform;

One or more bridge devices (Bridge Devices) conforming to the OCF protocol standard are provided within the OCF bridge platform.

In this solution, the OCF bridging platform specification provides a resource with a resource type of "oic.r.vodlist", and the resource attributes are defined as follows:

1) The set of OCF interfaces supported by this resource:

attribute name: if;

property type: array type: ["oic.if.baseline", "oic.if.r"];

Is it mandatory: no;

Access Mode: Read only.

2) Information group for each virtual OCF device created:

attribute name: vods;

Property Type: Array Type: [

{

"n": "smoke sensor",

"di": "12345678-1234-1234-1234-1234567890ABC",

"econame": "Zigbee 3.0"

},

{

"n": "light",

"di": "1234ABCD-ABCD-ABCD-ABCD-1234567890ABC",

"econame": "BLE"

},

...

];

Is it mandatory: yes;

Access Mode: Read only.

3) Resource type:

attribute name: rt;

property type: array type: ["oic.r.vodlist"];

Is it mandatory: no;

Access Mode: Read only.

4) The device name of the mapped device:

attribute name: n;

Attribute type: Multiple Types (usually strings are used);

Is it mandatory: yes;

Access mode: read and write.

5) Name of the ecosystem of bridge devices exposed by the virtual OCF device:

attribute name: econame;

property type: string;

Is it mandatory: yes;

Access Mode: Read only.

6) Mapping device device identification:

attribute name: di;

Attribute type: Multiple Types (usually strings are used);

Is it mandatory: yes;

Access mode: read and write.

The OCF client can access the ecological type (Zigbee 3.0 or BLE, etc.) of the non-OCF server mapped with the OCF protocol through the above-mentioned "oic.r.vodlist" resource, as well as information such as the device type of the non-OCF server.

The device type of the bridge device in the OCF bridge platform is "oic.d.bridge", and in implementation, the device needs to support the "oic.r.vodlist" resource type for OCF protocol clients to discover and access.

However, the above solution only provides access to information such as the ecological type and device type of the non-OCF server. For the non-OCF protocol network, flexible management control cannot be performed, and the management effect of the IoT network is poor.

Based on the above problem, subsequent embodiments of the present application provide an Internet of Things configuration solution, which can implement control and management of a non-OCF protocol network through an OCF client.

Please refer to FIG. 3 , which shows a flowchart of a method for configuring the Internet of Things provided by an embodiment of the present application. The method can be executed by an OCF bridging platform, wherein the above-mentioned OCF bridging platform can be in the network architecture shown in FIG. 1 . The OCF bridge platform 120. The method may include the following steps:

Step 301: Receive a network configuration request sent by the OCF client through the OCF bridge device, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is an attribute in a configuration resource supported by the OCF bridge device.

In this embodiment of the present application, the OCF bridge device is a virtual device constructed in the OCF bridge platform, and the OCF bridge device supports configuration resources.

In the IoT protocol, resources are used to express IoT devices, as well as information such as the functional services provided by the devices and the status of the devices. The device that provides resources is the server, and the device that accesses resources is the client. Optionally, the client and the server may be hardware entities or logical functional entities, and each device may be a client, a server, or both a client and a server. For example, a device (such as a light bulb) that implements a basic function can only be used as a server, and can be provided to the client for query and control.

Optionally, the business interaction between the client and the server can be achieved by performing RESTful operations on resources, that is, CRUDN operation methods such as Create (Create), Read (Retrieve), Update (Update), Delete (Delete), and Notify (Notify). accomplish. The client is the initiator of the RESTful operation, and the server is the responder of the RESTful operation. The client sends a resource operation request to the server, and requests to operate the resources on the server. The server performs the resource operation and returns a response to the client. , the content and description information of the resource are carried in the response.

In the IoT protocol, resources are described as the resource model layer. Each resource has a corresponding interface that supports Restful operations. It is the transmission protocol layer that transmits resource content and description information. By mapping resource operations to specific transmission protocols, the Restful operation of each resource is transformed into an entity message that is transmitted between devices to achieve interconnection between devices.

The resource resides in the device, and each resource has its own Uniform Resource Identifier (URI). The resource URI can be specified by the resource creator when the resource is created. Optionally, some specific resources have predefined resources. URI, i.e. the resource has a fixed URI. A resource has one or more resource types, and the request to create a resource needs to specify the resource type corresponding to the resource.

In the embodiment of the present application, the above-mentioned configuration resources are resources used for configuring the non-OCF protocol network. When the OCF client needs to configure the non-OCF protocol network, it sends a configuration attribute to the OCF bridge device in the OCF bridge platform. The property value of the network configuration request.

Step 302: Determine the non-OCF virtual client corresponding to the network configuration request.

The non-OCF virtual client is a virtual device constructed in the OCF bridging platform, and the non-OCF virtual client has a networking function, that is, the non-OCF virtual client is used to form a non-OCF protocol network, so as to support the non-OCF protocol network The non-OCF server accesses the non-OCF protocol network.

In the embodiment of the present application, one or more non-OCF virtual clients are built in the OCF bridge platform. After receiving the network configuration request through the OCF bridge device, the OCF bridge platform can determine the corresponding non-OCF virtual client according to the network configuration request client, that is, to determine the non-OCF virtual client to be configured by the network configuration request.

Step 303: Send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; the configuration operation is to the non-OCF virtual client The non-OCF protocol network corresponding to the terminal performs the configuration operation.

As mentioned above, the non-OCF virtual client has the networking function. Therefore, after the OCF bridge platform determines the non-OCF virtual client to be configured in the network configuration request, it can send a network configuration command to the non-OCF virtual client to pass the non-OCF virtual client. The OCF virtual client configures the non-OCF protocol network according to the attribute value of the configuration attribute.

The above steps in the embodiments of the present application may be implemented by an OCF bridging functional component in the OCF bridging platform. The OCF bridging functional component is a hardware component or a virtual component.

For example, please refer to FIG. 4 , which shows an architecture diagram of a network configuration involved in an embodiment of the present application. As shown in FIG. 4 , the OCF bridge platform includes an OCF bridge device 41 , an OCF bridge function component 42 and a non-OCF virtual client 43 . The non-OCF virtual client 43 has a networking function, and the OCF bridge device 41 has configuration resources for configuring the non-OCF protocol network corresponding to the non-OCF virtual client 43 . When the user uses the OCF client to access the OCF bridge platform, if the non-OCF protocol network corresponding to the non-OCF virtual client 43 needs to be configured, the OCF client can be triggered to send a network configuration request to the OCF bridge device 41 through the configuration operation. The network configuration request includes the attribute value of one or more configuration attributes in the above configuration resources; the OCF bridge device 41 sends the content in the network configuration request to the OCF bridging functional component 42, and the OCF bridging functional component 42 determines the The network configuration requests the non-OCF virtual client 43 to be configured, and then sends a network configuration instruction to the determined non-OCF virtual client 43, and the non-OCF virtual client 43 executes the attribute value corresponding to the above-mentioned configuration attribute according to the network configuration instruction. network configuration operations.

To sum up, in the solutions shown in the embodiments of the present application, the OCF bridge device is provided with configuration resources for configuring non-OCF protocol networks. When the configuration request contains the attribute value of the configuration attribute in the configuration resource, it instructs the non-OCF virtual client to perform the configuration operation on the non-OCF protocol network, thereby realizing the configuration of the non-OCF protocol network through the OCF client, thereby improving the performance of the network. The network management effect of the Internet of Things.

Please refer to FIG. 5 , which shows a flowchart of a method for configuring the Internet of Things provided by an embodiment of the present application. The method may be executed by an OCF bridging platform, wherein the above-mentioned OCF bridging platform may be in the network architecture shown in FIG. 1 . The OCF bridge platform 120. The method may include the following steps:

Step 501, create an OCF bridge device and a non-OCF virtual client.

In this embodiment of the present application, after the OCF bridge platform is started, an OCF bridge device and a non-OCF virtual client can be created locally.

In one possible implementation, the OCF bridge platform supports translation between the OCF protocol and one or more non-OCF protocols.

Wherein, when the OCF bridge platform supports translation between the OCF protocol and multiple non-OCF protocols, the OCF bridge platform creates a corresponding non-OCF virtual client for each OCF protocol it supports.

For example, assuming that the OCF bridge platform supports the translation between the OCF protocol and Zigbee 3.0 and BLE, when creating a non-OCF virtual client, the OCF bridge platform creates a non-OCF virtual client corresponding to Zigbee 3.0 (which can be called as Zigbee 3.0 virtual client) and BLE corresponding non-OCF virtual client (which can be called BLE virtual client).

In a possible implementation manner, the Zigbee 3.0 virtual client is a virtual coordinator device, and the BLE virtual client is a virtual provider (Provisioner) device.

In a possible implementation manner, when the OCF bridge platform creates the OCF bridge device, it creates an OCF bridge device common to different non-OCF protocols.

In the above possible implementation manner, the OCF bridge platform creates an OCF bridge device locally, and the OCF bridge device corresponds to multiple different non-OCF protocols, that is, corresponds to multiple non-OCF virtual clients created by the OCF bridge platform.

For example, taking the Zigbee 3.0 virtual client and BLE virtual client created by the OCF bridge platform as an example, the OCF bridge platform creates a single OCF bridge device, which corresponds to the Zigbee 3.0 virtual client and the BLE virtual client at the same time.

In another possible implementation manner, when the OCF bridge platform creates the OCF bridge device, it creates an OCF bridge device dedicated to each non-OCF virtual client.

In the above possible implementation manner, for one or more non-OCF virtual clients created by the OCF bridging platform, the OCF bridging platform further creates an OCF bridge device for each non-OCF virtual client.

For example, taking the Zigbee 3.0 virtual client and BLE virtual client created by the OCF bridge platform as an example, the OCF bridge platform creates an OCF bridge device corresponding to the Zigbee 3.0 virtual client, and another OCF bridge device corresponding to the BLE virtual client.

Step 502: Create configuration resources corresponding to non-OCF virtual clients for the OCF bridge device.

In the embodiment of the present application, the OCF bridging functional component in the OCF bridging platform creates corresponding configuration resources in the OCF bridge device for each non-OCF virtual client that has been created.

For example, take the Zigbee 3.0 virtual client and BLE virtual client created by the OCF bridge platform as an example, correspondingly, the OCF bridge function component instructs the OCF bridge device to create the Zigbee 3.0 protocol corresponding configuration resources for the Zigbee 3.0 virtual client, and instruct the OCF The bridge device creates configuration resources corresponding to the BLE protocol for the BLE virtual client.

Wherein, when the above-mentioned OCF bridge device is an OCF bridge device common to different non-OCF protocols, the OCF bridge function component instructs the common OCF bridge device to create a plurality of different non-OCF protocol configuration resources.

For example, taking the Zigbee 3.0 virtual client and BLE virtual client created by the OCF bridge platform as an example, when the OCF bridge device is a single OCF bridge device common to Zigbee 3.0 and BLE, the OCF bridge function component instructs the OCF bridge device to create two Configuration resources, respectively the configuration resources corresponding to the Zigbee 3.0 protocol and the configuration resources corresponding to the BLE protocol.

Alternatively, when the above-mentioned OCF bridge device is an OCF bridge device dedicated to a non-OCF virtual client, the OCF bridge function component instructs each OCF bridge device to create a corresponding non-OCF protocol configuration resource.

For example, taking the Zigbee 3.0 virtual client and BLE virtual client created by the OCF bridge platform as an example, when the OCF bridge platform creates the OCF bridge device a corresponding to the Zigbee 3.0 protocol and the OCF bridge device b corresponding to the BLE protocol, the OCF bridge The functional component instructs the OCF bridge device a to create configuration resources corresponding to the Zigbee 3.0 protocol, and instructs the OCF bridge device b to create configuration resources corresponding to the BLE protocol.

Wherein, the configuration resource includes at least one of the following attributes:

Event types supported by this configuration resource;

The status of configuring the non-OCF protocol network;

The protocol type of the non-OCF protocol network;

The network layer key of the non-OCF protocol network;

And, the application layer key of the non-OCF protocol network.

In a possible implementation manner of the embodiment of the present application, the configuration resource created in the OCF bridge platform is a resource whose resource type is "oic.r.configmgmt", and the resource attribute is defined as follows:

1) Event types supported by the resource:

attribute name: event;

Attribute type: enumeration type: ["start", "permit", "stop", "updatenetkey", "updateappkey"]; among them, the "start" type corresponds to starting a non-OCF protocol network; the "permit" type corresponds to allowing non-OCF The protocol device accesses the non-OCF protocol network (allows the non-OCF protocol device to associate with the non-OCF protocol network); the "stop" type corresponds to stop the network started by the non-OCF protocol; the "updatenetkey" type corresponds to update the non-OCF protocol network layer key; " The updateappkey" type corresponds to updating the non-OCF protocol application layer key;

Is it mandatory: yes;

Access mode: read and write.

2) Current status:

attribute name: status;

Attribute type: enumeration type: ["success", "failed"]; among them, the "success" type corresponds to the event request success; the "failed" type corresponds to the event request failure;

Is it mandatory: yes;

Access Mode: Read only.

3) Non-OCF protocol network type:

attribute name: ecosystem;

property type: string;

Is it mandatory: yes;

Access Mode: Read only.

4) Non-OCF protocol network layer key:

attribute name: netkey;

property type: string;

Is it mandatory: no;

Access mode: read and write.

5) Non-OCF protocol application layer key:

attribute name: appkey;

property type: string;

Is it mandatory: no;

Access mode: read and write.

In a possible implementation manner, the OCF interface types supported by the "oic.r.configmgmt" resource type are "oic.if.a" and "oic.if.baseline"; in this embodiment of the present application, the resource type Applied in OCF bridge device.

Step 503: Create an association relationship between the configuration resource and the non-OCF virtual client.

In a possible implementation manner, when the OCF bridge device is an OCF bridge device common to different non-OCF protocols, an association relationship between the uniform resource locator URL address of the configuration resource and the non-OCF virtual client is created.

In the above possible implementation manner, when the OCF bridge device is an OCF bridge device common to different non-OCF protocols, since the configuration resources of multiple different non-OCF protocols are set in the same OCF bridge device, the configuration resources can be configured through the URL address to distinguish different non-OCF protocol configuration resources. Correspondingly, the OCF bridging functional component can create an association relationship between the URL of each configuration resource and the corresponding non-OCF virtual client.

In another possible implementation manner, when the OCF bridge device is an OCF bridge device dedicated to a non-OCF protocol, an association relationship between the identifier of the OCF bridge device and the non-OCF virtual client is created.

In the above possible implementation manner, when the OCF bridge device is an OCF bridge device dedicated to a non-OCF protocol, since the configuration resources of different non-OCF protocols are set in different OCF bridge devices, the OCF bridge function component creates an OCF bridge device The association relationship between the identifier of , and the non-OCF virtual client, that is, the association between the configuration resource and the non-OCF virtual client can be realized.

Step 504: Receive a network configuration request sent by the OCF client through the OCF bridge device, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is an attribute in a configuration resource supported by the OCF bridge device.

In a possible implementation manner, when the OCF client sends the network configuration request, it can send the network configuration request according to the URL of the configuration resource of the non-OCF protocol network to be configured. Correspondingly, the OCF bridge platform receives the network configuration request through the OCF bridge device. The OCF client sends the network configuration request through the URL address of the configuration resource.

For example, the OCF client sends a Constrained Application Protocol (COAP) request of POST type, the address of the POST request is the URL of the configuration resource of the non-OCF protocol network to be configured, and the payload of the POST request is the The property value of the configuration property in the configuration resource.

Step 505: Determine the non-OCF virtual client corresponding to the network configuration request.

In a possible implementation manner of the embodiment of the present application, when the above-mentioned OCF bridge device is an OCF bridge device common to different non-OCF protocols, after receiving the network configuration request sent by the OCF client, the OCF bridge device, according to the network configuration Request the URL address of the corresponding configuration resource, and the payload of the network configuration request (that is, the attribute value of the above configuration attribute) to initiate a resolution mapping relationship request to the OCF bridging functional component in the OCF bridging platform, and the OCF bridging functional component corresponds to the network configuration request The URL address of the configuration resource to query the above association relationship, and determine the non-OCF virtual client corresponding to the network configuration request.

In a possible implementation manner, when the above-mentioned OCF bridge device is an OCF bridge device dedicated to a non-OCF protocol, after the OCF bridge device receives the network configuration request sent by the OCF client, according to the device identifier of the OCF bridge device, And the load of the network configuration request (that is, the attribute value of the above-mentioned configuration attribute) initiates a request for parsing the mapping relationship to the OCF bridging functional component in the OCF bridging platform, and the OCF bridging functional component receives the network configuration request according to the device identification of the OCF bridge device The above association relationship is queried to determine the non-OCF virtual client.

Step 506: Send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; the configuration operation is to the non-OCF virtual client The non-OCF protocol network corresponding to the terminal performs the configuration operation.

In a possible implementation manner, the configuration operation includes at least one of the following operations:

Start a non-OCF protocol network;

Allow non-OCF servers to access non-OCF protocol networks;

Close the non-OCF protocol network;

Modify the network layer key of the non-OCF protocol network;

And, modify the application layer key of the non-OCF protocol network.

Step 507: Receive the operation response of the configuration operation returned by the non-OCF virtual client; the operation response is used to indicate the operation result of the configuration operation.

In the embodiment of the present application, after the non-OCF virtual client performs the corresponding non-OCF protocol network configuration operation, the operation of whether the operation is successful is returned to the OCF bridging functional component. Correspondingly, the OCF bridging functional component receives the non-OCF virtual The operation response returned by the client.

Step 508: Send the operation response of the configuration operation to the OCF bridge device.

After receiving the operation response returned by the non-OCF virtual client, the OCF bridge function component can send the operation response to the OCF bridge device.

In a possible implementation solution, after receiving the operation response returned by the non-OCF virtual client, the OCF bridge function component returns the operation response to the corresponding OCF bridge device according to the URL address of the configuration resource. Correspondingly, the OCF bridge device stores the above operation response according to the URL address of the configuration resource.

Step 509, returning an operation response of the configuration operation to the OCF client through the OCF bridge device.

In a possible implementation manner, a response message of the network configuration request is returned to the OCF client through the OCF bridge device, and the response message includes an operation response of the configuration operation.

In the above step 504, after receiving the network configuration request, the OCF bridge device does not return a response message to the OCF client for the request, but waits for the operation response to the configuration operation returned by the OCF bridge function component. The OCF bridge device returns a response message of the network configuration request to the OCF client.

In another possible implementation manner, when an operation response query request sent by the OCF client is received through the OCF bridge device, an operation response of the configuration operation is returned to the OCF client through the OCF bridge device.

In the above step 504, after receiving the network configuration request, the OCF bridge device can immediately return a response message of the request to the OCF client, and the OCF client can subsequently query the OCF bridge device for the operation response of the configuration operation. For example, the OCF client sends a GET-type COAP request to the OCF bridge device through the URL address of the corresponding configuration resource. After receiving the request, the OCF bridge device returns the operation response of the configuration operation corresponding to the URL address to the OCF client.

Please refer to FIG. 6 , which shows a schematic diagram of enabling a non-OCF protocol network and allowing a non-OCF server to access/associate the network involved in an embodiment of the present application. As shown in Figure 6, in this solution, a virtual client using Zigbee 3.0 and BLE protocols is used in the OCF bridging platform to illustrate the solution process. The solution includes the following steps:

In the OCF bridge platform, the virtual Zigbee client (Virtual Zigbee 3.0 Client) and the virtual BLE client (Virtual BLE Client) are used as the coordinator device (that is, the Zigbee3.0 coordinator) and the provisioner device respectively. When the OCF bridge platform is powered on and started, First you need to do the following;

S61, Zigbee coordinator device (Virtual Zigbee 3.0 Client) and BLE Provisioner (Virtual BLE Client) device initialization.

S62, create an OCF bridge device (located in the OCF bridge platform), the device type is "oic.d.bridge", and there is only one OCF bridge device in the OCF bridge platform.

S63, create two resources for the OCF bridge device, the resource types of the two resources are the same, and both are "oic.r.configmgmt"; the resources are distinguished by url.

Among them, use url="/eco/zigbee3.0" to establish a mapping relationship with the Zigbee coordinator device, and use url="/eco/ble" to establish a mapping relationship with the BLE Provisioner device.

For example, as shown in Figure 6, the Virtual Zigbee 3.0 Client and the Virtual BLE Client respectively send a request to the OCF bridging functional component to establish an association relationship with the resource, and the OCF bridging functional component establishes the resource URL and the Virtual Zigbee3.0 Client or Virtual BLE Client. and instruct the OCF bridge device to create the resources corresponding to the two resource URLs respectively.

The OCF client must first perform the Onboarding operation on the OCF bridge device, so that the device becomes the master device, and the OCF client can securely access the resources on the device.

The OCF client completes the non-OCF protocol (Zigbee 3.0 or BLE) networking and allows non-OCF protocol device access control operations by sending a POST request to the corresponding url;

Taking starting the Zigbee 3.0 network and allowing Zigbee 3.0 devices to access the network as an example, the operation process is as follows:

S64, when the Zigbee 3.0 network needs to be started, the OCF client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device, and the payload carried is:

{"event":"start","netkey":"xxx","appkey":"xxx"}

S65, the OCF bridge device sends a request for parsing the mapping relationship to the OCF bridge functional component according to the "/eco/zigbee3.0" resource url and the payload of the POST request; the OCF bridge functional component finds the corresponding Zigbee from the mapping relationship table according to the url of the POST request The coordinator device determines to send a Zigbee network start request to the Zigbee coordinator according to the value start of the event in the payload, and sends the values of netkey and appkey to the Zigbee coordinator, and the Zigbee coordinator stores the values of netkey and appkey for Subsequent use, netkey will be broadcast through broadcast messages after the Zigbee network is successfully started. At the same time, the OCF bridge device waits for network startup status information.

S66, after receiving the network startup status information returned by the Zigbee coordinator, the OCF bridge device returns the result to the OCF client. That is, the ACK message of the success or failure of the network startup is returned.

S67, the OCF client decides whether to send a request to allow the network access device of the non-OCF protocol according to the network startup status returned by the OCF bridge device; when the OCF client receives the status information of the successful network startup, it sends a request to allow the network access device, and the OCF The client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device, and the payload is:

{"event":"permit"}

S68, the OCF bridge device sends a request for parsing the mapping relationship to the OCF bridge functional component according to the "/eco/zigbee3.0" resource url and the payload of the POST request; the OCF bridge functional component finds the corresponding Zigbee from the mapping relationship table according to the url of the POST request The coordinator device sends a request to allow Zigbee network access to the Zigbee coordinator according to the value permit of the event in the payload. At the same time, the OCF bridge device waits for status information that allows access.

S69, the OCF bridge device returns the result to the OCF client after receiving the status information of the network access allowed returned by the Zigbee coordinator; that is, returning an ACK message to the OCF client that the access is allowed or failed.

In a possible implementation manner, an outbound interface is reserved on the OCF client to configure the non-OCF server to access the network by means of voice or UI.

At this time, the Zigbee 3.0 server can access the network created and started by the Zigbee coordinator. After the Zigbee 3.0 server is successfully connected, it establishes a mapping relationship with the Virtual OCF Server, so that the OCF client can access the corresponding Zigbee through the Virtual OCF Server. 3.0 server;

The process of starting the BLE network and allowing BLE devices to access is the same as Zigbee 3.0, the difference is that the OCF bridge function component uses the "/eco/ble" resource address to find the BLE Provisioner device from the mapping relationship; the OCF client sends the POST request resource The url is "/eco/ble".

Please refer to FIG. 7 , which shows a schematic diagram of the operation flow of stopping the non-OCF protocol network involved in the embodiment of the present application; wherein, only the Zigbee 3.0 protocol is used to illustrate the operation of stopping the non-OCF protocol network, and the OCF client can stop Zigbee The coordinator (Virtual Zigbee 3.0 Client) continues to send out broadcast data for networking to stop the Zigbee coordinator from continuing to expand the network; other non-OCF protocols such as BLE operate the same; as shown in Figure 7:

S71, when the Zigbee 3.0 network needs to be stopped, the OCF client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device, and the payload carried is:

{"event":"stop"}

S72, the OCF bridge device sends a request for parsing the mapping relationship to the OCF bridge functional component according to the "/eco/zigbee3.0" resource url and the payload of the POST request; the OCF bridge functional component finds the corresponding Zigbee from the mapping relationship table according to the url of the POST request The coordinator device sends a request to stop the Zigbee network to the Zigbee coordinator according to the value stop of the event in the payload. At the same time, the OCF bridge device waits for network startup status information. After the OCF bridge device receives the network stop status information returned by the Zigbee coordinator, it returns the result to the OCF client. That is, an ACK message is returned for the success or failure of the network stop.

S73, after the Zigbee coordinator stops the network, the Zigbee coordinator does not send out broadcast data. The new Zigbee device cannot receive the broadcast data sent by the Zigbee coordinator and cannot access the network. The Zigbee device that has been connected to the network before can normal communication.

Please refer to FIG. 8 , which shows an operation flowchart of modifying a non-OCF protocol network key involved in an embodiment of the present application. The OCF client can update the Zigbee coordinator (Virtual Zigbee 3.0 Client) as the central trusted node to send the network layer key and application layer key to the network. In this operation, only the Zigbee 3.0 protocol is used as an example. The OCF protocol operates the same; as shown in Figure 8:

S81, the OCF client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device, and the payload carried is:

{"event":"updatenetkey","netkey":"xxxxx"} or

{"event":"updateappkey","appkey":"xxxxxx"}

Indicates to update the network layer key or application layer key of the Zigbee 3.0 network;

S82, the OCF bridge device sends a request for parsing the mapping relationship to the OCF bridge functional component according to the "/eco/zigbee3.0" resource url and the payload of the POST request; the OCF bridge functional component finds the corresponding Zigbee from the mapping relationship table according to the url of the POST request The coordinator sends a request for updating the network layer key or application layer key in the Zigbee network to the Zigbee coordinator according to the value updatenetkey or updateappkey of the event in the payload; after the OCF bridge device receives the key update status information returned by the Zigbee coordinator , which returns the result to the OCF client. That is, an ACK message is returned for the success or failure of the key update.

S83, the Zigbee coordinator uses the "netkey" or "appkey" in the payload to update the network layer key or the application layer key.

The above FIGS. 6 to 8 are all described by taking an example that the OCF bridge device is an OCF bridge device common to different non-OCF protocols. Please refer to FIG. 9 , which shows another schematic diagram of starting a non-OCF protocol network involved in an embodiment of the present application. As shown in Figure 9, in this solution, the virtual client using Zigbee 3.0 and BLE two protocols is used in the OCF bridge platform to illustrate the solution process. The solution includes the following steps:

S91 is the same as S61 in FIG. 6 above.

S92, create an OCF bridge device (located in the OCF bridge platform), the device type is "oic.d.bridge", and there are two OCF bridge devices in the OCF bridge platform, corresponding to the virtual clients of Zigbee 3.0 and BLE protocols respectively.

That is, an independent OCF bridge device is created for each supported non-OCF protocol bridge in the OCF bridge platform.

S93, respectively create resources for the two OCF bridge devices, the resource types of the two resources are the same, and both are "oic.r.configmgmt"; the resources are distinguished by url.

Among them, each non-OCF virtual client establishes an OCF bridge device, so the OCF bridge device id (unique identification device) is used to establish a mapping relationship with the non-OCF virtual client; that is, the ID of the OCF bridge device 1 is used to coordinate with Zigbee The device establishes a mapping relationship, and uses the identity of the OCF bridge device 2 to establish a mapping relationship with the BLE Provisioner device.

For example, as shown in Figure 6, the Virtual Zigbee 3.0 Client and the Virtual BLE Client respectively send a request to establish an association relationship with the resource to the OCF bridging functional component, and the OCF bridging functional component establishes the relationship between the identity of the OCF bridge device 1 and the Virtual Zigbee 3.0 Client. The association relationship between the OCF bridge device 2 and the Virtual BLE Client is established, and the OCF bridge device 1 is instructed to create the resources corresponding to Zigbee 3.0, and the OCF bridge device 2 is instructed to create the resources corresponding to BLE.

The OCF client completes the networking of the non-OCF protocol (Zigbee 3.0 or BLE) and the control operation of allowing the access of non-OCF protocol devices by sending a POST request to the corresponding url;

Taking the Zigbee 3.0 network as an example, the operation process is as follows:

S94, when the Zigbee 3.0 network needs to be started, the OCF client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device 1, and the payload carried is:

{"event":"start","netkey":"xxx","appkey":"xxx"}

S95 is the same as S65 in the above-mentioned FIG. 6 . Meanwhile, the OCF bridge device 1 waits for network startup status information.

S96, after receiving the network startup status information returned by the Zigbee coordinator, the OCF bridge device 1 returns the result to the OCF client. That is, the ACK message of the success or failure of the network startup is returned.

The startup process of the BLE network is the same as that of Zigbee 3.0, the difference is that the OCF bridge device 2 receives the request and returns the status information to the OCF client. The OCF bridge function component uses the "/eco/ble" resource address to find the BLE Provisioner from the mapping relationship device; the resource url sent by the OCF client POST request is "/eco/ble".

6 to 9 are described by taking the response status of the POST request and the non-OCF protocol operation status result as examples, wherein the response status of the POST request and the non-OCF protocol operation status result may not be synchronized. Please refer to FIG. 10 , which shows another schematic diagram of starting a non-OCF protocol network involved in an embodiment of the present application. As shown in Figure 10, in this solution, the Zigbee 3.0 virtual client is used in the OCF bridge platform to illustrate the solution process. The solution includes the following steps:

S1001 to S1005 are the same as S61 to S65 in FIG. 6 above.

S1006 , after the OCF bridge device sends the request for parsing the mapping relationship, it immediately returns network startup status information to the OCF client, for example, returns an ACK message that the network startup is successful.

S1007, the OCF client sends a GET request to the "/eco/zigbee3.0" resource url of the OCF bridge device.

S1008, after receiving the GET request sent by the OCF client, the OCF bridge device returns the network startup status information actually returned by the non-OCF virtual client to the OCF client.

Correspondingly, when the network startup status information actually returned by the non-OCF virtual client indicates that the network startup is successful, the OCF client may further initiate a request for allowing network access.

Among them, the solution shown in Figure 10 above only uses the Zigbee 3.0 protocol for description, and other non-OCF protocols (BLE) operate the same as the Zigbee 3.0 protocol; and this solution is applicable to a single OCF bridge device or multiple OCF bridge devices.

The following are apparatus embodiments of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

Please refer to FIG. 11 , which shows a block diagram of an IoT configuration apparatus provided by an embodiment of the present application. The device is used in an OCF bridging platform, and has the function of implementing the steps performed by the OCF bridging platform in the above-mentioned IoT configuration method. As shown in Figure 11, the apparatus may include:

The request receiving module 1101 is configured to receive, through the OCF bridge device, a network configuration request sent by the OCF client, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is one of the configuration resources supported by the OCF bridge device. Attributes;

A virtual client determining module 1102, configured to determine a non-OCF virtual client corresponding to the network configuration request;

A configuration module 1103, configured to send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform the configuration operation of the configuration attribute according to the attribute value; the The configuration operation is an operation of configuring the non-OCF protocol network corresponding to the non-OCF virtual client.

start the non-OCF protocol network;

Allowing the non-OCF server to access the non-OCF protocol network;

closing the non-OCF protocol network;

Modify the network layer key of the non-OCF protocol network;

And, modify the application layer key of the non-OCF protocol network.

In a possible implementation, the apparatus further includes:

a device creation module for creating the OCF bridge device;

A resource creation module, configured to create the configuration resource for the OCF bridge device.

In a possible implementation, the device creation module is used to create the OCF bridge device common to different non-OCF protocols;

The device also includes:

a first association module, configured to create an association relationship between the uniform resource locator URL address of the configuration resource and the non-OCF virtual client;

The request receiving module is configured to receive, through the OCF bridge device, the network configuration request sent by the OCF client through the URL address of the configuration resource;

The virtual client determining module is configured to query the association relationship through the URL address of the configuration resource corresponding to the network configuration request, and determine the non-OCF virtual client.

In a possible implementation manner, the device creation module is configured to create the OCF bridge device dedicated to the non-OCF virtual client;

The device also includes:

a second association module, configured to create an association relationship between the identifier of the OCF bridge device and the non-OCF virtual client;

The virtual client determining module is configured to query the association relationship according to the device identifier of the OCF bridge device that receives the network configuration request, and determine the non-OCF virtual client.

In a possible implementation manner, the configuration resource includes at least one of the following attributes:

Event types supported by the configuration resource;

The status of configuring the non-OCF protocol network;

The protocol type of the non-OCF protocol network;

The network layer key of the non-OCF protocol network;

And, the application layer key of the non-OCF protocol network.

In a possible implementation, the apparatus further includes:

a response receiving module, configured to receive the operation response of the configuration operation returned by the non-OCF virtual client; the operation response is used to indicate the operation result of the configuration operation;

a response sending module, configured to send the operation response of the configuration operation to the OCF bridge device;

A response returning module, configured to return an operation response of the configuration operation to the OCF client through the OCF bridge device.

In a possible implementation manner, the response returning module is configured to return a response message of the network configuration request to the OCF client through the OCF bridge device, where the response message includes the information of the configuration operation. Action response.

In a possible implementation manner, the response returning module is configured to return the operation response of the configuration operation to the OCF client when receiving the operation response query request sent by the OCF client.

It should be noted that, when the device provided in the above embodiment realizes its functions, only the division of the above functional modules is used as an example for illustration. In practical applications, the above functions can be allocated to different functional modules according to actual needs. That is, the content structure of the device is divided into different functional modules to complete all or part of the functions described above.

Regarding the apparatus in the above-mentioned embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be described in detail here.

Please refer to FIG. 12 , which shows a schematic structural diagram of a computer device 1200 provided by an embodiment of the present application. The computer device 1200 may include: a processor 1201 , a receiver 1202 , a transmitter 1203 , a memory 1204 and a bus 1205 .

The processor 1201 includes one or more processing cores, and the processor 1201 executes various functional applications and information processing by running software programs and modules.

The receiver 1202 and the transmitter 1203 may be implemented as a communication component, which may be a communication chip. The communication chip may also be referred to as a transceiver.

The memory 1204 is connected to the processor 1201 through the bus 1205 .

The memory 1204 can be used to store a computer program, and the processor 1201 is used to execute the computer program, so as to implement each step performed by the OCF bridge platform in the above method embodiments.

Additionally, memory 1204 may be implemented by any type or combination of volatile or non-volatile storage devices including, but not limited to, magnetic or optical disks, electrically erasable programmable Read Only Memory, Erasable Programmable Read Only Memory, Static Anytime Access Memory, Read Only Memory, Magnetic Memory, Flash Memory, Programmable Read Only Memory.

In an exemplary embodiment, the computer device includes a processor, a memory, and a transceiver (the transceiver may include a receiver for receiving information and a transmitter for transmitting information) and a transmitter.

In one possible implementation, when the computer device is implemented as an OCF bridge platform,

The transceiver is configured to receive, through the OCF bridge device, a network configuration request sent by the OCF client, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is one of the configuration resources supported by the OCF bridge device. Attributes;

the processor, configured to determine the non-OCF virtual client corresponding to the network configuration request;

the processor, configured to send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; The configuration operation is an operation of configuring the non-OCF protocol network corresponding to the non-OCF virtual client.

When the computer device is implemented as an OCF bridge, the processor and transceiver in the computer device involved in the embodiments of the present application may perform the steps performed by the OCF bridge in the method shown in FIG. 3 or FIG. 5 , which are not repeated here. Repeat.

An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored in the storage medium, and the computer program is loaded and executed by a processor to implement the Internet of Things configuration method shown in FIG. 3 or FIG. 5 . in each step.

The application also provides a computer program product or computer program, the computer program product or computer program comprising computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs each step in the Internet of Things configuration method shown in the above 3 or FIG. 5 .

Those skilled in the art should realize that, in one or more of the above examples, the functions described in the embodiments of the present application may be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium can be any available medium that can be accessed by a general purpose or special purpose computer.

The above are only exemplary embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the protection of the present application. within the range.

Claims

An Internet of Things configuration method, characterized in that the method is executed by the Open Connectivity Foundation OCF bridge platform, and the method includes:

Receive a network configuration request sent by the OCF client through the OCF bridge device, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is an attribute in a configuration resource supported by the OCF bridge device;

determining a non-OCF virtual client corresponding to the network configuration request;

Send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; the configuration operation is for the Configure the non-OCF protocol network corresponding to the non-OCF virtual client.
The method of claim 1, wherein the configuration operation comprises at least one of the following operations:

start the non-OCF protocol network;

Allowing the non-OCF server to access the non-OCF protocol network;

closing the non-OCF protocol network;

Modify the network layer key of the non-OCF protocol network;

And, modify the application layer key of the non-OCF protocol network.
The method according to claim 1, characterized in that before receiving the network configuration request sent by the OCF client through the OCF bridge device, the method further comprises:

Create the OCF bridge device;

The configuration resource is created for the OCF bridge device.
The method according to claim 3, wherein the creating the OCF bridge device comprises:

Create the OCF bridge device common to different non-OCF protocols;

The method also includes:

creating an association relationship between the Uniform Resource Locator URL address of the configuration resource and the non-OCF virtual client;

The receiving the network configuration request sent by the OCF client through the OCF bridge device includes:

receiving, by the OCF bridge device, the network configuration request sent by the OCF client through the URL address of the configuration resource;

The determining of the non-OCF virtual client corresponding to the network configuration request includes:

The non-OCF virtual client is determined by querying the association relationship through the URL address of the configuration resource corresponding to the network configuration request.
The method according to claim 3, wherein the creating the OCF bridge device comprises:

creating the OCF bridge device dedicated to the non-OCF virtual client;

The method also includes:

creating an association relationship between the identifier of the OCF bridge device and the non-OCF virtual client;

The determining of the non-OCF virtual client corresponding to the network configuration request includes:

The non-OCF virtual client is determined by querying the association relationship according to the device identifier of the OCF bridge device receiving the network configuration request.
The method of claim 3, wherein the configuration resource includes at least one of the following attributes:

Event types supported by the configuration resource;

The status of configuring the non-OCF protocol network;

The protocol type of the non-OCF protocol network;

The network layer key of the non-OCF protocol network;

And, the application layer key of the non-OCF protocol network.
The method according to claim 1, wherein the method further comprises:

receiving the operation response of the configuration operation returned by the non-OCF virtual client; the operation response is used to indicate the operation result of the configuration operation;

sending an operation response of the configuration operation to the OCF bridge device;

The operation response of the configuration operation is returned to the OCF client through the OCF bridge device.
The method according to claim 7, wherein the returning an operation response of the configuration operation to the OCF client through the OCF bridge device comprises:

A response message of the network configuration request is returned to the OCF client through the OCF bridge device, where the response message includes an operation response of the configuration operation.
The method according to claim 7, wherein the returning an operation response of the configuration operation to the OCF client through the OCF bridge device comprises:

When an operation response query request sent by the OCF client is received, the operation response of the configuration operation is returned to the OCF client.
An Internet of Things configuration device, characterized in that the device is used in an OCF bridge platform, and the device includes:

A request receiving module, configured to receive a network configuration request sent by an OCF client through an OCF bridge device, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is an attribute in a configuration resource supported by the OCF bridge device ;

a virtual client determination module, configured to determine a non-OCF virtual client corresponding to the network configuration request;

a configuration module, configured to send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; the configuration The operation is an operation of configuring the non-OCF protocol network corresponding to the non-OCF virtual client.
The apparatus of claim 10, wherein the configuration operation comprises at least one of the following operations:

start the non-OCF protocol network;

Allowing the non-OCF server to access the non-OCF protocol network;

closing the non-OCF protocol network;

Modify the network layer key of the non-OCF protocol network;

And, modify the application layer key of the non-OCF protocol network.
The apparatus of claim 10, wherein the apparatus further comprises:

a device creation module for creating the OCF bridge device;

A resource creation module, configured to create the configuration resource for the OCF bridge device.
The device of claim 12, wherein:

The device creation module is used to create the OCF bridge device common to different non-OCF protocols;

The device also includes:

a first association module, configured to create an association relationship between the uniform resource locator URL address of the configuration resource and the non-OCF virtual client;

The request receiving module is configured to receive, through the OCF bridge device, the network configuration request sent by the OCF client through the URL address of the configuration resource;

The virtual client determining module is configured to query the association relationship through the URL address of the configuration resource corresponding to the network configuration request, and determine the non-OCF virtual client.
The device of claim 12, wherein:

The device creation module is configured to create the OCF bridge device dedicated to the non-OCF virtual client;

The device also includes:

a second association module, configured to create an association relationship between the identifier of the OCF bridge device and the non-OCF virtual client;

The virtual client determining module is configured to query the association relationship according to the device identifier of the OCF bridge device that receives the network configuration request, and determine the non-OCF virtual client.
The apparatus according to claim 12, wherein the configuration resource includes at least one of the following attributes:

Event types supported by the configuration resource;

The status of configuring the non-OCF protocol network;

The protocol type of the non-OCF protocol network;

The network layer key of the non-OCF protocol network;

And, the application layer key of the non-OCF protocol network.
The apparatus of claim 10, wherein the apparatus further comprises:

a response receiving module, configured to receive the operation response of the configuration operation returned by the non-OCF virtual client; the operation response is used to indicate the operation result of the configuration operation;

a response sending module, configured to send the operation response of the configuration operation to the OCF bridge device;

A response returning module, configured to return an operation response of the configuration operation to the OCF client through the OCF bridge device.
The apparatus of claim 16, wherein:

The response returning module is configured to return a response message of the network configuration request to the OCF client through the OCF bridge device, where the response message includes an operation response of the configuration operation.
The apparatus of claim 16, wherein:

The response returning module is configured to return the operation response of the configuration operation to the OCF client when receiving the operation response query request sent by the OCF client.
A computer device, characterized in that the computer device is implemented as an OCF bridge platform, and the computer device includes a processor, a memory, and a transceiver;

The transceiver is configured to receive, through the OCF bridge device, a network configuration request sent by the OCF client, where the network configuration request includes an attribute value of a configuration attribute; the configuration attribute is one of the configuration resources supported by the OCF bridge device. Attributes;

the processor, configured to determine the non-OCF virtual client corresponding to the network configuration request;

the processor, configured to send a network configuration instruction to the non-OCF virtual client, where the network configuration instruction is used to instruct the non-OCF virtual client to perform a configuration operation of the configuration attribute according to the attribute value; The configuration operation is an operation of configuring the non-OCF protocol network corresponding to the non-OCF virtual client.
A computer-readable storage medium, characterized in that a computer program is stored in the storage medium, and the computer program is used to be executed by a processor to implement the Internet of Things configuration according to any one of claims 1 to 9 method.