WO2023082113A1

WO2023082113A1 - Method and apparatus for configuring bridging device, device, and storage medium

Info

Publication number: WO2023082113A1
Application number: PCT/CN2021/129911
Authority: WO
Inventors: 吕小强
Original assignee: Oppo广东移动通信有限公司
Priority date: 2021-11-10
Filing date: 2021-11-10
Publication date: 2023-05-19
Also published as: CN117917048A

Abstract

A method and apparatus for configuring a bridging device, a device, and a storage medium, relating to the technical field of Internet of things. The method comprises: configuring endpoint sharing information in a bridging device (401), the endpoint sharing information being used for indicating shared endpoints among endpoints corresponding to a bridged sub-device, the shared endpoints comprising all or some of the endpoints, and the bridged sub-device being an Internet of things device that accesses the bridging device. By means of the solution, a scenario in which the bridging device is configured in a multi-management mode is expanded, and the flexibility of Multi-admin configuration under a Bridge architecture is improved.

Description

Method, device, device and storage medium for configuring bridge device

technical field

The present application relates to the technical field of the Internet of Things, and in particular to a method, device, device and storage medium for configuring a bridging device.

Background technique

With the continuous development of Internet of Things (IoT) technology, more and more IoT devices have brought great convenience to users' production and life in many fields such as smart home and industrial production.

In related technologies, different IoT devices may support different IoT protocols. In order to enable IoT devices supporting different IoT protocols to be interconnected or managed in a unified manner, IoT devices supporting different IoT protocols can be networked through a bridging device.

Contents of the invention

Embodiments of the present application provide a method, device, device, and storage medium for configuring a bridging device. The solution can improve the flexibility of sharing the access control rights of the bridged sub-devices. Described technical scheme is as follows:

On the one hand, the embodiment of the present application provides a method for configuring a bridging device, the method is executed by the bridging device, and the method includes:

Configuring endpoint sharing information in the bridging device, the endpoint sharing information is used to indicate the shared endpoints among the endpoints corresponding to the bridged sub-device;

Wherein, the shared endpoints include all or part of the endpoints; the bridging sub-device is an IoT device connected to the bridging device.

On the one hand, an embodiment of the present application provides a method for configuring a bridging device, the method is executed by a first configuration device, and the method includes:

Send a request to open a configuration window to the bridge device, the request to open the configuration window includes a bridged sub-device list;

Wherein, the bridged sub-device list is used to indicate the shared endpoint; the shared endpoint includes all or part of the endpoints corresponding to the bridged sub-device; the bridged sub-device is a The Internet of Things device of the bridging device; the request to open the configuration window is used to instruct the bridging device to configure endpoint sharing information in the data model, and the endpoint sharing information is used to indicate the shared endpoint.

On the other hand, an embodiment of the present application provides an apparatus for configuring a bridging device, and the apparatus includes:

A configuration module, configured to configure endpoint sharing information in the bridging device, where the endpoint sharing information is used to indicate the shared endpoints among the endpoints corresponding to the bridged sub-device;

A sending module, configured to send a request to open a configuration window to the bridge device, wherein the request to open the configuration window includes a list of bridged sub-devices;

On the other hand, an embodiment of the present application provides a computer device, the computer device is implemented as an information reporting device, and the computer device includes a processor, a memory, and a transceiver;

A computer program is stored in the memory, and the processor executes the computer program, so that the computer device implements the above method for configuring the bridge device.

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 used to be executed by the processor to The foregoing method for configuring a bridge device is implemented.

In yet 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 a bridge device.

In yet another aspect, the present application also provides a chip, which is configured to run in a computer device, so that the computer device executes the above-mentioned method for configuring a bridge device.

In yet another aspect, the present application provides a computer program product 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 bridge device.

In yet another aspect, the present application provides a computer program, which is executed by a processor of a computer device, so as to implement the above method for configuring a bridge device.

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

For each endpoint corresponding to the IoT device connected to the bridge device, the bridge device can configure the shared endpoints of the above endpoints in the data model, and then accept the configuration of the configuration device based on these shared endpoints, thereby expanding The scenario of configuring the bridge device in the multi-administration mode improves the flexibility of Multi-admin configuration under the Bridge architecture.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings that need to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those skilled in the art, other drawings can also be obtained based on these drawings without creative effort.

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 the bridging architecture involved in the present application;

FIG. 3 is a schematic structural diagram of a data model of a device in the Internet of Things involved in the present application;

FIG. 4 is a flow chart of a method for configuring a bridging device provided by an embodiment of the present application;

FIG. 5 is a flowchart of a method for configuring a bridging device provided by an embodiment of the present application;

FIG. 6 is a configuration framework diagram of a multi-management mode provided by an embodiment of the present application;

FIG. 7 is a flowchart of a method for configuring a bridging device provided by an embodiment of the present application;

FIG. 8 is a schematic flow diagram of configuring an endpoint access cluster in a bridging device related to FIG. 7;

FIG. 9 is a schematic flowchart of configuring descriptor clusters in a bridge device related to FIG. 7;

FIG. 10 is a block diagram of an apparatus for configuring a bridging device provided by an embodiment of the present application;

Fig. 11 is a block diagram of an apparatus for configuring a bridging device 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 ways

In order to make the purpose, technical solution and advantages of the present application clearer, the implementation manners of the present application will be further described in detail below in conjunction with the accompanying drawings.

The network architecture and business scenarios described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute limitations on the technical solutions provided by the embodiments of the present application. The evolution of the technology and the emergence of new business scenarios, the technical solutions provided in the embodiments of this 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: an Internet of Things device 110 (shown as an Internet of Things device 110a and an Internet of Things device 110b in FIG. 1 ) and a control device 120 (shown as a control device 120a and a control device 120b in FIG. 1 ); Optionally, the network architecture may also include a bridging device 130 and a cloud server 140;

The IoT device 110 may refer to a device for providing a server function corresponding to the IoT protocol in the IoT.

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

Alternatively, the IoT device 110 may be an industrial production device, such as a lathe, an industrial robot, a solar panel, a wind generator, and the like.

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

Alternatively, the IoT device 110 may be an intelligent monitoring device, for example, a monitoring camera, an infrared sensor, a sound sensor, a temperature sensor and so on.

In a possible implementation manner, the control device 120 is a terminal device on the user side. For example, the control device 120 can be a smart controller, a smart remote control, a smart phone, a tablet computer, a smart watch, a smart TV, a smart speaker, a smart switch, a gateway, etc.; or, the control device 120 can also be a personal computer, such as a desktop PCs, laptops, personal workstations, and more.

In another possible implementation, the control device 120 is a client entity (which may be a virtual entity) running on a terminal device, for example, the control device 120 may run in a terminal device for accessing IoT devices , control, and management applications (Application, APP).

The bridge device 130 is used to realize the interaction between two devices supporting different IoT protocols. The bridging device 130 provides information conversion and transfer services between the IoT devices 110 supporting different IoT protocols, or between the IoT devices 110 supporting different IoT protocols and the control device 120 .

The bridging device 130 may be a device dedicated to bridging, or the bridging device 130 may also be an intelligent device with a bridging function, such as a gateway or a router.

The cloud server 140 is a server deployed on the network side. For example, the cloud server 140 can store relevant information of each IoT device 110, such as current status, binding account, etc.; the cloud server 140 can also provide a service interface for remote access to the IoT device 110, so that users 110 for remote management or control.

In this embodiment of the application, the aforementioned IoT device 110, control device 120, bridging device 130, and cloud server 140 may be electronic devices that meet the same or different IoT protocols, for example, they may be electronic devices that meet the requirements of the Connectivity Standards Alliance (Connectivity Standards Alliance) , CSA) (or Zigbee Alliance) under the Matter protocol (or through IP (Internet Protocol, Internet Protocol) connected home working group (Connected Home over IP Working Group, CHIP) project) electronic equipment.

In FIG. 1, when the IoT device 110a and the control device 120a support the same protocol specification, a secure connection can be established between the IoT device 110a and the control device 120a, for example, a secure connection based on the Matter specification.

When the IoT device 110b and the control device 120b support different protocol specifications, for example, the IoT device 110b is a Zigbee device, and the control device 120b is a Matter device, the IoT device 110b and the control device 120b can be connected through a bridge device 130 connected.

Taking the IoT device as a Matter device as an example, the data model of the Matter device has the following characteristics:

1) The Matter device contains one or more endpoints Endpoint, represented by an Endpoint Number (Endpoint Number, which can also be abbreviated as endpoint-no).

For example, if a Matter device is a spotlight, and the spotlight has three bulbs, each bulb corresponds to an endpoint, that is, an actual physical device can contain multiple endpoints (of course, it can only contain one endpoint); another example, a The Matter device is a socket, which has 4 jacks, and each jack can correspond to an Endpoint.

2) Each Endpoint corresponds to one or more device types (Device Type), which are represented by a device ID (Device ID).

For example, a Matter device is an air conditioner, and the air conditioner includes a thermostat and a fan. The thermostat and the fan correspond to the same Endpoint, the thermostat corresponds to one device type, and the fan corresponds to another device type. Fans can be controlled through the same Endpoint.

3) Each Endpoint contains a variety of clusters (Cluster), and the Cluster is divided into two types: Server and Client, and the corresponding Cluster IDs are the same.

4) Each Cluster contains a variety of attributes (Attribute), events (Event), and instructions (Command), which are represented by Attribute ID, Event ID, and Command ID, and Attribute and Event have corresponding data types.

The IoT device can also be a Zigbee device. The data model of the Zigbee device is similar to the data model structure of the Matter device. The difference is that there is no Event in the data model of the Zigbee device.

Multi-admin (Multi-admin) mode: In the current IoT, an IoT device or bridge device can be configured by multiple configuration devices to join the corresponding Fabric, and be controlled by controllers (Controllers) belonging to different fabrics respectively. ) to perform operations such as access control.

Among them, Fabric is a security domain, which allows a group of nodes to be identified in the context of the domain, and the identified group of nodes can communicate in the context of the security domain. A node can be identified in one or more security domains.

The configuration process of the above multi-management mode can be as follows:

Step 1: Admin A (Admin A) configures Node AB (the node corresponding to the device) for the first time: including assigning fabric and operational (Operational) identification (Identity, ID), and configuring access control lists (Access Control Lists, ACL) etc.

Step 2: Admin A sets Node AB to enter the configuration state. At this time, Node AB can be configured by Admin B (Admin B), so as to join the fabric to which Admin B belongs.

The process may include: Admin A generates a setup code (setupcode) and sends it to Admin B, and Admin B uses the Setupcode to establish a connection with Node AB; optionally, before establishing a connection, Node AB needs to first register Domain Name System Service Discovery (Domain Name System Service Discovery, DNS-SD) records, so that Admin B can discover Node AB.

Step 3: Admin B discovers the device information corresponding to Node AB through the manual pairing code, and then establishes a secure connection with Node AB and configures it. The configuration content is similar to that in step 1.

Please refer to FIG. 2 , which shows a schematic diagram of the bridge architecture involved in this application. As shown in Figure 2, taking the bridge framework under the Matter protocol as an example, in the current bridge solution of the Internet of Things, a bridge manufacturer application program 201 (also called bridge Manufacturer App, which is a privately implemented App by the manufacturer) is required. To complete the bridging function realization of heterogeneous devices (i.e. non-Matter protocol devices, such as Zigbee devices) such as bridged sub-device 202 (also called Bridged Device, corresponding to BD1～BD3 in Figure 2), wherein, in Figure 2 The Bridged Device can be a physical IoT device or a logical device; the bridge Manufacturer App controls the bridge device 203 (Bridge) to generate the corresponding Matter device 204 (also called Matter Device, corresponding to MD1 in Figure 2) for devices such as BD1 ~MD4), so that Apps that support the Matter protocol (ie, Matter App 1 to Matter App 3) can view and control the bridged sub-device 202 through the bridge device 203, wherein the Matter Device in Figure 2 can be a logical device.

Wherein, the implementation method of generating the corresponding Matter device 204 for devices such as BD1 can be: generate corresponding endpoints (endpoints) on the data model of Bridge, one or more endpoints correspond to a Matter Device; therefore, in the data model of Bridge, both It contains the endpoints of its own function (which can be called endpoint0), and also contains the endpoints corresponding to the heterogeneous devices it bridges.

Please refer to FIG. 3 , which shows a schematic structural diagram of a data model of a device in the Internet of Things involved in the present application. As shown in Figure 3, in the data model of an Internet of Things device, a node (Node) represents a physical device or a logical device, and a node can correspond to one or more endpoints, each endpoint is a logical device, and each endpoint corresponds to There are one or more function sets, and each function set corresponds to one or more specific functions (corresponding properties, methods, events, etc.).

Combined with Figure 3, there is a descriptor cluster (descriptor Cluster) on the endpoint0 of the Bridge device, and the device type (device type) in it needs to include bridge; its components list (parts list) parameter includes all the above endpoints (corresponding to logical devices); The device types parameter of the descriptor Cluster corresponding to the endpoints of Bridged Devices needs to include the bridged sub-device identifier (bridged node, which indicates that the endpoint represents a bridged sub-device) and its device type, thereby identifying the endpoint Corresponding to a Bridged Device function set, where each function set corresponds to one or more functions.

In the above-mentioned Bridge architecture, when the Multi-admin function is performed on the Bridge, the endpoints of Bridged Devices cannot be divided, that is to say, the Multi-admin function can only be performed on the entire Bridge device (including all endpoints); that is to say , when Admin A shares the IoT devices connected under the bridge device with Admin B, it can only share the bridge device and all IoT devices under the bridge device with Admin B, resulting in the The endpoints of Devices are less flexible for sharing.

For the above solution, the subsequent embodiments of this application provide a solution for configuring the bridging device. In the Multi-admin mode, the shared endpoint can be configured in the bridging device, and then the bridging device accepts the configuration of other configuration devices At the same time, the above-mentioned shared endpoints can be selectively configured to other configuration devices, thereby improving the flexibility of Multi-admin configuration under the Bridge architecture.

Please refer to FIG. 4 , which shows a flow chart of a method for configuring a bridge device provided by an embodiment of the present application. The method may be executed by a bridge device. For example, the bridge device may be in the network architecture shown in FIG. 1 The bridging device 130; the method may include the following steps:

Step 401, configure the endpoint sharing information in the bridge device, and the endpoint sharing information is used to indicate the shared endpoint; the above-mentioned shared endpoints include all or part of the endpoints corresponding to the bridged sub-device; the bridged sub-device is IoT devices connected to the bridge device.

After the bridged sub-device (Bridged Device) is connected to the bridged device (Bridge), the bridged device generates a corresponding endpoint (endpoint) locally for the bridged sub-device, so that the bridged device not only has its own endpoint, but also has a bridged device. Individual endpoints for subdevices.

In this embodiment of the application, for each endpoint corresponding to the bridged sub-device, the bridging device can further configure the shared endpoints in the data model, and when accepting the configuration of the configuration device, it can control the range of endpoints shared with the configuration device .

That is to say, in the embodiment of the present application, the above-mentioned endpoint sharing information is used to limit the range of endpoints shared with the configuration device when the bridging device accepts the configuration of the configuration device.

To sum up, in the scheme shown in the embodiment of this application, for each endpoint corresponding to the IoT device connected to the bridge device, the bridge device can configure the shared endpoints among the above endpoints in the data model, and the follow-up can be based on these The shared endpoint accepts the configuration of the configuration device, thereby expanding the scenario of configuring the bridge device in the multi-management mode, and improving the flexibility of Multi-admin configuration under the Bridge architecture.

Wherein, the endpoints to be shared among the bridged sub-devices may be indicated by the first configuration device to the bridging device.

Please refer to FIG. 5 , which shows a flowchart of a method for configuring a bridge device provided by an embodiment of the present application. The method can be executed by a first configuration device. For example, the first configuration device can be as shown in FIG. 1 The control device 120 in the network architecture may also be other devices other than the control device 120; the method may include the following steps:

Step 501, send a request to open the configuration window to the bridge device, and the request to open the configuration window includes a bridged sub-device list; the bridged sub-device list is used to indicate the shared endpoint; the shared endpoint includes the endpoint corresponding to the bridged sub-device All or part of the endpoints in the bridge; the sub-device of the bridge is the IoT device connected to the bridge device; the Open Commissioning Window (OCW) request is used to instruct the bridge device to configure the endpoint sharing information in the data model, and the endpoint sharing information is used to indicate the endpoint being shared.

In this embodiment of the present application, the first configuration device may be a device having full authority of the bridge device. The first configuration device may be a physical device or a logical device (such as a configuration App). After the first configuration device finishes configuring the bridge device, it may request to indicate the shared endpoint to the bridge device by opening a configuration window.

Wherein, in some scenarios, the above-mentioned request for opening the configuration window may also be called an instruction to open the configuration window (OCW Command).

To sum up, in the solution shown in the embodiment of the present application, for each endpoint corresponding to the IoT device connected to the bridge device, the first configuration device instructs the bridge device to configure the shared endpoint among the above endpoints in the data model, Subsequent configurations of configuration devices can be accepted based on these shared endpoints, thereby expanding the scenarios for configuring bridge devices in multi-management mode and improving the flexibility of Multi-admin configuration under the Bridge architecture.

Through the solutions shown in FIG. 4 and FIG. 5 above in this application, the user corresponding to the first configuration device can selectively share the endpoints of the sub-device bridged on the bridging device externally.

Please refer to FIG. 6 , which shows a configuration framework diagram of a multi-management mode provided by an embodiment of the present application. In a possible application scenario, as shown in FIG. 6, there are three bridging sub-devices (marked as 62a, 62b and 62c in FIG. 6) connected to the bridging device 61. Correspondingly, the bridging device 61 corresponds to the The three bridged sub-devices generate corresponding endpoints (ie, endpoint 1 to endpoint 5 in FIG. 6 ). After the first configuration device 63 completes the initial configuration of the bridging device 61, it can select some of the endpoints from endpoint 1 to endpoint 5 to share externally. The sharing process is as follows:

S1, the first configuration device 63 sends a request to open a configuration window OCW to the bridge device 61 .

For example, when user A wants to share part of the devices or functions of the three bridged sub-devices with user B, the shared endpoint or shared bridged sub-device can be set in the first configuration device 63 . The first configuration device 63 sends a request to open the configuration window to the bridge device 61 according to the settings of the user A. Wherein, taking the shared endpoints set by user A as endpoints 3 to 5 as an example, the request to open the configuration window may indicate that endpoints 3 to 5 are the endpoints to be shared.

S2, the bridging device 61 configures the initialized endpoint sharing information in the data model according to the request of opening the configuration window.

Wherein, after the bridging device 61 receives the request to open the configuration window, it can configure the endpoint sharing information in the data model. For example, in FIG. 6, the bridging device 61 configures the endpoint sharing information in the data model according to the endpoint 3 to the endpoint 5; That is to say, the endpoint sharing information is used to indicate in the data model that the aforementioned endpoints 3 to 5 are endpoints that can be shared.

S3, the bridging device 61 completes the configuration of the second configuration device 64 according to the initialized endpoint sharing information.

In FIG. 6, when the second configuration device 64 initiates configuration to the bridging device 61, the bridging device 61 accepts the configuration of the second configuration device 64 within the range from endpoint 3 to endpoint 5 indicated by the endpoint sharing information; that is to say , in the above configuration process, the endpoint shared to the second configuration device 64 does not exceed the range from endpoint 3 to endpoint 5 .

In the solutions shown in the above embodiments of the present application, the endpoint sharing information configured in the bridging device may include adding a dedicated cluster (Cluster) in the data model, or may include existing clusters in the data model.

Please refer to FIG. 7 , which shows a flow chart of a method for configuring a bridge device provided by an embodiment of the present application. The method can be executed interactively by the bridge device, the first configuration device, and the second configuration device. For example, the bridge The device may be the bridging device 130 in the network architecture shown in FIG. 1, and the first configuration device and the second configuration device may be the control device 120 in the network architecture shown in FIG. equipment; the method may include the following steps:

In step 701, the first configuration device sends a configuration window opening request to the bridge device; correspondingly, the bridge device receives the configuration window opening request.

Wherein, at least one bridging sub-device is connected to the bridging device. The sub-devices of the bridge are the IoT devices connected to the bridge device.

Wherein, the open configuration window OCW request is used to indicate the shared endpoint among the endpoints corresponding to the bridged sub-device.

A shared endpoint among the above endpoints corresponding to the bridged sub-device. Optionally, the above shared endpoints include all or part of the above endpoints.

In a possible implementation manner, the request for opening the configuration window includes a bridged sub-device list; the bridged sub-device list is used to indicate the endpoint to be shared.

That is to say, in the embodiment of the present application, the request to open the configuration window may include a bridged sub-device list (BridgedDevicesList), and the bridged sub-device list may directly or indirectly indicate the aforementioned shared endpoint.

In a possible implementation manner, the bridge sub-device list includes at least one of the following information:

The identity of the shared endpoint, and the device type of the shared endpoint.

In the solution shown in the embodiment of the present application, the bridged sub-device list may include the identifier of the shared endpoint, so as to directly indicate the above-mentioned shared endpoint.

Alternatively, the bridge sub-device list may also include the device type (DeviceType) of the shared endpoint to indirectly indicate the shared endpoint (that is, the endpoint corresponding to the device type is the shared endpoint).

For example, the parameters of the OCW request may be as shown in Table 1 below:

Table 1

Step 702, the bridging device publishes DNS-SD records for DNS service discovery.

In a possible implementation manner, the Domain Name System Service Discovery (DNS-SD) record includes at least one of a device type parameter, an endpoint list parameter, and an endpoint device type parameter; the above device type parameter is used to indicate the bridge device The device type; the endpoint list parameter is used to indicate the identifier of the endpoint contained in the discoverable device; the endpoint device type parameter is used to indicate the device type of the discoverable device.

In an exemplary solution, the endpoints included in the discoverable device may be all or part of the endpoints that are shared.

In an exemplary solution of the embodiment of the present application, the above-mentioned DNS-SD record may include the device type (Device Type, DT) parameter of the bridge device, the endpoint list (Endpoints List, EL) parameter and the endpoint device type (in SDT Indicates) parameters.

Among them, the DT field is bridge, indicating that the device type is a bridge device, and the EL field is a specified value (such as 4), wherein, when the DT parameter segment is "bridge", the EL parameter is used to indicate the bridged sub-device that can be discovered ( BridgedDevices) corresponds to the endpoint, and the SDT parameter corresponds to the device type of EL.

Among them, after the bridge device is configured with DNS-SD records, the second configuration device can subsequently discover the Bridge device and the corresponding Bridged Device through the DNS-SD discovery mechanism; the user corresponding to the second configuration device can confirm its configuration through EL information and SDT information After the Bridge device, the scope of the Bridged Device that can be controlled. If the user finds that the above information does not meet expectations, the configuration process can be ended.

Step 703, the first configuration device generates a pairing code, and sends the pairing code to the second configuration device; correspondingly, the second configuration device receives the pairing code.

In this embodiment of the application, the first configuration device may generate pairing code (Pairing Code) information for the second configuration device, and provide the generated pairing code information to the second configuration device in an out-of-band manner, for example, through Bluetooth or Two-dimensional code display and other methods are provided to the second configuration device.

Step 704, the second configuration device discovers the bridging device according to the pairing code, and establishes a secure link with the bridging device to initiate configuration on the bridging device.

Wherein, through the above-mentioned pairing code, the second configuration device can discover the bridging device, obtain information related to establishing a secure link with the bridging device, and establish a secure link with the bridging device according to the obtained information, so as to subsequently initiate configuration on the bridging device .

Step 705, the second configuration device initiates configuration to the bridging device; correspondingly, the bridging device accepts the configuration of the second configuration device according to the information shared by the above endpoints.

In this embodiment of the present application, when the user corresponding to the second configuration device determines to configure the bridge device, the second configuration device may initiate configuration to the bridge device.

In step 706, the bridging device configures endpoint sharing information in the bridging device, where the endpoint sharing information is used to indicate the above-mentioned endpoints to be shared.

Wherein, the bridging device may configure the endpoint sharing information in the bridging device according to the bridging sub-device list carried in the request for opening the configuration window.

In a possible implementation manner, the endpoint sharing information includes the endpoint access cluster, and configuring the endpoint sharing information in the bridge device includes:

Configure the endpoint access cluster in the bridge device;

Wherein, the attribute of the endpoint access cluster is an endpoint access list; the endpoint access list contains at least one endpoint access record; the endpoint access record is used to indicate the endpoints shared with the target security domain;

Wherein, the target security domain is a security domain (Fabric) to which the second configuration device that configures the bridge device belongs.

The above-mentioned endpoint access cluster is used to dynamically generate the attribute content of the component list in the descriptor cluster according to the content of the endpoint access cluster when the bridging device receives a service discovery request or a device discovery request after the configuration is completed.

Wherein, the attribute content of the component list in the dynamically generated descriptor cluster includes the content corresponding to the fabric where the requester of the service discovery request or device discovery request is located, that is, the content shared to the endpoint of the fabric.

Further, the attribute content of the component list in the dynamically generated descriptor cluster may be the content of the node corresponding to the requester of the service discovery request or device discovery request; that is, for different Nodes under the same fabric , the bridge device can generate different EndpointAccessCluster items (items), so that different nodes under the same fabric can limit the PartLists in the DescriptorCluster that can be displayed.

In an exemplary solution of the embodiment of the present application, the bridging device may configure a new dedicated cluster (EndpointAccessCluster) as the above-mentioned endpoint to share information.

Please refer to Table 2 below. The structure definition of the above-mentioned EndpointAccessCluster can be as follows:

Table 2

IDID	属性(attribute)attribute	类型(Type)type
00	EndpointAccessListEndpointAccessList	EndpointAccessStructEndpointAccessStruct

In a possible implementation manner, the endpoint access record includes an access identifier and endpoint indication information;

Wherein, the access identifier is used to indicate the object to be shared by the endpoint; the endpoint indication information is used to indicate the shared endpoint.

In a possible implementation manner, the endpoint indication information includes at least one of an endpoint list and a device type list;

The endpoint list contains the identity of the shared endpoints;

The device type list contains the device types of the shared endpoints.

Please refer to Table 3 below. The structure definition of the above-mentioned EndpointAccessStruct can be as follows:

table 3

In a possible implementation manner, the access identifier includes:

A structure index of the target security domain; or, a structure index of the target security domain, and a node identifier of a target node in the target security domain.

In the embodiment of the present application, the FabricIndex in Table 3 above indicates that the shared endpoint can be shared with any node in the target security domain corresponding to the FabricIndex.

Optionally, the FabricIndex in the above Table 3 can also be replaced by FabricIndex+Node ID, where the Node ID can be the identifier of a node in the target security domain. At this time, the information in Table 3 represents the above shared endpoint The node corresponding to the Node ID can be shared.

In a possible implementation manner, the endpoint sharing information includes the endpoint access cluster, and the configuration of the endpoint access cluster in the bridge device includes:

Initialize the endpoint access cluster in the bridge device; the value in the access identifier field in the initialized endpoint access cluster is a filling value; the access identifier field is a field for carrying the access identifier;

After the second configuration device configures the bridging device, the filled value is replaced with the access identifier.

In a possible implementation manner, the filling value is a password identifier or a specified character.

In the embodiment of this application, the process of the bridging device configuring the endpoint access cluster in the data model can be divided into two steps. The first step is to initialize the EndpointAccessStruct. Before the second configuration device configures the bridging device, the initialization The access identifier field in the endpoint access cluster of the endpoint is temporarily filled with the filling value; in the second step, after the second configuration device configures the bridging device, replace the filling value with the access identifier, that is, replace it with FabricIndex or FabricIndex+ Node ID.

In a possible implementation manner, the above filling value is a password identifier or a specified character.

Wherein, before the configuration of the bridging device by the second configuration device is completed, the bridging device may fill the password ID (passcodeID) or other special characters (such as 0) in the access identification field in the initialized endpoint access cluster.

Wherein, the above password identification can be used by the node (bridge device) to identify the temporary PAKE password verifier used for this configuration. For example, the above password identifier may be a password authenticated key exchange (Password Authenticated Key Exchange, PAKE) password ID.

In a possible implementation manner, the initialization of the endpoint access cluster in the bridge device includes:

Before accepting the configuration of the second configuration device, initializing the endpoint access cluster in the bridging device;

Alternatively, the endpoint access cluster is initialized in the bridging device during acceptance of configuration by the second configuration device.

In this embodiment of the present application, the above step of initializing the EndpointAccessStruct may be performed by the bridging device before accepting the configuration of the second configuration device, for example, before the above step 702, the bridging device may initialize the EndpointAccessStruct after receiving the OCW request.

Alternatively, the above step of initializing the EndpointAccessStruct may also be performed during the process of accepting the configuration of the second configuration device. For example, in step 705, when the bridge device detects that the configuration device initiates the configuration, it may initialize the EndpointAccessStruct.

In a possible implementation manner, the endpoint sharing information includes a descriptor cluster, and configuring the endpoint sharing information in the bridge device includes:

Configure descriptor clusters in the bridge device;

Among them, the component list in the descriptor cluster includes a list of supported endpoint records; the supported endpoint records include supported endpoint records; the supported endpoint records are used to indicate the endpoints that are shared with the target security domain;

Wherein, the target security domain is a security domain to which the second configuration device that configures the bridge device belongs.

In another exemplary solution of the embodiment of the present application, the bridging device may improve the descriptor cluster (Descriptor Cluster) in the bridging device's own endpoint (endpoint0), so as to configure the above-mentioned endpoint sharing information in the bridging device.

Wherein, the above-mentioned Descriptor Cluster is used to describe the server cluster (Server Cluster) information, client cluster (Client Cluster) information, and device type information on the corresponding endpoint; the Descriptor Cluster of the composite device can also include associated endpoint information. Wherein, the composite device may be a device corresponding to multiple endpoints of different device types.

Wherein, the above-mentioned bridge device can configure the above-mentioned endpoint sharing information in the component list in the Descriptor Cluster of endpoint0.

Among them, some attributes contained in the Descriptor Cluster can be shown in Table 4 below:

Table 4

In a possible implementation manner, the supported endpoint record (EndpointAvailableStruct) includes an access identifier and endpoint indication information;

In a possible implementation manner, the access identifier includes:

The endpoint list contains the identity of the shared endpoints;

The device type list contains the device types of the shared endpoints.

In the embodiment of this application, the bridging device can modify the data type of the PartsList in the Descriptor Cluster to a list of EndpointAvaliableStruct, and the structure of the list can be shown in Table 5 below:

table 5

IDID	Fieldfield	DescriptionDescription
00	AccessIDAccessID	Fabricindex+nodeIDFabric index+nodeID
11	EndpointListEndpointList	Endpoint列表Endpoint list

In Table 5, AccessID is the above-mentioned access ID, and the access ID in Table 5 is Fabricindex+nodeID. Optionally, the access ID in Table 5 above can also be replaced by Fabricindex. The meaning of the AccessID here is similar to that of field 0 in Table 3. The above Endpoint list is used to display the shared endpoints.

That is to say, in the embodiment of the present application, the AccessID in the above Table 5 is FabricIndex, indicating that the above shared endpoint can be shared with any node in the target security domain corresponding to the FabricIndex.

Alternatively, when the AccessID in the above table 5 is FabricIndex+node ID, the Node ID can be the identifier of a node in the target security domain, and the Node ID can be passed to the bridging device by the second configuration device during the configuration process. At this time, The information in Table 5 indicates that the above shared endpoint can be shared with the node corresponding to the Node ID.

Optionally, the Endpoint list in the above Table 5 may also be replaced with the device type of the shared endpoint, indicating that the endpoint corresponding to the device type is the shared endpoint.

In a possible implementation manner, configuring the descriptor cluster in the bridge device includes:

Initialize the descriptor cluster in the bridge device; the value in the access identification field in the initialized descriptor cluster is a filling value; the access identification field is a field for carrying the access identification;

In a possible implementation manner, initializing a descriptor cluster in a bridge device includes:

initializing a descriptor cluster in the bridge device prior to accepting configuration from the second configuration device;

Alternatively, the descriptor cluster is initialized in the bridging device during acceptance of configuration by the second configuration device.

Among them, the content and configuration method contained in the above-mentioned EndpointAvailableStruct in the Descriptor Cluster are similar to the content and configuration method contained in the above-mentioned EndpointAccessStruct, and will not be repeated here.

In a possible implementation manner, when accepting the configuration of the second configuration device, the bridging device configures an access control list cluster for nodes in the target security domain; the target endpoint of the access control list cluster belongs to the shared endpoint.

Wherein, the bridging device can generate information such as fabric ID (the ID of the fabric to which the second configuration device belongs), fabric index (the index of the fabric to which the second configuration device belongs) and node ID during the process of accepting the configuration of the second configuration device, And configure the access control list (Access Control List, ACL) cluster, etc. for the second configuration device; then, in the initialized EndpointAccessCluster or Descriptor Cluster, fill in the correct fabricindex or fabricindex+Node ID (the Node ID filled in here is the first 2. Configure the ID of the node in the fabric to which the device belongs). Wherein, the aforementioned fabric ID may be indicated to the bridging device by the second configuration device.

Among them, after the configuration of the above-mentioned descriptor cluster is completed, when the Bridge receives a service discovery request or a device discovery request, it can display to the requester the PartsList corresponding to the fabric where the requester is located according to the PartsList content in the Descriptor Cluster corresponding to the fabric where the requester is located. Content (such as endpoints or Bridged Devices that are allowed to be shared with the fabirc); further, the attribute content of the component list in the above-mentioned descriptor cluster can also be the content corresponding to the node of the requester of the service discovery request or device discovery request.

In the above process, under the same fabric, the target part configured in ACL does not exceed the content defined in EndpointAccessCluster or Descriptor Cluster (that is, it does not exceed the shared endpoint defined in EndpointAccessCluster or Descriptor Cluster).

Optionally, during the configuration process, the target part configured in the above-mentioned ACL is specified by the second configuration device, and the bridging device may check the target part specified by the second configuration device after receiving an instruction from the second configuration device to configure the above-mentioned target part Whether it exceeds the content defined in EndpointAccessCluster or Descriptor Cluster, and if so, an error response can be responded.

Please refer to FIG. 8 , which shows a schematic flowchart of configuring an endpoint access cluster in a bridging device according to an embodiment of the present application. As shown in Figure 8, the process includes the following steps:

S801, Admin 1 initiates a Multi-admin process: sends an OpenCommissioningWindow (OCW) request to the Bridge device, and the request can cause the Bridge device to enter a configuration state. Among them, the BridgedDevicesList parameter is added to the OpenCommissioningWindow request.

S802. After receiving the OCW command, the bridge device (Bridge) initializes the EndpointAccessCluster according to the parameter BridgedDevicesList carried in the request; during the initialization process, the fabricindex part is filled with passcodeID or other special values (such as 0), and the correct fabricindex is filled in after the configuration is completed. ; For EndpointAccess Cluster, admin1 defaults to full authority.

S803. The Bridge publishes the DNS-SD record. Admin 2 can discover this device through this mechanism.

S804, before or after Bridge releases the DNS-SD record, Admin 1 generates a Pairing Code, and sends it to Admin 2 in an out-of-band manner.

S805. After Admin 2 discovers the correct Bridge device and establishes a secure link, it starts to configure the Bridge device: that is, generate fabric ID, fabric index, node id and other information, configure ACL cluster and other information; configure EndpointAccess information, and fill in the correct fabricindex (where , the content of the above S802 can also be completed in this step).

After the above configuration is completed, when Bridge receives a service discovery or device discovery request, it can dynamically generate the PartsList attribute content of the DescriptorCluster of Endpoint0 according to the content of the EndpointAccessCluster, so as to display the content corresponding to the fabric where it is located to the requester (for example, allow the request to The endpoint or Bridged Devices shared by the fabric); further, different EndpointAccessCluster items (items) can be generated for different Nodes under the same fabric, so as to limit the Descriptor Clusters that can be displayed for different Nodes under the same fabric PartList.

Please refer to FIG. 9 , which shows a schematic flowchart of configuring a descriptor cluster in a bridge device according to an embodiment of the present application. As shown in Figure 9, the process includes the following steps:

S901, Admin 1 initiates a Multi-admin process: sends an OpenCommissioningWindow (OCW) request to the Bridge device, and the request can cause the Bridge device to enter a configuration state.

S902. After receiving the OCW command, the bridge device (Bridge) initializes the DescriptorCluster of Endpoint0 according to the parameter BridgedDevicesList carried in the request, and fills in the endpointList information; during the initialization process, the accessID part is filled with passcodeID or other special values such as 0. After the configuration is completed Fill in the correct fabricindex+nodeID, where "+" means string connection.

S903. The Bridge publishes the DNS-SD record. Admin 2 can discover this device through this mechanism.

S904, before or after Bridge releases the DNS-SD record, Admin 1 generates a Pairing Code, and sends it to Admin 2 in an out-of-band manner.

S905. After Admin 2 finds the correct Bridge device and establishes a secure link, it starts to configure the Bridge device: including generating information such as fabric ID, fabric index, and node id, configuring ACL cluster and other information; improving the Descriptor Cluster information of Endpoint0, and filling in the correct Access ID (wherein, the content of the above S902 can also be completed in this step).

After the above configuration is completed, when Bridge receives a service discovery or device discovery request, according to the PartsList content in the Descriptor Cluster, for different fabrics or (fabric+nodeID), it presents the corresponding content of different EndpointLists, so as to display to the requester The content corresponding to the fabric where it is located (such as endpoints or Bridged Devices that are allowed to be shared with the fabric); further, different EndpointAccessCluster items (items) can be generated for different Nodes under the same fabric, so that different The Node respectively limits the PartList in the Descriptor Cluster that it can display.

Through the scheme shown in this application, the subdivision of Bridged Devices can be completed when Multi-admin configuration is performed on Bridge, that is, part of Bridged Devices is allocated for the second configuration device, which provides users with stronger use convenience and sharing devices convenient.

In addition, through the solution shown in this application, it is also possible to indirectly display different content for different fabrics in one device, for example, through the Partslist in the Descriptor Cluster, for different fabrics, or different content in the same fabric. node renders different content.

Please refer to FIG. 10 , which shows a block diagram of an apparatus for configuring a bridge device according to an embodiment of the present application. The apparatus is capable of implementing the functions performed by the bridging device in the method shown in FIG. 4 or FIG. 7 above. As shown in Figure 10, the device may include:

The configuration module 1001 is configured to configure endpoint sharing information in the bridge device, where the endpoint sharing information is used to indicate the shared endpoints among the endpoints corresponding to the bridged sub-device;

In a possible implementation manner, the device further includes:

The receiving module is configured to receive a configuration window opening request sent by the first configuration device before the configuration module 1001 configures the endpoint sharing information in the bridge device, and the configuration window opening request includes a bridge sub-device list; The bridged sub-device list is used to indicate the shared endpoint;

The configuration module is configured to configure the endpoint sharing information in the bridging device according to the bridging sub-device list.

An identifier of the shared endpoint, and a device type of the shared endpoint.

In a possible implementation manner, the endpoint sharing information includes an endpoint access cluster, and the configuration module 1001 is configured to configure an endpoint access cluster in the bridge device;

Wherein, the attribute of the endpoint access cluster is an endpoint access list; the endpoint access list includes at least one endpoint access record; the endpoint access record is used to indicate the endpoint shared to the target security domain;

Wherein, the target security domain is a security domain to which the second configuration device that configures the bridging device belongs.

In a possible implementation manner, the access identifier includes:

a structural index of the target security domain;

Or, the structure index of the target security domain, and the node identifier of the target node in the target security domain.

The endpoint list includes the identifiers of the shared endpoints;

The device type list includes the device type of the shared endpoint.

In a possible implementation manner, the configuration module 1001 is configured to:

The endpoint access cluster is initialized in the bridging device; the value in the access identifier field in the initialized endpoint access cluster is a filling value; the access identifier field is used to carry the access identifier field;

After the second configuration device configures the bridging device, the filling value is replaced with the access identifier.

initializing the endpoint access cluster in the bridging device prior to accepting the configuration of the second configuration device;

or,

Initiating the endpoint access cluster in the bridging device during acceptance of configuration by the second configuration device.

In a possible implementation manner, the endpoint sharing information includes a descriptor cluster, and the configuration module 1001 is configured to configure the descriptor cluster in the bridge device;

Wherein, the component list in the descriptor cluster includes a list of supported endpoint records; the supported endpoint records include supported endpoint records; the supported endpoint records are used to indicate the endpoints shared to the target security domain;

In a possible implementation manner, the supported endpoint record includes an access identifier and endpoint indication information;

In a possible implementation manner, the access identifier includes:

a structural index of the target security domain;

The endpoint list includes the identifiers of the shared endpoints;

The device type list includes the device type of the shared endpoint.

Initialize the descriptor cluster in the bridge device; the value in the initialized access identifier field in the descriptor cluster is a filling value; the access identifier field is a field for carrying the access identifier ;

initializing the descriptor cluster in the bridge device prior to accepting configuration from the second configuration device;

or,

The descriptor cluster is initialized in the bridge device during acceptance of configuration by the second configuration device.

In a possible implementation manner, the configuration module 1001 is further configured to configure an access control list cluster for nodes in the target security domain when accepting the configuration of the second configuration device; the access control list The cluster's target endpoints belong to the shared endpoints.

In a possible implementation manner, the device further includes:

An publishing module, configured to publish a domain name system service discovery DNS-SD record before the configuration module configures an access control list cluster for nodes in the target security domain when accepting the configuration of the second configuration device;

Wherein, the DNS-SD record includes at least one of a device type parameter, an endpoint list parameter, and an endpoint device type parameter;

The device type parameter is used to indicate the device type of the bridging device;

The endpoint list parameter is used to indicate the identity of the endpoint contained in the discoverable device;

The endpoint device type parameter is used to indicate the device type of the discoverable device.

To sum up, in the scheme shown in the embodiment of this application, for each endpoint corresponding to the IoT device connected to the bridge device, the bridge device can configure the shared endpoints among the above endpoints in the data model, and the follow-up can be based on these The shared endpoint accepts the configuration of the configuration device, thereby expanding the configuration scenario of the bridge device in the multi-management mode, and improving the flexibility of the Multi-admin configuration under the Bridge architecture.

Please refer to FIG. 11 , which shows a block diagram of an apparatus for configuring a bridge device provided by an embodiment of the present application. The apparatus has the functions executed by the first configuration device in the method shown in FIG. 5 or FIG. 7 . As shown in Figure 11, the device may include:

The sending module 1101 is configured to send a request for opening a configuration window to the bridge device, and the request for opening the configuration window includes a bridge sub-device list;

An identifier of the shared endpoint, and a device type of the shared endpoint.

It should be noted that when the device provided by the above embodiment realizes its functions, it only uses the division of the above-mentioned functional modules as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by 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 foregoing embodiments, the specific manner in which each module executes operations has been described in detail in the embodiments related to 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 can be implemented as a communication component, which can be a communication chip. The communication chip can also be called a transceiver.

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

The memory 1204 may be used to store a computer program, and the processor 1201 is used to execute the computer program, so as to implement various steps in the foregoing method embodiments.

In addition, the memory 1204 can be realized by any type of volatile or non-volatile storage device or their combination, volatile or non-volatile storage device includes but not limited to: magnetic disk or optical disk, electrically erasable and 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 solution, when the computer device 1200 is implemented as a bridging device, the processor 1201 is configured to configure endpoint sharing information in the bridging device, and the endpoint sharing information is used to indicate the The endpoints that are shared among the endpoints;

Wherein, the processes performed by the processor 1201 and the transceiver in the computer device 1200 may refer to the steps performed by the bridge device in any of the methods shown in FIG. 4 or FIG. 7 above.

In another exemplary solution, when the computer device 1200 is implemented as the first configuration device, the transceiver is configured to send a request to open the configuration window to the bridge device, and the request to open the configuration window includes a bridge sub-device list ;

Wherein, the process executed by the processor 1201 and/or the transceiver in the computer device 1200 may refer to the steps executed by the first configuration device in any of the methods shown in FIG. 5 or FIG. 7 above.

The embodiment of the present application also 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 method shown in FIG. 4 , FIG. 5 or FIG. 7 above. In, all or part of the steps performed by the bridging device or the first configuration device.

The present application also provides a chip, which is used to run in a computer device, so that the computer device executes all the steps performed by the bridge device or the first configuration device in the method shown in FIG. 4 , FIG. 5 or FIG. 7 . or partial steps.

The present application also provides a computer program product, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the method shown in FIG. 4, FIG. 5 or FIG. 7 above, and the bridge device or the first configuration All or part of the steps performed by the device.

The present application also provides a computer program, the computer program is executed by the processor of the computer device, so as to realize all or partial steps.

Those skilled in the art should be aware that, in the foregoing one or more 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 media may be any available media that can be accessed by a general purpose or special purpose computer.

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

Claims

A method for configuring a bridging device, characterized in that the method is executed by the bridging device, and the method includes:

Configuring endpoint sharing information in the bridging device, the endpoint sharing information is used to indicate the shared endpoints among the endpoints corresponding to the bridged sub-device;

Wherein, the shared endpoints include all or part of the endpoints; the bridging sub-device is an IoT device connected to the bridging device.
The method according to claim 1, further comprising: before configuring the endpoint sharing information in the bridge device:

receiving a configuration window opening request sent by the first configuration device, the configuration window opening request including a bridged sub-device list; the bridged sub-device list is used to indicate the shared endpoint;

The configuring the endpoint sharing information in the bridge device includes:

Configuring the endpoint sharing information in the bridge device according to the bridge sub-device list.
The method according to claim 2, wherein the bridged sub-device list includes at least one of the following information:

An identifier of the shared endpoint, and a device type of the shared endpoint.
The method according to any one of claims 1 to 3, wherein the endpoint sharing information includes endpoint access clusters, and configuring the endpoint sharing information in the bridging device includes:

configuring the endpoint access cluster in the bridging device;

Wherein, the attribute of the endpoint access cluster is an endpoint access list; the endpoint access list includes at least one endpoint access record; the endpoint access record is used to indicate the endpoint shared to the target security domain;

Wherein, the target security domain is a security domain to which the second configuration device that configures the bridging device belongs.
The method according to claim 4, wherein the endpoint access record includes an access identifier, and endpoint indication information;

Wherein, the access identifier is used to indicate the object to be shared by the endpoint; the endpoint indication information is used to indicate the shared endpoint.
The method according to claim 5, wherein the access identifier comprises:

a structural index of the target security domain;

Or, the structure index of the target security domain, and the node identifier of the target node in the target security domain.
The method according to claim 5, wherein the endpoint indication information includes at least one of an endpoint list and a device type list;

The endpoint list includes the identifiers of the shared endpoints;

The device type list includes the device type of the shared endpoint.
The method according to claim 5, wherein the configuring the endpoint access cluster in the bridging device comprises:

Initialize the endpoint access cluster in the bridging device; the value in the initialized access identifier field in the endpoint access cluster is a filling value; the access identifier field is used to carry the access identifier field;

After the second configuration device configures the bridging device, the filling value is replaced with the access identifier.
The method according to claim 8, wherein the filling value is a password identifier or a specified character.
The method according to claim 8, wherein the initializing the endpoint access cluster in the bridging device comprises:

initializing the endpoint access cluster in the bridging device prior to accepting the configuration of the second configuration device;

or,

Initiating the endpoint access cluster in the bridging device during acceptance of configuration by the second configuration device.
The method according to any one of claims 1 to 3, wherein the endpoint sharing information includes a descriptor cluster, and configuring the endpoint sharing information in the bridge device includes:

configuring descriptor clusters in the bridge device;

Wherein, the component list in the descriptor cluster includes a list of supported endpoint records; the supported endpoint records include supported endpoint records; the supported endpoint records are used to indicate the endpoints shared to the target security domain;

Wherein, the target security domain is a security domain to which the second configuration device that configures the bridging device belongs.
The method according to claim 11, wherein the supported endpoint record includes an access identifier, and endpoint indication information;

Wherein, the access identifier is used to indicate the object to be shared by the endpoint; the endpoint indication information is used to indicate the shared endpoint.
The method according to claim 12, wherein the access identifier comprises:

a structural index of the target security domain;

Or, the structure index of the target security domain, and the node identifier of the target node in the target security domain.
The method according to claim 12, wherein the endpoint indication information includes at least one of an endpoint list and a device type list;

The endpoint list includes the identifiers of the shared endpoints;

The device type list includes the device type of the shared endpoint.
The method according to claim 12, wherein the configuring the descriptor cluster in the bridge device comprises:

Initialize the descriptor cluster in the bridge device; the value in the initialized access identifier field in the descriptor cluster is a filling value; the access identifier field is a field for carrying the access identifier ;

After the second configuration device configures the bridging device, the filling value is replaced with the access identifier.
The method according to claim 15, wherein the filling value is a password identifier or a specified character.
The method according to claim 15, wherein the initializing the descriptor cluster in the bridge device comprises:

initializing the descriptor cluster in the bridge device prior to accepting configuration from the second configuration device;

or,

The descriptor cluster is initialized in the bridge device during acceptance of configuration by the second configuration device.
The method according to any one of claims 4 to 17, further comprising:

When accepting the configuration of the second configuration device, configure an access control list cluster for the nodes in the target security domain; the target endpoint of the access control list cluster belongs to the shared endpoint.
The method according to any one of claims 1 to 18, further comprising:

Publish DNS service discovery DNS-SD records;

Wherein, the DNS-SD record includes at least one of a device type parameter, an endpoint list parameter, and an endpoint device type parameter;

The device type parameter is used to indicate the device type of the bridging device;

The endpoint list parameter is used to indicate the identity of the endpoint contained in the discoverable device;

The endpoint device type parameter is used to indicate the device type of the discoverable device.
A method for configuring a bridging device, wherein the method is executed by a first configuration device, and the method includes:

Send a request to open a configuration window to the bridge device, the request to open the configuration window includes a bridged sub-device list;

Wherein, the bridged sub-device list is used to indicate the shared endpoint; the shared endpoint includes all or part of the endpoints corresponding to the bridged sub-device; the bridged sub-device is a The Internet of Things device of the bridging device; the request to open the configuration window is used to indicate that the endpoint sharing information is configured in the bridging device, and the endpoint sharing information is used to indicate the shared endpoint.
The method according to claim 20, wherein the bridged sub-device list includes at least one of the following information:

An identifier of the shared endpoint, and a device type of the shared endpoint.
A device for configuring a bridging device, characterized in that the device comprises:

A configuration module, configured to configure endpoint sharing information in the bridging device, where the endpoint sharing information is used to indicate the shared endpoints among the endpoints corresponding to the bridged sub-device;

Wherein, the shared endpoints include all or part of the endpoints; the bridging sub-device is an IoT device connected to the bridging device.
The device according to claim 22, further comprising:

The receiving module is configured to receive a configuration window opening request sent by the first configuration device before the configuration module configures the endpoint sharing information in the bridging device, and the configuration window opening request includes a bridge sub-device list; the The bridged sub-device list is used to indicate the shared endpoint;

The configuration module is configured to configure the endpoint sharing information in the bridging device according to the bridging sub-device list.
The device according to claim 23, wherein the bridged sub-device list includes at least one of the following information:

An identifier of the shared endpoint, and a device type of the shared endpoint.
The device according to any one of claims 22 to 24, wherein the endpoint sharing information includes an endpoint access cluster, and the configuration module is configured to configure an endpoint access cluster in the bridging device;

Wherein, the attribute of the endpoint access cluster is an endpoint access list; the endpoint access list includes at least one endpoint access record; the endpoint access record is used to indicate the endpoint shared to the target security domain;

Wherein, the target security domain is a security domain to which the second configuration device that configures the bridging device belongs.
The device according to claim 25, wherein the endpoint access record includes an access identifier, and endpoint indication information;

Wherein, the access identifier is used to indicate the object to be shared by the endpoint; the endpoint indication information is used to indicate the shared endpoint.
The device according to claim 26, wherein the access identifier comprises:

a structural index of the target security domain;

Or, the structure index of the target security domain, and the node identifier of the target node in the target security domain.
The apparatus according to claim 26, wherein the endpoint indication information includes at least one of an endpoint list and a device type list;

The endpoint list includes the identifiers of the shared endpoints;

The device type list includes the device type of the shared endpoint.
The device according to claim 26, wherein the configuration module is configured to:

Initialize the endpoint access cluster in the bridging device; the value in the initialized access identifier field in the endpoint access cluster is a filling value; the access identifier field is used to carry the access identifier field;

After the second configuration device configures the bridging device, the filling value is replaced with the access identifier.
The device according to claim 29, wherein the filling value is a password identifier or a specified character.
The device according to claim 29, wherein the configuration module is configured to:

initializing the endpoint access cluster in the bridging device prior to accepting the configuration of the second configuration device;

or,

Initiating the endpoint access cluster in the bridging device during acceptance of configuration by the second configuration device.
The device according to any one of claims 22 to 24, wherein the endpoint sharing information includes a descriptor cluster, and the configuration module is configured to configure the descriptor cluster in the bridge device;

Wherein, the component list in the descriptor cluster includes a supported endpoint record list; the supported endpoint record includes a supported endpoint record; the supported endpoint record is used to indicate the endpoint shared to the target security domain;

Wherein, the target security domain is a security domain to which the second configuration device that configures the bridging device belongs.
The device according to claim 32, wherein the supported endpoint record includes an access identifier, and endpoint indication information;

Wherein, the access identifier is used to indicate the object to be shared by the endpoint; the endpoint indication information is used to indicate the shared endpoint.
The device according to claim 33, wherein the access identifier comprises:

a structural index of the target security domain;

Or, the structure index of the target security domain, and the node identifier of the target node in the target security domain.
The device according to claim 33, wherein the endpoint indication information includes at least one of an endpoint list and a device type list;

The endpoint list includes the identifiers of the shared endpoints;

The device type list includes the device type of the shared endpoint.
The device according to claim 33, wherein the configuration module is configured to:

Initialize the descriptor cluster in the bridge device; the value in the initialized access identifier field in the descriptor cluster is a filling value; the access identifier field is a field for carrying the access identifier ;

After the second configuration device configures the bridging device, the filling value is replaced with the access identifier.
The device according to claim 36, wherein the filling value is a password identifier or a specified character.
The device according to claim 36, wherein the configuration module is configured to:

initializing the descriptor cluster in the bridge device prior to accepting configuration from the second configuration device;

or,

The descriptor cluster is initialized in the bridge device during acceptance of configuration by the second configuration device.
The device according to any one of claims 25 to 38, wherein the configuration module is further configured to configure an access control list for nodes in the target security domain when accepting the configuration of the second configuration device cluster; the target endpoint of the access control list cluster belongs to the shared endpoint.
The device according to any one of claims 22 to 39, wherein the device further comprises:

An publishing module, configured to publish a domain name system service discovery DNS-SD record before the configuration module configures an access control list cluster for nodes in the target security domain when accepting the configuration of the second configuration device;

Wherein, the DNS-SD record includes at least one of a device type parameter, an endpoint list parameter, and an endpoint device type parameter;

The device type parameter is used to indicate the device type of the bridging device;

The endpoint list parameter is used to indicate the identity of the endpoint contained in the discoverable device;

The endpoint device type parameter is used to indicate the device type of the discoverable device.
A device for configuring a bridging device, characterized in that the device comprises:

A sending module, configured to send a request to open a configuration window to the bridge device, wherein the request to open the configuration window includes a list of bridged sub-devices;

Wherein, the bridged sub-device list is used to indicate the shared endpoint; the shared endpoint includes all or part of the endpoints corresponding to the bridged sub-device; the bridged sub-device is a The Internet of Things device of the bridging device; the request to open the configuration window is used to instruct the bridging device to configure endpoint sharing information in the data model, and the endpoint sharing information is used to indicate the shared endpoint.
The device according to claim 41, wherein the bridged sub-device list includes at least one of the following information:

An identifier of the shared endpoint, and a device type of the shared endpoint.
A computer device, characterized in that the computer device includes a processor, a memory, and a transceiver;

A computer program is stored in the memory, and the processor executes the computer program, so that the computer device implements the method for configuring a bridge device as shown in any one of claims 1 to 21.
A computer-readable storage medium, wherein a computer program is stored in the storage medium, and the computer program is used to be executed by a processor, so as to implement the bridge device as shown in any one of claims 1 to 21. The method of configuration.
A chip, characterized in that the chip is used to run in a computer device, so that the computer device executes the method for configuring a bridge device as claimed in any one of claims 1 to 21.
A computer program product, characterized in that the computer program product includes computer instructions, the computer instructions are stored in a computer-readable storage medium; a processor of a computer device reads the computer-readable instructions, and execute the computer instructions, so that the computer device executes the method for configuring a bridge device as shown in any one of claims 1 to 21.
A computer program, characterized in that the computer program is executed by a processor of a computer device to implement the method for configuring a bridge device as claimed in any one of claims 1 to 21.