WO2022011563A1 - Procédé et appareil de configuration de l'internet des objets, dispositif informatique, et support de stockage - Google Patents

Procédé et appareil de configuration de l'internet des objets, dispositif informatique, et support de stockage Download PDF

Info

Publication number
WO2022011563A1
WO2022011563A1 PCT/CN2020/101950 CN2020101950W WO2022011563A1 WO 2022011563 A1 WO2022011563 A1 WO 2022011563A1 CN 2020101950 W CN2020101950 W CN 2020101950W WO 2022011563 A1 WO2022011563 A1 WO 2022011563A1
Authority
WO
WIPO (PCT)
Prior art keywords
ocf
configuration
network
client
bridge device
Prior art date
Application number
PCT/CN2020/101950
Other languages
English (en)
Chinese (zh)
Inventor
茹昭
Original Assignee
Oppo广东移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to PCT/CN2020/101950 priority Critical patent/WO2022011563A1/fr
Priority to CN202080100473.2A priority patent/CN115486038B/zh
Publication of WO2022011563A1 publication Critical patent/WO2022011563A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0226—Mapping or translating multiple network management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Definitions

  • 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.
  • the user can remotely control the functional operation of the server device through the client.
  • the protocol widely used in the Internet of Things is the Open Connectivity Foundation (OCF) protocol.
  • OCF Open Connectivity Foundation
  • servers which can be called non-OCF servers
  • non-OCF servers that support non-OCF protocols on the market.
  • client OCF client
  • 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.
  • 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:
  • 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:
  • the OCF client Receives 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • a 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 OCF bridge device is provided with a configuration resource for configuring the non-OCF protocol network.
  • 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
  • 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.
  • FIG. 1 is a schematic diagram of a network architecture of the Internet of Things provided by an embodiment of the present application.
  • FIG. 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;
  • FIG. 3 is a flowchart of an Internet of Things configuration method provided by an embodiment of the present application.
  • FIG. 4 is an architectural diagram of a network configuration involved in the embodiment shown in FIG. 3;
  • FIG. 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;
  • FIG. 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;
  • FIG. 10 is a schematic diagram of another startup non-OCF protocol network involved in the embodiment shown in FIG. 5;
  • FIG. 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.
  • 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.
  • FIG. 1 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.
  • 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.
  • Zigbee protocol such as Zigbee 3.0, a wireless network protocol for low-speed and short-distance transmission
  • the non-OCF server 110 supports the Bluetooth protocol, such as Bluetooth low energy
  • Bluetooth Low Energy Bluetooth Low Energy
  • 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.
  • the server 110 may be industrial production equipment, such as lathes, industrial robots, solar panels, wind turbines, and the like.
  • the server 110 may be a commercial service device, for example, a vending machine or the like.
  • 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.
  • 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.
  • the above-mentioned OCF bridge platform 120 and the OCF client 130 are connected through a wired or wireless network.
  • the above wired or wireless network uses standard communication technologies and/or protocols.
  • the above wired or wireless network may be a communication network based on the IoT protocol of the Internet of Things.
  • FIG. 2 shows a schematic diagram of a bridge model from a Zigbee protocol to an OCF protocol involved in an embodiment of the present application.
  • 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 Zigbee Client is a virtual Zigbee 3.0 client, the virtual device can be a coordinator device (Coordinator), Router or common device (End Device);
  • 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 conforming to the OCF protocol standard are provided within the OCF bridge platform.
  • the OCF bridging platform specification provides a resource with a resource type of "oic.r.vodlist", and the resource attributes are defined as follows:
  • Attribute type Multiple Types (usually strings are used);
  • Access mode read and write.
  • Attribute type Multiple Types (usually strings are used);
  • 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.
  • ecological type Zigbee 3.0 or BLE, etc.
  • 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.
  • the above solution only provides access to information such as the ecological type and device type of the non-OCF server.
  • information such as the ecological type and device type of the non-OCF server.
  • flexible management control cannot be performed, and the management effect of the IoT network is poor.
  • FIG. 3 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 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.
  • the OCF bridge device is a virtual device constructed in the OCF bridge platform, and the OCF bridge device supports configuration resources.
  • 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.
  • 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.
  • a device such as a light bulb
  • a basic function can only be used as a server, and can be provided to the client for query and control.
  • 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).
  • RESTful operations on resources
  • CRUDN operation methods such as Create (Create), Read (Retrieve), Update (Update), Delete (Delete), and Notify (Notify).
  • the client is the initiator of the RESTful operation
  • 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.
  • 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).
  • URI Uniform Resource Identifier
  • the resource URI can be specified by the resource creator when the resource is created.
  • 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.
  • the above-mentioned configuration resources are resources used for configuring the non-OCF protocol network.
  • 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.
  • one or more non-OCF virtual clients are built in the OCF bridge platform.
  • 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.
  • 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.
  • 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
  • the OCF bridge device 41 has configuration resources for configuring the non-OCF protocol network corresponding to the non-OCF virtual client 43 .
  • 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.
  • the OCF bridge device is provided with configuration resources for configuring non-OCF protocol networks.
  • 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.
  • FIG. 5 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 method may include the following steps:
  • Step 501 create an OCF bridge device and a non-OCF virtual client.
  • an OCF bridge device and a non-OCF virtual client can be created locally.
  • the OCF bridge platform supports translation between the OCF protocol and one or more non-OCF protocols.
  • the OCF bridge platform 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.
  • the OCF bridge platform 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).
  • the Zigbee 3.0 virtual client is a virtual coordinator device
  • the BLE virtual client is a virtual provider (Provisioner) device.
  • the OCF bridge platform when the OCF bridge platform creates the OCF bridge device, it creates an OCF bridge device common to different non-OCF protocols.
  • 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.
  • 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.
  • the OCF bridge platform when the OCF bridge platform creates the OCF bridge device, it creates an OCF bridge device dedicated to each non-OCF virtual client.
  • the OCF bridging platform further creates an OCF bridge device for each non-OCF virtual client.
  • 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.
  • 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.
  • 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.
  • the OCF bridge function component instructs the common OCF bridge device to create a plurality of different non-OCF protocol configuration resources.
  • 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.
  • the OCF bridge function component instructs each OCF bridge device to create a corresponding non-OCF protocol configuration resource.
  • the OCF bridge platform 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.
  • the configuration resource includes at least one of the following attributes:
  • 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:
  • 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;
  • Access mode read and write.
  • 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;
  • Access mode read and write.
  • Access mode read and write.
  • 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.
  • 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.
  • the OCF bridge device is an OCF bridge device common to different non-OCF protocols
  • the configuration resources can be configured through the URL address to distinguish different non-OCF protocol configuration resources.
  • the OCF bridging functional component can create an association relationship between the URL of each configuration resource and the corresponding non-OCF virtual client.
  • 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.
  • 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.
  • the OCF client 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.
  • 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.
  • 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
  • the payload of the POST request is the The property value of the configuration property in the configuration resource.
  • COAP Constrained Application Protocol
  • Step 505 Determine the non-OCF virtual client corresponding to the network configuration request.
  • the OCF bridge device 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.
  • the above-mentioned OCF bridge device is an OCF bridge device dedicated to a non-OCF protocol
  • the OCF bridge device receives the network configuration request sent by the OCF client, according to the device identifier of the OCF bridge device
  • 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
  • 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.
  • the configuration operation includes at least one of the following operations:
  • 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.
  • the operation of whether the operation is successful is returned to the OCF bridging functional component.
  • 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.
  • the OCF bridge function component 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.
  • the OCF bridge function component 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.
  • 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.
  • 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.
  • the OCF bridge device after receiving the network configuration request, 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.
  • 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.
  • 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.
  • the OCF client sends a GET-type COAP request to the OCF bridge device through the URL address of the corresponding configuration resource.
  • the OCF bridge device 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.
  • FIG. 6 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.
  • 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:
  • 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.
  • the coordinator device that is, the Zigbee3.0 coordinator
  • the provisioner device that is, the Zigbee3.0 coordinator
  • Zigbee coordinator device (Virtual Zigbee 3.0 Client) and BLE Provisioner (Virtual BLE Client) device initialization.
  • 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;
  • the operation process is as follows:
  • the OCF client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device, and the payload carried is:
  • 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.
  • the OCF bridge device waits for network startup status information.
  • the OCF bridge device 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.
  • 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:
  • 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.
  • the OCF bridge device waits for status information that allows access.
  • 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.
  • 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.
  • 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".
  • FIG. 7 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:
  • the OCF client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device, and the payload carried is:
  • 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.
  • 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.
  • 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.
  • FIG. 8 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.
  • the Zigbee coordinator Virtual Zigbee 3.0 Client
  • the OCF protocol operates the same; as shown in Figure 8:
  • the OCF client sends a POST request to the "/eco/zigbee3.0" resource url of the OCF bridge device, and the payload carried is:
  • 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.
  • the Zigbee coordinator uses the "netkey” or "appkey” in the payload to update the network layer key or the application layer key.
  • 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.
  • FIG. 9 shows another schematic diagram of starting a non-OCF protocol network involved in an embodiment of the present application.
  • 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.
  • OCF bridge device located in the OCF bridge platform
  • the device type is "oic.d.bridge”
  • there are two OCF bridge devices in the OCF bridge platform corresponding to the virtual clients of Zigbee 3.0 and BLE protocols respectively.
  • 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.
  • 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.
  • 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;
  • the operation process is as follows:
  • 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:
  • S95 is the same as S65 in the above-mentioned FIG. 6 . Meanwhile, the OCF bridge device 1 waits for network startup status information.
  • the OCF bridge device 1 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".
  • FIG. 10 shows another schematic diagram of starting a non-OCF protocol network involved in an embodiment of the present application.
  • 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.
  • the OCF bridge device 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.
  • the OCF client sends a GET request to the "/eco/zigbee3.0" resource url of the OCF bridge device.
  • the OCF bridge device 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.
  • the OCF client may further initiate a request for allowing network access.
  • 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.
  • BLE non-OCF protocols
  • the OCF bridge device is provided with configuration resources for configuring non-OCF protocol networks.
  • 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.
  • FIG. 11 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.
  • 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.
  • the configuration operation includes at least one of the following operations:
  • the apparatus further includes:
  • a resource creation module configured to create the configuration resource for the OCF bridge device.
  • 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 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 configuration resource includes at least one of the following attributes:
  • 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.
  • 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.
  • 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.
  • the OCF bridge device is provided with configuration resources for configuring non-OCF protocol networks.
  • 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 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.
  • FIG. 12 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.
  • 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.
  • 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.
  • the transceiver may include a receiver for receiving information and a transmitter for transmitting information
  • the computer device 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.
  • 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 .
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention se rapporte au domaine technique de l'Internet des objets, et concerne un procédé et un appareil de configuration de l'Internet des objets, un dispositif informatique, et un support de stockage. Le procédé comporte les étapes consistant à: faire recevoir, par un dispositif de pont OCF, une demande de configuration de réseau émise par un client OCF, la demande de configuration de réseau comportant une valeur d'attribut d'un attribut de configuration; déterminer un client virtuel hors OCF correspondant à la demande de configuration de réseau; envoyer une instruction de configuration de réseau au client virtuel hors OCF, l'instruction de configuration de réseau étant utilisée pour enjoindre au client virtuel hors OCF d'effectuer une opération de configuration de l'attribut de configuration selon la valeur d'attribut, et l'opération de configuration étant une opération consistant à configurer un réseau hors protocole OCF correspondant au client virtuel hors OCF. La solution réalise la configuration d'un réseau hors protocole OCF par un client OCF, améliorant ainsi l'effet de gestion de réseau sur l'Internet des objets.
PCT/CN2020/101950 2020-07-14 2020-07-14 Procédé et appareil de configuration de l'internet des objets, dispositif informatique, et support de stockage WO2022011563A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2020/101950 WO2022011563A1 (fr) 2020-07-14 2020-07-14 Procédé et appareil de configuration de l'internet des objets, dispositif informatique, et support de stockage
CN202080100473.2A CN115486038B (zh) 2020-07-14 2020-07-14 物联网配置方法、装置、计算机设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/101950 WO2022011563A1 (fr) 2020-07-14 2020-07-14 Procédé et appareil de configuration de l'internet des objets, dispositif informatique, et support de stockage

Publications (1)

Publication Number Publication Date
WO2022011563A1 true WO2022011563A1 (fr) 2022-01-20

Family

ID=79555949

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/101950 WO2022011563A1 (fr) 2020-07-14 2020-07-14 Procédé et appareil de configuration de l'internet des objets, dispositif informatique, et support de stockage

Country Status (2)

Country Link
CN (1) CN115486038B (fr)
WO (1) WO2022011563A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422555A (zh) * 2022-03-28 2022-04-29 成都柔水科技有限公司 一种基于CIM平台可自定义配置IoT数据解析的方法
WO2024011368A1 (fr) * 2022-07-11 2024-01-18 Oppo广东移动通信有限公司 Procédé et appareil de découverte de dispositif, dispositif, support d'enregistrement et produit programme
WO2024031681A1 (fr) * 2022-08-12 2024-02-15 Oppo广东移动通信有限公司 Procédé et appareil de liaison de dispositif, et dispositif, support de stockage et produit-programme

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180063879A1 (en) * 2016-08-29 2018-03-01 Electronics And Telecommunications Research Institute Apparatus and method for interoperation between internet-of-things devices
WO2019112734A1 (fr) * 2017-12-06 2019-06-13 Intel Corporation Gestion de module d'extension pour optimisation de réseau de l'internet des objets (iot)
CN110858838A (zh) * 2018-08-24 2020-03-03 Oppo广东移动通信有限公司 桥接通信的方法和设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10938909B2 (en) * 2015-12-26 2021-03-02 Intel Corporation Reusable device management in machine-to-machine systems
CN109547524B (zh) * 2018-09-30 2022-07-05 青岛海尔科技有限公司 基于物联网的用户行为存储方法、装置、设备及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180063879A1 (en) * 2016-08-29 2018-03-01 Electronics And Telecommunications Research Institute Apparatus and method for interoperation between internet-of-things devices
WO2019112734A1 (fr) * 2017-12-06 2019-06-13 Intel Corporation Gestion de module d'extension pour optimisation de réseau de l'internet des objets (iot)
CN110858838A (zh) * 2018-08-24 2020-03-03 Oppo广东移动通信有限公司 桥接通信的方法和设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LI YONGHUA; HUANG XUXIN; WANG SIYE: "Multiple Protocols Interworking With Open Connectivity Foundation in Fog Networks", IEEE ACCESS, vol. 7, 1 January 1900 (1900-01-01), USA , pages 60764 - 60773, XP011725131, DOI: 10.1109/ACCESS.2019.2907554 *
OCF SPECIFICATION 2.1.1: "OCF Resource to Zigbee Cluster Mapping Specification", OCF RESOURCE TO ZIGBEE CLUSTER MAPPING SPECIFICATION VERSION 2.1.1, 29 February 2020 (2020-02-29), US, pages 1 - 65, XP009534031 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422555A (zh) * 2022-03-28 2022-04-29 成都柔水科技有限公司 一种基于CIM平台可自定义配置IoT数据解析的方法
WO2024011368A1 (fr) * 2022-07-11 2024-01-18 Oppo广东移动通信有限公司 Procédé et appareil de découverte de dispositif, dispositif, support d'enregistrement et produit programme
WO2024031681A1 (fr) * 2022-08-12 2024-02-15 Oppo广东移动通信有限公司 Procédé et appareil de liaison de dispositif, et dispositif, support de stockage et produit-programme

Also Published As

Publication number Publication date
CN115486038A (zh) 2022-12-16
CN115486038B (zh) 2024-05-03

Similar Documents

Publication Publication Date Title
WO2022011563A1 (fr) Procédé et appareil de configuration de l'internet des objets, dispositif informatique, et support de stockage
US11722456B2 (en) Communications in internet-of-things devices
EP3005822B1 (fr) Transport à couche mac pour plateforme de services d'application de services directs à wi-fi sans protocole internet
US20180063879A1 (en) Apparatus and method for interoperation between internet-of-things devices
TWI735429B (zh) 用戶端登錄伺服器端的鑑別方法、裝置、系統及電子設備
WO2022262465A1 (fr) Procédé et système de configuration d'utilisateur centralisée basée sur opc ua pour réseau sensible au temps
JP2003008585A (ja) 通信制御装置及び通信制御方法並びに通信装置及び通信方法
WO2017166130A1 (fr) Procédé d'accès à un équipement nas résidentiel, dispositif correspondant et système
WO2015067036A1 (fr) Procédé de configuration d'accès à distance, procédé, appareil et système d'accès à distance
WO2020038443A1 (fr) Procédé et dispositif de communication de pontage
WO2015168981A1 (fr) Procédé et appareil d'exploitation d'attributs
WO2013185696A2 (fr) Procédé et dispositif de traitement de données
US20230045914A1 (en) Method and apparatus for controlling device in internet of things, and gateway device and storage medium
US8924520B2 (en) Method, remote access server and system for configuring a quality of service parameter
JP4681388B2 (ja) 正しい無線ネットワークに加わるシステムおよび方法
WO2023221708A1 (fr) Procédé, système et appareil de numérotation pdn, procédé, système et appareil de configuration de numérotation multi-pdn, et dispositif et support de stockage
CN102833287B (zh) 分布式文件系统及分布式文件系统中访问数据资源的方法
US11750716B2 (en) Methods for publishing resource, and gateway
WO2022042545A1 (fr) Serveur d'application industrielle de réseau sensible au temps (tsn), client, système, procédé de service et support de stockage
JP2000253024A (ja) 通信システム及び通信装置
WO2017054733A1 (fr) Procédé et dispositif de traitement pour un hébergement et une commutation de stockage
WO2024011367A1 (fr) Procédé et appareil de découverte de dispositif, et dispositif, support de stockage et produit-programme
WO2023184559A1 (fr) Procédé et appareil de partage de dispositif, et dispositif, et support d'enregistrement et produit programme
CN115968543A (zh) 资源映射方法、装置、设备及存储介质
WO2020220272A1 (fr) Procédé et système de changement d'état de ressource, terminal et support de stockage

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20945207

Country of ref document: EP

Kind code of ref document: A1