WO2024065091A1

WO2024065091A1 - Method for device capability discovery, server device, and client device

Info

Publication number: WO2024065091A1
Application number: PCT/CN2022/121364
Authority: WO
Inventors: 包永明; 茹昭; 吕小强; 张军; 杨宁
Original assignee: Oppo广东移动通信有限公司
Priority date: 2022-09-26
Filing date: 2022-09-26
Publication date: 2024-04-04

Abstract

Provided are a method for device capability discovery, a server device, and a client device. The method comprises: a server device receiving a first message sent by a client device, the first message being used to query a first cluster, information of the first cluster being used by the client device to discover a capability of the server device, and the information of the first cluster comprising: information of all service endpoints included in the server device, and information of a cluster included in any service endpoint among all the service endpoints. In embodiments of the present application, the first cluster comprises information about all the service endpoints included in the server device, and information of clusters included in each service endpoint. Compared with a conventional client device, which needs to execute multiple read request operations to acquire information about clusters included in each service endpoint, the number of interactions between the client device and the server device can be reduced, acquisition efficiency can be increased, and the user experience can be improved.

Description

Method, server device and client device for device capability discovery

Technical Field

The present application relates to the technical field of Internet of Things, and more specifically, to a method for device capability discovery, a server device, and a client device.

Background technique

In some scenarios, the client device needs to perform capability discovery on the server device in order to control it according to the capabilities of the server device. In related technologies, the client device needs to perform multiple read request operations to discover all the capabilities of the server device. Using this method to discover the capabilities of the server device makes the interaction process between the client device and the server device complicated and inefficient, which in turn affects the user experience.

Summary of the invention

The present application provides a method for device capability discovery, a server device and a client device. The following introduces various aspects involved in the present application.

In a first aspect, a method for device capability discovery is provided, comprising: a server device receives a first message sent by a client device, the first message being used to query a first cluster; wherein information of the first cluster is used by the client device to discover capabilities of the server device, the information of the first cluster comprising: information of all service endpoints contained in the server device; and information of a cluster contained in any one of the service endpoints.

In a second aspect, a method for device capability discovery is provided, comprising: a client device sends a first message to a server device, the first message being used to query a first cluster; wherein information of the first cluster is used by the client device to discover capabilities of the server device, the information of the first cluster comprising: information of all service endpoints contained in the server device; and information of a cluster contained in any one of the service endpoints.

According to a third aspect, a server device is provided, comprising: a receiving module, used to receive a first message sent by a client device, the first message being used to query a first cluster; wherein the information of the first cluster is used by the client device to discover the capability of the server device, the information of the first cluster comprising: information of all service endpoints contained in the server device; and information of a cluster contained in any one of the service endpoints.

In a fourth aspect, a client device is provided, comprising: a sending module, used to send a first message to a server device, the first message being used to query a first cluster; wherein the information of the first cluster is used by the client device to discover the capabilities of the server device, and the information of the first cluster includes: information of all service endpoints contained in the server device; and information of the cluster contained in any one of the all service endpoints.

In a fifth aspect, a server device is provided, comprising a processor, a memory and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the server device executes part or all of the steps in the method of the first aspect.

In the sixth aspect, a client device is provided, comprising a processor, a memory and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the client device executes part or all of the steps in the method of the second aspect.

In a seventh aspect, an embodiment of the present application provides a communication system, which includes the above-mentioned server device and/or client device. In another possible design, the system may also include other devices that interact with the server device or client device in the solution provided by the embodiment of the present application.

In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program enables a server device or a client device to execute part or all of the steps in the methods of the above aspects.

In a ninth aspect, an embodiment of the present application provides a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a server device or a client device to perform some or all of the steps in the above-mentioned various aspects of the method. In some implementations, the computer program product can be a software installation package.

In the tenth aspect, an embodiment of the present application provides a chip, which includes a memory and a processor. The processor can call and run a computer program from the memory to implement some or all of the steps described in the methods of the above aspects.

In the embodiment of the present application, the first cluster includes information of all service endpoints contained in the server device and information of the cluster contained in each service endpoint. Compared with the traditional client device that needs to perform multiple read request operations to obtain the information of the cluster contained in each service endpoint, the number of interactions between the client device and the server device can be reduced, the acquisition efficiency can be improved, and the user experience can be improved.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of a data model structure of a Matter device applicable to an embodiment of the present application.

FIG2 is a diagram showing an example of a system architecture of a communication system to which an embodiment of the present application is applicable.

FIG. 3 is a flow chart of a conventional method for device capability discovery.

FIG. 4 is a flow chart of a method for device capability discovery provided in an embodiment of the present application.

FIG5 is a flow chart of a method for device capability discovery provided in another embodiment of the present application.

FIG6 is a flow chart of a method for device capability discovery provided in yet another embodiment of the present application.

FIG. 7 is a flow chart of a method for device capability discovery provided in yet another embodiment of the present application.

FIG8 is a schematic diagram of the structure of a server device provided in an embodiment of the present application.

FIG. 9 is a schematic diagram of the structure of a client device provided in an embodiment of the present application.

FIG. 10 is a schematic structural diagram of a communication device provided in an embodiment of the present application.

Detailed ways

The technical solution in the present application will be described below in conjunction with the accompanying drawings. For ease of understanding, the terms involved in the embodiments of the present application are introduced below in conjunction with Figures 1 and 2. It should be noted that the following takes the scenario of the Matter protocol as an example to introduce the terms involved in the embodiments of the present application and the solutions of the embodiments of the present application. Of course, the solutions of the embodiments of the present application can also be applied to other Internet of Things protocols.

It should be noted that the terms introduced below can be arbitrarily combined with the technical solutions described later, and they all belong to part of the embodiments of the present application.

The Internet of Things (IoT) is the "Internet of Everything Connected". It is a network that extends and expands on the basis of the Internet. It can connect any object to the Internet through various information sensing devices (such as radio frequency identification, global positioning system, etc.) to form a huge network for information exchange and communication to achieve interconnection between all things. In some embodiments, the IoT device can be a smart home device. For example, the IoT device can include smart air conditioners, smart refrigerators, washing machines, rice cookers, sweeping robots and other devices. In some embodiments, the IoT device can be a smart monitoring device. For example, the IoT device can include monitoring cameras, temperature sensors, sound sensors, etc.

At present, different manufacturers may use different communication protocols (also called ecological chain protocols) to achieve interconnection between IoT devices that support the communication protocols. This may lead to the inability of IoT devices produced by different manufacturers to communicate with each other, and the true interconnection of all things cannot be achieved.

Based on this, the Connectivity Standards Alliance (CSA) launched an IoT application layer technology standard - Matter standard protocol, which can provide an interoperable application layer solution for smart home devices based on the Internet Protocol (IP). In some embodiments, the Matter standard can also be called the connected home over IP (CHIP) standard. In some embodiments, the Matter standard can support three underlying communication protocols: Ethernet, Wi-Fi, and Thread, and can allow IoT devices with different protocols to communicate with each other.

Data Model of Matter Device

FIG1 is a data model structure of a Matter device applicable to an embodiment of the present application. The data model structure 100 of the Matter device includes a node 110, an endpoint 120, and a cluster 130.

Node 110 encapsulates an addressable, unique resource on the network, has a set of functions and capabilities, and can be clearly viewed by the user as a functional whole. Generally, node 110 can be the highest or outermost first-order element in the data model. In other words, node 110 is the only addressable element at the outermost layer of the data model. Therefore, the node can represent a device node and belongs to a logical device.

A physical entity (e.g., a Matter device) may be a node 110, or in other words, a node 110 may refer to a Matter device node. It should be noted that a node may have multiple node identifiers (IDs), and the scope of each node ID is a specific network (fabric). For example, when a node ID is used as a target address for an interaction, the network that specifies the scope of the node ID is the access network for the interaction.

A node may include one or more endpoints 120. An endpoint 120 is an instance, which may be a service instance or a virtual device, indicated by a device type. Each endpoint 120 conforms to one or more device type definitions, which define the clusters supported by the endpoint. In some embodiments, an endpoint may be understood as a service instance/virtual device indicated by a device type. A cluster is an object class instantiated on an endpoint.

It should be noted that in this architecture model, the device type can be the highest semantic element. The device type defines the conformance of a set of endpoints 120. The device type defines a set of requirements for a node 110 or an endpoint 120.

In some embodiments, endpoints can be divided into two categories: endpoint 0 and business endpoints. Endpoint 0 can be understood as the first endpoint in a node, and the device type of endpoint 0 is the "root node" device type. In some embodiments, endpoint 0 can also be called the root node endpoint. Endpoint 0 must be included under each node. A business endpoint can be understood as any endpoint in a node except endpoint 0. A business endpoint can support the main operations of a node. For example, a business endpoint can include one or more application clusters.

Each endpoint 120 may be a collection of functions, which may include one or more clusters 130 .

Cluster 130 is a functional building block element of the data model, or in other words, cluster 130 belongs to an element that builds a function set. In some embodiments, a cluster may also be referred to as a function set, a function set, a function cluster, a cluster, etc., which is not limited by the embodiments of the present application. The cluster specification defines a client and a server that correspond to each other through interaction. In other words, cluster 130 may include two roles, namely, a client and a server, wherein the client belongs to the control end and the server belongs to the controlled end. Cluster 130 may be regarded as an interface, a service or an object class, and is the lowest independent functional element in the data model.

Generally, the above clusters can be divided into two categories: utility clusters and application clusters.

The utility cluster is not part of the main application operation of the endpoint. The utility cluster can be used for configuration, discovery, addressing, diagnosis, monitoring device health, software updates, etc. The utility cluster may have a temporary relationship with its cluster counterpart. In an embodiment of the present application, the utility cluster may include a descriptor cluster. Of course, the embodiment of the present application is not limited to this. The utility cluster may also include other clusters such as a binding cluster.

An application cluster supports the main operations of an endpoint. In some embodiments, an application cluster may also be referred to as a business cluster. An application cluster may support the interaction of one or more persistent applications between a client and a server. For example, in a switch cluster (On/Off cluster) in a smart light, a client may send a control command to a server (i.e., a switch cluster) to control the switch of a smart light.

In some embodiments, the service cluster may refer to a cluster on other endpoints except endpoint 0 in the node, that is, a cluster on a service endpoint.

An application cluster is not a utility cluster, even though it may natively support utility functionality such as calibration, operation modes, etc. An application cluster specification should not involve layers and processes outside of its application domain.

Typically, each cluster 130 may be defined by a cluster specification, which defines the elements of the cluster 130, including attributes, events, commands, and behaviors related to the interactions between these elements. In some embodiments, attributes, commands, and events may also be referred to as interface units of the cluster 130, and corresponding functions may be provided through these three interface units.

In some embodiments, attributes, events, commands, and behaviors in cluster 130 are mandatory or optional, depending on the definition of cluster 130 .

The following is a brief introduction to the main elements of the cluster, including commands, properties, and events.

Attributes can be used to describe functional units in a cluster, and a cluster can contain 0 or more attributes. Attributes are cluster data. Currently, the protocol stipulates that each attribute can be listed in a table, and the data quality columns of the attributes defined in the table can include: ID, name, (data) type (type), constraint (constraint), other qualities, access, default (value) and compliance. In some implementations, attributes can also define their related semantics and behaviors. Attributes can reflect the queryable/settable status, configuration, and capabilities of a device. In some cases, if privileges are not explicitly defined for an attribute, the default access privilege is in effect.

Cluster commands (also called "commands") can be used to describe the control of a cluster. A cluster can contain 0 or more commands. A command is a set of data fields, each data type is passed between the client and server cluster instances to invoke the behavior of the command recipient. Currently, the protocol stipulates that each command can be listed in a table, which can contain data quality columns for the command: identification (ID), name (name), direction (direction), response (response), access (access), and conformance (conformance). Accordingly, a command can indicate zero or more fields defined in a table. Each command field is defined as a row in the table.

Events can be used to describe a record of a specific behavior that has occurred in the cluster in the past, or events define a record of what happened in the past. In this regard, an event record can be thought of as a log entry that provides a chronological view of events on a node through an event record stream. A cluster can contain 0 or more events. Unlike attributes, which do not provide any edge-preserving functionality (that is, there is no guarantee that every change in an attribute will be delivered to the observer), events allow each individual edge or change to be captured and reliably delivered to the observer. This is critical for safety and security applications that rely on guarantees of correct behavior. Currently, the protocol stipulates that each cluster event can be listed in a table, and the data quality columns of the event defined in the table can include: ID, priority, access, and compliance.

For ease of understanding, the following describes the meanings of several common data qualities contained in commands, attributes, and events. It should be noted that the commands, attributes, and events in the embodiments of the present application may also include other data qualities, or include parts of the above data qualities. The embodiments of the present application do not limit this.

Identifier, which indicates the unique field ID of a field, or the unique identifier of a command (or attribute, event).

Name, which indicates the unique name of the field, or the name of the command (or attribute).

Type indicates the data type of the field, or the data type of the command parameter (or attribute parameter).

Direction, usually present in the command list, is used to define the transmission direction of the command, for example, it can be defined as from the client to the server. For another example, it can be defined as from the server to the client.

Access permissions, which define how an element can be accessed (e.g., read or write) and what permissions are required to access the data. In some implementations, access permissions may include V, which indicates that read access or call access requires view privileges. Access permissions may also include O, which indicates that "read access", "write access", or "call access" requires operation permissions. Access permissions may also include R, which indicates read access. Access permissions may also include W, which indicates write access.

Response, usually exists in the command list, and is used to define the response message of the command.

Quality, used to define additional data qualities not covered in other columns.

Default, used to define the default value. It should be noted that the default value is not the value used when the server returns the factory refresh settings. The default value can indicate that the compliance specified for the data field can be optional or can change over time. When the actual data field value does not exist, a default value can be defined to complete the dependency.

Conformance, defines the optionality and dependencies of any data model element or set of elements. Typically, this column is valid for attributes, commands, events, enumerations, and fields of commands, events, or structures. In some implementations, "M" indicates that the corresponding command is part of the basic mandatory feature set, and "O" indicates that the corresponding command is part of the optional feature set.

For commands, client-to-server command conformance means that the server should recognize and support client-to-server commands and generate responses as defined. Server-to-client command conformance means that the server should send commands as defined by the cluster behavior, i.e., respond to client-to-server commands. Command conformance depends on supported server features. Clients should not be required to support optional commands or commands that depend on optional features.

Constraints include all and desc. All is defined in a numeric data type to allow all values. desc indicates that the constraint is defined in the description part.

Range, which indicates the value range of a field. Range can support two forms: explicit constraint and width constraint. Among them, the explicit constraint can give the minimum and maximum values corresponding to the value of the field, for example, the value range of a field is (0,128). The width constraint can limit the value of a field to a specific number of bytes, for example, the value of a field is limited to 8 bytes. In some embodiments, the value of the range can include "N/A" to indicate not applicable. Of course, "N/A" can also appear in other parts (other data quality), such as defaults, constraints, etc.

Priority: Each event record has an associated priority. This priority can be used to describe the usage semantics of the event.

For ease of understanding, a specific example is given below to illustrate the data model structure of Matter devices. Assume that a node represents a car device, which contains one or more endpoints, for example, endpoint 0 and endpoint 5, where the root node device type of the car is stored under endpoint 0, and the air conditioning device type of the car is stored under endpoint 5. Endpoint 5 contains one or more clusters, for example, a temperature control cluster and a fan cluster. Each cluster can contain 0 or more attributes, commands, and events. Taking the temperature control cluster as an example, the attributes contained in the temperature control cluster may include temperature attribute values, etc.; the commands contained may include temperature increase commands and temperature decrease commands; the events contained may include temperature abnormality alarm events, etc.

Communication system based on Matter protocol

The following describes a communication system applicable to an embodiment of the present application in conjunction with FIG2. The communication system shown in FIG2 includes a Matter client device 210, a Matter server device 220, and a configuration device 230. It should be noted that the data model structure of the Matter client device 210 and the Matter server device 220 can be as shown in FIG1.

Matter client device 210 is a client device on the user side, and Matter client device 210 can communicate with Matter server device 220. In some embodiments, Matter client device 210 and Matter server device 220 can be connected in a wired or wireless manner to communicate.

In some implementations, the Matter client device 210 may send control information to the Matter server device 220 to control the Matter server device 220. For example, when the Matter server device 220 is a smart air conditioner, the Matter client device 210 may control the temperature of the Matter server device 220 by sending control information to the Matter server device 220.

In some embodiments, the Matter client device 210 may refer to a terminal device installed with a Matter client, wherein the terminal device may be a mobile phone, a computer, a tablet computer, a personal digital assistant (PDA), a smart bracelet, a smart watch, etc., which is not limited in the embodiments of the present application. It should be understood that the Matter client may be an application (APP) or a mini-program, etc., which is not limited in the embodiments of the present application.

Matter server device 220 may refer to an IoT device that supports the Matter standard protocol. Matter server device 220 may communicate directly with Matter client device 210 so that Matter client device 210 controls Matter server device 220.

For example, when the Matter server device 220 is a smart air conditioner that supports the Matter standard protocol, the Matter client device 210 can control the smart air conditioner's switch and set the air conditioner temperature, wind speed, etc. When the Matter server device 220 is a sweeping robot that supports the Matter standard protocol, the Matter client device 210 can control the sweeping robot to start or stop working, control the sweeping robot's working mode, etc.

At present, the control interfaces supported by the Matter server device 220 mainly include control and subscribe and report. Among them, control can be understood as a group of clusters corresponding to one or more attribute values of the Matter server device that can be modified or retrieved. For example, the Matter client device is a smart speaker, and the Matter server device is a smart air conditioner. The user can say "cool down" to the smart speaker, and then the smart speaker sends a control command to lower the temperature to the smart air conditioner.

The configuration (commissioner) device 230 can be used to configure the Matter server device 220. In other words, the configuration device can be understood as a terminal device with a configuration terminal installed, and the user can configure the Matter server device 120 through the configuration terminal. Among them, the terminal device can be a mobile phone, a computer, a tablet computer, a PDA, a smart bracelet, a smart watch, etc., which is not limited in the embodiments of the present application. In some embodiments, the configuration terminal can be an application or a small program, etc., which is not limited in the embodiments of the present application.

It should be noted that the configuration end may be the same APP or applet as the Matter client, and of course, the configuration end may be a different APP or applet from the Matter client. This embodiment of the application does not limit this.

Descriptor Clusters

A descriptor cluster can be used to describe an endpoint in a node. That is, each endpoint has a descriptor cluster under it to describe its corresponding endpoint. For each descriptor cluster, the elements it includes are only attributes, but no commands and events. Specifically, the attributes included in the descriptor cluster can be seen in Table 1.

Table 1

Among them, F indicates that the field is a fixed value; R indicates read permission; V indicates view permission; and M indicates mandatory.

Specifically, the device type list can give the device type and corresponding version that the endpoint complies with, for example, contained in the DeviceTypeStruct structure. DeviceTypeStruct can contain two contents, one is DeviceTypeId, which can be used to describe the ID value of the device type; the other is Revision, which can be used to indicate the revision number (or version) of the device type. It should be noted that the device type list should contain at least one device type. For example: the extended color lamp device type may support the device type IDs of dimmable lamps and switch lamps because they are subsets of extended color lamps.

The server list may give all cluster IDs with server roles on the endpoint, or in other words, the server list may indicate the list information of the cluster IDs controlled by the current endpoint.

The client list may give all cluster IDs with client roles on the endpoint, or in other words, the client list may indicate the list information of the cluster IDs controlled by the current endpoint.

The parts list can give all the endpoints that make up the device type instance, or the parts list can represent the list information of the endpoint values associated with or contained in the current endpoint. For example, a refrigerator device type can be defined as consisting of multiple temperature sensor endpoints, a metering endpoint, and two thermostat endpoints.

Global properties of the cluster

In addition to the specific attribute definitions of the cluster, each cluster also contains global attributes. The global attributes in the cluster can be used to describe the general or basic information of the cluster. For ease of understanding, the embodiment of the present application provides some global attributes in Table 2 (the number of global attributes provided in Table 2 is 4). The global attributes of the cluster are briefly introduced in conjunction with Table 2.

Table 2

The attribute list can give the information of the attribute list under the cluster. Each cluster instance should support this global attribute. This global attribute can contain all the attribute IDs contained in its corresponding cluster instance.

The event list can give the information of the event list under the cluster. Each cluster instance should support this global attribute. This global attribute can contain all event IDs contained in its corresponding cluster instance.

The request command list can represent the command ID list of the client request command. Each cluster instance should support this global attribute. This global attribute can contain a list of command IDs generated by the client, which are all supported by the cluster service instance.

The response command list can represent the command ID list of the client response commands. Each cluster instance should support this global attribute. This global attribute can contain a list of command IDs generated by the server, which can be used to respond to the client's commands.

It should be noted that the global attributes listed in Table 2 are only examples and do not represent all global attributes. In some embodiments, the global attributes contained in the cluster may also include a cluster version (ClusterRevision), a network identifier (FabricIndex), etc., which is not limited in the embodiments of the present application.

In some scenarios, the client device may perform capability discovery on the server device to discover or obtain the capabilities of the server device, so that the server device may be controlled according to the capabilities possessed by the server device.

In some embodiments, the client device may perform capability discovery of the server device by reading the descriptor clusters of each endpoint contained in the server device and the global attributes of each cluster.

That is to say, if the client device wants to perform capability discovery on the server device, the client device needs to know which endpoints the server device contains, which clusters these endpoints contain, and which elements (for example, attributes, commands, events) are contained under each cluster, so as to determine which capabilities the server device has based on the relevant information of the elements of each cluster obtained.

For ease of understanding, the process of the client device discovering the capabilities of the server device is described below in conjunction with FIG. 3 .

As shown in FIG. 3 , in step 1 , the client device reads the descriptor cluster under endpoint 0 of the server device.

The client device can learn which endpoints (service endpoints) the server device contains by reading the descriptor cluster under endpoint 0 of the server device. This is because the component list contained in the descriptor cluster of each endpoint can contain the endpoint identifiers of all endpoints associated with or contained by the endpoint. In this way, the client device can learn which service endpoints the server device contains through the attribute of the component list in the descriptor cluster under endpoint 0.

In step 2, the server device returns the attribute information of the descriptor cluster under endpoint 0 to the client device.

It should be understood that in step 2, the server device can only return the cluster information under endpoint 0 to the client device. In order to obtain the cluster information under the service endpoint (other endpoints except endpoint 0), the client device also needs to know the endpoint information in the component list under endpoint 0, so as to obtain the cluster information under the service endpoint based on the endpoint information in the component list.

In step 3, the client device reads a descriptor cluster under a service endpoint of the server device.

The client device has learned which service endpoints the server device includes by reading the descriptor cluster under endpoint 0 of the server device. Furthermore, the client device can learn which clusters the service endpoint includes by sending a read request operation to the descriptor cluster of one of the service endpoints.

For example, assuming that after steps 1 and 2, the client device learns that the service endpoints included in the server device are endpoint 1, endpoint 2, and endpoint 3, then in step 3, the client device can send read request operations to endpoint 1, endpoint 2, and endpoint 3 respectively to read the descriptor clusters of endpoint 1, endpoint 2, and endpoint 3.

In step 4, the server device returns information about the descriptor cluster under the service endpoint to the client device.

The client device can learn which clusters the service endpoint contains through the information of the descriptor cluster under the service endpoint. For example, assuming that the client device requests to read the descriptor cluster of endpoint 1, the client device can learn which clusters endpoint 1 contains through step 4. For example, the clusters contained in endpoint 1 are cluster 1, cluster 2 and cluster 6.

In step 5, the client device reads a property list in the global properties under a certain cluster of the server device.

The attribute list may include all attribute IDs included in the corresponding cluster instance. Therefore, by reading the attribute list under each cluster, the client device can learn which attributes each cluster contains, and thus learn the capabilities of the server device.

Taking cluster 6 under endpoint 1 as an example, the client device can read the information of the attribute list in the global attributes under cluster 6, thereby obtaining the attribute ID, command ID and event ID contained in cluster 6, and then obtaining the capabilities of the server device represented by cluster 6.

In step 6, the server device returns information of the attribute list in the global attributes of the cluster to the client device.

It can be seen that if the client device wants to learn all capabilities of the server device, it needs to repeat steps 3 to 6 until all the information in the attribute list in the global attributes under all clusters of the server device is read.

That is to say, the client device needs to perform multiple read request operations (for example, the request operation to read the descriptor cluster of endpoint 0, the request operation to read the cluster ID of each endpoint, and the request operation to read the global attributes of each cluster) to discover all the capabilities of the server device. Using this method to discover the capabilities of the server device makes the interaction process between the client device and the server device complicated and inefficient, which in turn affects the user experience.

As a specific example, assuming that the server device includes three endpoints in addition to endpoint 0, when the client device discovers the capabilities of the server device, it needs to first know the three endpoint values contained in endpoint 0, and then read the descriptor cluster under each endpoint to obtain the corresponding cluster. It is impossible to achieve the purpose of obtaining all the capabilities of the server device with one or a few reads.

In order to solve the above problems, the embodiment of the present application provides a solution for device capability discovery, which can reduce the number of interactions between the client device and the server device during the process of server device capability discovery, improve acquisition efficiency, and thus enhance user experience. The solution provided by the embodiment of the present application is described in detail below in conjunction with the accompanying drawings.

FIG4 is a flow chart of a method for device capability discovery provided by an embodiment of the present application. The method shown in FIG4 is described from the perspective of interaction between a client device and a server device. Exemplarily, the client device and the server device may be, for example, the client device 210 and the server device 220 shown in FIG2 , respectively. The method shown in FIG4 may include step S410, which is described in detail below.

In step S410, the client device sends a first message to the server device.

The first message may be used to query the first cluster. Information about the first cluster may be used by the client device to discover the capability of the server device.

The client device discovering the capabilities of the server device can also be understood as the client device performing capability discovery on the server device. That is, the client device can perform capability discovery on the server device by querying the first cluster to discover or obtain the capabilities of the server device, for example, discovering or obtaining the functional services that the server device can implement. In some embodiments, device capability discovery can also refer to device resource discovery, that is, obtaining the resources of the server device through device capability discovery (by querying the first cluster).

In some embodiments, after the client device discovers the capabilities of the server device, it can control the server device based on the capabilities possessed by the server device.

In the embodiment of the present application, the information of the first cluster may include information of all service endpoints included in the server device, and information of the cluster included in any one of the service endpoints.

As mentioned above, a service endpoint can refer to any endpoint in the server device (or node) except endpoint 0. In other words, a service endpoint can be understood as a general term for other endpoints except endpoint 0, that is, except endpoint 0, any other endpoint can be called a service endpoint. For example, the server device includes endpoint 0 and 3 endpoints except endpoint 0, then these 3 endpoints can be understood as the service endpoints of the server device.

Continuing with the example that the server device includes endpoint 0 and three endpoints other than endpoint 0, the information of the first cluster includes the information of all the service endpoints contained in the server device, which may mean that the information of the first cluster includes the information of these three endpoints; the information of the first cluster includes the information of the cluster contained in any one of all the service endpoints, which may mean that the information of the first cluster includes the information of the cluster contained in each of the three endpoints.

In the embodiment of the present application, the first cluster includes information of all service endpoints included in the server device and information of the clusters included in each service endpoint. Compared with the traditional client device that needs to perform multiple read request operations to obtain the information of the clusters included in each service endpoint, the number of interactions between the client device and the server device can be reduced, the acquisition efficiency can be improved, and the user experience can be improved.

The first cluster is described in more detail below.

In some embodiments, the information of the first cluster including the information of the service endpoints included in the server device may refer to the endpoint identifiers (or endpoint numbers) of the service endpoints included in the server device included in the first cluster, hereinafter referred to as the endpoint identifiers of the service endpoints included in the first cluster. For example, the server device includes 3 endpoints other than endpoint 0, and their corresponding endpoint identifiers are endpoint 1, endpoint 2, and endpoint 3, respectively, then the first cluster may include endpoint identifiers of endpoint 1, endpoint 2, and endpoint 3.

In some embodiments, information about the service endpoints included in the server device may be stored in a certain attribute element of the first cluster, that is, by querying the attribute element of the first cluster, it is possible to know which service endpoints the server device specifically includes.

In some embodiments, in addition to the endpoint identifier of the service endpoint, the first cluster may also include one or more of the following information: the device type corresponding to the service endpoint, and information about other endpoints associated with/included by the service endpoint. In other words, the information of the first cluster may also include: the device type corresponding to all service endpoints included in the server device, and/or information about other endpoints associated with/included by all service endpoints included in the server device.

In some embodiments, the information of other endpoints associated with/included by the service endpoint may refer to the endpoint identifiers of other endpoints associated with/included by the service endpoint. For example, if endpoint 1 of the server device also includes endpoint 4, the information can also be obtained through the first cluster.

In some embodiments, information of other endpoints associated with/included by the service endpoint may be stored in a property element of the first cluster, that is, by querying the property element of the first cluster, the association relationship and/or inclusion relationship between the endpoints included in the server device may be known.

It should be noted that, in some embodiments, when there are nested endpoints (for example, endpoint 1 also includes endpoint 4), the information of endpoint 1 and endpoint 4 can be queried simultaneously through a certain attribute element of the first cluster. In some embodiments, when there are nested endpoints, the information of endpoint 1 and endpoint 4 can be queried together through a combination of attribute elements in the first cluster (for example, through two or more attribute elements).

In some embodiments, the information of the first cluster may also include information of a cluster included in any service endpoint in the server device.

In some embodiments, the information of the first cluster includes the information of the cluster contained in any service endpoint in the server device, which may refer to the first cluster including: the identifier of the cluster contained in the service endpoint in the server device, hereinafter referred to as the identifier of the cluster contained in the service endpoint in the first cluster. In some embodiments, the identifier of the cluster may refer to the cluster ID. For example, endpoint 1 includes cluster 1 and cluster 5, endpoint 2 includes cluster 2 and cluster 4, and endpoint 3 includes cluster 3, then the first cluster may include cluster IDs such as cluster 1, cluster 5, cluster 2, cluster 4 and cluster 3.

In some embodiments, the information of the clusters included in the service endpoint may be stored in a certain attribute element of the first cluster, that is, by querying the attribute element of the first cluster, it is possible to know which clusters the server device specifically includes.

In some embodiments, the first cluster may be a newly defined cluster. For example, a brand new first cluster may be defined under endpoint 0 of the server device for the client device to discover the capabilities of the server device. The present application embodiment does not specifically limit the name of the first cluster. For example, the first cluster may be understood as a resource cluster, a capability cluster, etc. Correspondingly, the first cluster may also be called a resource cluster, a capability cluster, etc.

In some embodiments, the first cluster may be a cluster obtained on the basis of an existing cluster. For example, if a descriptor cluster exists under endpoint 0 of a server device, the descriptor cluster under endpoint 0 may be modified to obtain a first cluster for the client device to discover the capability of the server device. In other words, the embodiment of the present application does not limit the generation or formation method of the first cluster, as long as the first cluster exists on the server device side, it includes the information of all service endpoints contained in the server device and the information of the cluster contained in any service endpoint.

In some embodiments, the first cluster may include a first attribute, the type of the first attribute may be a structure (e.g., a list), and through the first attribute of the first cluster, information of all service endpoints included in the server device and information of the cluster included in any service endpoint may be obtained. The first attribute is introduced below.

In some embodiments, the first attribute may be referred to as an endpoint list (EndpointList) attribute, and the definition of the first attribute may refer to Table 3.

table 3

The type of the first attribute is a structure of list type (for example, it can be called EpStruct). The access data quality of the first attribute includes read permission and view permission, that is, the client device can read or view the first attribute in the first cluster. The consistency of the first attribute is M (mandatory), that is, the first cluster must include the first attribute.

The type of the first attribute is introduced below in conjunction with Table 4. In other words, the structure (EpStruct) definition of the type of the first attribute may be as shown in Table 4.

Table 4

EndpointNo is the corresponding endpoint identifier under each EpStruct.

DeviceTypeList may give the device type and corresponding version that EndpointNo complies with, for example, contained in DeviceTypeStruct.

In some embodiments, DeviceTypeStruct may include two contents, one is DeviceTypeId, which may be used to describe the ID value of the device type; the other is Revision, which may be used to indicate the revision number of the device type.

In some embodiments, the device type corresponding to the service endpoint may further include a first field, which is used to mark the device type corresponding to the service endpoint using one or more labels. That is, DeviceTypeStruct may include content other than DeviceTypeId and Revision, for example, it may further include a first field (which may be called a Label field) to describe the device type through the first field.

In some embodiments, describing the device type through the first field may mean that the first field may be used to distinguish different labels of the same device type. Taking the server device as a car device as an example, for DeviceTypeIds of car windows, the corresponding Labels may be "main driver's window, sunroof, passenger driver's window, etc.", and the same device type can be distinguished through different Labels.

In some embodiments, the type of the first field may be a string type. In some embodiments, the first field may be a read-only type field.

PartsList can give a list of endpoint identifiers associated with or contained in EndpointNo. The content in the list is also EndpointNo, which can be used to reflect the endpoint identifiers nested and contained under EndpointNo.

As an example, assuming that the server device includes three endpoints (endpoint 1, endpoint 2, and endpoint 3) in addition to endpoint 0, the structure of the type of the first attribute (EndpointList) may include four rows (assuming that each row represents an endpoint), each row may include the endpoint identifier corresponding to the row, and the device type list, server cluster list, client cluster list, and component list corresponding to the endpoint identifier. For details about the endpoint identifier, device type list, server cluster list, client cluster list, and component list, please refer to the previous text, which will not be repeated here. The server cluster list corresponds to the server list in the previous text, and the client cluster list corresponds to the client list in the previous text.

In this way, the client device can obtain information about all service endpoints contained in the server device and the identifier of the cluster contained in any service endpoint by reading the first cluster, without the client device initiating a read request operation to each service endpoint to read the identifier of the cluster contained in the service endpoint.

In some embodiments, after the client device obtains the identifier of the cluster included in each service endpoint, it is necessary to further query the global attributes of each cluster to obtain the capability of the server device.

Therefore, in some embodiments, referring to the flowchart of the method for device capability discovery provided in FIG5 , after step S410, the method may further include step S420. In step S420, the client device sends a second message to the server device, and the second message is used to read the attribute list in the global attributes under a cluster of the server device.

As mentioned above, the attribute list in the global attributes under the cluster contains all the attribute IDs contained in the corresponding cluster instance. Therefore, by reading the attribute list under each cluster, the client device can know which attributes each cluster contains, and thus know the capabilities of the server device.

In some embodiments, when the client device sends a second message to the server device to query the global attributes of each cluster, the content of the global attributes can refer to Table 2 above. In Table 2, the command information of the cluster (including request command information and response command information) can be carried using two global attributes, for example, the request command list (AcceptedCommandList) is used to carry the command information of the client request command, and the response command list (GeneratedCommandList) is used to carry the command information of the client response command. In some embodiments, the command information of the cluster can refer to the command ID of the cluster, that is, the command ID of the cluster can be carried using two global attributes.

In some embodiments, the command information of the cluster can be carried using a global attribute. That is, the cluster included in the service endpoint may include a first global attribute, and the command information of the cluster included in the service endpoint (including request command information and response command information) is recorded in the first global attribute. The command information (for example, command ID) of the cluster included in the service endpoint can be recorded in a global attribute because the command ID defined in the cluster is non-repetitive and there is no need to distinguish whether it is a request command ID or a response command ID. Based on this, the global attributes of the cluster can also be expressed in the form of Table 5.

table 5

Compared with Table 2, Table 5 uses only one global attribute to record the command information under the cluster, that is, the command ID contained in the command list in Table 5 includes both the command ID in the request command list and the command ID in the response command list in Table 2. For other details about Table 5, please refer to Table 2 and will not be repeated here.

In some embodiments, to avoid the need for the client device to send the second message to the server device multiple times, the information of the first cluster, in addition to the identifier of the cluster contained in any service endpoint, may also include one or more of the following information: attribute information of the cluster contained in the service endpoint, command information of the cluster contained in the service endpoint, and event information of the cluster contained in the service endpoint.

In some embodiments, the attribute information of the cluster may refer to the attribute ID of the attribute contained in the cluster, the command information of the cluster may refer to the command ID of the command contained in the cluster, and the event information of the cluster may refer to the event ID of the event contained in the cluster.

When the first cluster includes one or more of the cluster's attribute information, command information, and event information, the client device can obtain all capabilities of the server device at one time by querying the first cluster. In other words, the client device can complete the capability discovery of the server device by initiating a read request operation, which greatly reduces the interaction process between the client device and the server device, improves the acquisition efficiency, and thus improves the user experience.

When the first cluster includes one or more of the cluster's attribute information, command information, and event information, the definition of the first attribute can still refer to Table 3, but the definition of the structure (EpStruct) of the type of the first attribute has changed. The definition of the structure (EpStruct) of the type of the first attribute in this case is introduced below in conjunction with Table 6.

Table 6

Compared with Table 4, the content corresponding to the type in the server cluster list is changed from list [ClusterID] to list [ClusterStruct], where list [ClusterID] only contains the cluster ID of the cluster included in the business endpoint, while list [ClusterStruct] is a structure, which includes other content in addition to the cluster ID of the cluster included in the business endpoint. [ClusterStruct] is described in detail below in conjunction with Table 7. It should be noted that other contents not described in detail in Table 6 can be referred to Table 4.

Table 7

For each service endpoint, its corresponding [ClusterStruct] contains the cluster ID of all clusters corresponding to the service endpoint, as well as the attribute list, event list and command list contained in the cluster corresponding to the cluster ID. Therefore, when the attribute information, command information and event information of the cluster contained in each service endpoint are included in the first cluster, the client device can initiate a read request operation to complete the capability discovery of the server device.

In some embodiments, if the first cluster includes command information of the clusters included in each service endpoint, the command information can be recorded using one attribute, or two or more attributes, which is not limited in the embodiments of the present application. For example, in the example of Table 7, the command information is recorded using one attribute (CommandList); in some embodiments, the command information can also be recorded using two attributes (e.g., AcceptedCommandList and GeneratedCommandList).

It can be seen that in the embodiment of the present application, by designing a structure (EpStruct) of the first attribute type in the first cluster, it is possible to define the content of the structure (EpStruct) to achieve the function of obtaining all capabilities of the server device with a few read operations.

In some embodiments, the first cluster may be located in a first endpoint, wherein the device type of the first endpoint is a root node device type. In other words, the first endpoint is endpoint 0, or the first endpoint is a root node endpoint.

Since the server device must include endpoint 0, when the first cluster is defined under endpoint 0 of the server device, the client device can successfully read the information of the first cluster at one time without determining the location of the first cluster in advance, which is conducive to further improving user experience.

However, the embodiments of the present application are not limited to this, or in other words, the embodiments of the present application do not limit the storage location of the first cluster. In some embodiments, the first cluster can also be located in other locations. For example, the first cluster can be stored under other endpoints of the server device; or, the information of the first cluster can be stored in the server of the server device or other storage location, as long as the client device can access the first cluster.

In some embodiments, after the client device discovers the capabilities of the server device, it can control the server device based on the capabilities of the server device. For example, taking the server device as a car device, after the client device discovers the capabilities of the car device, it finds that it can control the car device to open the window, turn on the air conditioner, etc. Based on this, the client device can send a command to the server device, and the command can be used to operate a cluster of server devices (e.g., an application cluster) to control opening the window, turning on the air conditioner, etc.

In order to facilitate understanding of the technical solution of the present application, two specific embodiments are given below. It should be noted that the embodiments are not intended to limit the technical solution of the present application.

Embodiment 1:

In the first embodiment, a first cluster is defined in endpoint 0. The first cluster may be a completely new cluster defined under endpoint 0, or a new cluster may be formed by modifying the descriptor cluster in endpoint 0. The first cluster includes a first attribute. For the content of the first attribute, please refer to the above text (for example, Table 3). For the definition of the structure of the type in the first attribute, please refer to Table 4 above. That is to say, in the first embodiment, the information of the first cluster includes the information of all the service endpoints included in the server device (for example, the endpoint identifiers of all the service endpoints, the device types corresponding to the service endpoints, and the endpoint information of other endpoints included in the service endpoints), as well as the identifier of the cluster included in any one of the service endpoints.

In the first embodiment, the interaction process between the client device and the server device can be seen in Figure 6. Figure 6 is a flow chart of a method for device capability discovery provided by another embodiment of the present application.

As shown in FIG. 6 , in step S610 , the client device reads the first cluster under endpoint 0 of the server device.

In step S620 , the server device returns attribute information of the first cluster under endpoint 0 to the client device.

In step S630, the client device obtains all service endpoints of the server device and the clusters corresponding to the service endpoints.

After the reading operation in step S610 , the client device may learn in step S630 which service endpoints the server device includes and which clusters are included under each service endpoint.

In step S640, the client device reads a property list in the global properties under a certain cluster of the server device.

In step S650, the server device returns information of the attribute list in the global attributes of the cluster to the client device.

After repeating step S640 and step S650, the client device can learn which attributes are included in each cluster, and thus learn the capabilities of the server device.

For example, it is assumed that the server device includes three endpoints (endpoint 1, endpoint 2, and endpoint 3) except endpoint 0, endpoint 1 includes cluster 1 and cluster 5, endpoint 2 includes cluster 2 and cluster 4, and endpoint 3 includes cluster 3. In step S630, the client device can learn that the server device includes the above-mentioned endpoints and clusters. By repeating steps S640 and S650, the global attributes of clusters 1 to 5 can be read respectively, so as to learn the capabilities of the server device.

Embodiment 2:

In the second embodiment, a first cluster is defined in endpoint 0. The first cluster may be a completely new cluster defined under endpoint 0, or a new cluster may be formed by modifying the descriptor cluster in endpoint 0. The first cluster includes a first attribute. For the content of the first attribute, please refer to the above text (for example, Table 3). For the definition of the structure of the type in the first attribute, please refer to Table 6 and Table 7. That is to say, in the second embodiment, the information of the first cluster includes the information of all service endpoints contained in the service-side device (for example, the endpoint identifiers of all service endpoints, the device types corresponding to the service endpoints, and the endpoint information of other endpoints contained in the service endpoints), as well as the identifier of the cluster contained in any service endpoint, the attribute information of the cluster, the event information of the cluster, and the command information of the cluster.

In the second embodiment, the interaction process between the client device and the server device can be seen in Figure 7. Figure 7 is a flow chart of a method for device capability discovery provided by another embodiment of the present application.

As shown in FIG. 7 , in step S710 , the client device reads the first cluster under endpoint 0 of the server device.

In step S720 , the server device returns attribute information of the first cluster under endpoint 0 to the client device.

In step S730, the client device obtains all service endpoints of the server device, the clusters corresponding to the service endpoints, and the corresponding attributes, events and commands under each cluster.

After the reading operation in step S710 , the client device can learn in step S730 which service endpoints the server device includes, which clusters each service endpoint includes, and specifically which attributes, events and commands each cluster includes.

At this point, in step S730, the client device can learn the capabilities of the server device.

For example, it is assumed that the server device includes three endpoints (endpoint 1, endpoint 2, and endpoint 3) in addition to endpoint 0, endpoint 1 includes cluster 1 and cluster 5, endpoint 2 includes cluster 2 and cluster 4, and endpoint 3 includes cluster 3. In step S730, the client device can learn that the server device includes the above-mentioned endpoints, clusters, and the attributes, events, and commands contained in each cluster, thereby learning the capabilities of the server device. In other words, the client device only needs to initiate a read request operation once to obtain all the capabilities of the server device.

The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 7, and the device embodiment of the present application is described in detail below in conjunction with Figures 8 to 10. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so the part not described in detail can refer to the previous method embodiment.

FIG8 is a schematic diagram of the structure of a server device provided in an embodiment of the present application. The server device 800 shown in FIG8 may include a receiving module 810 .

The receiving module 810 can be used to receive a first message sent by a client device, and the first message is used to query a first cluster; wherein the information of the first cluster is used by the client device to discover the capability of the server device, and the information of the first cluster includes: information of all service endpoints contained in the server device; and information of the cluster contained in any one of all the service endpoints.

Optionally, the information of the service endpoint includes an endpoint identifier of the service endpoint.

Optionally, the information of the service endpoint further includes one or more of the following information: a device type corresponding to the service endpoint, and information of other endpoints associated with/included by the service endpoint.

Optionally, the device type corresponding to the service endpoint includes a first field, and the first field is used to mark the device type corresponding to the service endpoint with one or more tags.

Optionally, the information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.

Optionally, the cluster information contained in the service endpoint further includes one or more of the following information: attribute information of the cluster contained in the service endpoint, command information of the cluster contained in the service endpoint, and event information of the cluster contained in the service endpoint.

Optionally, the cluster included in the service endpoint includes a first global attribute, and the command information of the cluster included in the service endpoint includes request command information and response command information for the cluster included in the service endpoint, wherein the request command information and the response command information are both recorded in the first global attribute.

Optionally, the server device includes a first endpoint, a device type of the first endpoint is a root node device type, and the first endpoint includes the first cluster.

Fig. 9 is a schematic diagram of the structure of a client device provided in an embodiment of the present application. The client device 900 shown in Fig. 9 may include a sending module 910.

The sending module 910 can be used to send a first message to the server device, and the first message is used to query the first cluster; wherein the information of the first cluster is used by the client device to discover the capabilities of the server device, and the information of the first cluster includes: information of all service endpoints contained in the server device; and information of the cluster contained in any one of all the service endpoints.

FIG10 is a schematic structural diagram of a communication device according to an embodiment of the present application. The dotted lines in FIG10 indicate that the unit or module is optional. The device 1000 may be used to implement the method described in the above method embodiment. The device 1000 may be a chip, a server device, or a client device.

The device 1000 may include one or more processors 1010. The processor 1010 may support the device 1000 to implement the method described in the method embodiment above. The processor 1010 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

The apparatus 1000 may further include one or more memories 1020. The memory 1020 stores a program, which can be executed by the processor 1010, so that the processor 1010 executes the method described in the above method embodiment. The memory 1020 may be independent of the processor 1010 or integrated in the processor 1010.

The apparatus 1000 may further include a transceiver 1030. The processor 1010 may communicate with other devices or chips through the transceiver 1030. For example, the processor 1010 may transmit and receive data with other devices or chips through the transceiver 1030.

The present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to the server device or client device provided in the present application, and the program enables the computer to execute the method performed by the server device or client device in each embodiment of the present application.

The embodiment of the present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the server device or client device provided in the embodiment of the present application, and the program enables the computer to execute the method performed by the server device or client device in each embodiment of the present application.

The embodiment of the present application also provides a computer program. The computer program can be applied to the server device or client device provided in the embodiment of the present application, and the computer program enables a computer to execute the method executed by the server device or client device in each embodiment of the present application.

It should be understood that the terms "system" and "network" in this application can be used interchangeably. In addition, the terms used in this application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application. The terms "first", "second", "third" and "fourth" in the specification and claims of this application and the accompanying drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions.

In the embodiments of the present application, the "indication" mentioned can be a direct indication, an indirect indication, or an indication of an association relationship. For example, A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, B can be obtained through C; it can also mean that there is an association relationship between A and B.

In the embodiment of the present application, "B corresponding to A" means that B is associated with A, and B can be determined according to A. However, it should be understood that determining B according to A does not mean determining B only according to A, and B can also be determined according to A and/or other information.

In the embodiments of the present application, the term "corresponding" may indicate that there is a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship of indication and being indicated, configuration and being configured, etc.

In the embodiments of the present application, "pre-definition" or "pre-configuration" can be implemented by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in a device (for example, including a server device and a client device), and the present application does not limit the specific implementation method. For example, pre-definition can refer to what is defined in the protocol.

In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communication field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

In the embodiments of the present application, the term "and/or" is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and/or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character "/" in this article generally indicates that the associated objects before and after are in an "or" relationship.

In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

A method for device capability discovery, comprising:

The server device receives a first message sent by the client device, where the first message is used to query the first cluster;

The information of the first cluster is used by the client device to discover the capability of the server device, and the information of the first cluster includes:

Information about all service endpoints contained in the server device; and

The cluster information contained in any one of all the service endpoints.
The method according to claim 1 is characterized in that the information of the service endpoint includes an endpoint identifier of the service endpoint.
The method according to claim 2, wherein the information of the service endpoint further includes one or more of the following information:

The device type corresponding to the service endpoint, and

Information about other endpoints associated with/included by the business endpoint.
The method according to claim 3 is characterized in that the device type corresponding to the service endpoint includes a first field, and the first field is used to use one or more tags to mark the device type corresponding to the service endpoint.
The method according to any one of claims 1-4 is characterized in that the information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.
The method according to claim 5, characterized in that the cluster information contained in the service endpoint further includes one or more of the following information:

The service endpoint contains the attribute information of the cluster,

The service endpoint contains the cluster command information, and

The service endpoint includes event information of the cluster.
The method according to any one of claims 1-6 is characterized in that the cluster included in the business endpoint includes a first global attribute, and the command information of the cluster included in the business endpoint includes request command information and response command information for the cluster included in the business endpoint, wherein the request command information and the response command information are both recorded in the first global attribute.
The method according to any one of claims 1-7 is characterized in that the server-side device includes a first endpoint, a device type of the first endpoint is a root node device type, and the first endpoint includes the first cluster.
A method for device capability discovery, comprising:

The client device sends a first message to the server device, where the first message is used to query the first cluster;

The information of the first cluster is used by the client device to discover the capability of the server device, and the information of the first cluster includes:

Information about all service endpoints contained in the server device; and

The cluster information contained in any one of all the service endpoints.
The method according to claim 9 is characterized in that the information of the service endpoint includes an endpoint identifier of the service endpoint.
The method according to claim 10, characterized in that the information of the service endpoint further includes one or more of the following information:

The device type corresponding to the service endpoint, and

Information about other endpoints associated with/included by the business endpoint.
The method according to claim 11 is characterized in that the device type corresponding to the service endpoint includes a first field, and the first field is used to use one or more tags to mark the device type corresponding to the service endpoint.
The method according to any one of claims 9 to 12, characterized in that the information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.
The method according to claim 13, characterized in that the cluster information contained in the service endpoint further includes one or more of the following information:

The service endpoint contains the attribute information of the cluster,

The service endpoint contains the cluster command information, and

The service endpoint includes event information of the cluster.
The method according to any one of claims 9-14 is characterized in that the cluster included in the business endpoint includes a first global attribute, and the command information of the cluster included in the business endpoint includes request command information and response command information for the cluster included in the business endpoint, wherein the request command information and the response command information are both recorded in the first global attribute.
The method according to any one of claims 9-15 is characterized in that the server-side device includes a first endpoint, the device type of the first endpoint is a root node device type, and the first endpoint includes the first cluster.
A server device, characterized by comprising:

A receiving module, configured to receive a first message sent by a client device, wherein the first message is used to query a first cluster;

The information of the first cluster is used by the client device to discover the capability of the server device, and the information of the first cluster includes:

Information about all service endpoints contained in the server device; and

The cluster information contained in any one of all the service endpoints.
The server device according to claim 17 is characterized in that the information of the service endpoint includes an endpoint identifier of the service endpoint.
The server device according to claim 18, wherein the information of the service endpoint further includes one or more of the following information:

The device type corresponding to the service endpoint, and

Information about other endpoints associated with/included by the business endpoint.
The server device according to claim 19 is characterized in that the device type corresponding to the service endpoint includes a first field, and the first field is used to use one or more tags to mark the device type corresponding to the service endpoint.
The server device according to any one of claims 17-20 is characterized in that the information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.
The server device according to claim 21, wherein the cluster information contained in the service endpoint further includes one or more of the following information:

The service endpoint contains the attribute information of the cluster,

The service endpoint contains the cluster command information, and

The service endpoint includes event information of the cluster.
The server device according to any one of claims 17-22 is characterized in that the cluster included in the business endpoint includes a first global attribute, and the command information of the cluster included in the business endpoint includes request command information and response command information for the cluster included in the business endpoint, wherein the request command information and the response command information are both recorded in the first global attribute.
The server device according to any one of claims 17-23 is characterized in that the server device includes a first endpoint, a device type of the first endpoint is a root node device type, and the first endpoint includes the first cluster.
A client device, comprising:

A sending module, configured to send a first message to a server device, wherein the first message is used to query a first cluster;

The information of the first cluster is used by the client device to discover the capability of the server device, and the information of the first cluster includes:

Information about all service endpoints contained in the server device; and

The cluster information contained in any one of all the service endpoints.
The client device according to claim 25 is characterized in that the information of the service endpoint includes an endpoint identifier of the service endpoint.
The client device according to claim 26, wherein the information of the service endpoint further includes one or more of the following information:

The device type corresponding to the service endpoint, and

Information about other endpoints associated with/included by the business endpoint.
The client device according to claim 27 is characterized in that the device type corresponding to the service endpoint includes a first field, and the first field is used to use one or more tags to mark the device type corresponding to the service endpoint.
The client device according to any one of claims 25-28 is characterized in that the information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.
The client device according to claim 29, wherein the cluster information included in the service endpoint further includes one or more of the following information:

The service endpoint contains the attribute information of the cluster,

The service endpoint contains the cluster command information, and

The service endpoint includes event information of the cluster.
The client device according to any one of claims 25-30 is characterized in that the cluster included in the service endpoint includes a first global attribute, and the command information of the cluster included in the service endpoint includes request command information and response command information for the cluster included in the service endpoint, wherein the request command information and the response command information are both recorded in the first global attribute.
The client device according to any one of claims 25-31 is characterized in that the server device includes a first endpoint, the device type of the first endpoint is a root node device type, and the first endpoint includes the first cluster.
A server device, characterized in that it includes a memory and a processor, the memory is used to store programs, and the processor is used to call the programs in the memory so that the server device executes the method as described in any one of claims 1-8.
A client device, characterized in that it includes a memory and a processor, the memory is used to store programs, and the processor is used to call the programs in the memory so that the client device executes the method as described in any one of claims 9-16.
A device, characterized in that it comprises a processor, which is used to call a program from a memory so that the device executes the method as described in any one of claims 1-16.
A chip, characterized in that it comprises a processor for calling a program from a memory so that a device equipped with the chip executes a method as described in any one of claims 1 to 16.
A computer-readable storage medium, characterized in that a program is stored thereon, wherein the program enables a computer to execute the method according to any one of claims 1 to 16.
A computer program product, characterized in that it comprises a program, wherein the program enables a computer to execute the method according to any one of claims 1 to 16.
A computer program, characterized in that the computer program enables a computer to execute the method according to any one of claims 1 to 16.