Method for device capability discovery, server device and client device

Abstract

The invention provides a method for device capability discovery, server-side equipment and client-side equipment. The method comprises the following steps: a server device receives a first message sent by a client device, wherein the first message is used for querying a first cluster; wherein the information of the first cluster is used for the client device to discover the capability of the server device, and the information of the first cluster comprises information of all service endpoints contained in the server device; and the cluster information contained in any service endpoint in all the service endpoints is obtained. In the embodiment of the invention, the first cluster comprises information of all service endpoints contained in the server equipment and information of clusters contained in each service endpoint. Compared with the traditional client equipment which needs to execute multiple reading request operations to obtain the cluster information contained in each service endpoint, the method and the device have the advantages that the times of interaction between the client equipment and the server equipment can be reduced, the obtaining efficiency is improved, and the user experience is further improved.

Description

Method, server device, and client device for device capability discovery Technical Field

[0001] The present application relates to the field of Internet of Things technology, and more specifically, to a method for device capability discovery, a server device, and a client device. Background Art

[0002] In some scenarios, client devices need to discover the capabilities of server devices in order to control them based on their capabilities. In related technologies, client devices must perform multiple read requests to discover all the capabilities of a server device. This approach to server capability discovery complicates and inefficiencies the interaction between client and server devices, impacting the user experience.

[0003] Summary of the Invention

[0004] The present application provides a method for device capability discovery, a server device, and a client device. The following introduces various aspects of the present application.

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

[0006] In a second aspect, a method for device capability discovery is provided, including: 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 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 a cluster contained in any one of all the service endpoints.

[0007] According to a third aspect, a server device is provided, comprising: a receiving module for receiving a first message sent by a client device, wherein 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 included in the server device; and information of a cluster included in any one of the service endpoints.

[0008] In a fourth aspect, a client device is provided, including: a sending module for sending 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 all the service endpoints.

[0009] In the 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.

[0010] 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.

[0011] 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 in the embodiment of the present application.

[0012] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, which 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.

[0013] In a ninth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a server device or a client device to perform some or all of the steps of the methods described in each of the above aspects. In some implementations, the computer program product may be a software installation package.

[0014] 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.

[0015] In this embodiment of the present application, the first cluster includes information about all service endpoints included in the server device, as well as information about the clusters included in each service endpoint. Compared to traditional client devices that require multiple read requests to obtain information about the clusters included in each service endpoint, this can reduce the number of interactions between the client device and the server device, improve acquisition efficiency, and thus enhance the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] 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.

[0018] FIG3 is a flow chart of a conventional method for device capability discovery.

[0019] FIG4 is a flow chart of a method for device capability discovery provided in an embodiment of the present application.

[0020] FIG5 is a flowchart of a method for device capability discovery provided in another embodiment of the present application.

[0021] FIG6 is a flowchart of a method for device capability discovery provided in yet another embodiment of the present application.

[0022] FIG7 is a flowchart of a method for device capability discovery provided in yet another embodiment of the present application.

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

[0024] FIG9 is a schematic diagram of the structure of a client device provided in an embodiment of the present application.

[0025] FIG10 is a schematic structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0027] 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 this application.

[0028] The Internet of Things (IoT), or "Internet of Everything," is an extension and expansion of the Internet. Through various information sensing devices (such as radio frequency identification and global positioning systems), any object can be connected to the Internet to form a vast network for information exchange and communication, enabling interconnection and interoperability between all things. In some embodiments, IoT devices can be smart home devices, such as smart air conditioners, smart refrigerators, washing machines, rice cookers, and robot vacuums. In some embodiments, IoT devices can be smart monitoring devices, such as surveillance cameras, temperature sensors, and sound sensors.

[0029] At present, different manufacturers may use different communication protocols (also known as ecological chain protocols) to achieve interoperability between IoT devices that support the communication protocols. This may result in the inability of IoT devices produced by different manufacturers to communicate with each other, and the failure to achieve true interconnection of all things.

[0030] Based on this, the Connectivity Standards Alliance (CSA) has launched an IoT application layer technology standard - the 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 enable IoT devices with different protocols to communicate with each other.

[0031] Data model of Matter device

[0032] 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 .

[0033] Node 110 encapsulates a unique, addressable resource on the network, possessing a set of functions and capabilities that users can clearly perceive as a functional entity. Typically, node 110 can be the highest or outermost first-order element in a data model. In other words, node 110 is the only addressable element at the outermost level of a data model. Therefore, a node can represent a device node and belong to a logical device.

[0034] A physical entity (e.g., a Matter device) can be a node 110, or in other words, a node 110 can refer to a Matter device node. It should be noted that a node can 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 the target address for an interaction, the network scoped to the specified node ID is the access network for the interaction.

[0035] A node may include one or more endpoints 120. An endpoint 120 is an instance, which can 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 can be understood as a service instance / virtual device indicated by a device type. A cluster is an object class instantiated on an endpoint.

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

[0037] In some embodiments, endpoints can be divided into two categories: endpoint 0 and service endpoints. Endpoint 0 can be understood as the first endpoint in a node, and its device type is the "root node" device type. In some embodiments, endpoint 0 can also be referred to as the root node endpoint. Every node must contain endpoint 0. A service endpoint can be understood as any endpoint in a node other than endpoint 0. A service endpoint can support the primary operations of the node. For example, a service endpoint can include one or more application clusters.

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

[0039] 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 (client) and a server (server) that correspond to each other through interaction. In other words, cluster 130 can include two roles, namely client and server, where the client belongs to the control end and the server belongs to the controlled end. Cluster 130 can be regarded as an interface, service or object class, which is the lowest independent functional element in the data model.

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

[0041] The utility cluster is not part of the primary 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.

[0042] An application cluster supports the primary operations of an endpoint. In some embodiments, an application cluster can also be referred to as a service cluster. An application cluster can support the interaction of one or more persistent applications between a client and a server. For example, in a smart light, a client can send control commands to a server (i.e., the switch cluster) to turn the smart light on or off.

[0043] 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.

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

[0045] Typically, each cluster 130 can be defined by a cluster specification that defines the elements of cluster 130, including attributes, events, commands, and behaviors associated with interactions with these elements. In some embodiments, attributes, commands, and events can also be referred to as interface units of cluster 130, and corresponding functions can be provided through these three interface units.

[0046] In some embodiments, properties, events, commands, and behaviors in a cluster 130 are mandatory or optional, depending on the definition of the cluster 130 .

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

[0048] 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 attribute 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 the device. In some cases, if no privileges are explicitly defined for an attribute, the default access privilege takes effect.

[0049] Cluster commands (also called "commands") can be used to describe the control of a cluster. A cluster can contain zero 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.

[0050] An event can be used to describe a record of a specific past behavior of a cluster, or in other words, an event defines a record of something that 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 a stream of event records. A cluster can contain zero or more events. Unlike attributes, which do not provide any edge-preserving functionality (that is, there is no guarantee that every attribute change will be transmitted to the observer), events allow each individual edge or change to be captured and reliably transmitted to the observer. This is critical for safety and security applications that rely on guaranteed correct behavior. Currently, the protocol stipulates that each cluster event can be listed in a table, and the data quality columns defined in this table may include: ID, priority, access, and compliance.

[0051] For ease of understanding, the following describes the meanings of several common data qualities included in commands, attributes, and events. It should be noted that the commands, attributes, and events in the embodiments of this application may also include other data qualities, or include some of the above data qualities. This embodiment of the application is not limited to this.

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

[0053] Name: The unique name of the field, or the name of the command (or attribute).

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

[0055] Direction, usually present in a 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. Another example is from the server to the client.

[0056] Access rights 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 rights may include V, which indicates that read access or call access requires the view privilege. Access rights may also include O, which indicates that "read access," "write access," or "call access" requires the operation privilege. Access rights may also include R, which indicates read access. Access rights may also include W, which indicates write access.

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

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

[0059] Default is used to define a default value. It should be noted that the default value is not the value used when the server returns the factory refresh settings. Default values ​​can indicate that the compliance specified for a data field is optional or can change over time. Default values ​​can be defined to fulfill dependencies when the actual data field value does not exist.

[0060] 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.

[0061] 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 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.

[0062] Constraints include "all" and "desc." "all" in a numeric data type indicates that all values ​​are allowed. "desc" indicates that the constraint is defined in the description section.

[0063] Range indicates the value range of the 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 the 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 may 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.

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

[0065] To facilitate 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. 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 zero 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, commands may include temperature increase commands, temperature decrease commands, and events may include temperature abnormality alarm events.

[0066] Communication system based on Matter protocol

[0067] The following describes a communication system applicable to an embodiment of the present application in conjunction with Figure 2. The communication system shown in Figure 2 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 Figure 1.

[0068] 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 to each other via a wired or wireless connection for communication.

[0069] 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.

[0070] In some embodiments, the Matter client device 210 may refer to a terminal device on which a Matter client is installed, 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.

[0071] 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 can control Matter server device 220.

[0072] 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 power on and off, and set the temperature, wind speed, etc. When the Matter server device 220 is a robot vacuum that supports the Matter standard protocol, the Matter client device 210 can control the robot vacuum to start or stop working, control the robot vacuum's operating mode, etc.

[0073] Currently, the control interfaces supported by the Matter server device 220 mainly include control and subscription and reporting. Among them, control can be understood as a set 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.

[0074] 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 installed with a configuration terminal, through which the user can configure the Matter server device 120. Among them, the terminal device can be a mobile phone, computer, tablet computer, PDA, smart bracelet, smart watch, etc., which is not limited in the embodiment 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 embodiment of the present application.

[0075] It should be noted that the configuration terminal can be the same APP or mini-program as the Matter client. Of course, the configuration terminal can be a different APP or mini-program from the Matter client. This embodiment of the application is not limited to this.

[0076] Descriptor Clusters

[0077] A descriptor cluster is used to describe an endpoint within a node. Each endpoint has a descriptor cluster that describes its corresponding endpoint. Each descriptor cluster contains only attributes, not commands or events. For details, see Table 1 for the attributes contained within a descriptor cluster.

[0078] Table 1

[0079]

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

[0081] 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 represent 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.

[0082] The server list may provide 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.

[0083] The client list may provide 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.

[0084] A parts list can list all the endpoints that make up a device type instance, or it can list the endpoint values ​​associated with or contained by 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.

[0085] Global properties of the cluster

[0086] In addition to the specific attribute definitions for each cluster, each cluster also contains global attributes. Global attributes in a cluster can be used to describe general or basic information about the cluster. For ease of understanding, the present embodiment provides some global attributes in Table 2 (the number of global attributes provided in Table 2 is 4). The following is a brief introduction to the global attributes of a cluster in conjunction with Table 2.

[0087] Table 2

[0088]

[0089]

[0090] The attribute list provides information about the attribute list of the cluster. Every cluster instance should support this global attribute. This global attribute can contain all attribute IDs contained in the corresponding cluster instance.

[0091] The event list provides information about the event list in the cluster. Every cluster instance should support this global attribute. This global attribute can contain all event IDs contained in the corresponding cluster instance.

[0092] The request command list can represent the command ID list of the client request command. Every cluster instance should support this global property. This global property can contain a list of command IDs generated by the client that are supported by the cluster service instance.

[0093] The response command list can represent a list of command IDs for commands that respond to the client. Every cluster instance should support this global property. This global property can contain a list of command IDs generated by the server that can be used to respond to client commands.

[0094] 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 included in the cluster may also include cluster version (ClusterRevision), network identifier (FabricIndex), etc., which is not limited in this embodiment of the present application.

[0095] In some scenarios, a client device may perform capability discovery on a server device to discover or obtain the capabilities of the server device, thereby controlling the server device based on the capabilities of the server device.

[0096] 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.

[0097] 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 obtained about the elements of each cluster.

[0098] For ease of understanding, the process of a client device discovering capabilities of a server device is described below with reference to FIG3 .

[0099] As shown in FIG3 , in step 1 , the client device reads the descriptor cluster under endpoint 0 of the server device.

[0100] 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 include the endpoint identifiers of all endpoints associated with or contained by that endpoint. In this way, the client device can learn which service endpoints the server device contains by using the component list attribute in the descriptor cluster under Endpoint 0.

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

[0102] 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.

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

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

[0105] 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.

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

[0107] The client device can learn which clusters the service endpoint contains by using the descriptor cluster information 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.

[0108] In step 5, the client device reads the attribute list in the global attributes under a cluster of the server device.

[0109] The attribute list can contain 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.

[0110] 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.

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

[0112] It can be seen that if the client device wants to learn all the 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.

[0113] In other words, the client device needs to perform multiple read requests (for example, a request to read the descriptor cluster of endpoint 0, a request to read the cluster IDs of each endpoint, and a request to read the global properties 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 and server device complex and inefficient, which in turn affects the user experience.

[0114] 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 in one or a few reads.

[0115] To address the above issues, the present invention provides a solution for device capability discovery that can reduce the number of interactions between client and server devices during server-side device capability discovery, improve acquisition efficiency, and thus enhance user experience. The solution provided by the present invention is described in detail below with reference to the accompanying drawings.

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

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

[0118] 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 capabilities of the server device.

[0119] 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 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 (using the method of querying the first cluster).

[0120] 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.

[0121] 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.

[0122] As mentioned above, a service endpoint can refer to any endpoint in a server device (or node) except endpoint 0. Alternatively, a service endpoint can be understood as a collective term for all endpoints other than endpoint 0. That is, any endpoint other than endpoint 0 can be considered a service endpoint. For example, if a server device includes endpoint 0 and three other endpoints, then all three endpoints can be considered service endpoints of the server device.

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

[0124] In this embodiment of the present application, the first cluster includes information about all service endpoints included in the server device, as well as information about the clusters included in each service endpoint. Compared to traditional client devices that require multiple read requests to obtain information about the clusters included in each service endpoint, this reduces the number of interactions between the client device and the server device, improves acquisition efficiency, and thus enhances the user experience.

[0125] The first cluster is described in more detail below.

[0126] 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, if the server device includes three endpoints other than endpoint 0, and their corresponding endpoint identifiers are endpoint 1, endpoint 2, and endpoint 3, then the first cluster may include the endpoint identifiers of endpoint 1, endpoint 2, and endpoint 3.

[0127] 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.

[0128] In some embodiments, in addition to the endpoint identifiers of the service endpoints, 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 or included in the service endpoint. In other words, the information in the first cluster may also include: the device types corresponding to all service endpoints included in the server device, and / or information about other endpoints associated with or included in all service endpoints included in the server device.

[0129] In some embodiments, the information of other endpoints associated with / included by the service endpoint may refer to 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.

[0130] In some embodiments, information about other endpoints associated with / included by a 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 and / or inclusion relationship between the endpoints included in the server device may be known.

[0131] 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).

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

[0133] In some embodiments, the information of the first cluster including the information of the clusters included in any service endpoint in the server device may refer to the first cluster including: the identifiers of the clusters included in the service endpoint in the server device, hereinafter referred to as the identifiers of the clusters included in the service endpoint in the first cluster. In some embodiments, the cluster identifiers may refer to cluster IDs. For example, if 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.

[0134] 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.

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

[0136] In some embodiments, the first cluster can be a cluster derived from an existing cluster. For example, if a descriptor cluster exists under endpoint 0 of a server device, the descriptor cluster under endpoint 0 can be modified to generate a first cluster for the client device to discover the server device's capabilities. In other words, the embodiments of the present application do not limit the method for generating or forming the first cluster; as long as the first cluster exists on the server device, it can include information about all service endpoints included in the server device and information about clusters included in any service endpoint.

[0137] In some embodiments, the first cluster may include a first attribute, which may be a structure (e.g., a list). Information about all service endpoints included in the server device and information about the clusters included in any service endpoint may be obtained through the first attribute of the first cluster. The first attribute is described below.

[0138] In some embodiments, the first attribute may be referred to as an endpoint list (EndpointList) attribute. The definition of the first attribute may be found in Table 3.

[0139] Table 3

[0140]

[0141] The type of the first attribute is a list-type structure (e.g., EpStruct). The access data quality of the first attribute includes read permission and view permission, which means that the client device can read or view the first attribute in the first cluster. The consistency of the first attribute is M (mandatory), which means that the first attribute must be included in the first cluster.

[0142] 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 can be as shown in Table 4.

[0143] Table 4

[0144]

[0145] EndpointNo is the corresponding endpoint identifier under each EpStruct.

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

[0147] In some embodiments, DeviceTypeStruct may include two contents: DeviceTypeId, which may be used to describe the ID value of the device type; and Revision, which may be used to indicate the revision number of the device type.

[0148] In some embodiments, the device type corresponding to a service endpoint may further include a first field, which is used to identify the device type corresponding to the service endpoint using one or more labels. That is, DeviceTypeStruct may include content in addition to DeviceTypeId and Revision. For example, it may further include a first field (which may be called a Label field) to describe the device type.

[0149] In some embodiments, describing the device type using the first field can mean that the first field can be used to distinguish different labels for the same device type. For example, if the server device is a car device, for DeviceTypeIds that are all car windows, the corresponding Labels might be "driver's window, sunroof, passenger window, etc." Different Labels can be used to distinguish the same device type.

[0150] 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.

[0151] 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.

[0152] As an example, assuming that the server device contains three endpoints (Endpoint 1, Endpoint 2, and Endpoint 3) in addition to Endpoint 0, the structure of the type of the first attribute (EndpointList) can contain four rows (assuming that each row represents an endpoint), each row can contain the endpoint identifier corresponding to the row, as well as 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 and will not be repeated here. The server cluster list corresponds to the server list mentioned above, and the client cluster list corresponds to the client list mentioned above.

[0153] 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.

[0154] 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 capabilities of the server device.

[0155] 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, where the second message is used to read an attribute list in the global attributes under a cluster of the server device.

[0156] As mentioned above, the attribute list in the global attributes under the cluster contains all the attribute IDs contained in its 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.

[0157] 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 be found in Table 2 above. In Table 2, the cluster's command information (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's request command, and the response command list (GeneratedCommandList) is used to carry the command information of the client's response command. In some embodiments, the cluster's command information can refer to the cluster's command ID, that is, the cluster's command ID can be carried using two global attributes.

[0158] 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 of the cluster included in the service endpoint (for example, command ID) 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.

[0159] Table 5

[0160]

[0161] Compared to Table 2, Table 5 uses only one global attribute to record cluster command information. That is, the command IDs contained in the command list in Table 5 include both the command IDs in the request command list and the command IDs 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.

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

[0163] In some embodiments, the attribute information of a cluster may refer to the attribute IDs of the attributes included in the cluster, the command information of a cluster may refer to the command IDs of the commands included in the cluster, and the event information of a cluster may refer to the event IDs of the events included in the cluster.

[0164] When the first cluster includes one or more of cluster attribute information, command information, and event information, the client device can obtain all capabilities of the server device at once by querying the first cluster. In other words, the client device can complete the capability discovery of the server device with a single read request, significantly reducing the interaction between the client and server devices, improving acquisition efficiency, and ultimately enhancing the user experience.

[0165] When the first cluster includes one or more of cluster attribute information, command information, and event information, the definition of the first attribute remains the same as in Table 3. However, the definition of the structure (EpStruct) of the first attribute type has changed. The following describes the definition of the structure (EpStruct) of the first attribute type in this case, in conjunction with Table 6.

[0166] Table 6

[0167]

[0168] Compared to Table 4, the content corresponding to the type in the server-side cluster list has changed from the list [ClusterID] to the list [ClusterStruct]. The list [ClusterID] contains only the cluster IDs of the clusters included in the service endpoint, while the list [ClusterStruct] is a structure that contains the cluster IDs of the clusters included in the service endpoint as well as other content. The following describes [ClusterStruct] in detail in conjunction with Table 7. It should be noted that for any content not described in detail in Table 6, refer to Table 4.

[0169] Table 7

[0170]

[0171] For each service endpoint, its corresponding [ClusterStruct] contains the cluster IDs 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 first cluster includes the attribute information, command information, and event information of the cluster contained in each service endpoint, the client device can initiate a read request operation to complete the capability discovery of the server device.

[0172] In some embodiments, if the first cluster includes command information for 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 this embodiment 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).

[0173] It can be seen that in the embodiment of the present application, by designing a structure (EpStruct) of the first attribute 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.

[0174] 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 in other words, the first endpoint is a root node endpoint.

[0175] 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 having to determine the location of the first cluster in advance, which is conducive to further improving user experience.

[0176] 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 on the server of the server device or in other storage locations, as long as the client device can access the first cluster.

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

[0178] To facilitate understanding of the technical solution of the present application, two specific embodiments are given below. It should be noted that these embodiments are not intended to limit the technical solution of the present application.

[0179] Example 1:

[0180] In the first embodiment, a first cluster is defined in endpoint 0. The first cluster can be a completely new cluster defined under endpoint 0, or a new cluster 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). The definition of the structure of the type in the first attribute can be referred to the above text Table 4. That is to say, in the first embodiment, the information of the first cluster includes the information of all the service endpoints contained in the server device (for example, the endpoint identifiers of all the service endpoints, the device type corresponding to the service endpoint, and the endpoint information of other endpoints contained in the service endpoint), as well as the identifier of the cluster contained in any one of the service endpoints.

[0181] 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.

[0182] As shown in FIG6 , in step S610 , the client device reads the first cluster under endpoint 0 of the server device.

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

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

[0185] 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.

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

[0187] In step S650 , the server device returns information of a property list in the global properties of the cluster to the client device.

[0188] 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.

[0189] For example, assume 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 S630, the client device can learn that the server device includes these endpoints and clusters. By repeating steps S640 and S650, the global attributes of Clusters 1 through 5 can be read, respectively, to learn the capabilities of the server device.

[0190] Example 2:

[0191] In the second embodiment, a first cluster is defined in endpoint 0. The first cluster can be a completely new cluster defined under endpoint 0, or a new cluster can 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). The definition of the structure of the type in the first attribute can be referred to Table 6 and Table 7 above. That is to say, in the second embodiment, the information of the first cluster includes the information of all the service endpoints contained 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 contained in the service endpoints), as well as the identifier of the cluster contained in any one of the service endpoints, the attribute information of the cluster, the event information of the cluster, and the command information of the cluster.

[0192] 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.

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

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

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

[0196] 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.

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

[0198] For example, assume 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 aforementioned endpoints and clusters, as well as 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 single read request operation to obtain the full capabilities of the server device.

[0199] The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 7 . 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. Therefore, for parts not described in detail, reference can be made to the above method embodiment.

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

[0201] 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 ability 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.

[0202] Optionally, the information of the service endpoint includes an endpoint identifier of the service endpoint.

[0203] 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.

[0204] 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 using one or more tags.

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

[0206] 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.

[0207] 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.

[0208] 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.

[0209] FIG9 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 FIG9 may include a sending module 910.

[0210] 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 ability 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.

[0211] Optionally, the information of the service endpoint includes an endpoint identifier of the service endpoint.

[0212] 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.

[0213] 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 using one or more tags.

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

[0215] 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.

[0216] 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.

[0217] 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.

[0218] Figure 10 is a schematic block diagram of a communication device according to an embodiment of the present application. The dashed lines in Figure 10 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.

[0219] 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 be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0220] The apparatus 1000 may further include one or more memories 1020. The memories 1020 store programs that can be executed by the processor 1010, causing the processor 1010 to perform the methods described in the above method embodiments. The memories 1020 may be independent of the processor 1010 or integrated into the processor 1010.

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

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

[0223] 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 present application, and the program causes a computer to execute the method performed by the server device or client device in each embodiment of the present application.

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

[0225] 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 this application and are not intended to limit this 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," as well as any variations thereof, are intended to cover non-exclusive inclusions.

[0226] In the embodiments of this application, the term "indication" may refer to a direct indication, an indirect indication, or an indication of an association. For example, "A indicates B" may refer to a direct indication of B, e.g., B can obtain information through A; it may refer to an indirect indication of B, e.g., A indicates C, e.g., B can obtain information through C; or it may refer to an association between A and B.

[0227] In the embodiment of the present application, "B corresponding to A" means that B is associated with A and B can be determined based on A. However, it should be understood that determining B based on A does not mean determining B based solely on A, but B can also be determined based on A and / or other information.

[0228] In the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and indication, configuration and configuration, etc.

[0229] 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 devices (for example, including server devices and client devices). The present application does not limit the specific implementation method. For example, pre-definition can refer to what is defined in the protocol.

[0230] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communications 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.

[0231] In the embodiments of this application, the term "and / or" is simply a description of the association relationship between related objects, indicating that three relationships can exist. 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 document generally indicates that the related objects are in an "or" relationship.

[0232] 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.

[0233] In the several embodiments provided in this 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 merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, 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.

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

[0235] 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.

[0236] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using 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 one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. 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 therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0237] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for device capability discovery, characterized in that: include: 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.

2. The method according to claim 1, characterized in that The information of the service endpoint includes the endpoint identifier of the service endpoint.

3. The method according to claim 2, characterized in that The service endpoint information also 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.

4. The method according to claim 3, characterized in that 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 using one or more tags.

5. The method according to any one of claims 1 to 4, characterized in that The information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.

6. The method according to claim 5, characterized in that The cluster information included in the service endpoint also includes one or more of the following information: The business endpoint contains the attribute information of the cluster, The service endpoint contains the cluster command information, and The service endpoint contains the event information of the cluster.

7. The method according to any one of claims 1 to 6, 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.

8. The method according to any one of claims 1 to 7, 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.

9. A method for device capability discovery, characterized in that: include: 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.

10. The method according to claim 9, characterized in that The information of the service endpoint includes the endpoint identifier of the service endpoint.

11. The method according to claim 10, characterized in that The service endpoint information also 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.

12. The method according to claim 11, characterized in that 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 using one or more tags.

13. 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.

14. The method according to claim 13, characterized in that The cluster information included in the service endpoint also includes one or more of the following information: The business endpoint contains the attribute information of the cluster, The service endpoint contains the cluster command information, and The service endpoint contains the event information of the cluster.

15. The method according to any one of claims 9 to 14, 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.

16. The method according to any one of claims 9 to 15, 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.

17. A server device, characterized in that: include: A receiving module, configured to receive a first message sent by a client device, where 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.

18. The server device according to claim 17, wherein: The information of the service endpoint includes the endpoint identifier of the service endpoint.

19. The server device according to claim 18, characterized in that: The service endpoint information also 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.

20. The server device according to claim 19, wherein: 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 using one or more tags.

21. The server device according to any one of claims 17 to 20, characterized in that: The information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.

22. The server device according to claim 21, characterized in that: The cluster information included in the service endpoint also includes one or more of the following information: The business endpoint contains the attribute information of the cluster, The service endpoint contains the cluster command information, and The service endpoint contains the event information of the cluster.

23. The server device according to any one of claims 17 to 22, 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.

24. The server device according to any one of claims 17 to 23, 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.

25. A client device, characterized in that: include: A sending module, configured to send a first message to a server device, where 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.

26. The client device according to claim 25, wherein: The information of the service endpoint includes the endpoint identifier of the service endpoint.

27. The client device according to claim 26, wherein: The service endpoint information also 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.

28. The client device according to claim 27, wherein: 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 using one or more tags.

29. The client device according to any one of claims 25 to 28, wherein: The information of the cluster included in the service endpoint includes an identifier of the cluster included in the service endpoint.

30. The client device according to claim 29, wherein: The cluster information included in the service endpoint also includes one or more of the following information: The business endpoint contains the attribute information of the cluster, The service endpoint contains the cluster command information, and The service endpoint contains the event information of the cluster.

31. The client device according to any one of claims 25 to 30, 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.

32. The client device according to any one of claims 25 to 31, 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.

33. A server device, characterized in that: The server comprises a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory so that the server device executes the method according to any one of claims 1 to 8.

34. A client device, characterized in that The method comprises a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory so that the client device executes the method according to any one of claims 9 to 16.

35. A device, characterized in that The device comprises a processor configured to call a program from a memory so as to enable the device to execute the method according to any one of claims 1 to 16.

36. A chip, characterized in that: The device comprises a processor configured to call a program from a memory so that a device equipped with the chip executes the method according to any one of claims 1 to 16.

37. A computer-readable storage medium, characterized in that A program is stored thereon, and the program causes a computer to execute the method according to any one of claims 1 to 16.

38. A computer program product, characterized in that The method comprises a program for causing a computer to execute the method according to any one of claims 1 to 16.

39. 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.

Images